Geekly articles weekly

Vorhandensein eines Routenziels in BGP-Ankündigungen zwischen PE und CE



Der Artikel geht davon aus, dass der Leser die Grundlagen von MPLS L3VPN bereits verstanden hat.

Hallo. Angenommen, Sie sind ein ISP . Und wie bei jedem ziemlich großen ISP basiert der Kern Ihres Netzwerks auf IP / MPLS. Wenn Sie es vollständig vereinfachen, kann Ihr Netzwerk durch die oben gezeigte Schaltung dargestellt werden. Nehmen wir außerdem an, dass Sie als ISP Ihren Kunden den L3VPN-Dienst verkaufen, der in Ihrem Netzwerk gemäß RFC 4364 (BGP / MPLS IP VPNs) implementiert ist. Und falls ein L3VPN-Client an einem bestimmten Standort nicht über genügend direkt verbundene Netzwerke verfügt und zusätzliche Routen zu anderen Standorten ankündigen möchte, wird eine BGP-Sitzung zwischen Ihrem Gerät (PE) und dem Client-Gerät (CE) ausgelöst, über die der Client das gewünschte ankündigen kann Routen. Bei alledem wenden Sie keine Filter / Richtlinien auf diese Sitzung an, die von der Tatsache geleitet werden, dass es sich um einen VPN-Client handeln soll, und es ist kostenlos, alles zu "steuern", was es will (zum Beispiel innerhalb der Grenze der Anzahl der Präfixe). Und jetzt ist die Frage: Was passiert, wenn der Client im Rahmen dieser BGP-Sitzung die Routen für Sie (den Anbieter) ankündigt und ihnen die Route Target Community hinzufügt? Dies kann beispielsweise das Ergebnis eines Fehlers oder der Wunsch zu experimentieren sein.

Für alle Fälle erinnern wir uns, dass das Routenziel eine der speziellen erweiterten BGP-Communities ist, die in MPLS L3VPN zur Auswahl von VRF verwendet werden. In der Routing-Tabelle muss die Route festgelegt werden, die über MP-BGP kam. Und da RT eine Community ist, hindert uns theoretisch nichts daran, sie regulären IPv4-Routen hinzuzufügen.

Kehren wir zur Frage zurück, was passieren kann, wenn CE mit RT gekennzeichnete Routen auf PE ankündigt (es gibt keine BGP-Richtlinien auf PE). Nach einigem Nachdenken können wir davon ausgehen, dass es drei verschiedene Ergebnisse gibt:

  1. PE wird eine solche Ankündigung fallen lassen.
  2. PE entfernt RT aus der Ansage, fügt die entsprechende VRF-RT hinzu und sendet die Ansage an andere PEs.
  3. PE akzeptiert die Ankündigung unverändert, fügt die entsprechende VRF-RT hinzu (dh zwei RTs sind bereits in der Ankündigung enthalten) und sendet die Ankündigung an andere PEs.

Das Interessanteste und gleichzeitig Gefährlichste für den Dienstleister ist natürlich die letzte Option. In diesem Fall kann der Client möglicherweise das Routing in anderen VRFs stören, sowohl im Client als auch im internen technologischen Bereich.

Aber ziemlich raten wir mal. Bei größerem Interesse werden wir sofort mehrere Netzwerkbetriebssysteme überprüfen. In Eve-NG wurde das folgende Schema erstellt:



Liste der Testteilnehmer:

  • 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

Hilfsrouter:

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

Beschreibung der Schaltung:

  1. Testteilnehmer - PE-Router. VRF-100 (RT 65001: 100) wurde auf jedem von ihnen erstellt. Im Rahmen dieses VRF-100 wurde eine BGP-Sitzung mit CE ohne Filter / Richtlinien organisiert.
  2. Jeder der getesteten PEs verfügt über eine MP-BGP-Sitzung mit einem Remote_PE-Router, über den VRF-Routen geleitet werden.
  3. Der CE-Router verfügt über 5 Subschnittstellen (1 zu jedem PE). In jeder Subschnittstelle wird die BGP-Sitzung auf das entsprechende CE angehoben. Jedes PE erhält ein eigenes Präfix des Formulars 1.1.1. N / 32, wobei N die Sequenznummer des PE von links nach rechts ist. Mit der CE-Exportrichtlinie wird jedem dieser Präfixe die Community RT: 65001: 200 hinzugefügt.
  4. Auf Remote_PE wurden zwei VRFs erstellt: VRF-100 (RT 65001: 100) und VRF-200 (RT 65001: 200)
  5. MPLS-Transport, P-Router, RR und andere Freuden, die normalerweise in einem realen Netzwerk vorhanden sind, werden hier weggelassen, weil es ist uns hier egal

