👩🏾‍🎨 🉑 💸 Présence d'un objectif de route dans les annonces BGP entre PE et CE 🧗 ♿️ 💬

L'article suppose que le lecteur a déjà une compréhension des bases de MPLS L3VPN .

Salut Supposons que vous êtes un FAI . Et comme tout FAI assez important, le cœur de votre réseau est basé sur IP / MPLS. Si vous le simplifiez complètement, votre réseau peut être représenté par le circuit illustré ci-dessus. Supposons également que vous, en tant que FAI, vendez à vos clients le service L3VPN, qui est implémenté sur votre réseau conformément à la RFC 4364 (VPN VPN BGP / MPLS). Et dans le cas où un client L3VPN sur un certain site ne dispose pas de suffisamment de réseaux directement connectés et souhaite annoncer des itinéraires supplémentaires vers d'autres sites, vous lèverez une session BGP entre votre équipement (PE) et l'équipement client (CE), à travers lequel le client peut annoncer le souhait itinéraires. Avec tout cela, vous n'appliquez aucun filtre / politique à cette session, guidé par le fait qu'il est censé être un client VPN, et il est libre de "conduire" tout ce qu'il veut (dans la limite du nombre de préfixes, par exemple). Et maintenant attention, la question est: que se passe-t-il si, dans le cadre de cette session BGP, le client vous annonce les itinéraires (le fournisseur), en y ajoutant la communauté Route Target? Cela peut être, par exemple, le résultat d'une erreur ou le désir d'expérimenter.

Juste au cas où, nous rappelons que la Route Target est l'une des communautés BGP étendues spéciales utilisées dans MPLS L3VPN pour sélectionner VRF, dans la table de routage dont il est nécessaire de définir la route qui est venue via MP-BGP. Et puisque RT est une communauté, alors en théorie, rien ne nous empêche de l'ajouter aux routes IPv4 régulières.

