The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"GRE-туннели"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (VPN, VLAN, туннель)
Изначальное сообщение [ Отслеживать ]

"GRE-туннели"  +/
Сообщение от gagner (ok) on 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

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

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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "GRE-туннели"  +/
Сообщение от Николай (??) on 25-Ноя-10, 16:43 
> Куда смотреть? В чем может быть проблема?

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

ip ospf mtu-ignore


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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "GRE-туннели"  +/
Сообщение от BJ (ok) on 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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "GRE-туннели"  +/
Сообщение от gagner (ok) on 26-Ноя-10, 16:05 
> Конфиг интерфейсов и sh ip ospf neighbor с одного устройства?

да.

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

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "GRE-туннели"  +/
Сообщение от BJ (ok) on 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?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "GRE-туннели"  +/
Сообщение от plohish email(??) on 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 все же не обойтись.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "GRE-туннели"  +/
Сообщение от BJ (ok) on 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...)

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру