Jump to content
Калькуляторы

GRE и Ethernet провайдер Что за фигня?

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

 

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

 

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

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

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

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

 

WTF?

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
что за канал? влан арендованый?

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Edited by -Px-

Share this post


Link to post
Share on other sites

keepalive:

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

How GRE Keepalives Work

 

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

Share this post


Link to post
Share on other sites
Так тоннель поднимается, или нет? Если поднимается, в нём трафик ходит?
GRE полностью stateless и "подниматься" и "опускаться" он не может. В циске все несколько сложнее. Но у меня для целей тестирования - две обычные линуксовые машины.

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

Share this post


Link to post
Share on other sites
Может стоит сделать 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

Share this post


Link to post
Share on other sites

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

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

 

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

 

Share this post


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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites
Ну вот всё сразу и видно стало.

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

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

 

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

 

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

 

Share this post


Link to post
Share on other sites
может стоит выбрать провайдера с MPLS ?

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

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
Меня больше интересует, что же это за фильтр такой? Я не очень хорошо разбираюсь в возможностях современных "умных" свичей, тем паче каталистов, которые на пути имеют быть, по крайней мере в разговоре с провом это слово звучало.
Забытый или неправильно сконфигуренный ACL-фильтр скорее всего это на каком-то промежуточном свитче по трассе (у вашего же прова, как я понял MPLS нет). Фильтр на пакеты IP с типом протокола 47(0x2F).

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

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

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

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

Edited by 1GE

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Ну вот всё сразу и видно стало.

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this