Существует несколько способов зарезервировать точку терминирования сети /30 – cluster/virtual-chassis (самый простой, но не всегда самый дешёвый), mpls pw termination с active/standby проводами на ближайшей PE (актуально для mpls-сетей с количеством PE больше одной-двух, но решается несколько иная задача, а именно уход от децентрализованного терминирования) и VRRP/HSRP (и аналоги). Если с cluster/virtual-chassis всё более-менее просто (MC-LAG в сторону нижестоящего устройства и создание L3 сабынтерфейса в нём), то с vrrp/hsrp несколько сложнее. В классическом варианте VRRP настраивается таким образом:

interface FastEthernet0/0.2
 encapsulation dot1Q 2
 ip address 192.0.2.6 255.255.255.248
 vrrp 1 ip 192.0.2.1

На втором роутере настраивается адрес 192.0.2.5/29, абоненту остаются адреса 192.0.2.2-4. Однако возникает вопрос что делать, если у вас есть 2 роутера без поддержки кластеризации (например, Cisco ASR1K, 7200 и подобные) и есть абоненты, включенные по схеме /30, для которых хочется сделать резервную точку терминирования?

При написании этой статьи использовались 4 роутера c7200 с ПО C7200-JK9S-M 12.4(13b). На современных IOS/IOS-XE некоторые команды могут выглядеть несколько иначе, а нюансы оказаться немного другими (или потребуется использовать другие способы их решения)

Использование secondary для резервирования /30 по VRRP/HSRP

Решение поставленной задачи заключается в использовании “левой” сети в качестве служебной для vrrp и создании статического directly-connected маршрута для абонентской сети /30. Это выглядит следующим образом:

R1:

interface FastEthernet0/0.2
 encapsulation dot1Q 2
 ip address 10.0.0.1 255.255.255.248
 vrrp 1 ip 10.0.0.3
 vrrp 1 ip 192.0.2.1 secondary
!
ip route 192.0.2.0 255.255.255.252 FastEthernet0/0.2

R2:

interface FastEthernet0/0.2
 encapsulation dot1Q 2
 ip address 10.0.0.2 255.255.255.248
 vrrp 1 ip 10.0.0.3
 vrrp 1 ip 192.0.2.1 secondary
!
ip route 192.0.2.0 255.255.255.252 FastEthernet0/0.2

В принципе, на этом можно заканчивать статью, однако существует ряд интересных нюансов.

Потенциальная проблема с arp при использовании secondary VRRP/HSRP

Рассмотрим ситуацию, когда с R4 на R1 приходит трафик на ip.dst=192.0.2.2, а в arp-таблице R1 нет записи для 192.0.2.2. В этом случае, R1 отправляет arp who-has 192.0.2.2, но в качестве sender ip address (одно из полей arp-запроса) используется 10.0.0.1. Поскольку на стороне абонента может стоять всё, что угодно, то такой arp-запрос гипотетически может быть зафильтрован. Такой сценарий маловероятен, кроме того R1 может изучить arp из абонентского who-has (когда он начнёт слать трафик).

R2 отравляет arp-кеш R1 после перезагрузки R1

Допустим, R1 только что перезагрузился, пока он не был доступен, его честно замещал R2. Затем, R1 загрузился, начал поднимать протоколы и так получилось, что трафик с R4 на R1 на ip.dst=192.0.2.2 стал приходить раньше, чем поднялся vrrp. R1 шлёт arp who-has 192.0.2.2, а R2 ему отвечает 192.0.2.2=VRRP_MAC. В дебаге это отображается так:

R2#debug arp
...
*Aug  3 17:24:24.703: IP ARP: rcvd req src 10.0.0.1 ca01.0655.0000, dst 192.0.2.2 FastEthernet0/0.2
*Aug  3 17:24:24.707: IP ARP: sent rep src 192.0.2.2 0000.5e00.0101, dst 10.0.0.1 ca01.0655.0000 FastEthernet0/0.2

И в arp-таблице R1 появляется очень неприятная запись:

R1#show ip arp | i 192.0.2.
Internet  192.0.2.2               4   0000.5e00.0101  ARPA   FastEthernet0/0.2
Internet  192.0.2.1               -   0000.5e00.0101  ARPA   FastEthernet0/0.2

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

Виновник этому (включенный по умолчанию) proxy-arp. Для решения проблемы с отравлением arp-кеша в момент времени, пока не работает vrrp, нужно использовать команду “no ip proxy-arp” в режиме конфигурирования абонентского сабынтерфейса (применять её нужно и на R1 и на R2, чтобы избежать случая, когда R1 отправляет кеш R2)

Двойная скорость отдачи

Если скоростные политики устанавливаются непосредственно на интерфейсы fa0/0.2 R1 и R2, то абонент может удвоить скорость отдачи (от абонента к оператору) таким образом:

R3:

interface FastEthernet0/0
 ip address 10.0.0.4 255.255.255.248 secondary
 ip address 192.0.2.2 255.255.255.252
