[Macil]

Канал у местного ethernet провайдера. IP по нему ходит без проблем. При попытке сделать GRE туннель, начинается засада: в ОДНУ сторону GRE ходит, в другую - как в черную дыру. Ситуация один в один и на циске и на линуксе. Постороннего оборудования нет вообще.

 

Техподдержка как мантру повторяет:

 

1. У нас канал второго уровня.

2. Мы ничего не режем.

3. Мы сами пользуемся GRE и все нормально.

4. У вас же IP ходит? Ходит! GOTO 1

 

WTF?

Как вообще бороться со слишком "умными" свичами и слишком "умной" топологией, когда чего-то ВНЕЗАПНО не ходит, по каналу L2?

Как объяснить eth-провайдеру что что-то не ходит, чтобы тебе поверили?

[woddy]

что за канал? влан арендованый?

[Macil]

что за канал? влан арендованый?

Ethernet точка-точка. VLAN - отдельный.

[woddy]

варианта вижу как минимум три

1) давить на коммерсантов угрожая отключиться. пусть коммерсанты мучают технарей

2) пытаться пробиться на следующую линию техподдержки в надежде услышать более вменяемых технарей

3) обойтись без ГРЕ

[s.lobanov]

>При попытке сделать GRE туннель, начинается засада: в ОДНУ сторону GRE ходит, в другую - как в черную дыру.

 

Вы уверены? Вы делали одновременно дамп с одной стороны и с другой? Там видно что с одной стороны уходит, с другой не приходит. Сделайте и отправьте это в техподдержку, чтобы у Ваши слова были более убедительны

[AlexBT]

На размеры пакета посмотрите. Иногда бывают фокусы из-за этого.

[visir]

И на keepalive обратите внимание, если хотя бы с одной стороны циска.

[n1k3]

Как минимум претензию письменную в офисе напишите.

[Macil]

>Вы делали одновременно дамп с одной стороны и с другой?

 

Ессно. Эта светлая идея возникла у техподдержки под вечер. Сейчас нашел в почте ответ:

 

Судя по прилагаемым дампам, ping в GRE туннеле между точками Х и Y успешен. ICMP пакеты проходят как в ту, так и в другую сторону. И это говорит о работе канала.

::/me бьется головой об стенку::

 

Размер пакетов исключается: во-первых ничего кроме ICMP там не ходит, во-вторых специально уменьшил MTU.

 

А может какие-то заморочки с рутингом? И пакет попадает в "петлю"?

 

А что такого с keep-alive'ами?

[-Px-]

При попытке сделать GRE туннель, начинается засада: в ОДНУ сторону GRE ходит, в другую - как в черную дыру

Судя по прилагаемым дампам, ping в GRE туннеле между точками Х и Y успешен. ICMP пакеты проходят как в ту, так и в другую сторону. И это говорит о работе канала.

Так тоннель поднимается, или нет? Если поднимается, в нём трафик ходит?

Edited May 14, 2010 by -Px-

[AlexBT]

keepalive:

http://www.cisco.com/en/US/tech/tk827/tk36...08040a17c.shtml

How GRE Keepalives Work

 

И посмотрите, как у Вас маршрутизация с обеих сторон прописана. Может банально забыли обратный маршрут прописать с одной стороны?

[Macil]

Так тоннель поднимается, или нет? Если поднимается, в нём трафик ходит?

GRE полностью stateless и "подниматься" и "опускаться" он не может. В циске все несколько сложнее. Но у меня для целей тестирования - две обычные линуксовые машины.

 

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

 

И самое главное, по куску кабеля все работает.

 

Жалко, что не потестировал IP-IP и IP-IP-GRE, но эти извращенные мысли пришли мне уже несколько позднее.

[Stak]

Можно предположить, что "туда" и "обратно" трафик идёт разными путями, с разным значением mtu...

[Macil]

Можно предположить, что "туда" и "обратно" трафик идёт разными путями, с разным значением mtu...

