Geekly articles weekly

Presencia de destino de ruta en anuncios de BGP entre PE y CE



El artículo asume que el lector ya comprende los conceptos básicos de MPLS L3VPN .

Hola Supongamos que eres un ISP . Y como cualquier ISP bastante grande, el núcleo de su red se basa en IP / MPLS. Si lo simplifica por completo, su red puede estar representada por el circuito que se muestra arriba. Supongamos también que usted, como ISP, vende a sus clientes el servicio L3VPN, que se implementa en su red de acuerdo con RFC 4364 (BGP / MPLS IP VPN). Y en el caso de que el cliente L3VPN en un determinado sitio no tenga suficientes redes conectadas directamente y quiera anunciar rutas adicionales a otros sitios, entonces generará una sesión BGP entre su equipo (PE) y el equipo del cliente (CE) a través del cual el cliente puede anunciar el deseado rutas. Con todo esto, no aplica ningún filtro / política a esta sesión, guiado por el hecho de que se supone que es un cliente VPN, y es libre de "manejar" lo que quiera en él (por ejemplo, dentro del límite del número de prefijos). Y ahora atención, la pregunta es: ¿qué sucede si, en el marco de esta sesión de BGP, el cliente anuncia las rutas para usted (el proveedor) y les agrega la Comunidad de destino de ruta? Esto puede ser, por ejemplo, el resultado de un error o el deseo de experimentar.

Por si acaso, recordamos que Route Target es una de las comunidades BGP extendidas especiales que se utilizan en MPLS L3VPN para seleccionar VRF, en la tabla de enrutamiento de las cuales es necesario instalar la ruta que vino a través de MP-BGP. Y dado que RT es una comunidad, en teoría, nada nos impide agregarlo a las rutas IPv4 normales.

Volvamos a la pregunta de qué puede suceder si CE anuncia rutas marcadas con RT en PE (no hay políticas de BGP en PE). Después de pensar un poco, podemos suponer que hay 3 resultados diferentes:

  1. PE dejará caer tal anuncio.
  2. PE eliminará RT del anuncio, agregará el RT VRF correspondiente y enviará el anuncio a otros PE.
  3. PE aceptará el anuncio sin cambios, agregará el RT VRF correspondiente (es decir, dos RT ya estarán contenidos en el anuncio) y enviará el anuncio a otros PE.

Lo más interesante y al mismo tiempo peligroso para el proveedor de servicios, por supuesto, es la última opción. En este caso, el cliente podría potencialmente interrumpir el enrutamiento en otros VRF, tanto del cliente como internos, tecnológicos.

Pero adivinen, verifiquemos. Para mayor interés, verificaremos de inmediato en varios sistemas operativos de red. En Eve-NG, se construyó el siguiente esquema:



Lista de participantes de la prueba:

  • 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

Enrutadores auxiliares:

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

Descripción del circuito:

  1. Participantes de prueba: enrutadores PE. Se creó VRF-100 (RT 65001: 100) en cada uno de ellos; en el marco de este VRF-100, se organizó una sesión de BGP con CE sin filtros / políticas.
  2. Cada uno de los PE probados tiene una sesión MP-BGP con un enrutador Remote_PE, a través del cual pasa rutas VRF.
  3. El enrutador CE tiene 5 subinterfaces (1 para cada PE), en cada subinterfaz la sesión BGP se eleva al CE correspondiente. Cada PE se anuncia su propio prefijo del formulario 1.1.1. N / 32, donde N es el número de secuencia del PE de izquierda a derecha. Con la política de exportación CE, la comunidad RT: 65001: 200 se agrega a cada uno de estos prefijos.
  4. Se crearon dos VRF en Remote_PE: VRF-100 (RT 65001: 100) y VRF-200 (RT 65001: 200)
  5. El transporte MPLS, los enrutadores P, RR y otras alegrías que generalmente están presentes en una red real se omiten aquí, porque No nos importa aquí.

Para aquellos que no están satisfechos con la descripción "solo en palabras", traeré las configuraciones de todos los dispositivos involucrados.

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


Anuncios CE-> PE


Entonces, el experimento es simple: con CE anunciaremos las rutas marcadas RT: 65001: 200, en Remote-PE buscamos ver si estas rutas aparecen en la tabla de enrutamiento VRF-200.

Primero, verifique la tabla de enrutamiento 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#

Recibimos rutas de los 5 PE. Ahora verifique si alguna de estas rutas está en el 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#

Las rutas de CHR, vMX y VSR terminaron en VRF-200. Esto significa que estos PE salvaron la comunidad RT: 65001: 200 añadida a CE.

Al mismo tiempo, las rutas de XRv y 3725 solo están disponibles en VRF-100. Esto significa que los enrutadores Cisco eliminaron la comunidad RT: 65001: 200 del anuncio.

Anuncios PE-> CE


No nos detendremos allí y verificaremos cómo se comportan los anuncios en la dirección opuesta, es decir. de PE a CE. Modificaremos ligeramente las configuraciones existentes.

En Remote_PE, cree un loopback cuya dirección 100.100.100.100/32 será anunciada por otro 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 !

En vMX, recuerde que no configuramos el transporte MPLS, lo que significa que la tabla inet.3 está vacía, y la ruta desde Remote_PE estará oculta. Copie las rutas OSPF a inet.3.

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

