4

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.

Diagram of the scenario

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
9
  • IF I understand you correctly, you want to leak a default route from the global table into the customer VRF, but there isn't a default route in the global table. Could you create a static default route to nul 0 on the BDR, and leak that? Since you have full tables, some other route will match first.
    – Ron Trunk
    Jan 28, 2022 at 12:56
  • @RonTrunk Thank you for the advice! I am trying to test this, but I thought it wouldn't work? My understanding is/was that the VRF will lookup any routes but if that takes it to the GRT it will not then do another lookup in GRT? So wouldn't this end up black holing traffic in null0? Unfortunately having issues trying to export the /31 in the VRF out to the GRT now... Any advice appreciated so I can test this out. Thanks!
    – Geekman
    Feb 2, 2022 at 8:49
  • @RonTrunk More updates! I found that using a static route actually does partly work for global to see the VRF's connected /31. But it won't work for traffic originating in the BDR global table, which is what mislead me. If instead I trace/ping from the remote CPE on that /31 it works. Also - I tried your suggestion but it seems pretty clear that it won't work, unless I misunderstood? See latest edits at the bottom.
    – Geekman
    Feb 2, 2022 at 10:06
  • Maybe I misunderstood. Can you make a simple diagram?
    – Ron Trunk
    Feb 2, 2022 at 14:17
  • @RonTrunk Sorry to keep you waiting, I just added a diagram of my GNS3 lab - does this help? Can add more detail if needed!
    – Geekman
    Feb 4, 2022 at 10:45

1 Answer 1

0

You should ask the upstream providers (transit routers) to advertise a default route via BGP and then inject that default route in the VRF.

router bgp 65000
 bgp log-neighbor-changes
 neighbor 172.16.102.1 remote-as 65003
 neighbor 172.16.103.1 remote-as 65004
 !
 address-family ipv4
  network 192.168.101.0   <--- the public subnet from the VRF
  redistribute connected
  neighbor 172.16.102.1 activate
  neighbor 172.16.102.1 next-hop-self
  neighbor 172.16.103.1 activate
  neighbor 172.16.103.1 next-hop-self
  default-information originate
 exit-address-family
 !
 address-family ipv4 vrf CUSTA
  redistribute connected
 exit-address-family
 !
 vrf definition CUSTA
 rd 65000:100
 !
 address-family ipv4
  import ipv4 unicast map global-TO-vrf
  export ipv4 unicast map vrf-TO-global
  route-target export 65000:100
  route-target import 65000:100
 exit-address-family
!
!
interface GigabitEthernet0/0
 vrf forwarding CUSTA
 ip address 192.168.101.100 255.255.255.0
!
ip prefix-list Default seq 5 permit 0.0.0.0/0
ip prefix-list vrf-TO-global seq 5 permit 192.168.101.0/24
!
route-map vrf-TO-global permit 10
 match ip address prefix-list vrf-TO-global
route-map global-TO-vrf permit 10
 match ip address prefix-list Default
!
R100#sh ip bgp            
     Network          Next Hop            Metric LocPrf Weight Path
 *    0.0.0.0          172.16.103.1                           0 65004 i
 *>                    172.16.102.1                           0 65003 i
!
R100%CUSTA#sh ip route | i 0.0/0
B*    0.0.0.0/0 [20/0] via 172.16.102.1, 00:01:05
!
R100%CUSTA#sh ip cef 0.0.0.0/0 
0.0.0.0/0
  nexthop 172.16.102.1 GigabitEthernet0/1

!
5
  • Thank you for this! This seems fairly similar to what I've already tried, can you help me understand what differences exactly are important here? I.e. I see you're using OSPF and I'm only using BGP - is that needed? I did not try default originate on my actual BDR, whereas you have, so that may indeed work better than my default route to null0! I will try this out over the weekend. Thanks again.
    – Geekman
    Feb 4, 2022 at 10:49
  • You don't need OSPF, you can use only BGP and yes, you need the default-information originate (you need a valid default route in the global for this to work). I just wondering why you need this - you still need to advertise the VRF subnets into the global for reachability purposes and in my opinion, you don't need that VRF.
    – new_py
    Feb 4, 2022 at 11:53
  • I'm only going to be leaking their public WAN IP. There's going to be a second interface also in the VRF used as a L3 VPN to AWS. I want to keep RFC1918 IPs isolated in the VRF, but I am trying to export/import their public internet address, which is currently already in the global.
    – Geekman
    Feb 4, 2022 at 12:43
  • With regards to what you said - I need a valid default route in the global for default-originate to work. But I don't have a default in most cases as the BDR is full tables. So I don't see how this is different to what I've already tried? I don't really want to use a default from my upstream transits because then I lose failover to other transits, and can't do TE to send some traffic over domestic peering, etc.
    – Geekman
    Feb 4, 2022 at 12:47
  • The best solution in your case is to ask the providers to advertise a default route because you won't be able to create a dummy one and use it in your case.
    – new_py
    Feb 5, 2022 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.