Дык, а какой у ethernet mtu? Кто-то принудительно ставил <1500? И для чего? Да и пакеты-то крохотные, ICMP'шки. Опять же, обычный IP нормально ходит.

[nuclearcat]

Может стоит сделать packet generator и зацепить временно с обоих сторон линуксы? и сгенерить аналогичные GRE пакеты и проверить прохождение

[1GE]

Снимите логи попыток соеденения вначале tcpdump-ом.

Гадать на кофейной гуще, что не работает вы будете дольше :)

 

[Macil]

Может стоит сделать packet generator и зацепить временно с обоих сторон линуксы? и сгенерить аналогичные GRE пакеты и проверить прохождение

Именно это я и сделал. Уходит, как в черную дыру.

 

Если кому-то интересно:

$ tcpdump -r X
reading from file X, link-type EN10MB (Ethernet)
17:08:18.629396 IP 192.168.99.2 > 192.168.99.1: ICMP echo request, id 23136, seq 1, length 64
17:08:18.629437 IP 192.168.99.1 > 192.168.99.2: ICMP echo reply, id 23136, seq 1, length 64
17:08:19.631297 IP 192.168.99.2 > 192.168.99.1: ICMP echo request, id 23136, seq 2, length 64
17:08:19.631343 IP 192.168.99.1 > 192.168.99.2: ICMP echo reply, id 23136, seq 2, length 64
17:08:42.641257 IP 192.168.99.1 > 192.168.99.2: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 43030, seq 1, length 64
17:08:43.648491 IP 192.168.99.1 > 192.168.99.2: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 43030, seq 2, length 64
17:08:44.648398 IP 192.168.99.1 > 192.168.99.2: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 43030, seq 3, length 64
17:08:45.648394 IP 192.168.99.1 > 192.168.99.2: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 43030, seq 4, length 64
17:08:46.648382 IP 192.168.99.1 > 192.168.99.2: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 43030, seq 5, length 64

tcpdump -r Y
reading from file Y, link-type EN10MB (Ethernet)
17:08:17.413653 IP 192.168.99.2 > 192.168.99.1: ICMP echo request, id 23136, seq 1, length 64
17:08:17.415058 IP 192.168.99.1 > 192.168.99.2: ICMP echo reply, id 23136, seq 1, length 64
17:08:18.415291 IP 192.168.99.2 > 192.168.99.1: ICMP echo request, id 23136, seq 2, length 64
17:08:18.417403 IP 192.168.99.1 > 192.168.99.2: ICMP echo reply, id 23136, seq 2, length 64
17:08:26.477749 IP 192.168.99.2 > 192.168.99.1: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 23392, seq 1, length 64
17:08:27.485163 IP 192.168.99.2 > 192.168.99.1: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 23392, seq 2, length 64
17:08:28.014718 IP 172.19.9.154 > 239.255.255.100: igmp v1 report 239.255.255.100
17:08:28.493143 IP 192.168.99.2 > 192.168.99.1: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 23392, seq 3, length 64
17:08:29.501157 IP 192.168.99.2 > 192.168.99.1: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 23392, seq 4, length 64
17:08:30.509136 IP 192.168.99.2 > 192.168.99.1: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 23392, seq 5, length 64
17:08:41.426885 IP 192.168.99.1 > 192.168.99.2: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 43030, seq 1, length 64
17:08:41.426956 IP 192.168.99.2 > 192.168.99.1: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 43030, seq 1, length 64
17:08:42.434103 IP 192.168.99.1 > 192.168.99.2: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 43030, seq 2, length 64
17:08:42.434135 IP 192.168.99.2 > 192.168.99.1: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 43030, seq 2, length 64
17:08:43.433985 IP 192.168.99.1 > 192.168.99.2: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 43030, seq 3, length 64
17:08:43.434025 IP 192.168.99.2 > 192.168.99.1: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 43030, seq 3, length 64
17:08:44.433958 IP 192.168.99.1 > 192.168.99.2: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 43030, seq 4, length 64
17:08:44.433999 IP 192.168.99.2 > 192.168.99.1: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 43030, seq 4, length 64
17:08:45.433936 IP 192.168.99.1 > 192.168.99.2: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 43030, seq 5, length 64
17:08:45.433975 IP 192.168.99.2 > 192.168.99.1: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 43030, seq 5, length 64

 

