Dmvpn

Кросспостинг, оригинальная публикация

DMVPN является известным решением для построения топологий hub&spoke. В ряде случаев может понадобиться поддержка изолированной передачи трафика различных клиентов. Конечно, можно построить DMVPN туннель в каждом VRF; однако в реальной жизни такой подход не является достаточно масштабируемым. В такой ситуации на ум приходит MPLS, который зарекомендовал себя в корпоративных и провайдерских сетях.

GRE поддерживает инкапсуляцию различных PDU, в том числе и MPLS, поэтому, на первый взгляд, не должно возникнуть проблем на уровне передачи трафика. С управляющими протоколами, однако, ситуация обстоит несколько сложнее. LDP и RSVP должны установить соседство перед тем, как обменяться какими-либо данными. Масштабируемость этих протоколов обусловлена использованием мультикаста для обнаружения соседей и обмена с ними необходимыми параметрами протокола. Ручная настройка LDP/RSVP соседства в DMVPN сведёт на нет масштабируемость, поэтому такой сценарий статья не рассматривает. Использование же мультикаста ограничивает функциональность решения, поскольку spoke могут обмениваться такими сообщениями только с hub, что исключает наличие spoke-to-spoke связности с использованием MPLS.

Впрочем, существует третье решение, которое является достаточно масштабируемым, а также способно обеспечить MPLS-связность spoke-узлов между собой это BGP labeled unicast (BGP LU). Существует несколько способов превратить spoke-маршрутизатор в PE (например, первый вариант отправить пакет с VPN меткой напрямую другому spoke, аналог второй фазы DMVPN; второй вариант hub принимает непосредственное участие в передаче пакета внутри VRF, выполняя перенаправление пакета, как в третьей фазе DMVPN); однако в определённых случаях может возникнуть необходимость разместить PE за spoke.

Как обычно, соберём лабу и итеративно построим рабочее решение. Ниже приведена используемая топология в рамках рассмотрения 2547oDMVPN:

Роли маршрутизаторов:

• R1, R5, R7 (and R6 later) MPLS PE;

• R3 провайдер для DMVPN;

• R2 DMVPN hub;

• R4, R6 DMVPN spokes.

Протоколы маршрутизации:

• R1-R2, R4-R5, R6-R7 OSPF на площадке организации;

• R3 OSPF провайдера, обеспечивающий связность между маршрутизаторами DMVPN;

• R1, R5, R7 (R6) MP-BGP VPNv4 AF;

• R2, R4, R6 MP-BGP IPv4 AF;

Loopback0 отвечает за идентификацию маршрутизатора в сети, например, за назначение OSPF RID. Loopback1 является интерфейсом, с которого маршрутизаторы устанавливают BGP LU сессии; причины такой настройки рассмотрены далее в статье. Loopback2 эмулирует клиентские сети внутри VRF.

Начнём с базовой конфигурации PE:

R1(config)# vrf definition AR1(config-vrf)# rd 1:1R1(config-vrf)# address-family ipv4R1(config-vrf-af)# route-target export 1:1R1(config-vrf-af)# route-target import 1:1R1(config-if)# interface Loopback0R1(config-if)# ip address 1.1.1.1 255.255.255.255R1(config)# interface Loopback2R1(config-if)# vrf forwarding AR1(config-if)# ip address 1.1.1.1 255.255.255.255R1(config)# interface FastEthernet0/0R1(config-if)# ip address 192.168.12.1 255.255.255.0R1(config-if)# mpls ldp router-id Loopback0R1(config)# router ospf 1R1(config-router)# mpls ldp autoconfigR1(config-router)# router-id 1.1.1.1R1(config-router)# network 0.0.0.0 255.255.255.255 area 0R1(config)# router bgp 1R1(config-router)# template peer-policy L3VPNR1(config-router-ptmp)# send-community bothR1(config-router-ptmp)# exit-peer-policyR1(config-router)# template peer-session SESSIONR1(config-router-stmp)# remote-as 1R1(config-router-stmp)# update-source Loopback0R1(config-router-stmp)# exit-peer-sessionR1(config-router)# bgp router-id 1.1.1.1R1(config-router)# no bgp default ipv4-unicastR1(config-router)# neighbor 5.5.5.5 inherit peer-session SESSIONR1(config-router)# neighbor 7.7.7.7 inherit peer-session SESSIONR1(config-router)# address-family vpnv4R1(config-router-af)# neighbor 5.5.5.5 activateR1(config-router-af)# neighbor 5.5.5.5 send-community extendedR1(config-router-af)# neighbor 5.5.5.5 inherit peer-policy L3VPNR1(config-router-af)# neighbor 7.7.7.7 activateR1(config-router-af)# neighbor 7.7.7.7 send-community extendedR1(config-router-af)# neighbor 7.7.7.7 inherit peer-policy L3VPNR1(config-router-af)# exit-address-familyR1(config-router)# address-family ipv4 vrf AR1(config-router-af)# redistribute connectedR1(config-router-af)# exit-address-family