!
ip route 0.0.0.0 0.0.0.0 192.0.2.1
ip route 0.0.0.0 128.0.0.0 10.0.0.1
ip route 128.0.0.0 128.0.0.0 10.0.0.2

Настройки vrrp (чтобы вычислить адрес 10.0.0.4) можно понять, посниферив трафик от оператора. Можно даже прирутить трекинг к некстхопам 10.0.0.1 и 10.0.0.2, с целью избежания деградации сервиса, когда один из роутеров оператора станет недоступен.

Для предотвращения подобных действий со стороны абонента, можно заблокировать на свитче IP-трафик (ethertype=0x0800) не на VRRP_MAC, на arp-запросах это не скажется (у них другой ethertype). Большое количество современных свитчей умеют L2-ACL с указанием mac.dst и ethertype. Однако, подобная ситуация маловероятна, мало кто из абонентов будет заниматься подобными вещами, если только вы не раздаёте интернет в тундре, а ваши аплинки это спутниковые каналы.

Двойная скорость приёма (от оператора к абоненту)

Если R1 и R2 являются ASBR-ами, то, скорее всего, у вас трафик приходит на оба устройства. Рассмотрим именно этот (самый сложный) сценарий. Просто поделить скорость абонента на 2 и прописать такую в service-policy будет неправильно, даже если визуально трафик, приходящий к вам из внешнего мира балансируется примерно поровну. Этого делать нельзя по той причине, что трафик почти всегда балансируется per-flow, т.е. если абонент будет качать файл с конкретного http-сервера, то этот трафик будет (почти всегда) приходить через один внешний линк и абонент увидит скорость, поделённую на 2.

Нужно настроить маршрутизацию таким образом, чтобы трафик к абоненту всегда уходил только через один роутер. Выбирем в качестве такого роутера R1. Для реализации этой идеи увеличим AD(административное расстояние) до 254 для статического directly-connected маршрута 192.0.2.0/30 на R2 и настроим ospf между R1 и R2. В этом случае, если R1 живой, то RIB на R2 выглядит так:

R2#show ip route | i 192.0.2.0/30 
O E2    192.0.2.0/30 [110/20] via 198.51.100.1, 00:36:54, FastEthernet1/0

Если же R1 становится недоступен, то его замещает локально сконфигурированный маршрут:

R2#show ip route | i 192.0.2.0/30
S       192.0.2.0/30 is directly connected, FastEthernet0/0.2

R2#show ip route 192.0.2.0 255.255.255.252
Routing entry for 192.0.2.0/30
  Known via "static", distance 254, metric 0 (connected)
  Redistributing via ospf 1
  Advertised by ospf 1 subnets
  Routing Descriptor Blocks:
  * directly connected, via FastEthernet0/0.2
      Route metric is 0, traffic share count is 1

Таким образом, трафик уходит к абоненту только через один маршрутизатор (R1 или R2) и можно на оба сабынтерфейса применять одинаковый service-policy, не боясь, что возникнет излишнее потребление трафика.

Для порядка, на R1 можно настроить priority и preemption (чтобы трафик в обоих направлениях ходил через R1(а не как повезёт), если он доступен). (!)vrrp priority и preempt не относятся к проблеме двойного потребления трафика.

R1#show run int fa0/0.2
interface FastEthernet0/0.2
 encapsulation dot1Q 2
 ip address 10.0.0.1 255.255.255.248
 no ip proxy-arp
 vrrp 1 ip 10.0.0.3
 vrrp 1 ip 192.0.2.1 secondary
 vrrp 1 preempt delay minimum 60
 vrrp 1 priority 254

Проблема кеширования adjacency в ip cef

Если R1 стал недоступен, его подменил R2, затем R1 снова стал доступен, то трафик, приходящий на R2 в сторону R4 уходит с его интерфейса fa0/0.2 в сторону абоненту, не смотря на то, что по таблице маршрутизации он должен уходить в сторону R1 (см. выше про двойную скорость от оператора к абоненту)

R2#show ip route 192.0.2.2
Routing entry for 192.0.2.0/30
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
  Last update from 198.51.100.1 on FastEthernet1/0, 00:00:27 ago
  Routing Descriptor Blocks:
  * 198.51.100.1, from 192.0.2.255, 00:00:27 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1

R2#show ip cef 192.0.2.2
192.0.2.2/32, version 107, epoch 0, cached adjacency 192.0.2.2
0 packets, 0 bytes
  via 192.0.2.2, FastEthernet0/0.2, 0 dependencies
    next hop 192.0.2.2, FastEthernet0/0.2
    valid cached adjacency

Т.е. по таблице маршрутизации, трафик должен отравляться в fa1/0 (в сторону R1), но по cef он отправляется в fa0/0.2. Для того, чтобы избавиться от этой закешированной записи (и предотвратить её в будущем), на R2 нужно использовать команду “ip cef table adjacency-prefix validate”. После применения этой команды, происходит периодическая проверка cef на предмет наличия подобных устаревших записей. На R1 эту команду применять не обязательно, но можно.

Заключение

