Jump to content

GRE и Ethernet провайдер

Macil

By Macil
in У нага

 Share

Recommended Posts

Macil

Macil

Posted
Posted

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

 

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

 

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

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

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

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

 

WTF?

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

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

woddy

woddy

Posted
Posted

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

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

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

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

s.lobanov

s.lobanov

Posted
Posted

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

 

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

Macil

Macil

Posted
  • Author
Posted

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

 

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

 

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

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

 

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

 

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

 

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

-Px-

-Px-

Posted
Posted (edited)

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

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

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

Edited by -Px-
AlexBT

AlexBT

Posted
Posted

keepalive:

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

How GRE Keepalives Work

 

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

Macil

Macil

Posted
  • Author
Posted
Так тоннель поднимается, или нет? Если поднимается, в нём трафик ходит?
GRE полностью stateless и "подниматься" и "опускаться" он не может. В циске все несколько сложнее. Но у меня для целей тестирования - две обычные линуксовые машины.

 

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

 

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

 

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

Macil

Macil

Posted
  • Author
Posted

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

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

1GE

1GE

Posted
Posted

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

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

 

Macil

Macil

Posted
  • Author
Posted
Может стоит сделать 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

1GE

Posted
Posted

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

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

 

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

 

Smoke

Smoke

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

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

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

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

s.lobanov

s.lobanov

Posted
Posted

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

 

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

Macil

Macil

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

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

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

 

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

 

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

 

Macil

Macil

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

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

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

 

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

 

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

 

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

 

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

1GE

1GE

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

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

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

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

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

Edited by 1GE

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.