Macil Опубликовано 14 мая, 2010 Канал у местного ethernet провайдера. IP по нему ходит без проблем. При попытке сделать GRE туннель, начинается засада: в ОДНУ сторону GRE ходит, в другую - как в черную дыру. Ситуация один в один и на циске и на линуксе. Постороннего оборудования нет вообще. Техподдержка как мантру повторяет: 1. У нас канал второго уровня. 2. Мы ничего не режем. 3. Мы сами пользуемся GRE и все нормально. 4. У вас же IP ходит? Ходит! GOTO 1 WTF? Как вообще бороться со слишком "умными" свичами и слишком "умной" топологией, когда чего-то ВНЕЗАПНО не ходит, по каналу L2? Как объяснить eth-провайдеру что что-то не ходит, чтобы тебе поверили? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
woddy Опубликовано 14 мая, 2010 что за канал? влан арендованый? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Macil Опубликовано 14 мая, 2010 что за канал? влан арендованый? Ethernet точка-точка. VLAN - отдельный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
woddy Опубликовано 14 мая, 2010 варианта вижу как минимум три 1) давить на коммерсантов угрожая отключиться. пусть коммерсанты мучают технарей 2) пытаться пробиться на следующую линию техподдержки в надежде услышать более вменяемых технарей 3) обойтись без ГРЕ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 14 мая, 2010 >При попытке сделать GRE туннель, начинается засада: в ОДНУ сторону GRE ходит, в другую - как в черную дыру. Вы уверены? Вы делали одновременно дамп с одной стороны и с другой? Там видно что с одной стороны уходит, с другой не приходит. Сделайте и отправьте это в техподдержку, чтобы у Ваши слова были более убедительны Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlexBT Опубликовано 14 мая, 2010 На размеры пакета посмотрите. Иногда бывают фокусы из-за этого. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 14 мая, 2010 И на keepalive обратите внимание, если хотя бы с одной стороны циска. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
n1k3 Опубликовано 14 мая, 2010 Как минимум претензию письменную в офисе напишите. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Macil Опубликовано 14 мая, 2010 >Вы делали одновременно дамп с одной стороны и с другой? Ессно. Эта светлая идея возникла у техподдержки под вечер. Сейчас нашел в почте ответ: Судя по прилагаемым дампам, ping в GRE туннеле между точками Х и Y успешен. ICMP пакеты проходят как в ту, так и в другую сторону. И это говорит о работе канала. ::/me бьется головой об стенку:: Размер пакетов исключается: во-первых ничего кроме ICMP там не ходит, во-вторых специально уменьшил MTU. А может какие-то заморочки с рутингом? И пакет попадает в "петлю"? А что такого с keep-alive'ами? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
-Px- Опубликовано 14 мая, 2010 (изменено) При попытке сделать GRE туннель, начинается засада: в ОДНУ сторону GRE ходит, в другую - как в черную дыру Судя по прилагаемым дампам, ping в GRE туннеле между точками Х и Y успешен. ICMP пакеты проходят как в ту, так и в другую сторону. И это говорит о работе канала. Так тоннель поднимается, или нет? Если поднимается, в нём трафик ходит? Изменено 14 мая, 2010 пользователем -Px- Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlexBT Опубликовано 15 мая, 2010 keepalive: http://www.cisco.com/en/US/tech/tk827/tk36...08040a17c.shtml How GRE Keepalives Work И посмотрите, как у Вас маршрутизация с обеих сторон прописана. Может банально забыли обратный маршрут прописать с одной стороны? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Macil Опубликовано 15 мая, 2010 Так тоннель поднимается, или нет? Если поднимается, в нём трафик ходит?GRE полностью stateless и "подниматься" и "опускаться" он не может. В циске все несколько сложнее. Но у меня для целей тестирования - две обычные линуксовые машины. Я вижу как GRE пакет уходит с физического интерфейса, при ошибке маршрутизации я наблюдал бы ICMP, и все-равно видел бы пакет сниффером. При неправильном указании одного из физических концов туннеля, я видел бы тучу арпхухэзов. При неправильном указании одного из логических концов туннеля, я все-равно видел бы GRE пакет на удаленном интерфейсе. И самое главное, по куску кабеля все работает. Жалко, что не потестировал IP-IP и IP-IP-GRE, но эти извращенные мысли пришли мне уже несколько позднее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 15 мая, 2010 Можно предположить, что "туда" и "обратно" трафик идёт разными путями, с разным значением mtu... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Macil Опубликовано 15 мая, 2010 Можно предположить, что "туда" и "обратно" трафик идёт разными путями, с разным значением mtu... Дык, а какой у ethernet mtu? Кто-то принудительно ставил <1500? И для чего? Да и пакеты-то крохотные, ICMP'шки. Опять же, обычный IP нормально ходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 15 мая, 2010 Может стоит сделать packet generator и зацепить временно с обоих сторон линуксы? и сгенерить аналогичные GRE пакеты и проверить прохождение Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
1GE Опубликовано 15 мая, 2010 Снимите логи попыток соеденения вначале tcpdump-ом. Гадать на кофейной гуще, что не работает вы будете дольше :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Macil Опубликовано 15 мая, 2010 Может стоит сделать 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
1GE Опубликовано 15 мая, 2010 Ну вот всё сразу и видно стало. GRE у вас закрыт на пути 192.168.99.2 > 192.168.99.1. Лог высылаете админам прова-пусть ищут где-то потерянный фильтр. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Smoke Опубликовано 15 мая, 2010 Как вообще бороться со слишком "умными" свичами и слишком "умной" топологией, когда чего-то ВНЕЗАПНО не ходит, по каналу L2?Как объяснить eth-провайдеру что что-то не ходит, чтобы тебе поверили? может стоит выбрать провайдера с MPLS ? там эти вопросы сами уйдут... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 15 мая, 2010 >Лог высылаете админам прова-пусть ищут где-то потерянный фильтр. А если не пробьётесь через техподдержку до админов, то ищите контакты во whois на реальные IP адреса вашего провайдера Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Macil Опубликовано 15 мая, 2010 Ну вот всё сразу и видно стало.GRE у вас закрыт на пути 192.168.99.2 > 192.168.99.1. Спасибо, кэп :)) Лог высылаете админам прова-пусть ищут где-то потерянный фильтр.Лог высылал, что они мне ответили - привел выше. В понедельник буду крепко ругаться :( Меня больше интересует, что же это за фильтр такой? Я не очень хорошо разбираюсь в возможностях современных "умных" свичей, тем паче каталистов, которые на пути имеют быть, по крайней мере в разговоре с провом это слово звучало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Macil Опубликовано 15 мая, 2010 может стоит выбрать провайдера с MPLS ?там эти вопросы сами уйдут... У этого провайдера MPLS имеет место быть (не знаю только где конкретно). От этого же провайдера получаем вполне серьезные услуги, некоторые вообще уникальные, где альтернатива, либо диалап, либо медяшка от Монополиста. Я вообще не понимаю, что случилось. Техподдержка, которая не умеет читать дампы меня вообще добила. Все же всегда было нормально, не первый год замужем... Идти к Монополисту? Так это другие деньги. И сроки. А канал существует не просто так. Тому месту какбы окупаться нужно... Идти к резко пошедшему в народ ТТК? Тоже не выход, ибо сетей доступа у него нема. Это так кризис повлиял? Или это происки призрака Мегателекома? Или просто новый хозяин решил "оптимизиовать"? Или начиная с определенного момента eth интфраструктура становится неуправляемой? Я всегда считал eth провайдеров основой малого и среднего бизнеса. Если их не будет, нам будет очень и очень тяжко. Т.к. реальной альтернативы НЕТ ВООБЩЕ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
1GE Опубликовано 15 мая, 2010 (изменено) Меня больше интересует, что же это за фильтр такой? Я не очень хорошо разбираюсь в возможностях современных "умных" свичей, тем паче каталистов, которые на пути имеют быть, по крайней мере в разговоре с провом это слово звучало.Забытый или неправильно сконфигуренный ACL-фильтр скорее всего это на каком-то промежуточном свитче по трассе (у вашего же прова, как я понял MPLS нет). Фильтр на пакеты IP с типом протокола 47(0x2F).Эта метка показывает, что по IP-пакетах передается GRE туннель. Если интересно почитайте RFC 2784 и RFC 2890. Такие фильтры раньше часто применялись в борьбе с "тарелочниками" и "колхозами" внутри сетей. Врядли это злой умысел. Обычное разгильдяйство. Изменено 15 мая, 2010 пользователем 1GE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 мая, 2010 Перейти на L2TP в разы быстрее было бы, если есть тех возможность. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
separaf Опубликовано 17 мая, 2010 Ну вот всё сразу и видно стало.GRE у вас закрыт на пути 192.168.99.2 > 192.168.99.1. подскажите пожалуйста, откуда это видно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...