R5(config)# vrf definition AR5(config-vrf)# rd 1:1R5(config-vrf)# address-family ipv4R5(config-vrf-af)# route-target export 1:1R5(config-vrf-af)# route-target import 1:1R5(config-vrf-af)# exit-address-familyR5(config-vrf)# interface Loopback0R5(config-if)# ip address 5.5.5.5 255.255.255.255R5(config-if)# interface Loopback2R5(config-if)# vrf forwarding AR5(config-if)# ip address 5.5.5.5 255.255.255.255R5(config-if)# interface FastEthernet0/0R5(config-if)# ip address 192.168.45.5 255.255.255.0R5(config-if)# mpls ldp router-id Loopback0R5(config)# router ospf 1R5(config-router)# mpls ldp autoconfigR5(config-router)# router-id 5.5.5.5R5(config-router)# network 0.0.0.0 255.255.255.255 area 0R5(config-router)# router bgp 1R5(config-router)# template peer-policy L3VPNR5(config-router-ptmp)# send-community bothR5(config-router-ptmp)# exit-peer-policyR5(config-router)# template peer-session SESSIONR5(config-router-stmp)# remote-as 1R5(config-router-stmp)# update-source Loopback0R5(config-router-stmp)# exit-peer-sessionR5(config-router)# bgp router-id 5.5.5.5R5(config-router)# no bgp default ipv4-unicastR5(config-router)# neighbor 1.1.1.1 inherit peer-session SESSIONR5(config-router)# neighbor 7.7.7.7 inherit peer-session SESSIONR5(config-router)# address-family vpnv4R5(config-router-af)# neighbor 1.1.1.1 activateR5(config-router-af)# neighbor 1.1.1.1 send-community extendedR5(config-router-af)# neighbor 1.1.1.1 inherit peer-policy L3VPNR5(config-router-af)# neighbor 7.7.7.7 activateR5(config-router-af)# neighbor 7.7.7.7 send-community extendedR5(config-router-af)# neighbor 7.7.7.7 inherit peer-policy L3VPNR5(config-router-af)# exit-address-familyR5(config-router)# address-family ipv4 vrf AR5(config-router-af)# redistribute connectedR5(config-router-af)# exit-address-family

R7(config)# vrf definition AR7(config-vrf)# rd 1:1R7(config-vrf)# address-family ipv4R7(config-vrf-af)# route-target export 1:1R7(config-vrf-af)# route-target import 1:1R7(config-vrf-af)# exit-address-familyR7(config-vrf)# interface Loopback0R7(config-if)# ip address 7.7.7.7 255.255.255.255R7(config-if)# interface Loopback2R7(config-if)# vrf forwarding AR7(config-if)# ip address 7.7.7.7 255.255.255.255R7(config-if)# interface FastEthernet0/0R7(config-if)# ip address 192.168.67.7 255.255.255.0R7(config-if)# mpls ldp router-id Loopback0R7(config)# router ospf 1R7(config-router)# mpls ldp autoconfigR7(config-router)# router-id 7.7.7.7R7(config-router)# network 0.0.0.0 255.255.255.255 area 0R7(config-router)# router bgp 1R7(config-router)# template peer-policy L3VPNR7(config-router-ptmp)# send-community bothR7(config-router-ptmp)# exit-peer-policyR7(config-router)# template peer-session SESSIONR7(config-router-stmp)# remote-as 1R7(config-router-stmp)# update-source Loopback0R7(config-router-stmp)# exit-peer-sessionR7(config-router)# bgp router-id 7.7.7.7R7(config-router)# bgp log-neighbor-changesR7(config-router)# no bgp default ipv4-unicastR7(config-router)# neighbor 1.1.1.1 inherit peer-session SESSIONR7(config-router)# neighbor 5.5.5.5 inherit peer-session SESSIONR7(config-router)# address-family ipv4R7(config-router-af)# exit-address-familyR7(config-router)# address-family vpnv4R7(config-router-af)# neighbor 1.1.1.1 activateR7(config-router-af)# neighbor 1.1.1.1 send-community extendedR7(config-router-af)# neighbor 1.1.1.1 inherit peer-policy L3VPNR7(config-router-af)# neighbor 5.5.5.5 activateR7(config-router-af)# neighbor 5.5.5.5 send-community extendedR7(config-router-af)# neighbor 5.5.5.5 inherit peer-policy L3VPNR7(config-router-af)# exit-address-familyR7(config-router)# address-family ipv4 vrf AR7(config-router-af)# redistribute connectedR7(config-router-af)# exit-address-family

Следующий шаг подключить DMVPN маршрутизаторы к локальным сегментам сети:

R2(config)# interface Loopback0R2(config-if)# ip address 2.2.2.2 255.255.255.255R2(config-if)# interface FastEthernet0/0R2(config-if)# ip address 192.168.12.2 255.255.255.0R2(config-if)# mpls ldp router-id Loopback0R2(config)# router ospf 1R2(config-router)# mpls ldp autoconfigR2(config-router)# router-id 2.2.2.2R2(config-router)# redistribute bgp 1 subnetsR2(config-router)# passive-interface defaultR2(config-router)# no passive-interface FastEthernet0/0R2(config-router)# no passive-interface Loopback0R2(config-router)# network 0.0.0.0 255.255.255.255 area 0

