I’m pretty inexperienced with VRF, and I am struggling to leak a default route from the worldwide desk, into the VRF. I’ve come throughout varied options, however none appear to correctly match my necessities, or I can not get them to work.
In abstract:
How can I leak a default path to a VRF, such that the site visitors goes to the worldwide routing desk on the identical router, and the next-hop doesn’t should be statically outlined? I.e. It might probably comply with the next-hop for that vacation spot, as outlined by the worldwide routing desk, for redundant paths?
EDIT: As under, I obtained a default route exported by way of BGP export maps, although this requires me to have a default route coming from all my transit upstreams, which isn’t the case proper now, and wouldn’t enable me to utilise any peering.
The situation is:
-
We now have a buyer with a PtP Ethernet hyperlink handed off to a VLAN on our aspect, which we offer web for. Proper now that is simply on the worldwide desk, however I’ll transfer it into the VRF.
-
We plan to have a number of PtP Ethernets for this buyer, and a shared VPN for all websites between their LANs and AWS. My most well-liked resolution is to make use of a VRF for this buyer.
-
The VRF will nonetheless must have a default route for web entry, and I suppose the worldwide desk will want a route for the web WAN IP.
The primary restrictions appear to be:
-
We now have a BDR router with a full desk, and iBGP paths to a number of different BDR routers with their very own full desk as restore paths. I do not wish to set a static next-hop within the international desk to considered one of our upstream transits, because it’s essential
-
The client’s VRF is on the identical router as our BDR/transit router, so the "subsequent hop" of the default route is on the identical router. This may need not been a problem if the shopper’s VRF was on a separate BNG router, however I can not change this proper now.
-
Solely considered one of our upstream transits offers us a default route along with a full desk, so actually there is no such thing as a upstream default route on our BDRs usually – the BDR routers alternate full tables with one another within the international desk.
Issues I’ve tried
-
I do not wish to do a static default route within the VRF as I would must specify the following hop as considered one of my transits, and this is able to break redundant/repair-paths for this VRF.
-
I attempted doing a static default path to the loopback of this BDR router within the international desk, nevertheless it stated
%Invalid subsequent hop tackle (it is this router) -
I’ve tried configuring an import map, which appears to require the usage of MP-BGP. I’m completely open to this as I plan to increase this config to make use of MPLS for inter-state site visitors anyway – nevertheless I can not get it to work.
That is what I’ve accomplished in GNS3.
router bgp 6500
address-family ipv4 vrf CUSTA
redistribute related
no synchronization
exit-address-family
ip prefix-list GLOBAL_TO_VRF_CUSTA seq 5 allow 0.0.0.0/0
route-map GLOBAL_TO_VRF_CUSTA allow 10
match ip tackle prefix-list GLOBAL_TO_VRF_CUSTA
ip vrf CUSTA
rd 64513:1
import ipv4 unicast map GLOBAL_TO_VRF_CUSTA
route-target each 64513:1
exit
interface GigabitEthernet1/0.1000
description CUSTA Web PtP
encapsulation dot1Q 1000
ip vrf forwarding CUSTA
ip tackle 1.2.3.4 255.255.255.254
I do not see a default route – simply the related CUSTA interface within the VRF:
BDR01#sh bgp vpnv4 unicast vrf CUSTA
BGP desk model is 7, native router ID is 1.1.1.1
Standing codes: s suppressed, d damped, h historical past, * legitimate, > finest, i - inner,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Community Subsequent Hop Metric LocPrf Weight Path
Route Distinguisher: 64513:1 (default for vrf CUSTA)
Import Map: GLOBAL_TO_VRF_CUSTA, Deal with-Household: IPv4 Unicast, Pfx Rely/Restrict: 0/1000
*> 1.2.3.4/31 0.0.0.0 0 32768 ?
BDR01#
EDIT: I’ve since obtained a default route leaked into the VRF utilizing the BGP export map. Although this isn’t superb because it requires a default route within the desk of all my BDR routers (i.e. all my upstream transits) and wouldn’t enable site visitors to go to IX Friends.
So whereas this technically works, I would love a extra versatile resolution.
The difficulty stopping the above from working was that the BDR router in my lab didn’t have a default route in it is international desk – I had simply marketed 8.8.8.0/24 + 8.8.8.8/32 from a "transit router" in my lab. As a result of there was no 0.0.0.0/0 within the international desk to export, it wasn’t exporting to the VRF.
The repair up to now 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 reveals within the VRF on the BDR:
----
BDR01#sh ip route vrf CUSTA
Routing Desk: CUSTA
Codes: C - related, S - static, R - RIP, M - cellular, B - BGP
D - EIGRP, EX - EIGRP exterior, O - OSPF, IA - OSPF inter space
N1 - OSPF NSSA exterior sort 1, N2 - OSPF NSSA exterior sort 2
E1 - OSPF exterior sort 1, E2 - OSPF exterior sort 2
i - IS-IS, su - IS-IS abstract, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter space, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of final resort is 5.5.5.5 to community 0.0.0.0
1.2.3.4/31 is subnetted, 1 subnets
C 1.2.3.5 is immediately related, GigabitEthernet1/0.1000
B* 0.0.0.0/0 [20/0] by way of 5.5.5.5, 00:00:07
Replace
As instructed by Ron under, I’ve eliminated the 0.0.0.0/0 from my faux upstream transit and as an alternative added it on the BDR router itself. This nonetheless appears to promote 0.0.0.0/0 to the VRF! Although it is pointing to Null0.
To check this correctly, I must export the /31 route from the VRF to the worldwide desk – however after making an attempt some issues, I additionally appear to be scuffling with that!
ANOTHER EDIT: It seems just like the static /31 route within the GRT to level to the interface within the VRF does work, however I suppose not domestically on the identical BDR router. See particulars under…
BDR01#sh ip route vrf CUSTA
Routing Desk: CUSTA
Codes: C - related, S - static, R - RIP, M - cellular, B - BGP
D - EIGRP, EX - EIGRP exterior, O - OSPF, IA - OSPF inter space
N1 - OSPF NSSA exterior sort 1, N2 - OSPF NSSA exterior sort 2
E1 - OSPF exterior sort 1, E2 - OSPF exterior sort 2
i - IS-IS, su - IS-IS abstract, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter space, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of final resort is 0.0.0.0 to community 0.0.0.0
1.0.0.0/31 is subnetted, 1 subnets
C 1.2.3.4 is immediately related, GigabitEthernet1/0.1000
B* 0.0.0.0/0 is immediately related, 00:00:03, Null0
BDR01#
Exporting from VRF to international
-
Tried utilizing a static route in GRT:
ip route 1.2.3.4 255.255.255.254 Gi1/0.1000- Whereas the route exists, I can not ping from GRT to the /31
- I can also’t ping from the distant finish of the /31 ptp hyperlink to the GRT.
-
I attempted utilizing BGP with a vrf export assertion, similar to I’ve accomplished for import above (which works). Proper now simply permitting all.
Exhibiting some excerpts of related config for export from VRF to international:
route-map VRF_CUSTA_TO_GLOBAL allow 10
ip vrf CUSTA
export map VRF_CUSTA_TO_GLOBAL
router bgp XXXX
address-family ipv4 vrf CUSTA
redistribute related
no-synchronization
exit-address-family
Weirdly, sh bgp vpnv4 vrf CUSTA appears to indicate this as a BGP community entry, so this is able to instructed related prefixes within the VRF are being redistributed accurately. However I do not see it within the GRT.
Additionally it reveals an import map, however not an export one? I suppose possibly it is because my older IOS model does not appear to help "unicast" for export maps?
BDR01#sh bgp vpnv4 unicast vrf CUSTA
BGP desk model is 9, native router ID is x.x.x.x
Standing codes: s suppressed, d damped, h historical past, * legitimate, > finest, i - inner,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Community Subsequent Hop Metric LocPrf Weight Path
Route Distinguisher: 64513:1 (default for vrf CUSTA)
Import Map: GLOBAL_TO_VRF_CUSTA, Deal with-Household: IPv4 Unicast, Pfx Rely/Restrict: 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 element CUSTA
VRF CUSTA; default RD 64513:1; default VPNID <not set>
Interfaces:
Gi1/0.1000
Linked addresses are usually not in international routing desk
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 restrict: 1000)
Export route-map: VRF_CUSTA_TO_GLOBAL
Added VRF /31 to World Desk with Static
-
Initially I believed utilizing a static route to place the /31 within the GRT was not working, nevertheless it seems it solely works for site visitors leaving the interface within the VRF — i.e. to the distant finish.
-
This is smart because the static route is
ip route 1.2.3.4 255.255.255.254 gi1/0.1000which factors to the distant finish. -
Nevertheless, pings/traces from BDR01 within the default desk can’t discuss to the distant finish. However the distant finish can discuss and get replies by way of 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> hint 8.8.8.8
hint to eight.8.8.8, 8 hops max, press Ctrl+C to cease
! 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 sort:3, code:3, Vacation spot port unreachable)
VPCS>
However this does not work:
BDR01-EQX-SY3#ping 1.2.3.5 !Pinging distant CPE
Kind escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.2.3.5, timeout is 2 seconds:
.....
Success charge is 0 p.c (0/5)
BDR01#
Testing 0.0.0.0 on BDR01 itself
As soon as I had a practical check, I attempted Ron’s suggestion of including a 0.0.0.0/0 route pointing to Null0 however as I believed, it looks like this simply blackholes the site visitors?
BDR01(config)#ip route 0.0.0.0 0.0.0.0 Null0
Offers me:
VPCS> ping 8.8.8.8
*1.2.3.4 icmp_seq=1 ttl=255 time=10.452 ms (ICMP sort:3, code:1, Vacation spot host unreachable)
*1.2.3.4 icmp_seq=2 ttl=255 time=9.956 ms (ICMP sort:3, code:1, Vacation spot host unreachable)
Then I take away the null0 route once more and ping works once more with the upstream transit’s default route:
BDR01(config)#no ip route 0.0.0.0 0.0.0.0 Null0
It really works once more:
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
