CISCO GRE

CISCO GRE — в статье рассмотрено развёртывание туннеля GRE и связанные с этим особенности на роутерах CISCO в виртуальной среде EVE-NG.

Немного о GRE

GRE (Generic Routing Encapsulation), нет ничего проще, чем GRE туннель. Буквально пара настроек и туннель готов. Какой-то большой смысловой нагрузки в этом туннеле нет. Но не всё так просто, дальше будет видно 🙂 GRE "всеядный": GRE может инкапсулировать мульткаст-трафик, броадкаст-трафик. В этом основное его достоинство. Сам GRE не имеет собственного шифрования, отсюда и пользы от GRE в чистом виде нет. Существовать так он может только где-то внутри большой корпоративной сети. В частности GRE может применяться чтобы соединить 2 области IPv6 через область IPv4.


Состоит GRE из 3 компонентов (на картинке):

  • Протокола-"пассажира" — любой протокол 3 уровня;
  • Несущего протокола — непосредственно сам GRE;
  • Протокола-"транспорта" — это IP.
CISCO GRE

Ещё про GRE:

  • Во внешнем заголовке IP в поле Protocol используется значение 47, указывающее на то, что внутри инкапсулирован GRE;
  • GRE разработан CISCO, но сейчас это IETF стандарт. Он расписан в RFC 2784 и обновлён в RFC 2890;
  • Протокол GRE по умолчанию является протоколом без отслеживания состояния (stateless) и не содержит механизмов управления потоком;
  • Заголовок GRE вместе с заголовком IP туннелирования, создаёт 24 байта (20 IP + 4 GRE) дополнительной служебной информации;
  • Пакеты GRE являются юникаст-пакетами;
  • Туннель GRE поддерживает функцию Keepalive.

Тестовая среда

Средой для тестов как всегда является EVE-NG (кто ещё не настраивал, бежать настраивать). Тестовая схема:

CISCO GRE

Почему такая вот странная схема? Как раз симулирует "большую" корпоративную среду. Роутеры не граничные, ната на них нет, он там не нужен при таком развёртывании. Зато есть какой-то протокол маршрутизации (IGP). Для определённости на всех роутерах настроен EIGRP:

R3# show run
...
router eigrp 1
network 10.10.20.0 0.0.0.3
network 10.10.30.0 0.0.0.3
...

Поэтому есть полная доступность всех адресов с любого устройства:

CISCO GRE

Нужно обратить внимание, что подсеть 192.168.2.0/24 находится в 5 переходах (хопах) от подсети 192.168.1.0/24. В качестве хопа считается только входящий интерфейс каждого роутера по пути следования пакета.


Настройка GRE

Туннель прокидывается между интерфейсами роутеров R1 и R4:

CISCO GRE
R1(config)# interface tunnel 1
R1(config-if)# ip address 10.10.100.1 255.255.255.252
R1(config-if)# tunnel source GigabitEthernet0/0
R1(config-if)# tunnel destination 10.10.30.2

R4(config)# interface tunnel 1
R4(config-if)# ip address 10.10.100.2 255.255.255.252
R4(config-if)# tunnel source GigabitEthernet0/0
R4(config-if)# tunnel destination 10.10.10.1

Проверяем туннель:

R4# ping 10.10.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.100.1, timeout is 2 seconds:
!!!!!

Посмотрим туннель:

R4# show interfaces tunnel 1
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.10.100.2/30
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source 10.10.30.2 (GigabitEthernet0/0), destination 10.10.10.1
   Tunnel Subblocks:
      src-track:
         Tunnel1 source tracking subblock associated with GigabitEthernet0/0
          Set of tunnels with source GigabitEthernet0/0, 1 member (includes iterators), on interface OK
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1476 bytes
  • Как можно видеть, из-за дополнительных заголовков в 24 байта MTU сокращён до 1476 байт;
  • Протокол/транспорт по умолчанию GRE/IP, поэтому не надо вводить дополнительную команду для туннеля:
R1(config-if)# tunnel mode gre ip

Особенности настройки

Посмотрим таблицу маршрутизации:

R1# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.10.10.0/30 is directly connected, GigabitEthernet0/0
L 10.10.10.1/32 is directly connected, GigabitEthernet0/0
D 10.10.20.0/30 [90/3072] via 10.10.10.2, 00:12:38, GigabitEthernet0/0
D 10.10.30.0/30 [90/3328] via 10.10.10.2, 00:12:38, GigabitEthernet0/0
C 10.10.100.0/30 is directly connected, Tunnel1
L 10.10.100.1/32 is directly connected, Tunnel1
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/1
L 192.168.1.1/32 is directly connected, GigabitEthernet0/1
D 192.168.2.0/24 [90/3584] via 10.10.10.2, 00:12:38, GigabitEthernet0/0
R1#