В статье не рассматривается случай выхода из строя линка R1-R2. Подразумевается, что это линк зарезервирован с помощью LAG или имеется резервируемая L3-связность между этими двумя роутерами. Также не рассматривается вопрос резервирования свитча SW1. Наиболее простой способ – использование модульного коммутатора с несколькими линейными картами (например, Huawei S9300) или с помощью hw-стека из двух независимых коммутаторов (например, Eltex MES-3124 или Cisco 3750). На сегодняшний день, на рынке имеются недорогие стекируемые коммутаторы с портами 1G и 10G.

Конфигурации R1, R2, R3, R4, SW1

version 12.4
!
hostname R1
!
ip cef
no ip domain lookup
!
interface Loopback0
 ip address 192.0.2.255 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 no ip address
 duplex half
!
interface FastEthernet0/0.2
 encapsulation dot1Q 2
 ip address 10.0.0.1 255.255.255.248
 no ip proxy-arp
 vrrp 1 ip 10.0.0.3
 vrrp 1 ip 192.0.2.1 secondary
 vrrp 1 preempt delay minimum 60
 vrrp 1 priority 254
!
interface FastEthernet1/0
 ip address 198.51.100.1 255.255.255.252
 ip ospf 1 area 0
 duplex half
!
interface FastEthernet2/0
 ip address 203.0.113.2 255.255.255.252
 duplex half
!
router ospf 1
 router-id 192.0.2.255
 log-adjacency-changes
 redistribute connected subnets
 redistribute static subnets
!
router bgp 64511
 bgp router-id 192.0.2.255
 bgp log-neighbor-changes
 neighbor 192.0.2.254 remote-as 64511
 neighbor 192.0.2.254 update-source Loopback0
 neighbor 203.0.113.1 remote-as 64510
 !
 address-family ipv4
 neighbor 192.0.2.254 activate
 neighbor 192.0.2.254 next-hop-self
 neighbor 192.0.2.254 soft-reconfiguration inbound
 neighbor 203.0.113.1 activate
 neighbor 203.0.113.1 soft-reconfiguration inbound
 no auto-summary
 no synchronization
 network 192.0.2.0
 exit-address-family
!
ip route 192.0.2.0 255.255.255.0 Null0
ip route 192.0.2.0 255.255.255.252 FastEthernet0/0.2

version 12.4
!
hostname R2
!
ip cef table adjacency-prefix validate
ip cef
no ip domain lookup
!
interface Loopback0
 ip address 192.0.2.254 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 no ip address
 duplex half
!
interface FastEthernet0/0.2
 encapsulation dot1Q 2
 ip address 10.0.0.2 255.255.255.248
 no ip proxy-arp
 vrrp 1 ip 10.0.0.3
 vrrp 1 ip 192.0.2.1 secondary
!
interface FastEthernet1/0
 ip address 198.51.100.2 255.255.255.252
 ip ospf 1 area 0
 duplex half
!
interface FastEthernet2/0
 ip address 203.0.113.6 255.255.255.252
 shutdown
 duplex half
!         
router ospf 1
 router-id 192.0.2.254
 log-adjacency-changes
 redistribute connected subnets
 redistribute static subnets
!
router bgp 64511
 bgp router-id 192.0.2.254
 bgp log-neighbor-changes
 neighbor 192.0.2.255 remote-as 64511
 neighbor 192.0.2.255 update-source Loopback0
 neighbor 203.0.113.5 remote-as 64510
 !
 address-family ipv4
 neighbor 192.0.2.255 activate
 neighbor 192.0.2.255 next-hop-self
 neighbor 192.0.2.255 soft-reconfiguration inbound
 neighbor 203.0.113.5 activate
 neighbor 203.0.113.5 soft-reconfiguration inbound
 no auto-summary
 no synchronization
 network 192.0.2.0
 exit-address-family
!
ip route 192.0.2.0 255.255.255.0 Null0
ip route 192.0.2.0 255.255.255.252 FastEthernet0/0.2 254

version 12.4
no service password-encryption
!
hostname R3
!
ip cef
no ip domain lookup
!
interface FastEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 duplex half
!         
ip route 0.0.0.0 0.0.0.0 192.0.2.1

version 12.4
!
hostname R4
!
ip cef
no ip domain lookup
!
interface Loopback0
 ip address 203.0.113.255 255.255.255.255
!
interface FastEthernet1/0
 ip address 203.0.113.1 255.255.255.252
 duplex half
!
interface FastEthernet2/0
 ip address 203.0.113.5 255.255.255.252
 duplex half
!
router bgp 64510
 bgp log-neighbor-changes
 neighbor 203.0.113.2 remote-as 64511
 neighbor 203.0.113.6 remote-as 64511
 !        
 address-family ipv4
 neighbor 203.0.113.2 activate
 neighbor 203.0.113.2 default-originate
 neighbor 203.0.113.2 soft-reconfiguration inbound
 neighbor 203.0.113.6 activate
 neighbor 203.0.113.6 default-originate
 neighbor 203.0.113.6 soft-reconfiguration inbound
 no auto-summary
 no synchronization
 exit-address-family
!

Конфигурация свитча SW1 (GNS3):