192.168.99.1 и 192.168.99.2 - физика точек X и Y

10.0.0.1 и 10.0.0.2 - туннель точек X и Y

[1GE]

Ну вот всё сразу и видно стало.

GRE у вас закрыт на пути 192.168.99.2 > 192.168.99.1.

 

Лог высылаете админам прова-пусть ищут где-то потерянный фильтр.

 

[Smoke]

Как вообще бороться со слишком "умными" свичами и слишком "умной" топологией, когда чего-то ВНЕЗАПНО не ходит, по каналу L2?

Как объяснить eth-провайдеру что что-то не ходит, чтобы тебе поверили?

может стоит выбрать провайдера с MPLS ?

там эти вопросы сами уйдут...

[s.lobanov]

>Лог высылаете админам прова-пусть ищут где-то потерянный фильтр.

 

А если не пробьётесь через техподдержку до админов, то ищите контакты во whois на реальные IP адреса вашего провайдера

[Macil]

Ну вот всё сразу и видно стало.

GRE у вас закрыт на пути 192.168.99.2 > 192.168.99.1.

Спасибо, кэп :))

 

Лог высылаете админам прова-пусть ищут где-то потерянный фильтр.

Лог высылал, что они мне ответили - привел выше. В понедельник буду крепко ругаться :(

 

Меня больше интересует, что же это за фильтр такой? Я не очень хорошо разбираюсь в возможностях современных "умных" свичей, тем паче каталистов, которые на пути имеют быть, по крайней мере в разговоре с провом это слово звучало.

 

[Macil]

может стоит выбрать провайдера с MPLS ?

там эти вопросы сами уйдут...

У этого провайдера MPLS имеет место быть (не знаю только где конкретно). От этого же провайдера получаем вполне серьезные услуги, некоторые вообще уникальные, где альтернатива, либо диалап, либо медяшка от Монополиста.

 

Я вообще не понимаю, что случилось. Техподдержка, которая не умеет читать дампы меня вообще добила. Все же всегда было нормально, не первый год замужем...

 

Идти к Монополисту? Так это другие деньги. И сроки. А канал существует не просто так. Тому месту какбы окупаться нужно... Идти к резко пошедшему в народ ТТК? Тоже не выход, ибо сетей доступа у него нема.

 

Это так кризис повлиял? Или это происки призрака Мегателекома? Или просто новый хозяин решил "оптимизиовать"? Или начиная с определенного момента eth интфраструктура становится неуправляемой?

 

Я всегда считал eth провайдеров основой малого и среднего бизнеса. Если их не будет, нам будет очень и очень тяжко. Т.к. реальной альтернативы НЕТ ВООБЩЕ.

[1GE]

Меня больше интересует, что же это за фильтр такой? Я не очень хорошо разбираюсь в возможностях современных "умных" свичей, тем паче каталистов, которые на пути имеют быть, по крайней мере в разговоре с провом это слово звучало.

Забытый или неправильно сконфигуренный ACL-фильтр скорее всего это на каком-то промежуточном свитче по трассе (у вашего же прова, как я понял MPLS нет). Фильтр на пакеты IP с типом протокола 47(0x2F).

Эта метка показывает, что по IP-пакетах передается GRE туннель.

Если интересно почитайте RFC 2784 и RFC 2890.

Такие фильтры раньше часто применялись в борьбе с "тарелочниками" и "колхозами" внутри сетей.

Врядли это злой умысел. Обычное разгильдяйство.

Edited May 15, 2010 by 1GE

[Ivan_83]

Перейти на L2TP в разы быстрее было бы, если есть тех возможность.

[separaf]

Ну вот всё сразу и видно стало.

GRE у вас закрыт на пути 192.168.99.2 > 192.168.99.1.

подскажите пожалуйста, откуда это видно?