R4(config)# interface Loopback0R4(config-if)# ip address 4.4.4.4 255.255.255.255R4(config-if)# interface FastEthernet0/0R4(config-if)# ip address 192.168.45.4 255.255.255.0R4(config-if)# mpls ldp router-id Loopback0R4(config)#router ospf 1R4(config-router)# mpls ldp autoconfigR4(config-router)# router-id 4.4.4.4R4(config-router)# redistribute bgp 1 subnetsR4(config-router)# passive-interface defaultR4(config-router)# no passive-interface FastEthernet0/0R4(config-router)# no passive-interface Loopback0R4(config-router)# network 0.0.0.0 255.255.255.255 area 0

R6(config)# interface Loopback0R6(config-if)# ip address 6.6.6.6 255.255.255.255R6(config-if)# interface FastEthernet0/0R6(config-if)# ip address 192.168.67.6 255.255.255.0R6(config-if)# mpls ldp router-id Loopback0R6(config)# router ospf 1R6(config-router)# mpls ldp autoconfigR6(config-router)# redistribute bgp 1 subnetsR6(config-router)# passive-interface defaultR6(config-router)# no passive-interface FastEthernet0/0R6(config-router)# no passive-interface Loopback0R6(config-router)# network 0.0.0.0 255.255.255.255 area 0

Наконец последний этап подготовки к рассмотрению BGP LU настройка DMVPN. В статье использован подход front-door VRF, чтобы уменьшить объём посторонней информации в глобальной таблице маршрутизации:

R3(config)# interface Loopback0R3(config-if)# ip address 3.3.3.3 255.255.255.255R3(config-if)# interface FastEthernet0/1R3(config-if)# ip address 192.168.34.3 255.255.255.0R3(config-if)# interface FastEthernet1/0R3(config-if)# ip address 192.168.23.3 255.255.255.0R3(config-if)# interface FastEthernet1/1R3(config-if)# ip address 192.168.36.3 255.255.255.0R3(config-if)# router ospf 1R3(config-router)# router-id 3.3.3.3R3(config-router)# network 0.0.0.0 255.255.255.255 area 0

R2(config)# vrf definition FVRFR2(config-vrf)# rd 1:1R2(config-vrf)# address-family ipv4R2(config-vrf-af)# exit-address-familyR2(config-vrf)# interface Tunnel0R2(config-if)# ip address 192.168.0.2 255.255.255.0R2(config-if)# no ip redirectsR2(config-if)# ip nhrp map multicast dynamicR2(config-if)# ip nhrp network-id 1R2(config-if)# ip nhrp redirectR2(config-if)# tunnel source FastEthernet1/0R2(config-if)# tunnel mode gre multipointR2(config-if)# tunnel vrf FVRFR2(config-if)# interface FastEthernet1/0R2(config-if)# vrf forwarding FVRFR2(config-if)# ip address 192.168.23.2 255.255.255.0R2(config-if)# router ospf 2 vrf FVRFR2(config-router)# router-id 192.168.23.2R2(config-router)# network 0.0.0.0 255.255.255.255 area 0

R4(config)# vrf definition FVRFR4(config-vrf)# rd 1:1R4(config-vrf)# address-family ipv4R4(config-vrf-af)# exit-address-familyR4(config-vrf)# interface Tunnel0R4(config-if)# ip address 192.168.0.4 255.255.255.0R4(config-if)# no ip redirectsR4(config-if)# ip nhrp network-id 1R4(config-if)# ip nhrp nhs 192.168.0.2 nbma 192.168.23.2 multicastR4(config-if)# ip nhrp shortcutR4(config-if)# tunnel source FastEthernet0/1R4(config-if)# tunnel mode gre multipointR4(config-if)# tunnel vrf FVRFR4(config-if)# interface FastEthernet0/1R4(config-if)# vrf forwarding FVRFR4(config-if)# ip address 192.168.34.4 255.255.255.0R4(config-if)# router ospf 2 vrf FVRFR4(config-router)# router-id 192.168.34.4R4(config-router)# network 0.0.0.0 255.255.255.255 area 0

R6(config)# vrf definition FVRFR6(config-vrf)# rd 1:1R6(config-vrf)# address-family ipv4R6(config-vrf-af)# exit-address-familyR6(config-vrf)# interface Tunnel0R6(config-if)# ip address 192.168.0.6 255.255.255.0R6(config-if)# no ip redirectsR6(config-if)# ip nhrp network-id 1R6(config-if)# ip nhrp nhs 192.168.0.2 nbma 192.168.23.2 multicastR6(config-if)# ip nhrp shortcutR6(config-if)# tunnel source FastEthernet1/1R6(config-if)# tunnel mode gre multipointR6(config-if)# tunnel vrf FVRFR6(config-if)# interface FastEthernet1/1R6(config-if)# vrf forwarding FVRFR6(config-if)# ip address 192.168.36.6 255.255.255.0R6(config-if)# router ospf 2 vrf FVRFR6(config-router)# network 0.0.0.0 255.255.255.255 area 0

