Hello everyone,
I have a NCS 540 running IOS-XR 24.2.2 and I'm trying to setup an architecture with a total of five vrf including a "hub" vrf where all routes should be exported to / imported from that I can't seems to get working: routes from one vrf imported into the hub never get learned by the other vrfs.
The first three (VRF_DNN_[1-3]) each have a eBGP peering with a third party system. They each export their routes with a different route target (65008:201[1-3]) and import the RT 65008:2010.
The fourth VRF (VRF_INFRA_5G) is more of the same, with an iBGP peering providing a default route, exporting to RT 65008:3000 and importing RT 65008:2010.
The final VRF VRF_DNN_HUB import the RTs of all the others DNN VRF and export to RT 65008:2010.
The gool is to have the routes from each DNN VRF into the INFRA_5G VRF and vice versa.
Since the VRF_DNN_HUB is a hub, I've use the "export to vrf allow-imported-vpn" command and with it, the imported routes are indeed reexported to the vpnv4 table with the community RT 65008:2010 but is not imported in the other VRFs.
The routes native to the hub VRF work fine.
I've experimented with different configurations (using RPL to add/rewrite RTs, single or dual RT for import and export, placement of the "export to vrf allow-imported-vpn" and "import from vrf advertise-as-vpn", exporting only a default route from the hub, etc... ), it seems to always end up in the same place : routes ends-up in the vpnv4 table with a RT that should be imported by the "spokes" vrf but doesn't, probably because it was imported before.
I sense that either this scenario is not supported on this platform or I'm missing a single command to allow the re-importation of routes. Does someone have insight on this subject?
Here is my configuration :
vrf VRF_DNN_1
address-family ipv4 unicast
import route-target
65008:2010
!
export route-target
65008:2011
!
!
!
vrf VRF_DNN_2
address-family ipv4 unicast
import route-target
65008:2010
!
export route-target
65008:2012
!
!
!
vrf VRF_DNN_3
address-family ipv4 unicast
import route-target
65008:2010
!
export route-target
65008:2013
!
!
!
vrf VRF_DNN_HUB
address-family ipv4 unicast
import route-target
65008:2011
65008:2012
65008:2013
65008:3000
!
export to vrf allow-imported-vpn
export route-target
65008:2010
!
!
!
vrf VRF_INFRA_5G
address-family ipv4 unicast
import route-target
65008:2010
!
export route-target
65008:3000
!
!
!
Here the example of route 10.14.15.0/24 originating from VRF_DNN_1 :
It is indeed re-exported by VRF_DNN_HUB with RT 65008:2010 that is imported by VRF_INFRA_5G but it doesn't show up in its routing table
RP/0/RP0/CPU0:ios#sh bgp vpnv4 unicast vrf VRF_DNN_1 10.14.15.0/24
Thu Nov 14 14:36:33.332 UTC
BGP routing table entry for 10.14.15.0/24, Route Distinguisher: 172.30.0.0:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 52 52
Local Label: 24003
Last Modified: Nov 13 10:59:04.866 for 1d03h
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
64901 64902
172.20.2.1 from 172.20.2.1 (172.20.2.1)
Origin IGP, localpref 100, valid, external, best, group-best, import-candidate
Received Path ID 0, Local Path ID 1, version 52
Community: 64901:101
Extended community: RT:65008:2011
RP/0/RP0/CPU0:ios#sh bgp vpnv4 unicast vrf VRF_DNN_HUB 10.14.15.0/24
Thu Nov 14 14:36:49.680 UTC
BGP routing table entry for 10.14.15.0/24, Route Distinguisher: 172.30.0.0:4
Versions:
Process bRIB/RIB SendTblVer
Speaker 43 43
Last Modified: Nov 13 10:59:04.866 for 1d03h
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
64901 64902
172.20.2.1 from 172.20.2.1 (172.20.2.1)
Origin IGP, localpref 100, valid, external, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 43
Community: 64901:101
Extended community: RT:65008:2010 RT:65008:2011
Source AFI: VPNv4 Unicast, Source VRF: VRF_DNN_1, Source Route Distinguisher: 172.30.0.0:1
RP/0/RP0/CPU0:ios#sh route vrf VRF_INFRA_5G
Thu Nov 14 14:37:07.984 UTC
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
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, E - EGP
i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP
A - access/subscriber, a - Application route
M - mobile route, r - RPL, t - Traffic Engineering, (!) - FRR Backup path
Gateway of last resort is 172.30.2.1 to network 0.0.0.0
B* 0.0.0.0/0 [200/0] via 172.30.2.1, 1d03h
B 172.16.32.0/26 [20/0] via 172.20.1.1, 1d03h
B 172.16.47.237/32 [20/0] via 172.20.1.9 (nexthop in vrf VRF_RAN), 17:42:48
B 172.16.47.238/32 [20/0] via 172.20.1.9 (nexthop in vrf VRF_RAN), 17:42:48
C 172.20.1.0/29 is directly connected, 1d03h, TenGigE0/0/0/4.30
L 172.20.1.6/32 is directly connected, 1d03h, TenGigE0/0/0/4.30
B 172.20.1.8/29 is directly connected, 17:42:48, TenGigE0/0/0/4.40 (nexthop in vrf VRF_RAN)
B 172.20.10.0/32 is directly connected, 17:42:48, Loopback2010 (nexthop in vrf VRF_DNN_HUB)
B 172.21.0.0/32 is directly connected, 17:42:48, Loopback2100 (nexthop in vrf VRF_RAN)
B 172.21.2.0/24 is directly connected, 17:42:48, BVI2100 (nexthop in vrf VRF_RAN)
B 172.30.0.0/16 [200/5000] via 172.30.2.1, 1d03h
B 172.30.0.0/24 [200/5000] via 172.30.2.1, 1d03h
L 172.30.0.0/32 is directly connected, 1d03h, Loopback3000
C 172.30.2.0/31 is directly connected, 1d03h, Bundle-Ether1.300
L 172.30.2.0/32 is directly connected, 1d03h, Bundle-Ether1.300
B 172.31.0.0/24 [200/1] via 172.30.2.1, 1d03h
B 172.31.2.0/24 [200/1] via 172.30.2.1, 1d03h
B 192.168.1.0/24 [200/1] via 172.30.2.1, 1d03h