Из таблицы видно, что на данный момент компьютеры ещё не используют туннель, маршрут EIGRP для подсети 192.168.2.0 указывает на интерфейс GigabitEthernet0/0, а должен на интерфейс Tunnel1. Добавим подсеть туннеля в EIGRP:

R1(config)# router eigrp 1
R1(config-router)# network 10.10.100.0 0.0.0.3

R4(config)# router eigrp 1
R4(config-router)# network 10.10.100.0 0.0.0.3

Роутеры R1 и R4 сформировали отношения смежности через туннель (а значит мультикаст через туннель ходит):

R1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.10.100.2 Tu1 11 00:01:36 11 1470 0 20
0 10.10.10.2 Gi0/0 11 00:24:26 4 100 0 32

Но если посмотреть снова таблицу маршрутизации, то ничего ровным счетом не изменилось, смотрим теперь таблицу топологии EIGRP:

R1# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(192.168.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 192.168.2.0/24, 1 successors, FD is 3584
via 10.10.10.2 (3584/3328), GigabitEthernet0/0
via 10.10.100.2 (26880256/2816), Tunnel1

Маршрут через туннель имеет бОльшую метрику и не попадает в таблицу маршрутизации. Посмотрим интерфейсы:

R4# show interfaces gigabitEthernet 0/0 | in DLY
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
R4# show interfaces tunnel 1 | in DLY
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,

— тут нужно учесть, что обозначение usec это микросекунды

Проверим/посчитаем метрику EIGRP для каждого интерфейса по формуле:

metric = bandwidth + delay, где
bandwidth = (10000000/bandwidth(i)) * 256;
delay = delay(i) * 256;
bandwidth(i) — наименьшая пропускная способность из всех исходящих интерфейсов по пути в подсеть назначения в килобитах;
delay(i) — сумма всех задержек на исходящих интерфейсах по пути в подсеть назначения в десятках микросекунд.

Поскольку у нас все интерфейсы одинаковые, а исходящих интерфейсов 4, для gigabitEthernet 0/0:
(10 000 000/1 000 000)*256 + (4*1)*256 = 3584

Для tunnel 1 самый медленный он и есть, а исходящих интерфейсов 2:
(10 000 000/100)*256 + (5000+1)*256 = 26880256

Всё верно. Как же заставить трафик идти через туннель?


Recursive Routing

Такое случается если роутер пытается достичь destination туннеля через сам туннель.

This is a common issue when the transport network is advertised into the same routing protocol that runs on the overlay network.

Как раз наш случай. Рассмотрим подробнее, можно изменять параметры Bandwidth (Delay) на интерфейсах. Изменять Bandwidth не рекомендуется, так как он участвует в расчётах для QoS, SNMP. Рекомендуется крутить Delay. При изменении данных параметров, одного или обоих, физические характеристики интерфейса не изменяются. Эти параметры нужны только для настройки протоколов.

Попробуем уменьшить Bandwidth на интерфейсе GigabitEthernet0/0:

R4(config)# interface GigabitEthernet 0/0
R4(config-if)# bandwidth 10
*Aug 11 18:35:16.717: %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel1 - looped chain attempting to stack
*Aug 11 18:35:25.197: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
*Aug 11 18:35:25.197: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Aug 11 18:35:25.206: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.10.100.1 (Tunnel1) is down: interface down

Как только метрика через туннель становится меньше, чем через гигабитный интерфейс, туннель сразу гасится с сообщениями о петле и рекурсивном роутинге.

Можно менять Bandwidth в настройках самого туннеля:

Virtual interfaces do not have the concept of latency and need to have a reference bandwidth configured so that routing protocols that use bandwidth for best-path calculation can make an intelligent decision.

bandwidth [1-10000000] - in kilobits per second

Не пробовал такую настройку, но скорее всего получится то же самое.


Статическая маршрутизация

Настраиваем статику:

R1(config)# ip route 192.168.2.0 255.255.255.0 tunnel 1
R4(config)# ip route 192.168.1.0 255.255.255.0 tunnel 1

Смотрим таблицу маршрутизации:

R1# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.10.10.0/30 is directly connected, GigabitEthernet0/0
L 10.10.10.1/32 is directly connected, GigabitEthernet0/0
D 10.10.20.0/30 [90/3072] via 10.10.10.2, 00:04:47, GigabitEthernet0/0
D 10.10.30.0/30 [90/3328] via 10.10.10.2, 00:04:47, GigabitEthernet0/0
C 10.10.100.0/30 is directly connected, Tunnel1
L 10.10.100.1/32 is directly connected, Tunnel1
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/1
L 192.168.1.1/32 is directly connected, GigabitEthernet0/1
S 192.168.2.0/24 is directly connected, Tunnel1