Время заняться делом. Необходимым условием для L3VPN является наличие рабочего LSP между PE. Поскольку ни LDP, ни RSVP в рамках DMVPN для этой задачи не подходят, используем MP-BGP для передачи следующей информации:

• адреса loopback;

• соответствующие им MPLS метки.

Звучит довольно просто. Что насчёт поддержки MPLS на интерфейсах?

R2# sho mpls interfacesInterface              IP            Tunnel   BGP Static OperationalFastEthernet0/0        Yes (ldp)     No       No  No     Yes  

На Tunnel0 MPLS пока не работает. Нам нужно разрешить только поддержку MPLS пакетов, не включая LDP, поэтому команда mpls ip не подходит. Впрочем, существует ещё одна менее известная команда, отвечающая нашей задаче:

R2(config)#interface Tunnel0R2(config-if)#mpls bgp forwardingR2#sho mpls interfacesInterface              IP            Tunnel   BGP Static OperationalFastEthernet0/0        Yes (ldp)     No       No  No     Yes        Tunnel0                No            No       Yes No     Yes

После выполнения этой команды на всех spoke можно приступать к настройке BGP. В этой статье мы используем iBGP между hub и spoke; hub выполняет роль route-reflector и принимает входящие BGP-соединения:

R2(config)# router bgp 1R2(config-router)# bgp router-id 2.2.2.2R2(config-router)# bgp listen range 192.168.0.0/24 peer-group DMVPNR2(config-router)# no bgp default ipv4-unicastR2(config-router)# neighbor DMVPN peer-groupR2(config-router)# neighbor DMVPN remote-as 1R2(config-router)# neighbor DMVPN update-source Tunnel0R2(config-router)# address-family ipv4R2(config-router-af)# network 1.1.1.1 mask 255.255.255.255R2(config-router-af)# neighbor DMVPN activateR2(config-router-af)# neighbor DMVPN route-reflector-clientR2(config-router-af)# neighbor DMVPN send-label

R4(config)# router bgp 1R4(config-router)# bgp router-id 4.4.4.4R4(config-router)# no bgp default ipv4-unicastR4(config-router)# neighbor 192.168.0.2 remote-as 1R4(config-router)# neighbor 192.168.0.2 update-source Tunnel0R4(config-router)# address-family ipv4R4(config-router-af)# network 5.5.5.5 mask 255.255.255.255R4(config-router-af)# neighbor 192.168.0.2 activateR4(config-router-af)# neighbor 192.168.0.2 send-label

R6(config)# router bgp 1R6(config-router)# bgp router-id 6.6.6.6R6(config-router)# no bgp default ipv4-unicastR6(config-router)# neighbor 192.168.0.2 remote-as 1R6(config-router)# neighbor 192.168.0.2 update-source Tunnel0R6(config-router)# address-family ipv4R6(config-router-af)# network 7.7.7.7 mask 255.255.255.255R6(config-router-af)# neighbor 192.168.0.2 activateR6(config-router-af)# neighbor 192.168.0.2 send-label

Проверим, есть ли IP-связность между PE:

R5#ping 1.1.1.1 so lo 0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 5.5.5.5!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 48/57/64 ms

Достаточно ли этого для связности внутри VRF?

R5#ping vrf A 1.1.1.1 so lo 0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 5.5.5.5.....Success rate is 0 percent (0/5)

К сожалению, решение несколько сложнее, чем могло бы показаться на первый взгляд. Причина отсутствия связности нерабочий LSP между PE:

R5#ping mpls ipv4 1.1.1.1/32 source 5.5.5.5Sending 5, 100-byte MPLS Echos to 1.1.1.1/32,     timeout is 2 seconds, send interval is 0 msec:Codes: '!' - success, 'Q' - request not sent, '.' - timeout,  'L' - labeled output interface, 'B' - unlabeled output interface,  'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,  'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,  'P' - no rx intf label prot, 'p' - premature termination of LSP,  'R' - transit router, 'I' - unknown upstream index,  'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.BBBBBSuccess rate is 0 percent (0/5)

Если быть точным, место отказа R4:

R4#sho mpls forwarding-table 1.1.1.1 32Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    Label      Label      or Tunnel Id     Switched      interface              19         No Label   1.1.1.1/32       1125          Tu0        192.168.0.2

Впрочем, является ли R4 местом возникновения проблемы? Разве R2 не должен был послать R4 префикс вместе с меткой?

R4#sho ip bgp labels   Network          Next Hop      In label/Out label   1.1.1.1/32       192.168.12.1   nolabel/nolabel   2.2.2.2/32       192.168.0.2    nolabel/imp-null   <output omitted>

Важное наблюдение: 1.1.1.1/32 не имеет сопутствующей MPLS метки, однако 2.2.2.2/32 ведёт себя так, как и было задумано. Также стоит обратить внимание на next-hop для 1.1.1.1/32 это адрес R1, а не R2. R2 импортировал маршрут в BGP, сохранив оригинальный next-hop из таблицы маршрутизации. Поскольку сессия между R2 и R4 iBGP, значение next-hop для 1.1.1.1/32 не меняется. Для 2.2.2.2/32 значение next-hop адрес R2. Это тонкое отличие, однако, является ключевым: BGP назначает префиксу MPLS метку только в том случае, когда BGP маршрутизатор является next-hopом для этого префикса, т.е. входит в LSP.

