GD Star Rating
loading...
loading...
товарищи, подскажите куда рыть:
Сервер на Centos 5.7 Внезапно до одного ip (из внешней сети) пропадает маршрут, ну то есть вообще все пропадает. icmp через tcpdump не ловится. В iptables айпишник никак не фигурирует, то сеть даже отрубаешь iptables и cfs+lfd всякие -результат один:
traceroute to 178.49.155.x (178.49.155.x), 30 hops max, 40 byte packets
1 host (91.x.92.67) 3005.290 ms!H 3005.281 ms!H 3005.278 ms!H
При всем при этом до всей подсети (местный провайдер) – трассировка идет, кроме этого “хорошего” айпишника.
Куда копать?
что показывает вывод команды ip r?
Таблицу роутинга виртуальных интерфесов, ну там их много – подсеть /22
: гм, да, теперь мы оба знаем, что показывает эта команда. но наверное я спросил конкретику, чтобы мы вместе поискали, каким путём должен уйти пакет на этот адрес?
Stephan-V: default via 91.226.92.1 dev eth0.4
91.226.92.0/22 dev eth0.4 proto kernel scope link src 91.226.92.67
91.226.92.0/22 dev eth0 proto kernel scope link src 91.226.92.70
91.226.92.5 dev eth0 scope link src 91.226.92.5
91.226.92.6 dev eth0 scope link src 91.226.92.6
Ну и так далее, то есть дальше однотипные записи как последние две из одной подсети.
: arping на этот адрес проходит? может так быть, что ARP-запросы попадают не в тот вилан?
Stephan-V: arping не проходит, но там собственно и ping не проходит. arp запросы все идут в один vlan Смущает в первую очередь следующее что до других ip из dest подсети маршруты есть:
(не работает)
traceroute -I 178.49.155.118
traceroute to 178.49.155.118 (178.49.155.118), 30 hops max, 40 byte packets
1 s5.sibhoster.ru (91.226.92.67) 3007.620 ms!H 3007.631 ms!H 3007.637 ms!H
(работает)
traceroute -I 178.49.155.117
traceroute to 178.49.155.117 (178.49.155.117), 30 hops max, 40 byte packets
1 gw.sibhoster.ru (91.226.92.1) 0.089 ms 0.068 ms 0.066 ms
2 87.226.224.49 (87.226.224.49) 0.269 ms 0.279 ms 0.285 ms
3 nsk01.transtelecom.net (217.150.59.206) 147.322 ms 147.369 ms 147.433 ms
4 217.150.42.122 (217.150.42.122) 53.536 ms 53.540 ms 53.533 ms^C
traceroute -I 178.49.155.119
traceroute to 178.49.155.119 (178.49.155.119), 30 hops max, 40 byte packets
1 gw.sibhoster.ru (91.226.92.1) 0.234 ms 0.208 ms 0.202 ms
2 87.226.224.49 (87.226.224.49) 0.340 ms 0.351 ms 0.355 ms
3 nsk01.transtelecom.net (217.150.59.206) 0.838 ms 0.907 ms 1.014 ms
4 217.150.42.122 (217.150.42.122) 0.806 ms 0.874 ms 0.963 ms
Перед сервером стоит шлюз, со шлюза все идет нормально, то есть проблемы на иском сервере. Со стороны клиента трассировка говорит, что не может найти этот сервер.
:
ты как арпинг делаешь? arping -Iинтерфейс ип_адрес? и нет ответов?
значит у тебя порт свитча как-то волшебно настроен, потому что арпинг вообще не смотрит на таблицу маршрутов, он тупо пакеты ARP рассылает куда сказано и для кого сказано. посмотри ещё с той стороны, слышны ли эти арп-запросы. но я ставлю на криво настроенный порт
Stephan-V: Тут другое, этот ip, как и другие из этой подсети – не пингуются (провайдер клиента закрывает). Возможно здесь у меня пробел, но он и с рабочей машины у меня не отдает arping. На сервере, например такой вывод:
arping -I eth0 178.49.155.118
ARPING 178.49.155.118 from 91.226.92.70 eth0
: а, так они у вас не в одной подсети. а на каком интерфейсе сидит адрес 91.226.92.70? не получается ли так, что у вас SRC-ip подставляется 91.226.92.70, а уходит всё через дефолтный гейт на другом интерфейсе?
Stephan-V: Так в том и прикол, что пробую менять src адрес, девайс, все без толку. И в тоже время до соседних апишников 178.49.155.119 и 178.49.155.117 (например) маршрут находится. И смущает, что я никак не могу отловить с помощью tcpdump icmp запросы, когда пытаюсь трасировать 178.49.155.118.
: приведи ip r и ip a целиком. можно в пост. иначе не разобраться
Stephan-V: постнул
: мне ничо не приходило
Раз работало и вдруг перестало – значит кто-то что-то подкрутил.
Или ты, или на стороне удалённого сервера/сетевого оборудования.
: Вопрос то стоит, как такое вообще может быть на уровне системы: фаервол отключаем, до подсети маршрут есть, до одного ip из этой подсети маршрута нет.