Добрый день! Есть juniper EX8200 (является шлюзом для сети), который получает fullview bgp и есть коммутаторы доступа EX3300, через которых подключаются клиенты. Если попытаться пинговать с компьютера, подключенного к коммутатору доступа, один адрес 80.82.46.209, то пинги не проходят. Если пинговать со шлюза то пинги проходят.пинг со стороны клиента
cisco#ping 80.82.46.209Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 80.82.46.209, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)пинг со шлюза
cor-1> ping 80.82.46.209
PING 80.82.46.209 (80.82.46.209): 56 data bytes
64 bytes from 80.82.46.209: icmp_seq=0 ttl=54 time=22.040 ms
64 bytes from 80.82.46.209: icmp_seq=1 ttl=54 time=21.875 ms
64 bytes from 80.82.46.209: icmp_seq=2 ttl=54 time=22.899 ms
64 bytes from 80.82.46.209: icmp_seq=3 ttl=54 time=21.974 msмаршрут до него на шлюзе
cor-1> show route 80.82.46.209inet.0: 535933 destinations, 1067038 routes (531833 active, 0 holddown, 4357 hidden)
+ = Active Route, - = Last Active, * = Both80.82.32.0/19 *[BGP/170] 1d 23:26:04, MED 0, localpref 150
AS path: 43727 44237 21017 ?, validation-state: unverified
> to 178.210.46.137 via ge-0/0/1.0[BGP/170] 4d 02:01:41, MED 0, localpref 80
AS path: 6856 44237 21017 ?, validation-state: unverified
> to 195.98.94.185 via ge-0/0/0.0Подскажите в чем может быть причина? В какую сторону-то хоть капать?
> Добрый день! Есть juniper EX8200 (является шлюзом для сети), который получает fullview
> bgp и есть коммутаторы доступа EX3300, через которых подключаются клиенты. Если
> попытаться пинговать с компьютера, подключенного к коммутатору доступа, один адрес
> 80.82.46.209, то пинги не проходят. Если пинговать со шлюза то
> пинги проходят.Локализовывать проблему несвязности надо в категориях src dst.
Например с джунипера попингайте с разных его src адресов (типа с внешнего и внутреннего).
ping 80.82.46.209 source <ip-ext>
ping 80.82.46.209 source <ip-int>Таким образом поймете, есть ли связность вашего ip-блока с миром.
>[оверквотинг удален]
>> bgp и есть коммутаторы доступа EX3300, через которых подключаются клиенты. Если
>> попытаться пинговать с компьютера, подключенного к коммутатору доступа, один адрес
>> 80.82.46.209, то пинги не проходят. Если пинговать со шлюза то
>> пинги проходят.
> Локализовывать проблему несвязности надо в категориях src dst.
> Например с джунипера попингайте с разных его src адресов (типа с внешнего
> и внутреннего).
> ping 80.82.46.209 source <ip-ext>
> ping 80.82.46.209 source <ip-int>
> Таким образом поймете, есть ли связность вашего ip-блока с миром.с остальным миром вроде проблем нету (по крайней мере никто не жаловался). Если запустить трассу с джунипера, то она доходит до узла без проблем, но если попробовать уже с компа в сети, то трасса обрывается на последнем хопе.
Что вы подразумиваете под <ip-int> и <ip-ext>. <ip-int> - наш внешний адрес? <ip-ext> - адрес пира?
> с остальным миром вроде проблем нету (по крайней мере никто не жаловался).
> Если запустить трассу с джунипера, то она доходит до узла без
> проблем, но если попробовать уже с компа в сети, то трасса
> обрывается на последнем хопе.Попингайте с проблемного src-клиента соседний dst-хост, например
ping 80.82.46.211 или 80.82.46.203, вместо 80.82.46.209Если не отвечает только 80.82.46.209, то проблема скорее именно на нем.
Ещё можно попингать 80.82.46.209 с соседнего src-клиента из вашего блока ip-адресов.
На худой канец гляньте дамп с аплинков(ваших внешних каналов), точно ли не возвращаются к вам пакеты только с определенного dst на конкретный dst.
> Если не отвечает только 80.82.46.209, то проблема скорее именно на нем.так со шлюза этот адрес отвечает на пинги, да и из другой сети то же отвечает.
> Ещё можно попингать 80.82.46.209 с соседнего src-клиента из вашего блока ip-адресов.
по всему блоку такая ситуация
> На худой конец гляньте дамп с аплинков(ваших внешних каналов), точно ли не
> возвращаются к вам пакеты только с определенного dst на конкретный dst.я смотрел логи bgp, но там ничего нету по этому поводу.
> по всему блоку такая ситуацияНа данном этапе локализации проблемы, принципиальный вопрос следующий:
Как с проблемного src-блока ваших адресов пингаются соседние dst-хосты, например
ping 80.82.46.211 или 80.82.46.203, вместо 80.82.46.209Т.е. писать ли вам жалобу владельцу конкретного хоста или администратору всей тамошней сети грубо говоря.
Пока они будут чинить вашу жалобу, можете оттранслировать(NAT) проблемные src в ваши же беспроблемные src (ну или в интерфейс аплинка),
только те пакеты, которые летят на нужный удаленный хост/блок-ip.
>> по всему блоку такая ситуацияуточнил, проблема наблюдается только на определенных коммутаторах доступа, ответственных за определенную подcеть в AS
> На данном этапе локализации проблемы, принципиальный вопрос следующий:
ping 80.82.46.199Обмен пакетами с 80.82.46.199 по с 32 байтами данных:
Ответ от 80.82.46.199: число байт=32 время=28мс TTL=55
Ответ от 80.82.46.199: число байт=32 время=28мс TTL=55
Хотя трасса до него все равно не доходит
> Пока они будут чинить вашу жалобу, можете оттранслировать(NAT) проблемные src в вашиу нас не используется NAT, клиентам выдается белый IP.
Что-то я теперь совсем теряюсь в догадках. В логах коммутатора доступа ничего подозрительного не обнаружено. Какие еще есть мысли по этому поводу?
>[оверквотинг удален]
>> На данном этапе локализации проблемы, принципиальный вопрос следующий:
>ping 80.82.46.199
> Обмен пакетами с 80.82.46.199 по с 32 байтами данных:
> Ответ от 80.82.46.199: число байт=32 время=28мс TTL=55
> Ответ от 80.82.46.199: число байт=32 время=28мс TTL=55
> Хотя трасса до него все равно не доходит
>> Пока они будут чинить вашу жалобу, можете оттранслировать(NAT) проблемные src в ваши
> у нас не используется NAT, клиентам выдается белый IP.
> Что-то я теперь совсем теряюсь в догадках. В логах коммутатора доступа ничего
> подозрительного не обнаружено. Какие еще есть мысли по этому поводу?Крайне маловероятен глюк обычного коммутатора, который бы спецфично влиял на ip.
Трасировка не важно, может доходить, может нет, зависит от udp/icmp и фильтрации где-то того или иного.Поверхностно выглядит так, что администратор хоста 80.82.46.209 зафильтровал у себя пакеты от одного из ваших ip-блоков.
(возможно когда-то этот блок нагадил ему спамом или флудом). Это типичная распространенная практика.
Пишите ему жалобу, типа "просьба проверить, с вашего хоста 80.82.46.209, не возвращаются пакеты на ip-блок такой-то."В идеале вам надо конечно уметь смотреть дамп с аплинков, и щупать нужные ресурсные порты на интересующем хосте.(пинги-трасировки дают только первое приближение проблемы).
NAT в данном случае, нужен только как временный костыль, чтобы получить доступ к крайне необходимому ресурсу с проблемных IP-адресов клиентов.(тут уж смотрите, стоит ли овчинка выделки)
> Поверхностно выглядит так, что администратор хоста 80.82.46.209 зафильтровал у себя пакеты
> от одного из ваших ip-блоков.
> (возможно когда-то этот блок нагадил ему спамом или флудом). Это типичная распространенная
> практика.
> Пишите ему жалобу, типа "просьба проверить, с вашего хоста 80.82.46.209, не возвращаются
> пакеты на ip-блок такой-то."Была такая мысль, но администратор говорит, что ничего не блокировал.
> NAT в данном случае, нужен только как временный костыль, чтобы получить доступ
> к крайне необходимому ресурсу с проблемных IP-адресов клиентов.(тут уж смотрите, стоит
> ли овчинка выделки)Простите не понял, как вы нат предлагаете использовать?
> Была такая мысль, но администратор говорит, что ничего не блокировал.Отлично. Запустите бесконечный пинг на 80.82.46.209
И продолжайте писать жалобы, теперь ещё и администратору сети 80.82.46...
Типа, просьба проверить, есть ли движение паекетов src:x.x.x.x dst:80.82.46.209
администратор хоста 80.82.46.209 утверждает, что пакеты до него не долетают.
По трассе выглядит так:
traceroute 80.82.46.209
...
...
Соседние хосты типа 80.82.46.199 мне нормально возвращают пакеты.Пока там рассматривают ваши жалобы, можете настроить
source NAT. Транслируете свои проблемные-srcip в свои беспроблемные-srcip,
только те пакеты, которые летят на dstip 80.82.46.209.