В нашем случае нужно назначать метку только префиксам, импортированным локально, и не менять информацию от spoke:

R2(config)#router bgp 1R2(config-router)#address-family ipv4R2(config-router-af)#neighbor PEER next-hop-self ?    all  Enable next-hop-self for both eBGP and iBGP received paths  <cr>R2(config-router-af)#neighbor PEER next-hop-self

Эта команда довольно хитрая. По умолчанию она заставляет R2 изменять next-hop для маршрутов, которые импортированы локально или получены через eBGP; если нужно изменить next-hop для всех префиксов, включая те, которые получены по iBGP, нужно добавить ключевое слово all. Появилась ли связность?

R5#ping mpls ipv4 1.1.1.1/32 source 5.5.5.5<output omitted>Type escape sequence to abort.!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 56/65/72 msR5#R5#ping vrf A 1.1.1.1 so lo 0              Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 5.5.5.5!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 52/80/108 msR5#R5#ping mpls ipv4 7.7.7.7/32 source 5.5.5.5<output omitted>Type escape sequence to abort.!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 56/60/64 msR5#R5#ping vrf A 7.7.7.7 so lo 2              Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:Packet sent with a source address of 5.5.5.5!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 48/79/104 msR5#R5#traceroute 7.7.7.7 so lo 0Type escape sequence to abort.Tracing the route to 7.7.7.7VRF info: (vrf in name/id, vrf out name/id)  1 192.168.45.4 [MPLS: Label 22 Exp 0] 88 msec 80 msec 80 msec  2 192.168.0.6 [MPLS: Label 16 Exp 0] 52 msec 64 msec 52 msec  3 192.168.67.7 40 msec 64 msec 64 msec

Мы добились работы L3VPN поверх DMVPN. Впрочем, внимательный читатель, который повторял описанные шаги в собственной лабе, мог заметить следующее предупреждение, возникающее при настройке BGP LU:

R4(config-router-af)#neighbor 192.168.0.2 send-label%BGP: For distributing MPLS labels to IBGP peers, the update source should be set to a loopback interface

Несмотря на то, что сообщение намекает на потенциальные проблемы, в нашей топологии они остались незамеченными. Рассмотрим следующую схему:

В рамках этого примера R1 устанавливает BGP сессию со своего интерфейса f0/0 до loopback интерфейса на R3, повторяя схему DMVPN. Control plane в данном случае будет работать без ошибок, тогда как связность на data plane LSP будет нарушена. Причина PHP, penultimate hop popping. Интерфейс f0/0 лежит в directly connected сети для R2, который анонсирует её с меткой implicit-null. Рассмотрим, что происходит с пакетом, который R3 отправит на R1:

1. R3 добавляет VPN метку (например, 16) к пакету;

2. R3 добавляет транспортную метку (implicit-null) к полученному MPLS кадру;

3. R3 отправляет полученный кадр в сторону R2, при этом VPN метка находится на вершине стека.

Далее возможны два исхода: R2 не знает, что делать с кадром (VPN метка отсутствует в LFIB), и отбрасывает его, или же R2 шлёт кадр в неверном направлении (случайное совпадение VPN метки в кадре и транспортной метки в LFIB). В любом случае шансы R1 на получение кадра ничтожно малы. Стоит отметить, что использование explicit-null не решит проблему, поскольку для передачи кадра всё так же будет использована нижележащая VPN метка.

Впрочем, какое это имеет отношение к нашей изначальной топологии? Описанная проблема относится к некорректно настроенным PE-маршрутизаторам. Однако эта проблема становится актуальной и в нашей топологии, если spoke превратить в PE, поскольку BGP использует Tunnel0 для установления сессии. Можно попробовать перенастроить BGP на использование loopback, хотя это ни к чему хорошему не приведёт: LSP будет разорван, т.к. некому анонсировать метки для самих loopback обычно это задача LSP/RSVP. Впрочем, решение довольно простое: можно использовать loopback только для VPNv4 AF сессий и анонсировать соответствующие метки с помощью BGP LU:

