VXLAN Underlay OSPF

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Hi Rene,

Great lesson as usually, thank you! I want to ask what is the meaning of the second route with the metric of 250?

3.3.3.3/32, ubest/mbest: 1/0
    *via 3.3.3.3, Eth1/1, [110/41], 00:11:01, ospf-UNDERLAY, intra
     via 3.3.3.3, Eth1/1, [250/0], 00:11:00, am
3

Hello Pinar

That’s a great observation. This is actually the result of an NX-OS internal mechanism that is applied by a process within the device known as the Adjacency Manager. That’s what the “am” at the end of that entry means.

AM routes are installed using a feature that creates a backup route when OSPF forms adjacency over a point-to-point link. This is not necessarily a point-to-point technology like a serial link, but a direct link between neighbors, even over an Ethernet connection, just like in your output.

It acts as a fallback mechanism if the OSPF-learned route is lost. It has an AD of 250, which is a very low preference. It is only better than “unknown,” which has a value of 255. It provides reachability to the neighbor’s router ID even if OSPF fails. It has the same exit interface as the OSPF route.

The AM route with AD 250 is a backup and won’t be used unless the OSPF route disappears. Note that in your output, the asterisk “*” is on the OSPF route, which is the currently chosen route. The other one acts as a standby backup, with a metric of 0. That 0 is actually just a place-holder, it has no meaning since AM is not really a routing protocol. The route itself is derived from the neighbor/ARP entry for that on-link IP, created by the Adjacency Manager to program the adjacency.

Why does this feature exist? Well, it provides additional resiliency. If you remove/lose the OSPF route, the AM route can become the active way to reach that specific neighbor IP (since it’s directly connected), but it won’t help you reach anything beyond it. It just keeps the adjacency up.

This behavior can be modified with the no ospf passive-interface command or by adjusting OSPF network types, but it’s generally beneficial to keep it for VXLAN underlay stability.

I hope this has been helpful!

Laz

4

Hello Laz,

Thank you very much for the explanation, very clear now!

5

Hi

Which nodes is it possible to use in CML for this lab instead of NX-9000? They require far too much memory. With my 64G I can start just 4 Nexus’

As an option I also consider Arista with the Containerlab

Thank you, Vladimir

6

Hello Vladimir

That’s a good question! There are several options you have at your disposal:

  1. You can use the CSR1000v or the Catalyst 8000v as VTEPs, which run IOS-XE and typically use about half of the resources of the NX-9000. However, the CLI of these devices is different, so you can’t simply copy and paste the configs from NX-OS to the IOS-XE OS. You must adapt the configs accordingly.
  2. Also keep in mind that the SPINE devices don’t operate as VTEPs, they only forward IP packets based on the OSPF/IS-IS underlay. So you can use IOSv devices for the spines and keep the NX-9000s as the VTEPs.

For option 2, if you do evolve to use BGP EVPN Route Reflectors on your SPINEs, your IOSv devices may not support this, so in this case you would need to deploy either the CSR1000v or the C8000v for that…

Hopefully, a combination of the above will help you out in getting more out of your CML deployment on your device.

I hope this has been helpful!

Laz

1 Like
7

Hello Laz

Thanks a lot!

A combination of 4 x NX-OS 9000 and 2 x CSR1000v works perfectly well.

Best regards,
Vladimir

8

Hello Vladimir

That’s great to hear, and it’s useful info for all those labbing these topologies!

Thanks again!

Laz