Существует несколько способов зарезервировать точку терминирования сети /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):
Добрый день!
Подскажите способ как сделать масштабируемым подключение клиентов на PE.
выдавать каждому /30 накладно…ip unnumbered?
из железа 28xx,18xx, 7206
PPPoE, ip unnumbered, серая транспортная сеть /30 + белый static route /32 (не всегда удобно для клиента). Самая “правильная” схема для IPoE для 7200 будет ISG IP Interface Subscriber (http://www.cisco.com/c/en/us/td/docs/ios/isg/configuration/guide/15_0s/isg_15_0s_book/isg_acess_sub_sessns.html#wp1054751 )