R6(config)# vrf definition AR6(config-vrf)# rd 2:2R6(config-vrf)# address-family ipv4R6(config-vrf-af)# route-target export 1:1R6(config-vrf-af)# route-target import 1:1R6(config-vrf-af)# exit-address-familyR6(config-vrf)# interface Loopback1R6(config-if)# ip address 100.0.0.6 255.255.255.255R6(config-if)# interface Loopback2R6(config-if)# vrf forwarding AR6(config-if)# ip address 6.6.6.6 255.255.255.255R6(config-if)# router bgp 1R6(config-router)# template peer-policy L3VPNR6(config-router-ptmp)# send-community bothR6(config-router-ptmp)# exit-peer-policyR6(config-router)# template peer-session SESSIONR6(config-router-stmp)# remote-as 1R6(config-router-stmp)# update-source Loopback1R6(config-router-stmp)# exit-peer-sessionR6(config-router)# neighbor 1.1.1.1 inherit peer-session SESSIONR6(config-router)# neighbor 5.5.5.5 inherit peer-session SESSIONR6(config-router)# neighbor 7.7.7.7 inherit peer-session SESSIONR6(config-router)# address-family ipv4R6(config-router-af)# network 100.0.0.6 mask 255.255.255.255R6(config-router-af)# exit-address-familyR6(config-router)# address-family vpnv4R6(config-router-af)# neighbor 1.1.1.1 activateR6(config-router-af)# neighbor 1.1.1.1 send-community extendedR6(config-router-af)# neighbor 1.1.1.1 inherit peer-policy L3VPNR6(config-router-af)# neighbor 5.5.5.5 activateR6(config-router-af)# neighbor 5.5.5.5 send-community extendedR6(config-router-af)# neighbor 5.5.5.5 inherit peer-policy L3VPNR6(config-router-af)# neighbor 7.7.7.7 activateR6(config-router-af)# neighbor 7.7.7.7 send-community extendedR6(config-router-af)# neighbor 7.7.7.7 inherit peer-policy L3VPNR6(config-router-af)# exit-address-familyR6(config-router)# address-family ipv4 vrf AR6(config-router-af)# redistribute connectedR6(config-router-af)# exit-address-family

Теперь R6 участвует в L3VPN, и можно проверить наличие связности внутри VRF:

R6#tclsh                                                      R6(tcl)#foreach x {1.1.1.1 5.5.5.5 7.7.7.7} {ping vrf A $x so lo 2}Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 6.6.6.6!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 28/59/84 msType escape sequence to abort.Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:Packet sent with a source address of 6.6.6.6!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/44 msType escape sequence to abort.Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:Packet sent with a source address of 6.6.6.6!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/16 ms

Наконец-то L3VPN поверх DMVPN работает так, как мы ожидали. Мне кажется, сложности описанной конструкции заключаются в следующем:

• обладание тайным знанием о существовании BGP LU;

• назначение MPLS метки только в том случае, если маршрутизатор является next-hopом для префикса;

• понимание, в каких случаях PHP способен сломать LSP.

В этой статье мы обсудили настройку MPLS L3VPN поверх DMVPN (2547oDMVPN) с использованием iBGP LU для распространения MPLS меток в рамках опорной сети. Отличие от документированных способов это возможность разместить PE-маршрутизатор за hub/spokes без нарушения spoke-to-spoke связности поверх DMVPN. Что касается настройки с помощью eBGP, я бы хотел оставить её как домашнее задание для любознательных читателей.

Спасибо за рецензию: Анастасии Куралевой, Максиму Климанову

Кросспостинг, оригинальная публикация

Про настройку и диагностику технологии DMVPN в интернете написано немало статей. Однако про использование мультикаста поверх DMVPN лучшее, что мне удалось найти это маленькая заметка в Configuration Guide.

In DMVPN, it is recommended to configure a Rendezvous Point (RP) at or behind the hub. If there is an IP multicast source behind a spoke, the ip pim spt-threshold infinity command must be configured on spokes to avoid multicast traffic going through spoke-to-spoke tunnels.

Давайте выясним, в чем на самом деле заключается необходимость этой команды. Тестовая схема выглядит следующим образом.

Как можно заметить, это самый обыкновенный DMVPN Phase 2, собранный в GNS3. Интерфейсы Loopback на каждом маршрутизаторе позволяют смоделировать клиентские подсети; также логично разместить RP на Hub-маршрутизаторе как центральной точке логической топологии. Для удобства адресации примем Hub = R1, Spoke1 = R2, Spoke2 = R3, Internet = R4.

Настроим PIM и RP внутри DMVPN облака:

Hub(config)#interface Loopback0Hub(config-if)#ip address 1.1.1.1 255.255.255.255Hub(config-if)#ip pim sparse-modeHub(config)#interface Tunnel0Hub(config-if)#ip address 192.168.0.1 255.255.255.0Hub(config-if)#no ip redirectsHub(config-if)#no ip split-horizon eigrp 1Hub(config-if)#ip pim sparse-modeHub(config-if)#ip nhrp map multicast dynamicHub(config-if)#ip nhrp network-id 1Hub(config-if)#tunnel source FastEthernet0/0Hub(config-if)#tunnel mode gre multipointHub(config-if)#tunnel vrf AHub(config)#ip pim rp-address 1.1.1.1

Spoke1(config)#interface Loopback0Spoke1(config-if)#ip address 2.2.2.2 255.255.255.255Spoke1(config-if)#ip pim sparse-modeSpoke1(config)#interface Tunnel0Spoke1(config-if)#ip address 192.168.0.2 255.255.255.0Spoke1(config-if)#no ip redirectsSpoke1(config-if)#ip pim sparse-modeSpoke1(config-if)#ip nhrp network-id 1Spoke1(config-if)#ip nhrp nhs 192.168.0.1 nbma 192.168.14.1 multicastSpoke1(config-if)#tunnel source FastEthernet0/1Spoke1(config-if)#tunnel mode gre multipointSpoke1(config-if)#tunnel vrf ASpoke1(config)#ip pim rp-address 1.1.1.1

