En unos equipos 6500 tenemos configuradas distintas VRF y necesitamos en ciertos casos realizar leakings entre ellas para poder establecer comunicaciones entre equipamiento en distintas vrfs. Para ello las VRF disponen de route-maps de exportación y/o de importación. En este caso intentábamos realizar el leaking de la VRF de 6500-1 a 6500-2.
ip vrf 6500-1
description Red Corporativa
rd 100:100
route-target export 100:100
route-target import 100:100
route-target import 50:100
route-target import 150:100
route-target import 175:100
route-target import 200:100
route-target import 300:100
route-target import 400:400
route-target import 500:100
route-target import 550:100
route-target import 600:100
route-target import 700:100
route-target import 650:100
route-target import 750:100
ip vrf 6500-2
description Datacenter
rd 750:100
import map To_6500-2
export map From_6500-2
route-target export 750:100
route-target import 750:100
route-target import 50:100
route-target import 100:100
route-target import 175:100
route-target import 400:400
route-target import 500:100
route-target import 150:100
route-target import 600:100
route-target import 550:100
route-target import 200:100
route-target import 700:100
route-target import 300:100
La red a importar en 6500-2 es:
CORE-VSS#show ip route vrf 6500-1 10.200.76.108
Routing Table: 6500-1
Routing entry for 10.200.76.108/32
Known via "static", distance 1, metric 0
Redistributing via ospf 100, bgp 65535
Advertised by bgp 65535
Routing Descriptor Blocks:
* 172.25.147.4
Route metric is 0, traffic share count is 1
Como veis en la configuración la VRF de 6500-1 exporta directamente todas las redes que conoce (No tiene ningún route-map asociado), mientras que la vrf de 6500-2 si tiene route-map de importación (To_6500-2).
Además de esto, explicar que por el lado de la VRF de 6500-2 tenemos una adyacencia con protocolo BGP contra equipos Juniper MX. Utilizamos este mismo route-map (To_6500-2) como filtro para controlar las redes que exportamos por BGP en esta adyacencia.
router bgp 65535
!
address-family ipv4 vrf 6500-2
redistribute static metric 120 route-map Static-Nets
redistribute ospf 750 match internal external 1 external 2 route-map From_6500-2
neighbor MX peer-group
neighbor MX remote-as xxyyzz
neighbor MX timers 30 90
neighbor MX fall-over bfd
neighbor MX next-hop-self
neighbor MX soft-reconfiguration inbound
neighbor MX route-map From_6500-2 in
neighbor MX route-map To_6500-2 out
neighbor 172.25.150.137 peer-group MX
neighbor 172.25.150.137 activate
neighbor 172.25.150.141 peer-group MX
neighbor 172.25.150.141 activate
maximum-paths 4
exit-address-family
Configuración realizada
Para realizar el leaking de la ruta proveniente de la vrf 6500-1 hacia 6500-2 hemos realizado cambios en la configuración de una de las prefix que matchea el route-map To_6500-2 (Acorto la salida de la configuración del route-map únicamente con la prefix que nos interesa):
CORE-VSS#sh route-map To_6500-2
.
.
.
route-map To_6500-2, permit, sequence 120
Match clauses:
ip address prefix-lists: 6500-1_to_6500-2
Set clauses:
Policy routing matches: 0 packets, 0 bytes
.
.
.
CORE-VSS#show ip prefix-list 6500-1_to_6500-2
ip prefix-list 6500-1_to_6500-2: 9 entries
seq 10 permit 10.123.0.0/16 ge 24 le 28
seq 11 permit 10.122.0.0/16 ge 24 le 28
seq 15 permit 10.110.96.0/21
seq 20 permit 10.172.70.0/24
seq 30 permit 10.200.12.0/22
seq 40 permit 10.230.254.32/27
seq 50 permit 10.230.254.96/27
seq 60 permit 172.25.36.112/29
De manera que el comando que hemos introducido ha sido:
ip prefix-list 6500-1_to_6500-2 seq 70 permit 10.200.76.108/32
Problema que nos ha producido
Nos hemos dado cuenta de que el 6500 no estaba instalando las rutas que recibía a través de la adyacencia BGP en la vrf de 6500-2 (Matizo que la adyacencia estaba levantada, recibíamos las rutas pero no las estaba instalando en su tabla de rutas)
Redes que se recibían por bgp de uno de sus vecinos:
CORE-VSS%6500-2#sho ip bgp vpnv4 vrf 6500-2 neighbors 172.25.150.137 received-routes
BGP table version is 394768, local router ID is 172.25.144.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 750:100 (default for vrf 6500-2)
* 10.150.3.0/24 172.25.150.137 100 0 207060 i
* 10.150.4.0/23 172.25.150.137 100 0 207060 i
* 10.168.225.0/24 172.25.150.137 100 0 207060 i
* 10.190.80.0/20 172.25.150.137 100 0 207060 i
* 10.190.240.0/20 172.25.150.137 100 0 207060 i
* 10.200.191.120/29
172.25.150.137 100 0 207060 i
* 10.200.208.0/20 172.25.150.137 100 0 207060 i
* 10.220.0.0/23 172.25.150.137 100 0 207060 i
* 10.220.4.0/24 172.25.150.137 100 0 207060 i
* 10.220.6.200/29 172.25.150.137 100 0 207060 i
* 10.230.254.32/27 172.25.150.137 150 0 207060 i
* 172.25.150.136/30
172.25.150.137 100 0 207060 i
* 172.25.150.140/30
172.25.150.137 100 0 207060 i
* 172.25.151.136/29
172.25.150.137 100 0 207060 i
* 172.25.151.152/29
172.25.150.137 100 0 207060 i
* 172.26.186.0/26 172.25.150.137 150 0 207060 i
* 172.26.219.90/31 172.25.150.137 100 0 207060 i
* 172.26.255.0/28 172.25.150.137 100 0 207060 i
* 172.26.255.32/28 172.25.150.137 100 0 207060 i
* 172.26.255.48/28 172.25.150.137 100 0 207060 i
* 172.26.255.160/28
172.25.150.137 150 0 207060 i
* 172.26.255.192/27
172.25.150.137 100 0 207060 i
* 172.26.255.224/28
172.25.150.137 100 0 207060 i
Total number of prefixes 23
Ejemplo de red no instalada en su tabla
CORE-VSS%6500-2#sh ip route 10.200.208.0
Routing Table: 6500-2
% Subnet not in table
Ahora mismo el problema se ha solventado. Durante el proceso para corregir el problema hemos realizado la marcha atrás del cambio de configuración de la prefix (No ha tenido efecto alguno, seguíamos con el problema). Lo que ha conseguido solventar el problema ha sido “resetear” la adyacencia BGP con un: clear bgp vrf 6500-2 ipv4 unicast peer-group MX para el lado del 6500 y un: clear bgp neighbor 172.25.150.138 en el lado de los Juniper MX. Una vez restablecido el servicio hemos vuelto a aplicar la configuración de la prefix de la misma manera que la primera vez y no hemos detectado problema alguno, hemos entendido que no ha sido un problema de configuración sino algo anómalo.
Se os ocurre ¿que ha podido suceder? ¿Alguna idea?