Что произошло? Статический маршрут, который имеет административное расстояние равное 1, заменил собой маршрут EIGRP, у которого административное расстояние (AD) 90. Проверяем на компьютере:

CISCO GRE

Другой протокол маршрутизации

Убираем статику, иначе она своей AD = 1 забьёт все другие маршруты:

R1(config)# no ip route 192.168.2.0 255.255.255.0 tunnel 1 
R4(config)# no ip route 192.168.1.0 255.255.255.0 tunnel 1

Настраиваем протокол OSPF на R1 и R4:

R1(config)# router ospf 1
R1(config)# router-id 1.1.1.1
R1(config-router)# network 192.168.1.0 0.0.0.255 area 0
R1(config-router)# network 10.10.100.0 0.0.0.3 area 0

R4(config)# router ospf 101
R4(config)# router-id 2.2.2.2
R4(config-router)# network 192.168.2.0 0.0.0.255 area 0
R4(config-router)# network 10.10.100.0 0.0.0.3 area 0

Обращаю внимание, что для OSPF совпадение Process ID (1 и 101) необязательно.

Убираем информацию о подсетях 192.168.1.0/24, 192.168.2.0/24 из EIGRP:

R1(config)# router eigrp 1
R1(config-router)# no network 192.168.1.0

R4(config)# router eigrp 1
R4(config-router)# no network 192.168.2.0

Зачем это делать? EIGRP имеет AD = 90, против 110 у OSPF. Поэтому пока существует маршрут EIGRP, у маршрута OSPF нет шансов попасть в таблицу маршрутизации.

Смотрим таблицу маршрутизации:

R1# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.10.10.0/30 is directly connected, GigabitEthernet0/0
L 10.10.10.1/32 is directly connected, GigabitEthernet0/0
D 10.10.20.0/30 [90/3072] via 10.10.10.2, 01:20:16, GigabitEthernet0/0
D 10.10.30.0/30 [90/3328] via 10.10.10.2, 01:20:16, GigabitEthernet0/0
C 10.10.100.0/30 is directly connected, Tunnel1
L 10.10.100.1/32 is directly connected, Tunnel1
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/1
L 192.168.1.1/32 is directly connected, GigabitEthernet0/1
O 192.168.2.0/24 [110/1001] via 10.10.100.2, 00:00:07, Tunnel1

Policy-Based Routing

Возвращаем как было изначально EIGRP:

R1(config)# router eigrp 1 
R1(config-router)# network 192.168.1.0 

R4(config)# router eigrp 1 
R4(config-router)# network 192.168.2.0

Если кто обратил внимание, то подсети были добавлены без обратной маски. Так можно сделать потому, что наши подсети совпадают с подсетью класса C.

Убираем OSPF:

R1(config)# no router ospf 1 
R4(config)# no router ospf 101

Пакеты от PC1 к PC2 и обратно снова ходят мимо туннеля.

Создаём ACL для отбора трафика между PC1 и PC2:

R1(config)# access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

R4(config)# access-list 101 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

Создаём политику перенаправления трафика:

R1(config)# route-map PBR permit 10
R1(config-route-map)# match ip address 101
R1(config-route-map)# set ip next-hop 10.10.100.2

R4(config)# route-map PBR permit 10
R4(config-route-map)# match ip address 101
R4(config-route-map)# set ip next-hop 10.10.100.1

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

PBR для локального трафика

Запускаем трассировку с роутера R1:

R1# traceroute 192.168.2.2 source 192.168.1.1

Type escape sequence to abort.
Tracing the route to 192.168.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.10.2 2 msec 2 msec 1 msec
2 10.10.20.2 2 msec 2 msec 2 msec
3 10.10.30.2 4 msec 3 msec 3 msec
4 192.168.2.2 6 msec 3 msec 3 msec

Теперь применяем политику и снова проверяем:

R1(config)# ip local policy route-map PBR
R1(config)# end
R1# traceroute 192.168.2.2 source 192.168.1.1

Type escape sequence to abort.
Tracing the route to 192.168.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.100.2 5 msec 4 msec 4 msec
2 192.168.2.2 6 msec 4 msec 5 msec
PBR для транзитного трафика

Убираем локальную политику:

R1(config)# no ip local policy route-map PBR

Вешаем на внутренний интерфейс:

R1(config)# interface GigabitEthernet 0/1
R1(config-if)# ip policy route-map PBR

R4(config)# interface GigabitEthernet 0/1
R4(config-if)# ip policy route-map PBR

Теперь все пакеты, проходящие через GigabitEthernet 0/1 проверяются на совпадение с ACL 101 и при таком совпадении перенаправляются в туннель. Проверяем для PC1:

Для PC2:

