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