The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"непонятки с доступом"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (Маршрутизация)
Изначальное сообщение [ Отслеживать ]

"непонятки с доступом"  +/
Сообщение от tetst (ok) on 19-Фев-15, 16:14 
Добрый день! Есть juniper EX8200 (является шлюзом для сети), который получает fullview bgp и есть коммутаторы доступа EX3300, через которых подключаются клиенты. Если попытаться пинговать с компьютера, подключенного к коммутатору доступа,  один адрес  80.82.46.209, то пинги не проходят. Если пинговать со шлюза то пинги проходят.

пинг со стороны клиента


cisco#ping  80.82.46.209

Type 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.209

inet.0: 535933 destinations, 1067038 routes (531833 active, 0 holddown, 4357 hidden)
+ = Active Route, - = Last Active, * = Both

80.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

Подскажите в чем может быть причина? В какую сторону-то хоть капать?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "непонятки с доступом"  +/
Сообщение от cant email on 20-Фев-15, 13:29 
> Добрый день! Есть 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-блока с миром.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "непонятки с доступом"  +/
Сообщение от tetst (ok) on 20-Фев-15, 14:09 
>[оверквотинг удален]
>> 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> - адрес пира?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "непонятки с доступом"  +/
Сообщение от cant email on 20-Фев-15, 14:39 
> с остальным миром вроде проблем нету (по крайней мере никто не жаловался).
> Если запустить трассу с джунипера, то она доходит до узла без
> проблем, но если попробовать уже с компа в сети, то трасса
> обрывается на последнем хопе.

Попингайте с проблемного 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.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "непонятки с доступом"  +/
Сообщение от tetst (ok) on 20-Фев-15, 15:19 
> Если не отвечает только 80.82.46.209, то проблема скорее именно на нем.

так со шлюза этот адрес отвечает на пинги, да и из другой сети то же отвечает.

> Ещё можно попингать 80.82.46.209 с соседнего src-клиента из вашего блока ip-адресов.

по всему блоку такая ситуация

> На худой конец гляньте дамп с аплинков(ваших внешних каналов), точно ли не
> возвращаются к вам пакеты только с определенного dst на конкретный dst.

я смотрел логи bgp, но там ничего нету по этому поводу.


Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "непонятки с доступом"  +/
Сообщение от cant email on 20-Фев-15, 15:40 
> по всему блоку такая ситуация

На данном этапе локализации проблемы, принципиальный вопрос следующий:

Как с проблемного src-блока ваших адресов пингаются соседние dst-хосты, например
ping 80.82.46.211 или 80.82.46.203, вместо 80.82.46.209

Т.е. писать ли вам жалобу владельцу конкретного хоста или администратору всей тамошней сети грубо говоря.

Пока они будут чинить вашу жалобу, можете оттранслировать(NAT) проблемные src в ваши же беспроблемные src (ну или в интерфейс аплинка),
только те пакеты, которые летят на нужный удаленный хост/блок-ip.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "непонятки с доступом"  +/
Сообщение от tetst (ok) on 23-Фев-15, 16:02 
>> по всему блоку такая ситуация

уточнил, проблема наблюдается только на определенных коммутаторах доступа, ответственных за определенную под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.

Что-то я теперь совсем теряюсь в догадках. В логах коммутатора доступа ничего подозрительного не обнаружено. Какие еще есть мысли по этому поводу?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "непонятки с доступом"  +/
Сообщение от cant email on 24-Фев-15, 12:22 
>[оверквотинг удален]
>> На данном этапе локализации проблемы, принципиальный вопрос следующий:
>
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-адресов клиентов.(тут уж смотрите, стоит ли овчинка выделки)

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "непонятки с доступом"  +/
Сообщение от tetst (ok) on 26-Фев-15, 09:26 
> Поверхностно выглядит так, что администратор хоста 80.82.46.209 зафильтровал у себя пакеты
> от одного из ваших ip-блоков.
> (возможно когда-то этот блок нагадил ему спамом или флудом). Это типичная распространенная
> практика.
> Пишите ему жалобу, типа "просьба проверить, с вашего хоста 80.82.46.209, не возвращаются
> пакеты на ip-блок такой-то."

Была такая мысль, но администратор говорит, что ничего не блокировал.

> NAT в данном случае, нужен только как временный костыль, чтобы получить доступ
> к крайне необходимому ресурсу с проблемных IP-адресов клиентов.(тут уж смотрите, стоит
> ли овчинка выделки)

Простите не понял, как вы нат предлагаете использовать?

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "непонятки с доступом"  +/
Сообщение от cant email on 26-Фев-15, 11:19 
> Была такая мысль, но администратор говорит, что ничего не блокировал.

Отлично. Запустите бесконечный пинг на 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.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру