1. дома
  2. Вопрос и ответ
  3. Пинг-ответ показывает, что он отличается от другого адреса mac

Пинг-ответ показывает, что он отличается от другого адреса mac

2016-08-12 4 views
0

У меня возникло такое странное явление о пинге.Пинг-ответ показывает, что он отличается от другого адреса mac

Установка является:

  • Unit A: Операционная система Windows

    • Virtio adapter1 с IP 1.2.3.4 и MAC a.b.c.d.e.f
    • Virtio adapter2 с IP 5.6.7.8 и MAC g.h.i.j.k.l

  • Unit B: Red Hat OS

    • IP 2.4.6.8 и MAC m.n.o.p.q.r

Внутри терминала Red Hat OS, мы свистеть IP-адрес адаптера Virtio.

Я не могу понять, почему:

  1. дубликат пинг ответы происходит, либо в качестве альтернативы или каждые 2 других запросов Пинга.
  2. Я выполнил трассировку при выполнении пинга, и заметно, что MAC-адрес ответа НЕ, что MAC-адрес запрашиваемого IP-адреса.

При запуске ping 1.2.3.4:

PING REQ m.n.o.p.q.r > a.b.c.d.e.f :: 2.4.6.8 > 1.2.3.4 
PING RES g.h.i.j.k.l > m.n.o.p.q :: 1.2.3.4 > 2.4.6.8 
PING RES g.h.i.j.k.l > m.n.o.p.q :: 1.2.3.4 > 2.4.6.8 DUP!

Я сделал arp -an и записи таблицы ARP были правильными в соответствии с указанным IP-к-MAC отношения ...

Что может вызвать такие вхождение? Будет ли это некорректная конфигурация сети между двумя подразделениями?

Редактировать

Вот точные подробности моей настройки сети ... модифицировали MAC-адресов; префиксы «m.n.o» представляют сходства, которые я видел при выполнении команд в единицах.

Unit B детали, где мы выполняем запрос ping.

ifconfig -a:

ctrl: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450 
    inet 10.0.2.100 netmask 255.255.255.0 broadcast 0.0.0.0 
    inet6 fe80::f427:50ff:fe58:b132 prefixlen 64 scopeid 0x20<link> 
    ether **aa:bb:cc:ee:dd:ee** txqueuelen 1000 (Ethernet) 

ctrlpub0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 
    inet 10.40.90.151 netmask 255.255.255.224 broadcast 0.0.0.0 
    inet6 fe80::f816:3eff:fe71:6754 prefixlen 64 scopeid 0x20<link> 
    ether **m.n.o.71.67.54** txqueuelen 1000 (Ethernet) 

ctrlpub1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 
    inet 10.40.90.183 netmask 255.255.255.224 broadcast 0.0.0.0 
    inet6 fe80::f816:3eff:fe52:a3d4 prefixlen 64 scopeid 0x20<link> 
    ether **m:n:o:52:ad:34** txqueuelen 1000 (Ethernet) 

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 
    inet 127.0.0.1 netmask 255.0.0.0 
    inet6 ::1 prefixlen 128 scopeid 0x10<host> 

oam: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450 
    inet 10.0.0.105 netmask 255.255.255.0 broadcast 0.0.0.0 
    inet6 fe80::641d:cfff:feac:1129 prefixlen 64 scopeid 0x20<link> 
    ether **aa.bb.cc.dd.ee.ff** txqueuelen 1000 (Ethernet)

arp -an:

? (10.40.90.131) at **m.n.o.p.q.r** [ether] on ctrlpub0 <--- so this is the one that we ping to... 
? (10.0.0.3) at X:X:X:X:X:X [ether] on oam 
? (10.0.2.102) at X:X:X:X:X:X [ether] on ctrl 
? (10.0.2.101) at X:X:X:X:X:X [ether] on ctrl 
? (10.40.90.158) at **g.h.i.j.k.l** [ether] on ctrlpub0 <--- but this is the mac address in the reply, and yes it is not starting with the m.n.o. prefix ... 
? (10.0.0.11) at X:X:X:X:X:X [ether] on oam 
? (10.0.2.90) at X:X:X:X:X:X [ether] on ctrl 
? (10.0.0.100) at X:X:X:X:X:X [ether] on oam 
? (10.0.0.1) at X:X:X:X:X:X [ether] on oam 
? (10.0.2.103) at X:X:X:X:X:X [ether] on ctrl

В ОС Windows, Unit A:

PWindows IP Configuration 

    Host Name . . . . . . . . . . . . . . . . : GEN162401 
    Primary Dns Suffix . . . . . . . . . . . : 
    Node Type . . . . . . . . . . . . . . . . : Hybrid 
    IP Routing Enabled . . . . . . . . . . . : No 
    WINS Proxy Enabled . . . . . . . . . . . : No 

