I am fairly inexperienced with VRF, and I'm struggling to leak a default route from the global table, into the VRF. I've come across various solutions, but none seem to properly fit my requirements, or I can't get them to work.
In summary: How can I leak a default route to a VRF, such that the traffic goes to the global routing table on the same router, and the next-hop does not need to be statically defined? I.e. It can follow the next-hop for that destination, as defined by the global routing table, for redundant paths?
EDIT: As below, I got a default route exported via BGP export maps, though this requires me to have a default route coming from all my transit upstreams, which is not the case right now, and would not allow me to utilise any peering.
The scenario is:
We have a customer with a PtP Ethernet link handed off to a VLAN on our side, which we provide internet for. Right now this is just on the global table, but I will move it into the VRF.
We plan to have multiple PtP Ethernets for this customer, and a shared VPN for all sites between their LANs and AWS. My preferred solution is to use a VRF for this customer.
The VRF will still need to have a default route for internet access, and I suppose the global table will need a route for the internet WAN IP.
The main restrictions seem to be:
We have a BDR router with a full table, and iBGP paths to multiple other BDR routers with their own full table as repair paths. I don't want to set a static next-hop in the global table to one of our upstream transits, as it's important
The customer's VRF is on the same router as our BDR/transit router, so the "next hop" of the default route is on the same router. This might have not been an issue if the customer's VRF was on a separate BNG router, but I can't change this right now.
Only one of our upstream transits gives us a default route in addition to a full table, so really there is no upstream default route on our BDRs in most cases - the BDR routers exchange full tables with each other in the global table.
Things I've tried
I don't want to do a static default route in the VRF as I'd need to specify the next hop as one of my transits, and this would break redundant/repair-paths for this VRF.
I tried doing a static default route to the loopback of this BDR router in the global table, but it said
%Invalid next hop address (it's this router)
I've tried configuring an import map, which seems to require the use of MP-BGP. I am totally open to this as I plan to expand this config to use MPLS for inter-state traffic anyway - however I can't get it to work.
This is what I've done in GNS3.
router bgp 6500 address-family ipv4 vrf CUSTA redistribute connected no synchronization exit-address-family ip prefix-list GLOBAL_TO_VRF_CUSTA seq 5 permit 0.0.0.0/0 route-map GLOBAL_TO_VRF_CUSTA permit 10 match ip address prefix-list GLOBAL_TO_VRF_CUSTA ip vrf CUSTA rd 64513:1 import ipv4 unicast map GLOBAL_TO_VRF_CUSTA route-target both 64513:1 exit interface GigabitEthernet1/0.1000 description CUSTA Internet PtP encapsulation dot1Q 1000 ip vrf forwarding CUSTA ip address 22.214.171.124 255.255.255.254
I don't see a default route - just the connected CUSTA interface in the VRF:
BDR01#sh bgp vpnv4 unicast vrf CUSTA BGP table version is 7, local router ID is 126.96.36.199 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 64513:1 (default for vrf CUSTA) Import Map: GLOBAL_TO_VRF_CUSTA, Address-Family: IPv4 Unicast, Pfx Count/Limit: 0/1000 *> 188.8.131.52/31 0.0.0.0 0 32768 ? BDR01#
EDIT: I have since got a default route leaked into the VRF using the BGP export map. Though this is not ideal as it requires a default route in the table of all my BDR routers (i.e. all my upstream transits) and would not allow traffic to go to IX Peers.
So while this technically works, I'd love a more flexible solution.
The issue preventing the above from working was that the BDR router in my lab did not have a default route in it's global table - I had just advertised 184.108.40.206/24 + 220.127.116.11/32 from a "transit router" in my lab. Because there was no 0.0.0.0/0 in the global table to export, it wasn't exporting to the VRF.
The fix so far was:
TRANSIT-GW101-01(config)#router bgp 6550 TRANSIT-GW101-01(config-router)#default-information originate TRANSIT-GW101-01(config)#ip route 0.0.0.0 0.0.0.0 Null0 And now it shows in the VRF on the BDR: ---- BDR01#sh ip route vrf CUSTA Routing Table: CUSTA 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 18.104.22.168 to network 0.0.0.0 22.214.171.124/31 is subnetted, 1 subnets C 126.96.36.199 is directly connected, GigabitEthernet1/0.1000 B* 0.0.0.0/0 [20/0] via 188.8.131.52, 00:00:07
As suggested by Ron below, I have removed the
0.0.0.0/0 from my fake upstream transit and instead added it on the BDR router itself. This still seems to advertise
0.0.0.0/0 to the VRF! Though it's pointing to Null0.
To test this properly, I need to export the /31 route from the VRF to the global table - but after trying some things, I also seem to be struggling with that!
ANOTHER EDIT: It looks like the static /31 route in the GRT to point to the interface in the VRF does work, but I guess not locally on the same BDR router. See details below...
BDR01#sh ip route vrf CUSTA Routing Table: CUSTA 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 0.0.0.0 to network 0.0.0.0 184.108.40.206/31 is subnetted, 1 subnets C 220.127.116.11 is directly connected, GigabitEthernet1/0.1000 B* 0.0.0.0/0 is directly connected, 00:00:03, Null0 BDR01#
Exporting from VRF to global
Tried using a static route in GRT:
ip route 18.104.22.168 255.255.255.254 Gi1/0.1000
- While the route exists, I can't ping from GRT to the /31
- I also can't ping from the remote end of the /31 ptp link to the GRT.
I tried using BGP with a vrf export statement, just like I've done for import above (which works). Right now just allowing all.
Showing some excerpts of relevant config for export from VRF to global:
route-map VRF_CUSTA_TO_GLOBAL permit 10 ip vrf CUSTA export map VRF_CUSTA_TO_GLOBAL router bgp XXXX address-family ipv4 vrf CUSTA redistribute connected no-synchronization exit-address-family
sh bgp vpnv4 vrf CUSTA seems to show this as a BGP network entry, so this would suggested connected prefixes in the VRF are being redistributed correctly. But I don't see it in the GRT.
Also it shows an import map, but not an export one? I guess maybe this is because my older IOS version doesn't seem to support "unicast" for export maps?
BDR01#sh bgp vpnv4 unicast vrf CUSTA BGP table version is 9, local router ID is x.x.x.x Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 64513:1 (default for vrf CUSTA) Import Map: GLOBAL_TO_VRF_CUSTA, Address-Family: IPv4 Unicast, Pfx Count/Limit: 1/1000 *> 0.0.0.0 0.0.0.0 0 32768 i *> 22.214.171.124/31 0.0.0.0 0 32768 ?
BDR01#sh ip vrf detail CUSTA VRF CUSTA; default RD 64513:1; default VPNID <not set> Interfaces: Gi1/0.1000 Connected addresses are not in global routing table Export VPN route-target communities RT:64513:1 Import VPN route-target communities RT:64513:1 Import route-map for ipv4 unicast: GLOBAL_TO_VRF_CUSTA (prefix limit: 1000) Export route-map: VRF_CUSTA_TO_GLOBAL
Added VRF /31 to Global Table with Static
Initially I thought using a static route to put the /31 in the GRT was not working, but it turns out it only works for traffic leaving the interface in the VRF -- i.e. to the remote end.
This makes sense as the static route is
ip route 126.96.36.199 255.255.255.254 gi1/0.1000which points to the remote end.
However, pings/traces from BDR01 in the default table cannot talk to the remote end. But the remote end can talk and get replies via BDR01.
E.g. This works:
VPCS> ping 188.8.131.52 84 bytes from 184.108.40.206 icmp_seq=1 ttl=254 time=91.234 ms 84 bytes from 220.127.116.11 icmp_seq=2 ttl=254 time=36.464 ms VPCS> trace 18.104.22.168 trace to 22.214.171.124, 8 hops max, press Ctrl+C to stop ! The BDR gi1/0.100 interface 1 126.96.36.199 59.757 ms 21.889 ms 46.877 ms ! Upstream transit with 188.8.131.52 as a loopback 2 *184.108.40.206 56.333 ms (ICMP type:3, code:3, Destination port unreachable) VPCS>
But this doesn't work:
BDR01-EQX-SY3#ping 220.127.116.11 !Pinging remote CPE Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 18.104.22.168, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) BDR01#
Testing 0.0.0.0 on BDR01 itself
Once I had a functional test, I tried Ron's suggestion of adding a 0.0.0.0/0 route pointing to Null0 but as I thought, it seems like this just blackholes the traffic?
BDR01(config)#ip route 0.0.0.0 0.0.0.0 Null0
VPCS> ping 22.214.171.124 *126.96.36.199 icmp_seq=1 ttl=255 time=10.452 ms (ICMP type:3, code:1, Destination host unreachable) *188.8.131.52 icmp_seq=2 ttl=255 time=9.956 ms (ICMP type:3, code:1, Destination host unreachable)
Then I remove the null0 route again and ping works again with the upstream transit's default route:
BDR01(config)#no ip route 0.0.0.0 0.0.0.0 Null0
It works again:
VPCS> ping 184.108.40.206 84 bytes from 220.127.116.11 icmp_seq=1 ttl=254 time=91.234 ms 84 bytes from 18.104.22.168 icmp_seq=2 ttl=254 time=36.464 ms 84 bytes from 22.214.171.124 icmp_seq=3 ttl=254 time=14.171 ms