URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID6
Нить номер: 21967
[ Назад ]

Исходное сообщение
"GRE-туннели"

Отправлено gagner , 25-Ноя-10 16:23 
Добрый день, многоуважаемый 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

При этом гре-туннели, построенные поверх других сетей, с участием того же железа - работают без проблем.

Куда смотреть? В чем может быть проблема?


Содержание

Сообщения в этом обсуждении
"GRE-туннели"
Отправлено Николай , 25-Ноя-10 16:43 
> Куда смотреть? В чем может быть проблема?

Пропишите на тунеле TO_HUB1 и с другой стороны тунеля (10.1.1.1)

ip ospf mtu-ignore


и отпишитесь помогла таблетка :)


"GRE-туннели"
Отправлено gagner , 25-Ноя-10 18:20 
ip ospf mtu-ignore не прокатило.
Как и жесткое выставление mtu на туннельных интерфейсах (1200, например).

Хождение хелло говорит о том, что туннель вроде как сошелся - но при этом ничего кроме хелло там и не ходит (даже icmp). Это ломает мой мозг.


"GRE-туннели"
Отправлено BJ , 26-Ноя-10 00:33 
Конфиг интерфейсов и 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

Почему локальный и удаленный адрес одинаковые?


"GRE-туннели"
Отправлено gagner , 26-Ноя-10 16:05 
> Конфиг интерфейсов и sh ip ospf neighbor с одного устройства?

да.

> Почему локальный и удаленный адрес одинаковые?

это не локальный и удаленный адреса - это Neighbor ID и Neighbor Address.


"GRE-туннели"
Отправлено BJ , 26-Ноя-10 16:53 
Все равно не понял, почему _локальный_ адрес на туннеле и Neighbor  Address(он же с другой стороны?) одинаковые?

> это не локальный и удаленный адреса - это Neighbor ID и Neighbor
> Address.


"GRE-туннели"
Отправлено gagner , 26-Ноя-10 19:10 
> Все равно не понял, почему _локальный_ адрес на туннеле и Neighbor
> Address(он же с другой стороны?) одинаковые?

Он не с другой стороны. Спрашивая sh ip ospf neighbor - вы получаете список нейборов, там нет локальных адресов устройства, которому вы собственно задаете такие вопросы. только интерфейс, по которому установилось соседство...


"GRE-туннели"
Отправлено BJ , 26-Ноя-10 20:45 
> Он не с другой стороны. Спрашивая 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        Tunnel1

Router-ID (1-й столбец) вашего нейбора-Хаба 10.1.2.2, и адрес на туннельном интерфейсе Хаба (5-й столбец) также 10.1.2.2?


"GRE-туннели"
Отправлено gagner , 30-Ноя-10 11:47 
> Router-ID (1-й столбец) вашего нейбора-Хаба 10.1.2.2, и адрес на туннельном интерфейсе
> Хаба (5-й столбец) также 10.1.2.2?

Да, ошиблась при замене адресов - считаю неправильным выкладывать куски конфига с "оригинальной" адресацией.


"GRE-туннели"
Отправлено BJ , 30-Ноя-10 19:39 
> Да, ошиблась при замене адресов - считаю неправильным выкладывать куски конфига с
> "оригинальной" адресацией.

Ок, проехали. Судя по иниту на споуке, пакеты от хаба к нему долетают. Значит проблема с пакетами от споука до хаба.
Вы упамянули замену оборудования у клиента, какой класс устройств был заменен? Это сузит область поиска проблем: нет маршрута , правила на фаерволе, нат влючен\выключен где не надо и тд.


"GRE-туннели"
Отправлено plohish , 01-Дек-10 15:07 
>> Router-ID (1-й столбец) вашего нейбора-Хаба 10.1.2.2, и адрес на туннельном интерфейсе
>> Хаба (5-й столбец) также 10.1.2.2?
> Да, ошиблась при замене адресов - считаю неправильным выкладывать куски конфига с
> "оригинальной" адресацией.

А Вы не пробовали проверить работу GRE без OSPF ?
Буквально вчера борол похожее. Тунель постоянно падал, поднимался, грешил на разные MTU, но проблема оказалась таки в OSPF. Да, и если в Вашем случае MTU все же разные, без ip ospf mtu-ignore все же не обойтись.


"GRE-туннели"
Отправлено aZL , 02-Дек-10 16:26 
> А Вы не пробовали проверить работу GRE без OSPF ?

Поддержу, может просто туннели недоконфигурированны? Насколько помню, для правильной настройки туннелей обязательно должны присутствовать статик роуты, поправьте если ошибаю.


"GRE-туннели"
Отправлено gagner , 02-Дек-10 18:09 
1. по поводу работы GRE без OSPF - я не пингую туннельного соседа (как с хаба, так и со споука). Т.е. с моей точки зрения - оспф тут не при чем.

2. с рутингом все неплохо - я пингую tunnel dest (как с хаба, так и со споука). причем пингую именно по нужному стыку.

3. клиент переходил на циски, предположительно есть аса - но для нас это черный ящик.
(Чисто теоретически - что можно закрыть на асе, что бы был такой эффект? Там все чисто-чисто конкретно-конкретно: permit/deny gre...)


"GRE-туннели"
Отправлено crash , 03-Дек-10 06:15 
> 3. клиент переходил на циски, предположительно есть аса - но для нас
> это черный ящик.
> (Чисто теоретически - что можно закрыть на асе, что бы был такой
> эффект? Там все чисто-чисто конкретно-конкретно: permit/deny gre...)

если на интерфейса asa разный секьюрите левел, то весь трафик с меньшего секьюрити левела в больший не будет ходить, если не разрешить с помощью access-listа например.


"GRE-туннели"
Отправлено BJ , 03-Дек-10 09:57 
Если стоит АСА, будет полезно запросить у клиента результат 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...)


"GRE-туннели"
Отправлено joenky , 10-Янв-12 09:35 
> 1. по поводу работы GRE без OSPF - я не пингую туннельного
> соседа (как с хаба, так и со споука). Т.е. с моей
> точки зрения - оспф тут не при чем.
> 2. с рутингом все неплохо - я пингую tunnel dest (как с
> хаба, так и со споука). причем пингую именно по нужному стыку.
> 3. клиент переходил на циски, предположительно есть аса - но для нас
> это черный ящик.
> (Чисто теоретически - что можно закрыть на асе, что бы был такой
> эффект? Там все чисто-чисто конкретно-конкретно: permit/deny gre...)

проблема решилась? у меня один в один такая же фигня, интересует, это все таки косяк провайдера или мне в конфигах копать?