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

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

Да не уходит

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?

20:01:32.579550 ARP, Request who-has 192.168.198.100 tell 192.168.198.75, length 28

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

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

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

Верно ARP ответов нет!, поэтому ICMP echo request и не формируется?

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

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

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

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

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

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

vlan какой-нибудь?

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

А dlink случайно не твой?

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

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

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

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

«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 туннель?

А dlink случайно не твой?

Мой «Телефон D-Link»

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

На том конце просто коммутатор и устройства ждут по DHCP адреса себе.

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

Тогда другой вопрос - а ты уверен, что 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

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

Т.е. 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

Достучались

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

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

Да!

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

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

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

arping 192.168.198.140
ARPING 192.168.198.140

Нет

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

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

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

tcpdump -ni _lo_

Эммм… а нафига?

так ты «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

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

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

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

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

ответы самому себе не выходят за пределы хоста, т.е. передаются через интерфейс lo

т.е. все формируется

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

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

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

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

[удаленный_коммутатор_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 сразу за его портом.

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