Revenons à la question de ce qui peut arriver si CE annonce des itinéraires marqués avec RT sur PE (il n'y a pas de politiques BGP sur PE). Après un peu de réflexion, nous pouvons supposer qu'il existe 3 résultats différents:

PE abandonnera une telle annonce.
Le PE supprimera le RT de l'annonce, lui ajoutera le RT VRF correspondant et enverra l'annonce aux autres PE.
Le PE acceptera l'annonce inchangée, y ajoutera le RT VRF correspondant (c'est-à-dire que deux RT seront déjà contenus dans l'annonce) et enverra l'annonce à d'autres PE.

La dernière option est la plus intéressante et en même temps dangereuse pour le prestataire de services. Dans ce cas, le client pourrait potentiellement perturber le routage dans d'autres VRF, à la fois client et interne, technologique.

Mais devinez, vérifions. Pour plus d'intérêt, nous allons vérifier immédiatement sur plusieurs OS réseau. Dans Eve-NG, le schéma suivant a été créé:

Liste des participants au test:

CHR - Mikrotik CHR , RouterOS 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

Routeurs auxiliaires:

Remote-PE - Cisco 3725 (Dynamips), IOS 12.4
CE - Mikrotik CHR, RouterOS 6.40.8

Description du circuit:

Participants au test - Routeurs PE. VRF-100 (RT 65001: 100) a été créé sur chacun d'eux; dans le cadre de ce VRF-100, une session BGP avec CE a été organisée sans aucun filtre / politique.
Chacun des PE testés a une session MP-BGP avec un routeur Remote_PE, à travers lequel il passe des routes VRF.
Le routeur CE a 5 sous-interfaces (1 pour chaque PE), dans chaque sous-interface la session BGP est élevée au CE correspondant. Chaque PE est annoncé son propre préfixe du formulaire 1.1.1. N / 32, où N est le numéro de séquence du PE de gauche à droite. Avec la politique d'exportation CE, la communauté RT: 65001: 200 est ajoutée à chacun de ces préfixes.
Deux VRF ont été créés sur Remote_PE: VRF-100 (RT 65001: 100) et VRF-200 (RT 65001: 200)
Le transport MPLS, les routeurs P, RR et autres joies qui sont généralement présents dans un vrai réseau sont omis ici, car cela n'a pas d'importance pour nous ici.

Pour ceux qui ne sont pas satisfaits de la description "uniquement en mots", je vais apporter les configs de tous les appareils impliqués.

/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

Annonces CE-> PE

L'expérience est donc simple: avec CE, nous annonçons les routes marquées RT: 65001: 200, sur Remote-PE, nous cherchons à voir si ces routes apparaissent dans la table de routage VRF-200.

Tout d'abord, vérifiez la table de routage 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#

Nous avons reçu des itinéraires des 5 PE. Maintenant, vérifiez si l'une de ces routes se trouve dans le 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#

Les routes à partir de CHR, vMX et VSR se sont retrouvées dans VRF-200. Cela signifie que la communauté RT: 65001: 200 ajoutée à CE a été enregistrée par ces PE.

Dans le même temps, les itinéraires à partir de XRv et 3725 ne sont disponibles que dans VRF-100. Cela signifie que les routeurs Cisco ont supprimé la communauté RT: 65001: 200 de l'annonce.

Annonces PE-> CE

Nous ne nous arrêterons pas là et vérifierons comment les annonces se comportent dans la direction opposée, c'est-à-dire de PE à CE. Modifiez un peu les configurations existantes

Sur Remote_PE, créez un bouclage dont l'adresse 100.100.100.100/32 sera annoncée par un autre 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 !

Sur vMX, rappelez-vous que nous n'avons pas configuré le transport MPLS, ce qui signifie que la table inet.3 est vide et la route à partir de Remote_PE sera masquée. Copiez les routes OSPF dans inet.3.

 set routing-options rib-groups RG-INET3 import-rib [ inet.0 inet.3 ] set protocols ospf rib-group RG-INET3

Sur les autres routeurs, les paramètres actuels devraient être suffisants.

Nous regardons les itinéraires sur 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

Tous les routeurs sauf Cisco ont quitté Route Target dans l'annonce de l'itinéraire. Cisco ne l'a pas fait simplement parce qu'une communauté leur a été envoyée par défaut. Réparez-le.
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

* L'utilisation de ces commandes ne modifie en rien les résultats de la première expérience avec les annonces CE-> PE.

Maintenant, regardez à nouveau l'itinéraire sur 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 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

Maintenant, absolument tous les PE envoient des routes avec l'indication de RT vers CE.

Un résultat similaire me semblait personnellement quelque peu étrange. Si la préservation de la RT dans l'annonce CE-> PE peut théoriquement être considérée comme une application, alors dans l'annonce PE-> CE, RT ressemble à des informations manifestement inutiles.

De plus, l'existence de phénomènes de conservation de la RT à la fois vers CE-> PE et vers PE-> CE pourrait potentiellement avoir un impact négatif sur l'option Inter-AS A.

Rubrique «Ce que nous dit la RFC»

La RFC 4364 , mentionnée au début de l'article, indique spécifiquement ceci:

Si le PE et le CE sont eux-mêmes des pairs BGP, alors
le SP peut permettre au client, dans certaines limites, de spécifier comment
les itinéraires doivent être distribués. Le SP et le client devraient
convenir à l'avance de l'ensemble des RT qui peuvent être joints à
les routes VPN du client. Le CE pourrait alors joindre un ou plusieurs
ces RT à chaque route IP qu'il distribue au PE. Cela donne
le client la liberté de spécifier en temps réel, dans les délais convenus
limites, ses politiques de distribution des routes. Si le CE est autorisé à
attacher des RT à ses routes, le PE DOIT filtrer toutes les routes qui
contiennent des RT que le client n'est pas autorisé à utiliser. Si le CE est
pas autorisé à attacher RTs à ses routes, mais le fait de toute façon, le PE
DOIT supprimer le RT avant de convertir la route du client en VPN-
Route IPv4.

Ainsi, la préservation de la RT dans les annonces CE-> PE a une base tout à fait légale, bien que son application pratique me semble quelque peu douteuse.
Concernant RT dans les annonces PE-> CE, rien n'est dit dans le RFC.

Supprimer RT des sessions avec CE

Tout est clair avec Cisco à l'avance. Dans les annonces CE-> PE, tous les RT sont supprimés catégoriquement (je n'ai pas pu trouver une commande qui changerait ce comportement), dans PE-> CE RT les annonces sont absentes par défaut, il suffit de ne pas permettre l'envoi de communautés étendues.