Für diejenigen, die mit der Beschreibung "nur in Worten" nicht zufrieden sind, bringe ich die Konfigurationen aller beteiligten Geräte mit.

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


Ankündigungen CE-> PE


Das Experiment ist also einfach: Mit CE werden wir die mit RT: 65001: 200 gekennzeichneten Routen bekannt geben. Auf Remote-PE prüfen wir, ob diese Routen in der Routing-Tabelle VRF-200 aufgeführt sind.

Überprüfen Sie zunächst die VRF-100-Routing-Tabelle:

 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#

Wir haben Routen von allen 5 PE erhalten. Überprüfen Sie nun, ob sich eine dieser Routen im VRF-200 befindet:

 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#

Routen von CHR, vMX und VSR landeten in VRF-200. Dies bedeutet, dass die zu CE hinzugefügte Community RT: 65001: 200 von diesen PEs gespeichert wurde.

Gleichzeitig sind Routen von XRv und 3725 nur in VRF-100 verfügbar. Dies bedeutet, dass die Cisco-Router die Community RT: 65001: 200 aus der Ankündigung entfernt haben.

Ankündigungen PE-> CE


Wir werden hier nicht anhalten und prüfen, wie sich die Ansagen in die entgegengesetzte Richtung verhalten, d. H. von PE nach CE. Wir werden die vorhandenen Konfigurationen geringfügig ändern.

Erstellen Sie auf Remote_PE einen Loopback, dessen Adresse 100.100.100.100/32 von einem anderen PE angekündigt wird:

 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 !

Denken Sie unter vMX daran, dass wir den MPLS-Transport nicht konfiguriert haben. Dies bedeutet, dass die Tabelle inet.3 leer ist und die Route von Remote_PE ausgeblendet wird. Kopieren Sie die OSPF-Routen nach inet. 3.

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

Auf den restlichen Routern sollten die aktuellen Einstellungen ausreichen.

Wir betrachten Routen auf 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

Alle Router außer Cisco haben Route Target in der Ankündigung der Route verlassen. Cisco hat dies nicht getan, nur weil standardmäßig eine Community an sie gesendet wurde. Repariere es.
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

* Die Verwendung dieser Befehle ändert nichts an den Ergebnissen des ersten Experiments mit CE-> PE-Ankündigungen.