Spoke2(config)#interface Loopback0Spoke2(config-if)#ip address 3.3.3.3 255.255.255.255Spoke2(config-if)#ip pim sparse-modeSpoke2(config)#interface Tunnel0Spoke2(config-if)#ip address 192.168.0.3 255.255.255.0Spoke2(config-if)#no ip redirectsSpoke2(config-if)#ip pim sparse-modeSpoke2(config-if)#ip nhrp network-id 1Spoke2(config-if)#ip nhrp nhs 192.168.0.1 nbma 192.168.14.1 multicastSpoke2(config-if)#tunnel source FastEthernet1/0Spoke2(config-if)#tunnel mode gre multipointSpoke2(config-if)#tunnel vrf ASpoke2(config)#ip pim rp-address 1.1.1.1

На данном этапе есть связность между Spoke, а также необходимые протоколы управления групповым вещанием. Самое время подписаться на мультикаст поток на Spoke1:

Spoke1(config)#int lo 0Spoke1(config-if)#ip igmp join-group 224.1.1.1Spoke1#sho ip mroute(*, 224.1.1.1), 00:00:37/00:02:22, RP 1.1.1.1, flags: SJCL  Incoming interface: Tunnel0, RPF nbr 192.168.0.1  Outgoing interface list:   Loopback0, Forward/Sparse, 00:00:37/00:02:22

Запустим сам поток в виде ICMP echo request сообщений, отправляемых на multicast адрес, на Spoke2:

Spoke2#ping 224.1.1.1 source lo0 rep 1000 Type escape sequence to abort.Sending 1000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:Packet sent with a source address of 3.3.3.3Reply to request 0 from 2.2.2.2, 156 ms....

Не работает, причём довольно хитрым образом: первый пакет проходит (мы получаем на него ответ), однако последующие почему-то пропадают. Взглянем на то, что происходит в данный момент, на уровне пакетов.

Spoke1:

Hub:

Итак, это Hub не шлёт пакеты потока после обработки самого первого пакета. С чего бы вдруг?

Hub#sho ip mroute<output omitted>(*, 224.1.1.1), 00:03:31/00:02:55, RP 1.1.1.1, flags: SP  Incoming interface: Null, RPF nbr 0.0.0.0  Outgoing interface list: Null(3.3.3.3, 224.1.1.1), 00:03:08/00:02:46, flags: PJT  Incoming interface: Tunnel0, RPF nbr 192.168.0.3  Outgoing interface list: Null

Список OIL (outgoing interface list) пуст, что и является причиной потери потока. Или не является? Почему же тогда прошёл самый первый пакет? Давайте взглянем на Hub за пару секунд до того:

Hub#sho ip mroute<output omitted>(*, 224.1.1.1), 00:00:13/00:03:16, RP 1.1.1.1, flags: S  Incoming interface: Null, RPF nbr 0.0.0.0  Outgoing interface list:   Tunnel0, Forward/Sparse, 00:00:13/00:03:16

(*,G) содержит Tunnel0, что ожидаемо; RPF сосед также пока неизвестен, поскольку ни один пакет из потока ещё не прошёл через Hub. А дальше следите за руками:

1. Spoke2 шлёт самый первый мультикаст пакет внутри unicast сообщения RP-Register;

2. Hub, он же RP, получает RP-Register и выполняет следующие два действия: отправляет пакет согласно OIL (Tunnel0); кроме того, отправляет PIM Join в сторону источника потока (Tunnel0);

3. В режиме PIM-SM входящий интерфейс (IIF, incoming interface) не может присутствовать в OIL (RPF check), поскольку это может породить петлю; следовательно, Tunnel0 необходимо исключить из OIL в этот момент Spoke2 теряет поток.

Суть проблемы кроется в NBMA (non-broadcast multiple access) поведении DMVPN: Spoke2 логически находится в одном широковещательном сегменте со Spoke1, хотя физически это совсем не так (а Вы думали, Frame-Relay жил, Frame-Relay жив, Frame-Relay будет жить; надеюсь, это шутка). Впрочем, решение задачи довольно простое надо явно указать Hub, что Tunnel0 следует рассматривать не как один интерфейс, а как набор нескольких:

Hub(config)#interface Tunnel0Hub(config-if)#ip pim nbma-mode

Теперь таблица маршрутизации мультикаста правильная:

Hub#sho ip mroute(*, 224.1.1.1), 00:03:51/00:03:27, RP 1.1.1.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list:  Tunnel0, 192.168.0.2, Forward/Sparse, 00:00:02/00:03:27(3.3.3.3, 224.1.1.1), 00:03:29/00:02:25, flags: JT  Incoming interface: Tunnel0, RPF nbr 192.168.0.3 Outgoing interface list:   Tunnel0, 192.168.0.2, Forward/Sparse, 00:00:02/00:03:27