Ethernet Adapter EXT-CP2-EL5: 

    Connection-specific DNS Suffix . . . . . : 
    Description . . . . . . . . . . . . . . . : Red Hat VirtIO Ethernet Adapter #5 
    Physical Address . . . . . . . . . . . . : m:n:o:D5:5d:FC 
    DHCP Enabled . . . . . . . . . . . . . . : No 
    Autoconfiguration Enabled . . . . . . . . : Yes 
    IPv4 Address . . . . . . . . . . . . . . : 10.40.90.163(Preferred) 
    Subnet Mask . . . . . . . . . . . . . . . : 255.255.255.224 
    Default Gateway . . . . . . . . . . . . . : 
    NetBIOS over Tcpip . . . . . . . . . . . : Enabled 

Ethernet Adapter EXT-CP1-EL4: 

    Connection-specific DNS Suffix . . . . . : 
    Description . . . . . . . . . . . . . . . : Red Hat VirtIO Ethernet Adapter #4 
    Physical Address . . . . . . . . . . . . : **m:n:o:p:q:r** <---- **this is the one we are pinging to** 
    DHCP Enabled . . . . . . . . . . . . . . : No 
    Autoconfiguration Enabled . . . . . . . . : Yes 
    IPv4 Address . . . . . . . . . . . . . . : 10.40.90.131(Preferred) 
    Subnet Mask . . . . . . . . . . . . . . . : 255.255.255.224 
    Default Gateway . . . . . . . . . . . . . : 
    NetBIOS over Tcpip . . . . . . . . . . . : Enabled 

Ethernet Adapter OnM: 

    Connection-specific DNS Suffix . . . . . : 
    Description . . . . . . . . . . . . . . . : Red Hat VirtIO Ethernet Adapter 
    Physical Address . . . . . . . . . . . . : m:n:o:78:55:AA 
    DHCP Enabled . . . . . . . . . . . . . . : No 
    Autoconfiguration Enabled . . . . . . . . : Yes 
    Link-local IPv6 Address . . . . . . . . . : fe80:f0c1:45d2:5417:a8c3%5(Preferred) 
    IPv4 Address . . . . . . . . . . . . . . : 172.24.17.100(Preferred) 
    Subnet Mask . . . . . . . . . . . . . . . : 255.255.255.0 
    Default Gateway . . . . . . . . . . . . . : 172.24.17.1 
    DNS Servers . . . . . . . . . . . . . . : fec0:0:0:ffff:1%1 
               fec0:0:0:ffff:2%1 
               fec0:0:0:ffff:3%1 
    NetBIOS over Tcpip . . . . . . . . . . . : Enabled

делает ping 10.40.90.131 выходы:

12:39:13.896547 **m.n.o.71.67.54** > **m:n:o:p:q:r**, ethertype IPv4 (0x0800), length 98: 10.40.90.151 > 10.40.90.131: ICMP echo request, id 843, seq 1, length 64 
    12:39:13.897344 **g.h.i.j.k.l** > **m.n.o.71.67.54**, ethertype IPv4 (0x0800), length 98: 10.40.90.131 > 10.40.90.151: ICMP echo reply, id 843, seq 1, length 64 
    12:39:14.897181 **m.n.o.71.67.54** > **m:n:o:p:q:r**, ethertype IPv4 (0x0800), length 98: 10.40.90.151 > 10.40.90.131: ICMP echo request, id 843, seq 2, length 64 
    12:39:14.897500 **g.h.i.j.k.l** > **m.n.o.71.67.54**, ethertype IPv4 (0x0800), length 98: 10.40.90.131 > 10.40.90.151: ICMP echo reply, id 843, seq 2, length 64 
    12:39:15.897284 **m.n.o.71.67.54** > **m:n:o:p:q:r**, ethertype IPv4 (0x0800), length 98: 10.40.90.151 > 10.40.90.131: ICMP echo request, id 843, seq 3, length 64 
    12:39:15.897633 **g.h.i.j.k.l** > **m.n.o.71.67.54**, ethertype IPv4 (0x0800), length 98: 10.40.90.131 > 10.40.90.151: ICMP echo reply, id 843, seq 3, length 64 
    12:39:16.897243 **m.n.o.71.67.54** > **m:n:o:p:q:r**, ethertype IPv4 (0x0800), length 98: 10.40.90.151 > 10.40.90.131: ICMP echo request, id 843, seq 4, length 64 
    12:39:16.897483 **g.h.i.j.k.l** > **m.n.o.71.67.54**, ethertype IPv4 (0x0800), length 98: 10.40.90.131 > 10.40.90.151: ICMP echo reply, id 843, seq 4, length 64 
    12:39:17.260557 **g.h.i.j.k.l** > **m.n.o.71.67.54**, ethertype IPv4 (0x0800), length 98: 10.40.90.131 > 10.40.90.151: ICMP echo reply, id 843, seq 4, length 64

