LINUX.ORG.RU
решено ФорумAdmin

Не формируются ICMP echo request

 ,


0

2

Все выполняю на маршрутизаторе.
Есть интерфейс eth5

ifconfig eth5
eth5      Link encap:Ethernet  HWaddr 52:54:00:4f:f8:06  
          inet addr:192.168.198.75  Bcast:192.168.198.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe4f:f806/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:191508 errors:0 dropped:2 overruns:0 frame:0
          TX packets:29514 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:22648809 (21.5 MiB)  TX bytes:6457700 (6.1 MiB)
делаю пинг 192.168.198.100
ping 192.168.198.100
PING 192.168.198.100 (192.168.198.100) 56(84) bytes of data.
From 192.168.198.75 icmp_seq=2 Destination Host Unreachable
From 192.168.198.75 icmp_seq=3 Destination Host Unreachable
From 192.168.198.75 icmp_seq=4 Destination Host Unreachable
From 192.168.198.75 icmp_seq=5 Destination Host Unreachable
From 192.168.198.75 icmp_seq=6 Destination Host Unreachable
From 192.168.198.75 icmp_seq=7 Destination Host Unreachable
From 192.168.198.75 icmp_seq=8 Destination Host Unreachable
From 192.168.198.75 icmp_seq=9 Destination Host Unreachable
From 192.168.198.75 icmp_seq=10 Destination Host Unreachable
в это время tcpdump -i eth5 не показывает ICMP echo request
 tcpdump -i eth5 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth5, link-type EN10MB (Ethernet), capture size 65535 bytes

только ARP

tcpdump -i eth5
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth5, link-type EN10MB (Ethernet), capture size 65535 bytes
20:01:30.579432 ARP, Request who-has 192.168.198.100 tell 192.168.198.75, length 28
20:01:31.442363 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 2316.00:1e:f7:f6:1f:40.820c, length 42
20:01:31.579597 ARP, Request who-has 192.168.198.100 tell 192.168.198.75, length 28
20:01:32.579550 ARP, Request who-has 192.168.198.100 tell 192.168.198.75, length 28
20:01:33.446187 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 2316.00:1e:f7:f6:1f:40.820c, length 42
20:01:33.579624 ARP, Request who-has 192.168.198.100 tell 192.168.198.75, length 28
20:01:33.942374 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from b0:c5:54:80:0a:5a (oui Unknown), length 548
20:01:33.942591 IP 192.168.198.75.bootps > 192.168.198.140.bootpc: BOOTP/DHCP, Reply, length 300
20:01:34.579468 ARP, Request who-has 192.168.198.100 tell 192.168.198.75, length 28
20:01:35.494885 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 2316.00:1e:f7:f6:1f:40.820c, length 42
20:01:35.579484 ARP, Request who-has 192.168.198.100 tell 192.168.198.75, length 28
20:01:35.942307 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from b0:c5:54:80:0a:5a (oui Unknown), length 548
20:01:35.942780 IP 192.168.198.75.bootps > 192.168.198.140.bootpc: BOOTP/DHCP, Reply, length 300
^C
Ума не приложу почему не формируются ICMP echo request?

★★★★★

Покажи вывод ip route, у тебя скорее всего ответ уходит через другой интерфейс.

AnDoR ★★★★★ ()
Ответ на: комментарий от AnDoR

Да не уходит

ping 192.168.198.100
PING 192.168.198.100 (192.168.198.100) 56(84) bytes of data.
From 192.168.198.75 icmp_seq=1 Destination Host Unreachable
From 192.168.198.75 icmp_seq=2 Destination Host Unreachable
From 192.168.198.75 icmp_seq=3 Destination Host Unreachable

tcpdump dst 192.168.198.100
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

ip route
default via 111.111.111.111 dev eth1 
111.111.0.0/24 dev eth1  proto kernel  scope link  src 111.111.111.111 
172.16.200.0/24 via 172.16.200.2 dev tun0 
172.16.200.2 dev tun0  proto kernel  scope link  src 172.16.200.1 
192.168.1.0/24 dev eth2  proto kernel  scope link  src 192.168.1.25 
192.168.198.0/24 dev eth5  proto kernel  scope link  src 192.168.198.75 
192.168.199.0/24 dev eth3  proto kernel  scope link  src 192.168.199.75 
192.168.200.0/24 dev eth0  proto kernel  scope link  src 192.168.200.75 
192.168.206.0/24 via 192.168.206.75 dev tap0 
192.168.206.75 dev tap0  scope link 

Даже если уходит, разве я не должен увидеть ICMP echo request?

