GRE туннель между роутерами Cisco со статической маршрутизацией

Рассмотрим построение GRE туннеля точка-точка между маршрутизаторами двух компаний - COMPANY-A и COMPANY-B:

Подключаются компании к различным провайдерам, по одному провайдеру у каждого.
Адресация следующая:

	COMPANY-A	COMPANY-B
WAN IP	101.0.0.2/24	201.0.0.2/24
LAN HOST IP	10.0.0.100/24	192.168.0.100/24
TUNNEL IP	172.16.0.1/24	172.16.0.2/24

На маршрутизаторах прописаны DHCP пулы для LAN:

COMPANY-A#sh run | s dhcp

ip dhcp excluded-address 10.0.0.1 10.0.0.99
ip dhcp pool LAN-A
 network 10.0.0.0 255.255.255.0
 default-router 10.0.0.254
 lease 3

COMPANY-B#sh run | s dhcp

ip dhcp excluded-address 192.168.0.1 192.168.0.99
ip dhcp pool LAN-B
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.254
 lease 3

USER-A

VPCS> ip dhcp

DORA 

IP 10.0.0.100/24 GW 10.0.0.254

На каждом маршрутизаторе настроен статический маршрут по умолчанию в сторону провайдера:

COMPANY-A
interface Ethernet0/0
 description UPLINK to ISP-1
 ip address 101.0.0.2 255.255.255.0
ip route 0.0.0.0 0.0.0.0 101.0.0.1

COMPANY-B
interface Ethernet0/0
 description to ISP-2
 ip address 201.0.0.2 255.255.255.0

ip route 0.0.0.0 0.0.0.0 201.0.0.1

Маршрутизаторы "видят" WAN интерфейсы друг друга:

COMPANY-A#ping 201.0.0.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 201.0.0.2, timeout is 2 seconds:

!!!!!

Но пользователи в сети LAN не могут обмениваться пакетами:

USER-A> ping 192.168.0.100

192.168.0.100 icmp_seq=1 timeout

 Для того чтобы это произошло, поднимем туннель с инкапсуляцией GRE:

COMPANY-A

interface Tunnel0

 description TUNNEL to COMPANY B

 ip address 172.16.0.1 255.255.255.0

 tunnel source Ethernet0/0

 tunnel destination 201.0.0.2

COMPANY-B

interface Tunnel0

 description TUNNEL to COMPANY A

 ip address 172.16.0.2 255.255.255.0

 tunnel source 201.0.0.2

 tunnel destination 101.0.0.2

При этом в настройках туннельных интерфейсов по разному указан исходящий адрес туннеля - для А это интерфейс Ethernet0/0, для В конкретный IP.  Второй вариант необходимо использовать если на интерфейсе прописан второй (secondary) адрес.

Далее необходимо завернуть трафик между LAN сетями в созданный туннель:

COMPANY-A

ip route 192.168.0.0 255.255.255.0 tunnel 0

COMPANY-B

ip route 10.0.0.0 255.255.255.0 172.16.0.1

И опять, здесь назначением можно указать как удаленный IP туннеля, так и название локального туннеля. Проверяем:

USER-A> ping 192.168.0.100

84 bytes from 192.168.0.100 icmp_seq=1 ttl=62 time=5.851 ms

84 bytes from 192.168.0.100 icmp_seq=2 ttl=62 time=3.927 ms

84 bytes from 192.168.0.100 icmp_seq=3 ttl=62 time=3.652 ms

84 bytes from 192.168.0.100 icmp_seq=4 ttl=62 time=4.858 ms

Также необходимо добавить для тунненльных интерфейсов мониторинг - отправку периодических keepalive. Без этого туннели будут всегда подняты, даже если IP связность нарушилась, например разорвем BGP соседство между ISP-1 и ISP-2:

ISP-2(config)#router bgp 456

ISP-2(config-router)# neighbor 100.0.0.1 shutdown

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

COMPANY-B#sh int tun 0

Tunnel0 is up, line protocol is up

Добавим мониторинг:

COMPANY-B(config)#int tun 0

COMPANY-B(config-if)#keepalive 2 3  # Отправлять каждые 2 секунды, после 3 попыток перевести интерфейс в DOWN. 

Итог:

 %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down

Аналогично на другом конце туннеля:

После этого маршрут до удаленной LAN будет изъят из таблицы маршрутизации:

COMPANY-A#sh ip route 192.168.0.0

% Network not in table

*Трафик будет пытаться уходить напрямую к провайдеру по дефолтному маршруту:

COMPANY-A#sh ip cef 192.168.0.0

0.0.0.0/0

  nexthop 101.0.0.1 Ethernet0/0

Вернём связность обратно:

ISP-2(config-router)#no  neighbor 100.0.0.1 shutdown.

 %BGP-5-ADJCHANGE: neighbor 100.0.0.1 Up

COMPANY-B(config-if)#

%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

Туннель поднялся.

Теперь попробуем пустить пакеты с максимально возможным payload для Ethernet - 1500 байт, и выставим DF флаг - не фрагментировать.

VPCS> ping 192.168.0.100 -l 1500 -D

packet size is greater than MTU(1500) 

Пакет не проходит. Это связано с тем, что исходный IP пакет инкапсулируется в GRE. Таким образом увеличивая заголовок на 24 байта - 4 байта GRE и 20 байт дополнительный IP (содержащий src и desination IP туннелей). Поэтому без разбивки пакета, он просто не "пролезет" в наш туннель. А с учетом того что транспорт не всегда такой идеальный как на стенде, и возможны различные инкапсуляции по пути, то необходимо заранее снизить размер MTU для того чтобы не терять пакеты. Конечно же будет применяться фрагментация пакетов размером MTU свыше указанной на туннельном интерфейсе.

Помимо MTU понизить необходимо и размер TCP сегмента (без заголовка TCP) на интерфейсе. Cisco рекомендует следующие значения:

mtu=1400

ip tcp adjust-mss=1360

Применим на маршрутизаторах:

COMPANY-A:

interface Tunnel0

 description TUNNEL to COMPANY B

 ip address 172.16.0.1 255.255.255.0

 ip mtu 1420

 ip tcp adjust-mss 1360

 keepalive 2 3

 tunnel source Ethernet0/0

 tunnel destination 201.0.0.2

COMPANY-B:

interface Tunnel0

 description TUNNEL to COMPANY A

 ip address 172.16.0.2 255.255.255.0

 ip mtu 1420

 ip tcp adjust-mss 1360

 keepalive 2 3

 tunnel source 201.0.0.2

 tunnel destination 101.0.0.

В следующем выпуске добавим шифрование туннеля и динамическую маршрутизацию.