En el resto de los enrutadores, la configuración actual debería ser suficiente.

Nos fijamos en las rutas en 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 los enrutadores, excepto Cisco, abandonaron el destino de la ruta en el anuncio de la ruta. Cisco no hizo esto solo porque se les envió una comunidad por defecto. Arreglarlo
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

* El uso de estos comandos no cambia los resultados del primer experimento de ninguna manera con los anuncios CE-> PE.

Ahora mire la ruta en CE nuevamente:

 [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

Ahora absolutamente todos los PE envían rutas con la indicación de RT hacia CE.

Un resultado similar para mí personalmente me pareció algo extraño. Si preservar RT en el anuncio CE-> PE puede teóricamente considerarse como una aplicación, entonces en el anuncio PE-> CE RT parece obviamente información innecesaria.

Además, la existencia de fenómenos de conservación de RT tanto hacia CE-> PE como hacia PE-> CE, podría tener un impacto negativo en la Opción A de Inter-AS.

Encabezado "Lo que nos dice la RFC


RFC 4364 , mencionado al comienzo del artículo, establece específicamente esto:
Si el PE y el CE son pares de BGP, entonces
El SP puede permitir al cliente, dentro de ciertos límites, especificar cómo
Las rutas deben ser distribuidas. El SP y el cliente necesitarían
acordar de antemano el conjunto de RT que se pueden adjuntar a
Las rutas VPN del cliente. El CE podría entonces adjuntar uno o más de
esos RT a cada ruta IP que distribuye al PE. Esto da
el cliente la libertad de especificar en tiempo real, dentro de lo acordado
límites, sus políticas de distribución de rutas. Si se permite a la CE
adjunte RTs a sus rutas, el PE DEBE filtrar todas las rutas que
contienen RT que el cliente no puede usar. Si el CE es
no está permitido adjuntar RTs a sus rutas, pero lo hace de todos modos, el PE
DEBE eliminar el RT antes de convertir la ruta del cliente a una VPN
Ruta IPv4.

Por lo tanto, la preservación de RT en los anuncios CE-> PE tiene una base completamente legal, aunque la aplicación práctica de esto me parece algo dudosa.
Sobre RT en los anuncios PE-> CE, nada se dice en el RFC.

Eliminar RT de sesiones con CE


Todo está claro con Cisco por adelantado. En los anuncios CE-> PE, todos los RT se eliminan categóricamente (no pude encontrar un comando que cambiara este comportamiento), en los anuncios PE-> CE RT están ausentes de forma predeterminada, es suficiente para no permitir el envío de comunidades extendidas.

Descubriremos cómo deshacerse de RT en otros participantes en nuestras pruebas.

Enebro


Todo lo que necesita hacer para eliminar RT de los anuncios (tanto PE-> CE como CE-> PE) es crear una política y el primer término para eliminar todas las comunidades que comienzan con "target:", dando el prefijo a procesamiento en los siguientes términos.

Por ejemplo, si queremos aceptar y anunciar todas las rutas, simplemente eliminando RT de ellas:

 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 deshabilitar el envío de comunidades extendidas a un par BGP, puede usar el comando:

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

Para eliminar RT de los anuncios de CE, debe crear una política similar a como se hizo en Juniper y aplicarla a una sesión con 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


Pero con Mikrotik estaremos decepcionados. Simplemente no existe un mecanismo para eliminar RT del anuncio. Parece que en el filtro de enrutamiento hay un parámetro set-route-objetivos, y haría algo como

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

pero, desafortunadamente, set-route-destinos = "" significa que este parámetro (set-route-objetivos) debe eliminarse por completo de la regla. Un ejemplo:

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

En este caso, todavía vale la pena recordar que Mikrotik es principalmente un enrutador SOHO avanzado, y probablemente no sea del todo correcto exigirle la misma funcionalidad que en el enrutador de clase Carrier. Queda por depender de RouterOS 7.

Conclusiones


Al agregar la RT deseada a sus anuncios, su cliente aún no podrá acceder a su MGMT VRF, por ejemplo, porque La conectividad será unidireccional. Sin embargo, es bastante posible que el cliente interrumpa el enrutamiento en MGMT VRF (por supuesto, para esto debe adivinar con RT y con las rutas anunciadas).

Además, al implementar la Opción A de Inter-AS, es posible que una ruta del proveedor A ingrese a la red del proveedor B, mientras mantiene su RT. Además, si en la red del proveedor B este RT ya se usa bajo algún otro VRF, la ruta se filtra en este VRF, que, por supuesto, no es el comportamiento deseado.

Por lo tanto, el problema no es demasiado significativo, porque Para que ella "dispare", varios factores deben coincidir. Por otro lado, corregir este comportamiento no deseado es mucho más fácil que descubrir por qué de repente "no funciona".

Así que de nuevo, muy brevemente:

1. Si es posible, elimine RT de los anuncios entre PE y CE (a menos, por supuesto, que los necesite).
2. A juzgar por los resultados de la prueba, los propietarios de cisco-PE pueden dormir tranquilos, su RT está cortada en la máquina. Sin embargo, por si acaso, volvería a verificar. Quizás en otras versiones de iOS el comportamiento es diferente.

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

More articles:


All Articles