petav ★★★★★ ()
Последнее исправление: petav (всего исправлений: 1)
20:01:32.579550 ARP, Request who-has 192.168.198.100 tell 192.168.198.75, length 28

Что здесь непонятно? :) Адресация в пределах сети идёт не по IP, а по MAC. MAC неизвестен, пинг слать некому

router ★★★★★ ()

Может я туплю, но в последнем дампе не вижу ARP ответов. Пингуемый комп в той-же подсети что и роутер, значит роутер должен отправлять IP пакеты сразу целевому хосту по L2 (а не отправлять пакет другому роутеру, что-бы тот разбирался), но он не может получить L2 адрес пингуемого хоста, а значит не может составить L2 пакет в который нужно засунуть соответствующий IP пакет.

MrClon ★★★★★ ()
Ответ на: комментарий от petav

разве я не должен увидеть ICMP echo request?

Ещё раз, в пределах сети адресация идёт по MAC адресу. MAC адреса ты не знаешь. Письмо отправишь «на деревню дедушке»?

router ★★★★★ ()
Ответ на: комментарий от petav

Ну а как он сформируется-то, если ведро не знает что писать в поле DST MAC (или как-там его) ethernet-фрэйма?

Нет, я всё понимаю. Пятница, день тяжёлый, зимний авитаминоз…

MrClon ★★★★★ ()
Ответ на: комментарий от router

Понял, дополняя тему. Приобрели туннель у провайдера между двумя географически распределенными зданиями и вот эта ситуация. Эскалирую проблему ему.

petav ★★★★★ ()
Ответ на: комментарий от MrClon

Да, подозревая ответы, я хотел убедиться. Спасибо!

petav ★★★★★ ()
Ответ на: комментарий от MrClon

У меня порт провайдера через локальный vlan заведен на маршрутизатор. Я вижу в eth5 как удаленная, моя, железка долбиться с ARP, Request who-has

petav ★★★★★ ()
Последнее исправление: petav (всего исправлений: 1)
Ответ на: комментарий от petav

А в этот vlan больше ничего не воткнуто? В дампе какой-то DHCP трафик засветился. Что вообще слышно из порта провайдера? Может на том конце просто IP другой, или ещё что-то.

MrClon ★★★★★ ()
Ответ на: комментарий от petav

Я вижу в eth5 как удаленная, моя, железка долбиться с ARP, Request who-has

Наоборот. Это с твоего eth5 уходят ARP запросы

router ★★★★★ ()
Ответ на: комментарий от petav

«RFC 1812, pages 80 and 82:

The ICMP Destination Unreachable message is sent by a router in response to a packet which it cannot forward because the destination (or next hop) is unreachable or a service is unavailable. Examples of such cases include a message addressed to a host which is not there and therefore does not respond to ARP requests, and messages addressed to network prefixes for which the router has no valid route.»

Вы уверены, что провайдер дал вам именно L2 туннель?

rubic ()
Ответ на: комментарий от petav

Тогда может проблема у тебя с vlan'ом, а не у провайдера с каналом

router ★★★★★ ()
Ответ на: комментарий от petav

Т.е. DHCP запрос пришёл через канал? Тогда другой вопрос - а ты уверен, что 192.168.198.100 физически включен и знает, что это его адрес?

router ★★★★★ ()
Ответ на: комментарий от router
Feb 13 20:42:39 router dhcpd: DHCPDISCOVER from b0:c5:54:80:0a:5a via eth5
Feb 13 20:42:39 router dhcpd: DHCPOFFER on 192.168.198.140 to b0:c5:54:80:0a:5a via eth5
petav ★★★★★ ()
Ответ на: комментарий от router

Тогда другой вопрос - а ты уверен, что 192.168.198.100 физически включен и знает, что это его адрес?

Такого адреса сейчас нет, но аналогичная ситуация с существующим удаленным адресом 192.168.198.76, который принадлежит коммутатору.

ping 192.168.198.76
PING 192.168.198.76 (192.168.198.76) 56(84) bytes of data.
From 192.168.198.75 icmp_seq=1 Destination Host Unreachable
From 192.168.198.75 icmp_seq=2 Destination Host Unreachable
From 192.168.198.75 icmp_seq=3 Destination Host Unreachable
From 192.168.198.75 icmp_seq=4 Destination Host Unreachable
From 192.168.198.75 icmp_seq=5 Destination Host Unreachable
From 192.168.198.75 icmp_seq=6 Destination Host Unreachable

tcpdump dst 192.168.198.76
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

petav ★★★★★ ()
Ответ на: комментарий от petav

До твоего DHCP они, я так понимаю, ещё не достучались?
Что слышно на том порте в который воткнуты шнурок от провайдера? Раз оно в vlan зарулено, значит на твоей стороне управляемый свич и можно посмотреть что там приходит из провайдерского штурка. Если ничего — озадачь провайдера, может у него что-то не то.

