Redistributing OSPF into EVPN

I was recently working on a lab for VXLAN/EVPN and was trying to simulate a connection to the outside world. For the lab, I was using OSPF to connect to the pretend ISP router, and wanted to redistribute that route into the EVPN-based fabric for a customer using our fabric. I got most of this to work fairly simply, but ran into issues redistributing the Gateway of last resort.

Lab Setup

This is a very basic OSPF setup. I have an EOS device (acting as the pretend ISP) peering to a pair of MLAG/iBGP Leafs (Leaf 9 & Leaf 10), acting as Border Leafs. They peer on a 192.168.254.0/30 and 192.168.254.4/30 set of L3 links, and learn 3 subnets:

1. 192.168.1.0/24
2. 192.168.2.0/24
3. 192.168.3.0/24

The Pretend_ISP is also injecting the default route via ‘default information originate always’

Below is a screenshot of the topology.

And here is the OSPF Config for each

Pretend_ISP (vEOS11)

PRETEND_ISP#show run | sec router ospf 
router ospf 10
   router-id 11.11.11.11
   network 11.11.11.11/32 area 0.0.0.0
   network 192.168.0.0/16 area 0.0.0.0
   max-lsa 12000
   default-information originate always
PRETEND_ISP#

Leaf 9 (vEOS9)

Leaf9(config-router-bgp-vrf-CUST1)#do show run | sec router ospf 
router ospf 10 vrf CUST1
   network 192.168.0.0/16 area 0.0.0.0
   max-lsa 12000

Leaf 10 (vEOS10)

Leaf10(config)#do show run | sec router ospf 
router ospf 10 vrf CUST1
   router-id 10.10.10.10
   network 192.168.0.0/16 area 0.0.0.0
   max-lsa 12000

CUST1 Routing Table - Working Well

On verification, we can see that the routing table for Cust1 is as it should be. There is a gateway of last resort (thanks to the default-information originate always) from the Pretend_ISP, and we are also learning host routes devices in the same vrf from within the fabric. Things are looking good for us!

Redist OSPF

So, now all I need to do is to redistribute OSPF routes into the customer vrf and I will be golden! So let’s do that with ‘redistribute ospf’. There’s nothing fancy here, it’s just a lab after all, so we’ll just redistribute them without route-maps or anything like that.

Let’s check the route tables on other our other leaves and ensure we are good to go. Here’s Leaf1’s VRF for CUST1:

This is all pretty good. We can see we are learning the subnets as we expect. Oh, hang on a minute…

!! We are missing the gateway of last resort !!

Troubleshooting

I’ll keep this bit brief, because you don’t want to read me banging on about my troubleshooting methods. I initially thought that this was because it needed to be matched in a route-map. So i created a prefix list to match all routes, and chucked that in a route-map to permit. Finally, I referenced that route map on the redistribution.

Unfortunately, this didn’t work, which I thought was odd. I also checked the evpn soup using:

show bgp evpn route-type ip-prefix

But the prefix was missing. This was the expected outcome, but I did not have it:

Solution!

To cut a long story short, and to save you frustration, I needed to include the “match external” keywords on the OSPF redistribution. I don’t know if this is expected behaviour, or if it’s just an issue with my lab, but here’s what I had to do:

Now, let’s check Leaf1’s routing table:

Bonus Points for me - Double Backup Power!

In the example above, I had only redist’d from Leaf9. I matched the config from Leaf9 to Leaf10 (so they both worked) and wanted to show you that the routing table learns the gateway of last resort from both Leaf 9 & 10

Anyway, that’s it. Hope I have solved a problem for you. If I ever find out if this behaviour is abnormal from the good folks at Arista, I will let you know.