источник

2016-08-12 mashiro

+0

Каковы сетевые маски ваших интерфейсов? Если у вас несколько адресов с разными адресами в одной сети, [поведение исходящих пакетов в ОС, таких как Windows или Linux, не определено] (http://wiki.treck.com/Appendix_C%3a_Strong_End_System_Model_/_Weak_End_System_Model) (и это поведение можно ожидать, потому что пакеты всегда будут проходить через один и тот же интерфейс). – pistache

+0

Если оба адаптера VirtIO находятся в одной сети, 'Unit A' может использовать любой из них для отправки ответного пакета. Нет требования, чтобы он отправлял от адаптера с IP-адресом, который вы пинговали. – Barmar

+0

@Barmar спасибо за информацию. Сохраняется ли это, если адаптеры находятся только в одном устройстве? – mashiro

ответ

0

В вашем примере IP-адреса подразумевают, что устройства не находятся в одной подсети. Если устройства не находятся в одной подсети, они будут связываться через свои шлюзы по умолчанию.

Пакеты, которые проходят через маршрутизаторы/шлюзы по умолчанию, будут разделены и перестроены. Вызывая макрос src, который вы считаете маком устройства пересылки маршрутизатора/L3, последний прошедший IP-пакет.

Также вы видите повторяющиеся ответы, так что возможно также, что у вас есть 2 устройства в одной сети (широковещательный домен) с дублированной конфигурацией IP-адреса.

источник

2016-08-13 22:13:28 Jolly

+0

Спасибо за ответ! Хм, это было то, о чем я сначала думал о том, что юниты не находятся в одной подсети, но я не уверен, что после того, как я сделал traceddump. он показывает, что Unit B> Unit A (10.40.90.151> 10.40.90.131) Я отредактировал сообщение с более подробной информацией. Но должно быть что-то, что я действительно неправильно сконфигурировал. – mashiro

0

Похоже, что 10.10.90.158 присвоен на том же хосте (на другом интерфейсе), что и 10.40.90.131. Однако я не могу найти этот адрес в конфигурации, которую вы вставляли.

Если это так, поскольку эти интерфейсы находятся в одной сети, хост абсолютно не может сказать, какой из них следует использовать при отправке пакета из-за последствий «слабого сетевого сетевого стека», , Из-за этого пакет выходит на другой интерфейс, даже если бы вы ожидали, что он выйдет на том же интерфейсе, что и он.

Вы не можете назначить несколько адресов на перекрывающихся сетях на нескольких интерфейсах на таких систем (Windows, Mac OS, Linux, ничего особенного).

EDIT: Проще говоря, вы уверены, что у вас нет дополнительных адресов на EXT-CP1-EL4?

источник

2016-08-14 18:04:46 pistache

+0

есть. Я сделал ipconfig/all, и он показал только то, что я вставил. Ваше понимание об этом - promisin ;! Я попытаюсь посмотреть, есть ли способ увидеть «кто» это 10.40.90.158 Также я пробовал пинговать другой интерфейс virtio, и дубликат также встречается и с «двойным» IP-адресом MAC ... почти такая же природа, как и с 10.40.90.131 – mashiro

+0

Последние два пакета в вашем дампе имеют один и тот же порядковый номер ICMP и MAC-адрес источника. Я не понимаю, почему это произойдет, если у вас нет проблемы Layer1 или MAC. (Кроме того, дублированный пакет появился намного позже (350 мс), что странно. Может быть, в вашей сети есть прокси-серверы ARP, сидящие в ~ 175 мс?). Как вы захватили трафик (только ICMP? Можно было бы куда-нибудь отправить дамп 'pcap'?) – pistache

+0

Да, это действительно странно. В любом случае, вот что я захватил на машине-инициаторе ping. Для этого я сначала очистил таблицу arp этого устройства, чтобы он начал чист. https://www.cloudshark.org/captures/1e8dbc95f7bb – mashiro

0

12: 39: 16,897483 GHIJKL>mno71.67.54, Ethertype IPv4 (0x0800), длина 98: 10.40.90.131> 10.40.90.151: эхо-ответ, ID 843, сл 4, длина 64 12: 39: 17,260557 GHIJKL>mno71.67.54, Ethertype IPv4 (0x0800), длина 98: 10.40.90.131> 10.40.90.151: эхо-ответ, ID 843, сл 4, длина 64

В ваш обновленный вариант показывает два пакета, которые вы упоминаете, исходящие из одного и того же src ip и того же src mac. Пакеты могут дублироваться путем переполнения коммутаторов/мостов на пути между двумя хостами. У вас есть виртуальный мост ethernet (brctl) или реальные переключатели на пути между хостами? Могут ли они формировать петлю?

источник

2016-08-15 19:47:49 Jolly

 Смежные вопросы

  • Нет связанных вопросов^_^