MrClon ★★★★★ ()
Ответ на: комментарий от router

Т.е. DHCP запрос пришёл через канал?

Да и мой DHCP выдал ему адрес, повторюсь:

Feb 13 20:42:39 router dhcpd: DHCPDISCOVER from b0:c5:54:80:0a:5a via eth5
Feb 13 20:42:39 router dhcpd: DHCPOFFER on 192.168.198.140 to b0:c5:54:80:0a:5a via eth5

petav ★★★★★ ()
Ответ на: комментарий от petav

b0:c5:54:80:0a:5a точно живёт по ту сторону канала, а не про эту? По эту сторону канала что-то кроме твоего роутера до того линка доступ имеет? 192.168.198.140 с роутера пинжится, а если arping-ом?

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

b0:c5:54:80:0a:5a точно живёт по ту сторону канала, а не про эту?

Да!

По эту сторону канала что-то кроме твоего роутера до того линка доступ имеет?

коммутаторы, bridge

192.168.198.140 с роутера пинжится, а если arping-ом?

arping 192.168.198.140
ARPING 192.168.198.140

Нет

petav ★★★★★ ()
Последнее исправление: petav (всего исправлений: 1)
Ответ на: комментарий от petav

Правильно я понимаю что Feb 13 20:42:39 по времени сервера это сегодня, 16:42 по мск (кстати когда Калуга успела переехать на дальний восток :)?
Т.е. в 16:42 связь была, а в 17:04 уже нет? На своей стороне в это время какие-то настройки менял? Думаю надо напхать провайдеру, пусть глянет что там с его стороны видно.

Запусти в отдельном терминале пинг этого 192.168.198.140, посмотри может связь будет появляться и исчезать.

MrClon ★★★★★ ()
Ответ на: комментарий от vel

так ты «tcpdump -ni lo» запусти

так ты «tcpdump -ni lo» запусти
tcpdump -ni lo
1:12:37.415481 IP 192.168.198.75 > 192.168.198.75: ICMP host 192.168.198.76 unreachable, length 92
21:12:37.415500 IP 192.168.198.75 > 192.168.198.75: ICMP host 192.168.198.76 unreachable, length 92
21:12:37.415509 IP 192.168.198.75 > 192.168.198.75: ICMP host 192.168.198.76 unreachable, length 92
petav ★★★★★ ()
Ответ на: комментарий от MrClon

Правильно я понимаю что Feb 13 20:42:39 по времени сервера это сегодня, 16:42 по мск (кстати когда Калуга успела переехать на дальний восток :)?

Да заметил. Создал инцидент по этой проблеме.

Т.е. в 16:42 связь была, а в 17:04 уже нет? На своей стороне в это время какие-то настройки менял? Думаю надо напхать провайдеру, пусть глянет что там с его стороны видно.

Связи не было ни когда, кроме запросов DHCP. Написал.

petav ★★★★★ ()
Ответ на: комментарий от vel

т.е. ICMP echo request всё-таки формируется, но ядро не сумев запаковать его в ethernet-фрэйм само отправляет ICMP echo response? Занятно

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

реквест сформирован программой ping, но в сеть не отправляется, т.к. его некому посылать - нет адреса получателя. Посылающая сторона уведомляется, что хост недоступен. Ответ идет через lo и естественно не виден в eth5.

запустив «tcpdump -ni any icmp» можно пронаблюдать весь процесс.

vel ★★★★★ ()

Провел диагностические исследования. Схеме подключения такая

[удаленный_коммутатор_192.168.198.76] <-> Провайдер <-> [локальный_коммутатор2] <-> [локальный_коммутатор1] <-> [локальный_коммутатор3] <-> [bridge_host] <-> [eth5_192.168.198.75]

Так вот, на локальном объекте я воткнулся вместо провайдера (прикинулся провайдером), ноутбуком с адресом 192.168.198.76 и пинговал 192.168.198.75 - Работает. Делаю вывод, что мои железки не причем.

Далее, втыкаюсь в провайдера ноутбуком с адресом 192.168.198.75 и пингую ту сторону 192.168.198.76 - Работает. Делаю вывод...

Что что-то с ARP... Скорее всего провайдер думает, что eth5 сразу за его портом.

petav ★★★★★ ()
Ответ на: комментарий от petav

Причина выяснена, провайдер разрешал на порту только 5 MAC адресов, а в нашей реальности их более 5. Поэтому таблица ARP не строилась. Решение выделение для наших нужд целого VLAN ID от провайдера...

petav ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.