Schauen Sie sich jetzt noch einmal die Route auf CE an:

 [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

Jetzt senden absolut alle PEs Routen mit der Angabe von RT in Richtung CE.

Ein ähnliches Ergebnis erschien mir persönlich etwas seltsam. Wenn die Beibehaltung von RT in der CE-> PE-Ankündigung theoretisch als Anwendung betrachtet werden kann, dann sieht RT in der PE-> CE-Ankündigung offensichtlich nach unnötigen Informationen aus.

Darüber hinaus könnte das Vorhandensein von RT-Erhaltungsphänomenen sowohl gegenüber CE-> PE als auch gegenüber PE-> CE möglicherweise negative Auswirkungen auf die Inter-AS-Option A haben.

Überschrift "Was der RFC uns sagt"


In RFC 4364 , der am Anfang des Artikels erwähnt wurde, heißt es ausdrücklich:
Wenn PE und CE selbst BGP-Peers sind, dann
Der SP kann dem Kunden innerhalb bestimmter Grenzen erlauben, anzugeben, wie sein
Routen sind zu verteilen. Der SP und der Kunde müssten
Vereinbaren Sie im Voraus die RTs, an die angehängt werden darf
die VPN-Routen des Kunden. Das CE könnte dann einen oder mehrere von anbringen
diese RTs zu jeder IP-Route, die sie an das PE verteilt. Das gibt
dem Kunden die Freiheit, in Echtzeit innerhalb der vereinbarten zu spezifizieren
Grenzen, seine Routenverteilungsrichtlinien. Wenn das CE darf
Wenn Sie RTs an seine Routen anhängen, MUSS das PE alle Routen herausfiltern, die
RTs enthalten, die der Kunde nicht verwenden darf. Wenn das CE ist
Es ist nicht erlaubt, RTs an seine Routen anzuhängen, aber das PE trotzdem
MUSS die RT entfernen, bevor die Route des Kunden in ein VPN konvertiert wird.
IPv4-Route.

Somit hat die Erhaltung von RT in den Ankündigungen CE-> PE eine völlig rechtliche Grundlage, obwohl die praktische Anwendung davon mir etwas zweifelhaft erscheint.
Über RT wird in den Ankündigungen PE-> CE im RFC nichts gesagt.

Entfernen Sie RT aus Sitzungen mit CE


Mit Cisco ist im Voraus alles klar. In CE-> PE-Ankündigungen werden alle RTs kategorisch gelöscht (ich konnte keinen Befehl finden, der dieses Verhalten ändern würde). In PE-> CE RT-Ankündigungen fehlen standardmäßig keine erweiterten Communitys.

Wir werden herausfinden, wie wir RT bei anderen Teilnehmern unserer Tests loswerden können.

Wacholder


Alles, was Sie tun müssen, um RT aus den Ankündigungen zu entfernen (sowohl PE-> CE als auch CE-> PE), ist eine Richtlinie und den allerersten Begriff zu erstellen, um alle Communitys zu entfernen, beginnend mit "Ziel:", wobei das Präfix zu angegeben wird Verarbeitung in den folgenden Begriffen.

Wenn wir beispielsweise alle Routen akzeptieren und ankündigen möchten, entfernen Sie einfach RT von ihnen:

 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


Um das Senden erweiterter Communitys an einen BGP-Peer zu deaktivieren, können Sie den folgenden Befehl verwenden:

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

Um RT aus CE-Ankündigungen zu entfernen, müssen Sie eine Richtlinie erstellen, die der Vorgehensweise in Juniper ähnelt, und diese auf eine Sitzung mit CE anwenden.

 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


Aber mit Mikrotik erwartet uns eine Enttäuschung. Es gibt einfach keinen Mechanismus, um RT aus der Ansage zu entfernen. Es scheint, dass es im Routing-Filter einen Parameter für festgelegte Routenziele gibt, der so etwas tun würde

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

aber leider bedeutet set-route-destination = "", dass dieser Parameter (set-route-target) vollständig aus der Regel entfernt werden muss. Ein Beispiel:

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

In diesem Fall ist immer noch daran zu erinnern, dass Mikrotik in erster Linie ein fortschrittlicher SOHO-Router ist und es wahrscheinlich nicht ganz richtig ist, von ihm die gleiche Funktionalität zu verlangen wie im Router der Carrier-Klasse. Es bleibt auf RouterOS 7 zu verlassen.

Schlussfolgerungen


Wenn Sie Ihren Ankündigungen die gewünschte RT hinzufügen, kann Ihr Client beispielsweise weiterhin nicht auf Ihre MGMT VRF zugreifen, weil Die Konnektivität erfolgt in eine Richtung. Trotzdem ist es für den Client durchaus möglich, das Routing in MGMT VRF zu stören (dazu müssen Sie natürlich mit RT und den angekündigten Routen raten).

Darüber hinaus ist es bei der Implementierung von Inter-AS Option A möglich, dass eine Route von Anbieter A in das Netzwerk von Anbieter B eingeht, wobei dessen RT erhalten bleibt. Wenn im Netzwerk von Anbieter B diese RT bereits unter einer anderen VRF verwendet wird, tritt die Route in diese VRF ein, was natürlich nicht das gewünschte Verhalten ist.

Somit ist das Problem nicht zu bedeutend, weil Damit sie „schießen“ kann, müssen mehrere Faktoren zusammenfallen. Andererseits ist es viel einfacher, dieses unerwünschte Verhalten zu korrigieren, als herauszufinden, warum es plötzlich „nicht mehr funktioniert“.

Also nochmal ganz kurz:

1. Wenn möglich, schneiden Sie RT aus den Ansagen zwischen PE und CE ab (es sei denn, Sie benötigen sie natürlich).
2. Gemessen an den Testergebnissen können Besitzer von Cisco-PE ruhig schlafen, ihre RT ist auf der Maschine ausgeschnitten. Für alle Fälle würde ich es jedoch noch einmal überprüfen. Möglicherweise ist das Verhalten in anderen Versionen von iOS anders.

Source: https://habr.com/ru/post/de412615/

More articles:


All Articles