Добрый день, многоуважаемый All.У меня собрана следующая схема: 2 хаба (большие циски), пачка споуков (871 циски); поверх сети клиента строятся простые gre-туннели. Никакого шифрования, конфигурация элементарна и идентична (и на хабах, и на споуках):
interface Tunnel0
description TO_HUB1
ip address 10.1.1.2 255.255.255.252
tunnel source 192.168.0.70
tunnel destination 10.16.1.30
!
interface Tunnel1
description TO_HUB2
ip address 10.1.2.2 255.255.255.252
tunnel source 192.168.0.70
tunnel destination 10.16.1.26Поверх gre - ospf. Долгое время все работало, до тех пор, пока клиент не сменил оборудование на своей сети.
На данный момент туннели TO_HUB2 работают без нареканий и вопросов. А с туннелями TO_HUB1 - странности.
Я не пингую соседа по туннелю. Но по нему ходят оспф хелло. (и так на всех споках, а не на каком-то одном конкретном ))Router#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.1.2.2 0 FULL/ - 00:00:30 10.1.2.2 Tunnel1
10.1.1.1 0 INIT/ - 00:00:35 10.1.1.1 Tunnel0При этом гре-туннели, построенные поверх других сетей, с участием того же железа - работают без проблем.
Куда смотреть? В чем может быть проблема?
> Куда смотреть? В чем может быть проблема?Пропишите на тунеле TO_HUB1 и с другой стороны тунеля (10.1.1.1)
ip ospf mtu-ignore
и отпишитесь помогла таблетка :)
ip ospf mtu-ignore не прокатило.
Как и жесткое выставление mtu на туннельных интерфейсах (1200, например).Хождение хелло говорит о том, что туннель вроде как сошелся - но при этом ничего кроме хелло там и не ходит (даже icmp). Это ломает мой мозг.
Конфиг интерфейсов и sh ip ospf neighbor с одного устройства?ip address 10.1.2.2 255.255.255.252
10.1.2.2 0 FULL/ - 00:00:30 10.1.2.2 Tunnel1Почему локальный и удаленный адрес одинаковые?
> Конфиг интерфейсов и sh ip ospf neighbor с одного устройства?да.
> Почему локальный и удаленный адрес одинаковые?
это не локальный и удаленный адреса - это Neighbor ID и Neighbor Address.
Все равно не понял, почему _локальный_ адрес на туннеле и Neighbor Address(он же с другой стороны?) одинаковые?> это не локальный и удаленный адреса - это Neighbor ID и Neighbor
> Address.
> Все равно не понял, почему _локальный_ адрес на туннеле и Neighbor
> Address(он же с другой стороны?) одинаковые?Он не с другой стороны. Спрашивая sh ip ospf neighbor - вы получаете список нейборов, там нет локальных адресов устройства, которому вы собственно задаете такие вопросы. только интерфейс, по которому установилось соседство...
> Он не с другой стороны. Спрашивая sh ip ospf neighbor - вы
> получаете список нейборов, там нет локальных адресов устройства, которому вы собственно
> задаете такие вопросы. только интерфейс, по которому установилось соседство...Цитируя Ваше основное сообщение:
interface Tunnel1
description TO_HUB2
ip address 10.1.2.2 255.255.255.252
tunnel source 192.168.0.70
tunnel destination 10.16.1.26Споук (871) имеет адрес на туннеле 10.1.2.2, правильно?
Выполнив на ней же команду sh ip ospf neighbor, видим
Neighbor ID Pri State Dead Time Address Interface
10.1.2.2 0 FULL/ - 00:00:30 10.1.2.2 Tunnel1Router-ID (1-й столбец) вашего нейбора-Хаба 10.1.2.2, и адрес на туннельном интерфейсе Хаба (5-й столбец) также 10.1.2.2?
> Router-ID (1-й столбец) вашего нейбора-Хаба 10.1.2.2, и адрес на туннельном интерфейсе
> Хаба (5-й столбец) также 10.1.2.2?Да, ошиблась при замене адресов - считаю неправильным выкладывать куски конфига с "оригинальной" адресацией.
> Да, ошиблась при замене адресов - считаю неправильным выкладывать куски конфига с
> "оригинальной" адресацией.Ок, проехали. Судя по иниту на споуке, пакеты от хаба к нему долетают. Значит проблема с пакетами от споука до хаба.
Вы упамянули замену оборудования у клиента, какой класс устройств был заменен? Это сузит область поиска проблем: нет маршрута , правила на фаерволе, нат влючен\выключен где не надо и тд.
>> Router-ID (1-й столбец) вашего нейбора-Хаба 10.1.2.2, и адрес на туннельном интерфейсе
>> Хаба (5-й столбец) также 10.1.2.2?
> Да, ошиблась при замене адресов - считаю неправильным выкладывать куски конфига с
> "оригинальной" адресацией.А Вы не пробовали проверить работу GRE без OSPF ?
Буквально вчера борол похожее. Тунель постоянно падал, поднимался, грешил на разные MTU, но проблема оказалась таки в OSPF. Да, и если в Вашем случае MTU все же разные, без ip ospf mtu-ignore все же не обойтись.
> А Вы не пробовали проверить работу GRE без OSPF ?Поддержу, может просто туннели недоконфигурированны? Насколько помню, для правильной настройки туннелей обязательно должны присутствовать статик роуты, поправьте если ошибаю.
1. по поводу работы GRE без OSPF - я не пингую туннельного соседа (как с хаба, так и со споука). Т.е. с моей точки зрения - оспф тут не при чем.2. с рутингом все неплохо - я пингую tunnel dest (как с хаба, так и со споука). причем пингую именно по нужному стыку.
3. клиент переходил на циски, предположительно есть аса - но для нас это черный ящик.
(Чисто теоретически - что можно закрыть на асе, что бы был такой эффект? Там все чисто-чисто конкретно-конкретно: permit/deny gre...)
> 3. клиент переходил на циски, предположительно есть аса - но для нас
> это черный ящик.
> (Чисто теоретически - что можно закрыть на асе, что бы был такой
> эффект? Там все чисто-чисто конкретно-конкретно: permit/deny gre...)если на интерфейса asa разный секьюрите левел, то весь трафик с меньшего секьюрити левела в больший не будет ходить, если не разрешить с помощью access-listа например.
Если стоит АСА, будет полезно запросить у клиента результат packet-tracer выполненный в обе стороны прохождения туннеля.Примерно так:
packet-tracer input outside rawip 192.168.1.2 47 172.168.5.5 detailed> 2. с рутингом все неплохо - я пингую tunnel dest (как с
> хаба, так и со споука). причем пингую именно по нужному стыку.Если пинги проходят, а gre нет: включите netflow на интерфейсах куда должен приходить GRE и отследите что реально приходит от спока на хаб. Мне так удавалось выявить ненужный nat на асах.
> 3. клиент переходил на циски, предположительно есть аса - но для нас
> это черный ящик.
> (Чисто теоретически - что можно закрыть на асе, что бы был такой
> эффект? Там все чисто-чисто конкретно-конкретно: permit/deny gre...)
> 1. по поводу работы GRE без OSPF - я не пингую туннельного
> соседа (как с хаба, так и со споука). Т.е. с моей
> точки зрения - оспф тут не при чем.
> 2. с рутингом все неплохо - я пингую tunnel dest (как с
> хаба, так и со споука). причем пингую именно по нужному стыку.
> 3. клиент переходил на циски, предположительно есть аса - но для нас
> это черный ящик.
> (Чисто теоретически - что можно закрыть на асе, что бы был такой
> эффект? Там все чисто-чисто конкретно-конкретно: permit/deny gre...)проблема решилась? у меня один в один такая же фигня, интересует, это все таки косяк провайдера или мне в конфигах копать?