Nous découvrirons comment se débarrasser de la RT sur les autres participants à nos tests.

Genévrier

Tout ce que vous devez faire pour supprimer RT des annonces (à la fois PE-> CE et CE-> PE) est de créer une politique et le tout premier terme pour supprimer toutes les communautés commençant par «cible:», en donnant le préfixe à traitement dans les termes suivants.

Par exemple, si nous voulons accepter et annoncer tous les itinéraires, il suffit de supprimer RT d'eux:

 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

Pour désactiver l'envoi de communautés étendues à un homologue BGP, vous pouvez utiliser la commande:

 configure service vprn "VRF-100" bgp group "CE" disable-communities extended

Pour supprimer RT des annonces CE, vous devez créer une stratégie similaire à la façon dont cela a été fait dans Juniper et l'appliquer à une session avec 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

Mais avec Mikrotik, la déception nous attend. Il n'y a tout simplement pas de mécanisme pour supprimer RT de l'annonce. Il semblerait que dans le filtre de routage il y ait un paramètre set-route-target, et ferait quelque chose comme

 /routing filter add chain=TO-CE set-route-targets="" action=passthrough add chain=TO-CE action=accept

mais, malheureusement, set-route-target = "" signifie que ce paramètre (set-route-target) doit être complètement supprimé de la règle. Un exemple:

 [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=""

Dans ce cas, il convient de se rappeler que Mikrotik est principalement un routeur SOHO avancé, et il n'est probablement pas tout à fait correct d'exiger la même fonctionnalité que celle du routeur de classe Carrier. Il reste à s'appuyer sur RouterOS 7.

Conclusions

En ajoutant la RT souhaitée à vos annonces, votre client ne pourra toujours pas accéder à votre MGMT VRF, par exemple, car la connectivité sera à sens unique. Néanmoins, il est tout à fait possible que le client perturbe le routage dans MGMT VRF (bien sûr, pour cela, vous devez deviner avec RT et avec les routes annoncées).

De plus, lors de la mise en œuvre de l'option A inter-AS, il est possible qu'une route du fournisseur A entre dans le réseau du fournisseur B, en préservant sa RT. De plus, si dans le réseau du fournisseur B ce RT est déjà utilisé sous un autre VRF, la route fuit dans ce VRF, ce qui, bien sûr, n'est pas le comportement souhaité.

Ainsi, le problème n'est pas trop important, car pour qu'elle puisse «tirer», plusieurs facteurs doivent coïncider. D'un autre côté, il est beaucoup plus facile de corriger ce comportement indésirable que de comprendre pourquoi cela «ne fonctionne pas» soudainement.

Encore une fois, très brièvement:

1. Si possible, coupez RT des annonces entre PE et CE (sauf si, bien sûr, vous en avez besoin).
2. À en juger par les résultats des tests, les propriétaires de cisco-PE peuvent dormir paisiblement, leur RT est coupé sur la machine. Cependant, juste au cas où, je revérifierais. Peut-être que dans d'autres versions d'iOS, le comportement est différent.

Présence d'un objectif de route dans les annonces BGP entre PE et CE