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 1.2.3.4 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 1.1.1.1
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
*> 1.2.3.4/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 8.8.8.0/24 + 8.8.8.8/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 5.5.5.5 to network 0.0.0.0
1.2.3.4/31 is subnetted, 1 subnets
C 1.2.3.5 is directly connected, GigabitEthernet1/0.1000
B* 0.0.0.0/0 [20/0] via 5.5.5.5, 00:00:07
Update
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
1.0.0.0/31 is subnetted, 1 subnets
C 1.2.3.4 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 1.2.3.4 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
Weirdly, 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
*> 1.2.3.4/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 1.2.3.4 255.255.255.254 gi1/0.1000
which 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 8.8.8.8
84 bytes from 8.8.8.8 icmp_seq=1 ttl=254 time=91.234 ms
84 bytes from 8.8.8.8 icmp_seq=2 ttl=254 time=36.464 ms
VPCS> trace 8.8.8.8
trace to 8.8.8.8, 8 hops max, press Ctrl+C to stop
! The BDR gi1/0.100 interface
1 1.2.3.4 59.757 ms 21.889 ms 46.877 ms
! Upstream transit with 8.8.8.8 as a loopback
2 *5.5.5.5 56.333 ms (ICMP type:3, code:3, Destination port unreachable)
VPCS>
But this doesn't work:
BDR01-EQX-SY3#ping 1.2.3.5 !Pinging remote CPE
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.2.3.5, 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
Gives me:
VPCS> ping 8.8.8.8
*1.2.3.4 icmp_seq=1 ttl=255 time=10.452 ms (ICMP type:3, code:1, Destination host unreachable)
*1.2.3.4 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 8.8.8.8
84 bytes from 8.8.8.8 icmp_seq=1 ttl=254 time=91.234 ms
84 bytes from 8.8.8.8 icmp_seq=2 ttl=254 time=36.464 ms
84 bytes from 8.8.8.8 icmp_seq=3 ttl=254 time=14.171 ms