Поскольку Tunnel0 теперь работает как несколько интерфейсов, таблица маршрутизации мультикаста содержит не только сам интерфейс, но и адреса как получателя (192.168.0.2), так и отправителя (192.168.0.3) потока. Стоит отметить ещё одну любопытную особенность поведения DMVPN, когда поток мультикаста идёт со стороны Hub в сторону Spoke. По умолчанию, DMVPN отправляет мультикаст каждому Spoke (ip nhrp map multicast dynamic), что успешно используют протоколы маршрутизации, отправляя служебную информацию или обновления мультикастом. Однако если сеть является географически распределённой (например, несколько регионов), такое поведение может быть нежелательным: мультикаст, отправленный во все регионы, в том числе туда, где нет PIM подписки, занимает полосу, после чего его отбрасывают все Spoke, кроме того, кому поток был действительно нужен. Такое поведение можно исправить использованием PIM NBMA режима для DMVPN, что позволяет различать Spoke по адресам на уровне мультикаста и отправлять поток только тем регионам, где на него есть подписка.

Настало время ещё раз проверить связность между Spoke для мультикаста:

Spoke2#ping 224.1.1.1 so lo 0 rep 1000 Type escape sequence to abort.Sending 1000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:Packet sent with a source address of 3.3.3.3 Reply to request 0 from 2.2.2.2, 176 ms....

Ничего не поменялось, но мы упорные. Начнём проверять по порядку, начиная с Hub:

Hub#sho ip mroute(*, 224.1.1.1), 00:52:32/00:02:58, RP 1.1.1.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list:  Tunnel0, 192.168.0.2, Forward/Sparse, 00:02:12/00:02:58(3.3.3.3, 224.1.1.1), 00:01:30/00:01:31, flags: PT Incoming interface: Tunnel0, RPF nbr 192.168.0.3  Outgoing interface list: Null

(S,G) запись неактивна (флаг P) на Hub, соответственно, OIL пуст. Очевидно, что это дело рук Spoke1, больше некому:

Spoke1#sho ip mroute<output omitted>(*, 224.1.1.1), 00:52:44/stopped, RP 1.1.1.1, flags: SJCL Incoming interface: Tunnel0, RPF nbr 192.168.0.1 Outgoing interface list:  Loopback0, Forward/Sparse, 00:09:18/00:02:26(3.3.3.3, 224.1.1.1), 00:01:39/00:01:20, flags: LJT Incoming interface: Tunnel0, RPF nbr 192.168.0.3 Outgoing interface list:   Loopback0, Forward/Sparse, 00:01:39/00:02:26

Вроде бы таблица правильная Но нет: RPF сосед Spoke 2, а должен быть Hub. Посмотрим внимательно на весь процесс ещё раз.

1. Spoke2 отправляет первый пакет потока внутри RP-Register;

2. Hub пересылает пакет Spoke1 и начинает построение SPT дерева в сторону Spoke2;

3. Spoke1 получает первый пакет, создаёт новое состояние для потока в таблице маршрутизации, высылает ответ.

4. Spoke1 осознаёт, что RPF сосед для источника мультикаста это Spoke2, поэтому он отправляет SPT-Join в сторону Spoke2. Однако в силу NBMA поведения DMVPN, физически SPT-Join идёт в сторону Hub. Последний его с радостью отбрасывает, поскольку внутри пакета в качестве RPF соседа указан Spoke2.

5. IIF для RPT и SPT один и тот же, Tunnel0, поэтому Spoke1 отправляет сообщение (*,G) Prune в сторону Hub, где он и обрабатывается.

В результате, Hub отключает у себя (*,G) запись, а Spoke1 не может завершить создание (S,G) записи в таблице маршрутизации, что приводит к нарушению связности между Spoke.Корень зла в этом случае SPT-switchover: между Spoke нет прямой связности для мультикаста, единственный доступный путь через Hub. В конце концов, мы пришли к команде, которая упоминается в Configuration Guide ip pim spt-threshold infinity. Неужели теперь связность появится?

Spoke2#ping 224.1.1.1 so lo 0 rep 1000 Type escape sequence to abort.Sending 1000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:Packet sent with a source address of 3.3.3.3 Reply to request 0 from 2.2.2.2, 112 msReply to request 1 from 2.2.2.2, 84 msReply to request 2 from 2.2.2.2, 76 msReply to request 3 from 2.2.2.2, 80 msReply to request 4 from 2.2.2.2, 52 msReply to request 5 from 2.2.2.2, 48 ms

На данном этапе мультикаст работает, как и ожидалось вначале. Поток может быть передан в любом направлении (hub-spoke, spoke-spoke, spoke-hub), причём только в сторону тех Spoke, которые на него подписались. Стоит отметить, однако, что передача мультикаста напрямую между Spoke чревата повышением нагрузки на канал вследствие рассылки мультикаста внутри направленных пакетов; канал до Spoke на такую нагрузку, как правило, не рассчитан, что может привести как к проблемам с масштабированием решения, так и к ухудшению связности для существующих приложений.

В статье мы рассмотрели, что необходимо добавить к обычному DMVPN Phase 2, чтобы успешно запустить поверх него мультикаст. К тонким моментам можно отнести, пожалуй, только режим PIM NBMA и SPT-switchover это единственное отличие от общеизвестных настроек DMVPN Phase 2.