O artigo pressupõe que o leitor já tenha um entendimento dos conceitos básicos do MPLS L3VPN .Oi Suponha que você seja um
ISP . E, como qualquer ISP razoavelmente grande, o núcleo da sua rede é baseado em IP / MPLS. Se você simplificá-lo completamente, sua rede pode ser representada pelo circuito mostrado acima. Suponhamos também que você, como ISP, venda a seus clientes o serviço L3VPN, implementado em sua rede de acordo com a RFC 4364 (VPNs BGP / MPLS IP). E caso o cliente L3VPN em um determinado site não tenha redes diretamente conectadas suficientes e deseje anunciar rotas adicionais para outros sites, você cria uma sessão BGP entre seu equipamento (PE) e o equipamento do cliente (CE), através do qual o cliente pode anunciar o desejado rotas. Com tudo isso, você não aplica nenhum filtro / política a esta sessão, sendo guiado pelo fato de ser um cliente VPN, e é livre para "dirigir" o que quiser nele (dentro do limite do número de prefixos, por exemplo). E agora atenção, a pergunta é: o que acontece se, dentro da estrutura desta sessão do BGP, o cliente anuncia as rotas para você (o provedor), adicionando a comunidade de destino da rota a elas? Pode ser, por exemplo, o resultado de um erro ou o desejo de experimentar.
Apenas no caso, lembramos que o Target Route é uma das comunidades BGP estendidas especiais usadas no MPLS L3VPN para selecionar VRF, na tabela de roteamento da qual é necessário definir a rota que veio através do MP-BGP. E como o RT é uma comunidade, então, em teoria, nada nos impede de adicioná-lo às rotas IPv4 regulares.
Voltemos à questão do que pode acontecer se o CE anunciar rotas marcadas com RT no PE (não há políticas de BGP no PE). Após um pouco de reflexão, podemos assumir que existem três resultados diferentes:
- O PE descartará esse anúncio.
- O PE removerá o RT do anúncio, adicionará o VRF RT correspondente a ele e enviará o anúncio para outros PEs.
- O PE aceitará o anúncio inalterado, incluirá o VRF RT correspondente (ou seja, dois RTs já estarão contidos no anúncio) e enviará o anúncio para outros PEs.
A mais interessante e ao mesmo tempo perigosa para o provedor de serviços, é claro, é a última opção. Nesse caso, o cliente pode potencialmente interromper o roteamento em outros VRFs, tanto internos como tecnológicos.
Mas adivinhem, vamos verificar. Para maior interesse, verificaremos imediatamente em vários sistemas operacionais de rede. No Eve-NG, o seguinte esquema foi construído:
Lista de participantes do teste:
- Mikrotik CHR , roteadorOS 6.40.8
- VSR - Nokia VSR, TiMOS 15.0.R6
- vMX - Juniper vMX, JUNOS 14.1R1.10
- XRv - Cisco XRv, IOS-XR 6.1.1
- 3725 - Cisco 3725 (Dynamips), IOS 12.4
Roteadores auxiliares:
- Remote-PE - Cisco 3725 (Dynamips), IOS 12.4
- CE - Mikrotik CHR, roteadorOS 6.40.8
Descrição do circuito:
- Participantes de teste - Roteadores PE. O VRF-100 (RT 65001: 100) foi criado em cada um deles; no âmbito deste VRF-100, uma sessão BGP com CE foi organizada sem filtros / políticas.
- Cada um dos PEs testados possui uma sessão MP-BGP com um roteador Remote_PE, através do qual passa rotas VRF.
- O roteador CE possui 5 subinterfaces (1 para cada PE), em cada subinterface a sessão do BGP é aumentada para o CE correspondente. Cada PE é anunciado com seu próprio prefixo do formulário 1.1.1. N / 32, onde N é o número de sequência do PE da esquerda para a direita. Com a política de exportação da CE, a comunidade RT: 65001: 200 é adicionada a cada um desses prefixos.
- Dois VRFs foram criados no Remote_PE: VRF-100 (RT 65001: 100) e VRF-200 (RT 65001: 200)
- O transporte MPLS, roteadores P, RR e outras alegrias que geralmente estão presentes em uma rede real são omitidos aqui, porque isso não importa para nós aqui.
Para quem não estiver satisfeito com a descrição "apenas em palavras", trarei as configurações de todos os dispositivos envolvidos.
CE/interface vlan add interface=ether1 name=ether1.10 vlan-id=10 add interface=ether1 name=ether1.20 vlan-id=20 add interface=ether1 name=ether1.30 vlan-id=30 add interface=ether1 name=ether1.40 vlan-id=40 add interface=ether1 name=ether1.50 vlan-id=50 /interface wireless security-profiles set [ find default=yes ] supplicant-identity=MikroTik /routing bgp instance set default as=65002 /ip address add address=192.168.30.2/24 interface=ether1.30 network=192.168.30.0 add address=192.168.10.2/24 interface=ether1.10 network=192.168.10.0 add address=192.168.20.2/24 interface=ether1.20 network=192.168.20.0 add address=192.168.40.2/24 interface=ether1.40 network=192.168.40.0 add address=192.168.50.2/24 interface=ether1.50 network=192.168.50.0 /ip dhcp-client add disabled=no interface=ether3 add disabled=no interface=ether1.30 /ip route add distance=1 dst-address=1.1.1.1/32 type=blackhole add distance=1 dst-address=1.1.1.2/32 type=blackhole add distance=1 dst-address=1.1.1.3/32 type=blackhole add distance=1 dst-address=1.1.1.4/32 type=blackhole add distance=1 dst-address=1.1.1.5/32 type=blackhole /routing bgp network add network=1.1.1.3/32 add network=1.1.1.1/32 add network=1.1.1.2/32 add network=1.1.1.4/32 add network=1.1.1.5/32 /routing bgp peer add comment=VMX name=VMX out-filter=TO-VMX remote-address=192.168.30.1 \ remote-as=65001 add comment=CHR name=CHR out-filter=TO-CHR remote-address=192.168.10.1 \ remote-as=65001 add comment=VSR name=VSR out-filter=TO-VSR remote-address=192.168.20.1 \ remote-as=65001 add comment=XRV name=XRV out-filter=TO-XRV remote-address=192.168.40.1 \ remote-as=65001 add comment=3725 name=3725 out-filter=TO-3725 remote-address=192.168.50.1 \ remote-as=65001 /routing filter add action=accept chain=TO-VMX prefix=1.1.1.3 set-route-targets=65001:200 add action=accept chain=TO-CHR prefix=1.1.1.1 set-route-targets=65001:200 add action=accept chain=TO-VSR prefix=1.1.1.2 set-route-targets=65001:200 add action=accept chain=TO-XRV prefix=1.1.1.4 set-route-targets=65001:200 add action=accept chain=TO-3725 prefix=1.1.1.5 set-route-targets=65001:200 add action=discard chain=TO-VMX add action=discard chain=TO-CHR add action=discard chain=TO-VSR add action=discard chain=TO-XRV add action=discard chain=TO-3725 /system identity set name=CE
CHR /interface bridge add name=lo0 protocol-mode=none /interface vlan add interface=ether1 name=ether1.10 vlan-id=10 add interface=ether2 name=ether2.10 vlan-id=10 /interface wireless security-profiles set [ find default=yes ] supplicant-identity=MikroTik /routing bgp instance set default as=65001 add as=65001 name=vrf-100 redistribute-other-bgp=yes router-id=192.168.10.1 \ routing-table=VRF-100 /ip address add address=192.168.10.1/24 interface=ether1.10 network=192.168.10.0 add address=10.0.1.1/24 interface=ether2.10 network=10.0.1.0 add address=10.1.1.1 interface=lo0 network=10.1.1.1 /ip dhcp-client add disabled=no interface=ether1 /ip route vrf add export-route-targets=65001:100 import-route-targets=65001:100 interfaces=\ ether1.10 route-distinguisher=65001:100 routing-mark=VRF-100 /routing bgp instance vrf add redistribute-other-bgp=yes routing-mark=VRF-100 /routing bgp peer add address-families=vpnv4 comment=remote_PE name=remote_PE remote-address=\ 10.10.10.10 remote-as=65001 update-source=lo0 add comment=CE instance=vrf-100 name=CE remote-address=192.168.10.2 \ remote-as=65002 /routing ospf network add area=backbone network=10.0.0.0/8 /system identity set name=CHR
Vsr # TiMOS-B-15.0.R6 both/x86_64 Nokia 7750 SR Copyright (c) 2000-2017 Nokia. # All rights reserved. All use subject to applicable license agreements. # Built on Mon Nov 20 12:58:19 PST 2017 by builder in /builds/150B/R6/panos/main # Generated MON JAN 01 00:32:55 2018 UTC exit all configure #-------------------------------------------------- echo "System Configuration" #-------------------------------------------------- system snmp shutdown exit time sntp shutdown exit zone UTC exit exit #-------------------------------------------------- echo "System Security Configuration" #-------------------------------------------------- system security dist-cpu-protection policy "_default-access-policy" create exit policy "_default-network-policy" create exit exit exit exit #-------------------------------------------------- echo "Log Configuration" #-------------------------------------------------- log exit #-------------------------------------------------- echo "Card Configuration" #-------------------------------------------------- card 1 card-type iom-v mda 1 mda-type m20-v no shutdown exit no shutdown exit #-------------------------------------------------- echo "Port Configuration" #-------------------------------------------------- port 1/1/1 description "CE" ethernet mode hybrid encap-type qinq exit no shutdown exit port 1/1/2 description "remote_PE" ethernet mode hybrid encap-type qinq exit no shutdown exit port 1/1/3 shutdown ethernet exit exit port 1/1/4 shutdown ethernet exit exit #-------------------------------------------------- echo "Management Router Configuration" #-------------------------------------------------- router management exit #-------------------------------------------------- echo "Router (Network Side) Configuration" #-------------------------------------------------- router Base interface "remote_PE" address 10.0.2.1/24 port 1/1/2:20.* no shutdown exit interface "system" address 10.2.2.2/32 no shutdown exit autonomous-system 65001 #-------------------------------------------------- echo "OSPFv2 Configuration" #-------------------------------------------------- ospf 0 area 0.0.0.0 interface "system" no shutdown exit interface "remote_PE" mtu 1500 no shutdown exit exit no shutdown exit exit #-------------------------------------------------- echo "Service Configuration" #-------------------------------------------------- service customer 1 create description "Default customer" exit vprn 100 customer 1 create autonomous-system 65001 route-distinguisher 65001:100 vrf-target target:65001:100 interface "CE" create address 192.168.20.1/24 sap 1/1/1:20.0 create exit exit bgp group "CE" type external export "TO-CE" peer-as 65002 neighbor 192.168.20.2 exit exit no shutdown exit service-name "VRF-100" no shutdown exit exit #-------------------------------------------------- echo "Router (Service Side) Configuration" #-------------------------------------------------- router Base #-------------------------------------------------- echo "OSPFv2 Configuration" #-------------------------------------------------- ospf 0 no shutdown exit #-------------------------------------------------- echo "Policy Configuration" #-------------------------------------------------- policy-options begin policy-statement "TO-CE" entry 10 action accept exit exit exit commit exit #-------------------------------------------------- echo "BGP Configuration" #-------------------------------------------------- bgp group "remote_PE" family vpn-ipv4 type internal local-address system neighbor 10.0.2.2 exit exit no shutdown exit exit exit all
vMX ## Last commit: 2018-05-25 12:37:27 UTC by root version 14.1R1.10; system { host-name vmx01; root-authentication { encrypted-password "$1$zA/8snt5$g3mYVmz7MzTZZOhtjRX6g1"; ## SECRET-DATA } } interfaces { ge-0/0/0 { vlan-tagging; encapsulation flexible-ethernet-services; unit 30 { vlan-id 30; family inet { address 192.168.30.1/24; } } } ge-0/0/1 { vlan-tagging; encapsulation flexible-ethernet-services; unit 30 { vlan-id 30; family inet { address 10.0.3.1/24; } } } lo0 { unit 0 { family inet { address 10.3.3.3/32; } } } } routing-options { autonomous-system 65001; } protocols { bgp { group remote_PE { type internal; local-address 10.3.3.3; family inet-vpn { unicast; } neighbor 10.10.10.10; } } ospf { area 0.0.0.0 { interface lo0.0; interface ge-0/0/1.30; } } } routing-instances { VRF-100 { instance-type vrf; interface ge-0/0/0.30; route-distinguisher 65001:100; vrf-target target:65001:100; protocols { bgp { group CE { type external; peer-as 65002; neighbor 192.168.30.2; } } } } }
Xrv !! IOS XR Configuration 6.1.1 !! Last configuration change at Fri May 25 15:24:01 2018 by Cisco ! hostname XRv vrf VRF-100 address-family ipv4 unicast import route-target 65001:100 ! export route-target 65001:100 ! ! ! interface Loopback0 no shutdown ipv4 address 10.4.4.4 255.255.255.255 ! interface MgmtEth0/0/CPU0/0 no shutdown shutdown ! interface GigabitEthernet0/0/0/0.40 no shutdown vrf VRF-100 ipv4 address 192.168.40.1 255.255.255.0 encapsulation dot1q 40 ! interface GigabitEthernet0/0/0/1.40 no shutdown ipv4 address 10.0.4.1 255.255.255.0 encapsulation dot1q 40 ! interface GigabitEthernet0/0/0/2 no shutdown shutdown ! route-policy TO-CE pass end-policy ! route-policy FROM-CE pass end-policy ! router ospf main area 0 interface Loopback0 ! interface GigabitEthernet0/0/0/1.40 ! ! ! router bgp 65001 address-family ipv4 unicast ! address-family vpnv4 unicast ! neighbor 10.10.10.10 remote-as 65001 update-source Loopback0 address-family vpnv4 unicast ! ! vrf VRF-100 rd 65001:100 bgp router-id 192.168.40.1 address-family ipv4 unicast ! neighbor 192.168.40.2 remote-as 65002 address-family ipv4 unicast route-policy FROM-CE in route-policy TO-CE out ! ! ! ! end
3725 ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname 3725 ! boot-start-marker boot-end-marker ! ! no aaa new-model memory-size iomem 5 ip cef ! ! ! ! ip vrf VRF-100 rd 65001:100 route-target export 65001:100 route-target import 65001:100 ! no ip domain lookup ! multilink bundle-name authenticated ! ! ! archive log config hidekeys ! ! ! interface Loopback0 ip address 10.5.5.5 255.255.255.255 ! interface FastEthernet0/0 no ip address duplex auto speed auto ! interface FastEthernet0/0.50 encapsulation dot1Q 50 ip vrf forwarding VRF-100 ip address 192.168.50.1 255.255.255.0 ! interface FastEthernet0/1 no ip address duplex auto speed auto ! interface FastEthernet0/1.50 encapsulation dot1Q 50 ip address 10.0.5.1 255.255.255.0 ! router ospf 123 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 65001 no bgp default ipv4-unicast no bgp default route-target filter bgp log-neighbor-changes neighbor 10.10.10.10 remote-as 65001 neighbor 10.10.10.10 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.10 activate neighbor 10.10.10.10 send-community extended exit-address-family ! address-family ipv4 vrf VRF-200 no synchronization exit-address-family ! address-family ipv4 vrf VRF-100 neighbor 192.168.50.2 remote-as 65002 neighbor 192.168.50.2 activate neighbor 192.168.50.2 soft-reconfiguration inbound no synchronization exit-address-family ! ip forward-protocol nd ! ! ip http server no ip http secure-server ! ! ! control-plane ! ! ! line con 0 line aux 0 line vty 0 4 ! ! end
Remote_PE ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname remote_PE ! boot-start-marker boot-end-marker ! ! no aaa new-model memory-size iomem 5 ip cef ! ! ! ! ip vrf VRF-100 rd 65001:100 route-target export 65001:100 route-target import 65001:100 ! ip vrf VRF-200 rd 65001:200 route-target export 65001:200 route-target import 65001:200 ! ! multilink bundle-name authenticated ! ! ! ! archive log config hidekeys ! ! ! ! interface Loopback0 ip address 10.10.10.10 255.255.255.255 ! interface FastEthernet0/0 no ip address duplex auto speed auto ! interface FastEthernet0/0.10 description CHR encapsulation dot1Q 10 ip address 10.0.1.2 255.255.255.0 ! interface FastEthernet0/0.20 encapsulation dot1Q 20 ip address 10.0.2.2 255.255.255.0 ! interface FastEthernet0/0.30 encapsulation dot1Q 30 ip address 10.0.3.2 255.255.255.0 ! interface FastEthernet0/0.40 encapsulation dot1Q 40 ip address 10.0.4.2 255.255.255.0 ! interface FastEthernet0/0.50 encapsulation dot1Q 50 ip address 10.0.5.2 255.255.255.0 ! interface FastEthernet0/1 no ip address shutdown duplex auto speed auto ! router ospf 123 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 65001 no bgp default ipv4-unicast no bgp default route-target filter bgp log-neighbor-changes neighbor 10.1.1.1 remote-as 65001 neighbor 10.2.2.2 remote-as 65001 neighbor 10.3.3.3 remote-as 65001 neighbor 10.4.4.4 remote-as 65001 neighbor 10.5.5.5 remote-as 65001 ! address-family vpnv4 neighbor 10.1.1.1 activate neighbor 10.1.1.1 send-community extended neighbor 10.2.2.2 activate neighbor 10.2.2.2 send-community extended neighbor 10.3.3.3 activate neighbor 10.3.3.3 send-community extended neighbor 10.4.4.4 activate neighbor 10.4.4.4 send-community extended neighbor 10.5.5.5 activate neighbor 10.5.5.5 send-community extended exit-address-family ! address-family ipv4 vrf VRF-200 no synchronization exit-address-family ! address-family ipv4 vrf VRF-100 redistribute connected no synchronization exit-address-family ! ip forward-protocol nd ! ! ip http server no ip http secure-server ! ! control-plane ! ! ! line con 0 line aux 0 line vty 0 4 login ! ! end
Anúncios CE-> PE
Portanto, o experimento é simples: com a CE, anunciaremos as rotas marcadas RT: 65001: 200, no Remote-PE, veremos se essas rotas aparecem na tabela de roteamento VRF-200.
Primeiro, verifique a tabela de roteamento do VRF-100:
remote_PE#show ip route vrf VRF-100 1.1.1.0 255.255.255.0 longer-prefixes Routing Table: VRF-100 Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 5 subnets B 1.1.1.1 [200/0] via 10.1.1.1, 00:01:02 B 1.1.1.3 [200/0] via 10.3.3.3, 05:19:08 B 1.1.1.2 [200/0] via 10.2.2.2, 00:02:47 B 1.1.1.5 [200/0] via 10.5.5.5, 01:36:05 B 1.1.1.4 [200/0] via 10.4.4.4, 02:32:21 remote_PE#
Recebemos rotas de todos os 5 PE. Agora verifique se alguma dessas rotas está no VRF-200:
remote_PE#show ip route vrf VRF-200 Routing Table: VRF-200 Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 3 subnets B 1.1.1.1 [200/0] via 10.1.1.1, 00:01:24 B 1.1.1.3 [200/0] via 10.3.3.3, 05:19:29 B 1.1.1.2 [200/0] via 10.2.2.2, 00:03:08 remote_PE#
As rotas do CHR, vMX e VSR acabaram no VRF-200. Isso significa que a comunidade RT: 65001: 200 adicionada ao CE foi salva por esses PEs.
Ao mesmo tempo, as rotas do XRv e 3725 estão disponíveis apenas no VRF-100. Isso significa que os roteadores Cisco removeram a comunidade RT: 65001: 200 do anúncio.
Anúncios PE-> CE
Não vamos parar por aí e verificar como os anúncios se comportam na direção oposta, ou seja, de PE para CE. Modificaremos ligeiramente as configurações existentes.
No Remote_PE, crie um loopback cujo endereço
100.100.100.100/32 será anunciado por outro PE:
interface Loopback100 ip vrf forwarding VRF-100 ip address 100.100.100.100 255.255.255.255 ! router bgp 65001 address-family ipv4 vrf VRF-100 redistribute connected exit-address-family !
No vMX, lembre-se de que não configuramos o transporte MPLS, o que significa que a tabela inet.3 está vazia e a rota do Remote_PE ficará oculta. Copie as rotas OSPF para inet.
set routing-options rib-groups RG-INET3 import-rib [ inet.0 inet.3 ] set protocols ospf rib-group RG-INET3
No restante dos roteadores, as configurações atuais devem ser suficientes.
Observamos as rotas no CE:
[admin@CE] > ip route print detail where dst-address=100.100.100.100/32 Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 0 ADb dst-address=100.100.100.100/32 gateway=192.168.20.1 gateway-status=192.168.20.1 reachable via ether1.20 distance=20 scope=40 target-scope=10 bgp-as-path="65001" bgp-origin=incomplete bgp-ext-communities="RT:65001:100" received-from=VSR 1 Db dst-address=100.100.100.100/32 gateway=192.168.50.1 gateway-status=192.168.50.1 reachable via ether1.50 distance=20 scope=40 target-scope=10 bgp-as-path="65001" bgp-origin=incomplete received-from=3725 2 Db dst-address=100.100.100.100/32 gateway=192.168.10.1 gateway-status=192.168.10.1 reachable via ether1.10 distance=20 scope=40 target-scope=10 bgp-as-path="65001" bgp-origin=incomplete bgp-ext-communities="RT:65001:100" received-from=CHR 3 Db dst-address=100.100.100.100/32 gateway=192.168.30.1 gateway-status=192.168.30.1 reachable via ether1.30 distance=20 scope=40 target-scope=10 bgp-as-path="65001" bgp-origin=incomplete bgp-ext-communities="RT:65001:100" received-from=VMX 4 Db dst-address=100.100.100.100/32 gateway=192.168.40.1 gateway-status=192.168.40.1 reachable via ether1.40 distance=20 scope=40 target-scope=10 bgp-as-path="65001" bgp-origin=incomplete received-from=XRV
Todos os roteadores, exceto a Cisco, deixaram o Route Target no anúncio da rota. A Cisco não fez isso apenas porque qualquer comunidade foi enviada a eles por padrão. Corrija.
3725: *
router bgp 65001 address-family ipv4 vrf VRF-100 neighbor 192.168.50.2 send-community extended
XRv: *
router bgp 65001 vrf VRF-100 neighbor 192.168.40.2 address-family ipv4 unicast send-extended-community-ebgp
* O uso desses comandos não altera os resultados do primeiro experimento de forma alguma com os anúncios CE-> PE.Agora observe a rota no CE novamente:
[admin@CE] > ip route print detail where dst-address=100.100.100.100/32 Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 0 ADb dst-address=100.100.100.100/32 gateway=192.168.20.1 gateway-status=192.168.20.1 reachable via ether1.20 distance=20 scope=40 target-scope=10 bgp-as-path="65001" bgp-origin=incomplete bgp-ext-communities="RT:65001:100" received-from=VSR 1 Db dst-address=100.100.100.100/32 gateway=192.168.50.1 gateway-status=192.168.50.1 reachable via ether1.50 distance=20 scope=40 target-scope=10 bgp-as-path="65001" bgp-origin=incomplete bgp-ext-communities="RT:65001:100" received-from=3725 2 Db dst-address=100.100.100.100/32 gateway=192.168.10.1 gateway-status=192.168.10.1 reachable via ether1.10 distance=20 scope=40 target-scope=10 bgp-as-path="65001" bgp-origin=incomplete bgp-ext-communities="RT:65001:100" received-from=CHR 3 Db dst-address=100.100.100.100/32 gateway=192.168.30.1 gateway-status=192.168.30.1 reachable via ether1.30 distance=20 scope=40 target-scope=10 bgp-as-path="65001" bgp-origin=incomplete bgp-ext-communities="RT:65001:100" received-from=VMX 4 Db dst-address=100.100.100.100/32 gateway=192.168.40.1 gateway-status=192.168.40.1 reachable via ether1.40 distance=20 scope=40 target-scope=10 bgp-as-path="65001" bgp-origin=incomplete bgp-ext-communities="RT:65001:100" received-from=XRV
Agora, absolutamente todos os PEs enviam rotas com a indicação de RT para CE.
Um resultado semelhante a mim pessoalmente parecia um pouco estranho. Se a preservação da RT no anúncio do CE-> PE pode ser teoricamente considerada uma aplicação, então no anúncio do PE-> CE o RT parece informações obviamente desnecessárias.
Além disso, a existência de fenômenos de conservação de TR tanto para CE-> PE, quanto para PE-> CE, poderia potencialmente ter um impacto negativo na opção A.
Título "O que a RFC nos diz"
A RFC 4364 , mencionada no início do artigo, afirma especificamente isso:
Se o PE e o CE são eles próprios pares de BGP, então
o SP pode permitir ao cliente, dentro de certos limites, especificar como
rotas devem ser distribuídas. O SP e o cliente precisariam
concordar com antecedência sobre o conjunto de TRs que podem ser anexados a
rotas de VPN do cliente. O CE poderia então anexar um ou mais dos
esses RTs para cada rota IP que distribui para o PE. Isso dá
ao cliente a liberdade de especificar em tempo real, dentro dos prazos acordados
limites, suas políticas de distribuição de rotas. Se o CE for autorizado a
anexar RTs às suas rotas, o PE DEVE filtrar todas as rotas que
contêm RTs que o cliente não tem permissão para usar. Se o CE é
não tem permissão para anexar RTs às suas rotas, mas de qualquer maneira, o PE
DEVE remover o RT antes de converter a rota do cliente em um VPN-
Rota IPv4.
Assim, a preservação da RT nos anúncios CE-> PE tem uma base completamente legal, embora a aplicação prática disso me pareça um tanto duvidosa.
Sobre a RT nos anúncios PE-> CE, nada é dito na RFC.
Remova o RT das sessões com CE
Tudo está claro com a Cisco com antecedência. Nos anúncios CE-> PE, todos os RTs são excluídos categoricamente (não foi possível encontrar um comando que alterasse esse comportamento). Nos anúncios PE-> CE, o RT está ausente por padrão, é suficiente para não permitir o envio de comunidades estendidas.
Vamos descobrir como se livrar da RT em outros participantes de nossos testes.
Juniper
Tudo o que você precisa para remover a RT dos anúncios (PE-> CE e CE-> PE) é criar uma política e o primeiro termo para remover todas as comunidades começando com "target:", fornecendo o prefixo para processamento nos seguintes termos.
Por exemplo, se queremos aceitar e anunciar todas as rotas, basta remover a RT delas:
edit policy-options set community RT-ALL members target:.+:.+ set policy-statement TO-CE term 10 then community delete RT-ALL set policy-statement TO-CE term 10 then next term set policy-statement TO-CE then accept copy policy-statement TO-CE to policy-statement FROM-CE
Nokia
Para desativar o envio de comunidades estendidas para um ponto BGP, você pode usar o comando:
configure service vprn "VRF-100" bgp group "CE" disable-communities extended
Para remover a RT dos anúncios da CE, é necessário criar uma política semelhante à como foi feita no Juniper e aplicá-la a uma sessão com a CE.
configure router policy-options begin community "RT-ALL" members "target:.+&.+" policy-statement FROM-CE entry 10 action next-entry community remove "RT-ALL" exit exit default-action accept exit exit commit
Mikrotik
Mas com Mikrotik, a decepção nos espera. Simplesmente não há mecanismo para remover a RT do anúncio. Parece que no filtro de roteamento existe um parâmetro set-route-target e faria algo como
/routing filter add chain=TO-CE set-route-targets="" action=passthrough add chain=TO-CE action=accept
mas, infelizmente, set-route-target = "" significa que esse parâmetro (set-route-target) precisa ser completamente removido da regra. Um exemplo:
[admin@CE] /routing filter> add chain=TO-CE action=passthrough set-route-targets="" [admin@CE /routing filter> print where chain=TO-CE Flags: X - disabled 0 chain=TO-CE invert-match=no action=passthrough set-bgp-prepend-path=""
Nesse caso, ainda vale lembrar que o Mikrotik é principalmente um roteador SOHO avançado e provavelmente não está certo exigir a mesma funcionalidade do roteador da classe Carrier. Resta confiar no RouterOS 7.
Conclusões
Ao adicionar o RT desejado aos seus anúncios, seu cliente ainda não poderá acessar seu MGMT VRF, por exemplo, porque a conectividade será unidirecional. No entanto, é bem possível que o cliente interrompa o roteamento no MGMT VRF (é claro, para isso você precisa adivinhar com o RT e com as rotas anunciadas).
Além disso, ao implementar a Opção A Inter-AS, é possível que uma rota do provedor A entre na rede do provedor B, preservando seu RT. Além disso, se na rede do provedor B esse RT já é usado em algum outro VRF, a rota vaza para esse VRF, o que, é claro, não é o comportamento desejado.
Assim, o problema não é muito significativo, porque para que ela “atire”, vários fatores devem coincidir juntos. Por outro lado, corrigir esse comportamento indesejado é muito mais fácil do que descobrir por que de repente "não funciona".
Então, novamente, muito brevemente:
1. Se possível, corte RT dos anúncios entre PE e CE (a menos que, é claro, você precise deles).
2. A julgar pelos resultados do teste, os proprietários do Cisco-PE podem dormir em paz, o RT é cortado na máquina. No entanto, apenas no caso, eu iria verificar. Talvez em outras versões do iOS o comportamento seja diferente.