Как видно, пакеты для адресов 10.10.0.0/16 по прежнему ходят мимо туннеля, так и должно быть.

Особенности PBR

С PBR нужно обращаться аккуратно, любая ошибка в настройке может привести к  неочевидным последствиям. Удалим "случайно" ACL 101 на R1:

R1(config)# no access-list 101

Теперь пакеты для адресов 10.10.0.0/16 (кроме адреса интерфейса роутера R1 10.10.10.1) заворачивают сначала в туннель и уже из него к нужному адресу. Маршрут получается не оптимальный, а кривой.

PBR перехватывает пакеты до стандартной маршрутизации. Другими словами PBR действует на входящий (ingress) трафик:

PBR applies a route map to all ingress unicast traffic received on a PBR-enabled interface. PBR cannot
be applied to egress traffic or to multicast traffic. 

Поэтому если перевесить политику на GigabitEthernet 0/0 (куда прибывают уже смаршрутизированные пакеты), то политика не отрабатывает, попаданий в ACL 101 нет. Включим дебаг и ещё раз запустим пинг с PC1 на PC2. Что при этом происходит, интересная штука:

R1# debug ip policy

Policy routing debugging is on
*Dec 8 18:19:18.097: IP: s=192.168.2.2 (GigabitEthernet0/0), d=192.168.1.2, len 84, FIB policy rejected(no match) - normal forwarding
*Dec 8 18:19:19.105: IP: s=192.168.2.2 (GigabitEthernet0/0), d=192.168.1.2, len 84, FIB policy rejected(no match) - normal forwarding

Политика не проверяет исходящие с GigabitEthernet 0/0 пакеты PC1, но проверяет ответные от PC2, так как они являются входящими для интерфейса.


Keepalive

Протокол GRE по умолчанию является протоколом без отслеживания состояния, то есть статус одной оконечной точки туннеля неизвестен для другой. Интерфейс туннеля сразу переходит в Up, если в таблице маршрутизации имеется маршрут до destination туннеля. Когда маршрут динамический, туннель полагается на таймеры протокола маршрутизации, чтобы отслеживать состояние маршрута и значит состояние туннеля. Если же это статический маршрут, то и механизмов никаких нет.

Механизм Keepalive исправляет эту ситуацию. И траблшутинге позволит сразу оценить в каком состоянии туннель. Подробно работа Keepalive для GRE в реализации CISCO рассказана тут, значения параметров описаны здесь. Параметры:

  • Period — Опциональный параметр частоты отправки сообщений Keepalive (по умолчанию 10 секунд);
  • Retries — Опциональный параметр, счётчик невернувшихся обратных пакетов (по умолчанию 5).

Кратко перескажу работу Keepalive: сторона туннеля (R1), на которой настроен Keepalive периодически отправляет "хитрые" пакеты другой стороне (R4), когда хитрый пакет распакуется на R4, то внутри окажется обратный пакет для R1 (пустой, без нагрузки). Когда R1 получит обратный пакет, то он поймёт, что всё в порядке. Если обратный пакет не вернётся, то счетчик увеличивается на 1. Когда счётчик достигнет установленного значения, Keepalive переведёт Line Protocol для интерфейса Tunnel в состояние Down. Пользовательский трафик отправляться не сможет. При этом отправка пакетов Keepalive продолжится. Как только будет получен обратный пакет, Line Protocol будет переведён в UP, а счётчик обнулится.

При работе Keepalive сразу можно увидеть когда есть проблема с туннелем по упавшему Line Protocol. Для нашего примера:

R1(config)# interface tunnel 1 
R1(config-if)# keepalive  

R4(config)# interface tunnel 1 
R4(config-if)# keepalive

Смотрим конфигурацию:

interface Tunnel1
ip address 10.10.100.1 255.255.255.252
keepalive 10 3
tunnel source GigabitEthernet0/0
tunnel destination 10.10.10.2

Должно быть по умолчанию keepalive 10 5, на практике немного отличается: keepalive 10 3. Теперь посмотрим WireShark:

CISCO GRE

Теперь погасим интерфейс Tunnel 1 на R4:

R4(config)# interface tunnel 1
R4(config-if)# sh

*Aug 19 12:17:27.550: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Aug 19 12:17:27.551: %LINK-5-CHANGED: Interface Tunnel1, changed state to administratively down

И посмотрим что будет на R1:

R1# show interfaces tunnel 1

Tunnel1 is up, line protocol is down

После поднятия интерфейса туннеля на R4, туннель полностью поднимается и на R1.


Заключение

Рассмотренные примеры больше умозрительные, чем боевые, так как GRE в чистом виде неинтересен, кроме каких-то очень частных случаев. Рекомендую рассмотреть боевую реализацию GRE over IPSec.

Leave a Comment

Scroll to Top