GRE туннель поверх GRE. Возможно ли?

Question

[Metalhaker97]

Всем привет!
Имеется вот такая, на первый взгляд сложная схема сети.

Удаленная точка CISCO 1, центральный узел CISCO 2.
На удаленной точке установлен роутер IRZ с сим-картой оператора с APN адресом 10.100.0.1. Линковочная сеть между CISCO 1 и IRZ 192.168.0.0 /30.
На центральном узле имеется некий стык с оператором - линковочная сеть 10.120.0.0 /30, через которую работают APN адреса. Для работы APN адреса на CISCO 2 прописан статический маршрут: ip route 10.100.0.1 255.255.255.255 10.120.0.2
Задача сводилась к тому, чтобы построить связность между CISCO 1 и CISCO 2 через IRZ.
Для этого сначала был построен GRE туннель между CISCO 2 и IRZ.
Конфигурация GRE туннеля на CISCO 2:

interface Tunnel1
 description Link-to-IRZ-via-APN
 ip address 10.22.0.2 255.255.255.252
 ip mtu 1400
 tunnel source 10.120.0.1
 tunnel destination 10.100.0.1

Ответная конфигурация на IRZ:

Local Address: 10.100.0.1
Remote Address: 10.120.0.1
Network Type: L3
Tunnel IP: 10.22.0.1
Tunnel Mask: 255.255.255.252
Установлен флажок в поле: Don't Fragment packets

Связность между IRZ и CISCO 2 налажена, пинг идет.

Далее нужно поднять туннель между CISCO 1 и CISCO 2. Тут уже интереснее.
На CISCO 1 конфигурация туннеля:

interface Tunnel2
 description Link-to-CISCO-2-via-IRZ
 ip address 10.21.0.1 255.255.255.252
 ip mtu 1400
 tunnel source 192.168.0.1
 tunnel destination 10.22.0.2

И прописан статический маршрут:
ip route 10.22.0.2 255.255.255.255 192.168.0.2

На CISCO 2 конфигурация туннеля:

interface Tunnel2
 description Link-to-CISCO-1-via-IRZ
 ip address 10.21.0.2 255.255.255.252
 ip mtu 1400
 tunnel source 10.22.0.2
 tunnel destination 192.168.0.1

И прописан статический маршрут:
ip route 192.168.0.1 255.255.255.255 10.22.0.1

А вот данный туннель уже не работает. Не могу разобраться в чем причина и должно ли это вообще работать?

Answer 1

[Сергей]

Как вариант, можно попробовать:
1. Указать в статической маршрутизации не адреса, а конкретные туннели типа
ip route 192.168.0.1 255.255.255.255 Tunnel0
2. Проверить статику на всех устройствах. Скорее всего, на стороне филиала будет правильно использовать в статике 2 записи: 1-я запись для указания маршрута к провайдеру, а вторая запись - завернуть весь траффик на туннель: ip route 0.0.0.0 0.0.0.0 Tunnel0
3. Попробуйте keepalive 2 3 поставить на туннелях. У нас на некоторых кошках с некоторыми ИОСами была проблема, когда туннель не работал без постоянных keepalive-пакетов.
4. Включите дебаг и посмотрите, где что проходит, а где - нет

Comments

[Haba122]

Я еще бы посоветовал понизить mtu для второго тоннеля

[Metalhaker97]

Haba122, на первом туннеле понизил MTU до 1400, на втором туннеле до 1300.

[Metalhaker97]

Вообще возможно чтобы туннель работал внутри туннеля?

[Haba122]

Metalhaker97, да, возможно. вам надо все же вычислить оптимальный мту первого тоннеля, а уже потом играться со вторым. Ведь трафик первого уже тоже может проходить тоннели вашего провайдера. Если все хорошо, то 1400 для первого достаточно, а вот 1300 для второго уже может быть много. Попробуйте 1280.

[Metalhaker97]

Haba122, попробую на втором туннеле MTU понизить.

[Metalhaker97]

Haba122, а вообще нормально указывать для второго туннеля указывать source адресом ip адрес первого туннеля?