Solved

In-band mgmt of cumulus switches using EVPN


I’m deploying a bunch of cumulus switches and plan on using EVPN to provide client connectivity.

I won’t be able to make use of the external management ports, so I was thinking of using in-band management. Since EVPN already provides VXLANs I figured I might as well make use of that and put my management interfaces in there, but I’m not 100% sure on what the best approach to that would be.

  1. Create separate In-Band MGMT VXLAN
  2. Add VXLAN to bridge
  3. Add VNI to bridge
  4. Add VNI to mgmt VRF

Would that be the way to go? Would perhaps someone have a configuration example on how to do that?

icon

Best answer by Eric Pulvino 19 May 2020, 17:32

Complexity is your enemy.

Management networks should generally be simple, always available things in the event that something does go wrong you want your mgmt connectivity to be the most stable.

With that in mind I wouldn’t setup VxLAN for your mgmt traffic. Personally I would leverage the existing loopbacks on the switch and their advertisement into the underlay (upon which EVPN is built) to provide your In-band management, this will decouple a failure in EVPN from a failure in your MGMT network. If I were really paranoid…. sometimes I am…. I would consider adding sub-interfaces to my routed fabric links to build a separate L2 mgmt network that does not depend on routing but instead on STP and blocking links to provide a second in-band mgmt network that does not rely on the exchange of routing information.

View original

2 replies

Userlevel 5

Complexity is your enemy.

Management networks should generally be simple, always available things in the event that something does go wrong you want your mgmt connectivity to be the most stable.

With that in mind I wouldn’t setup VxLAN for your mgmt traffic. Personally I would leverage the existing loopbacks on the switch and their advertisement into the underlay (upon which EVPN is built) to provide your In-band management, this will decouple a failure in EVPN from a failure in your MGMT network. If I were really paranoid…. sometimes I am…. I would consider adding sub-interfaces to my routed fabric links to build a separate L2 mgmt network that does not depend on routing but instead on STP and blocking links to provide a second in-band mgmt network that does not rely on the exchange of routing information.

Complexity is your enemy.

Management networks should generally be simple, always available things in the event that something does go wrong you want your mgmt connectivity to be the most stable.

With that in mind I wouldn’t setup VxLAN for your mgmt traffic. Personally I would leverage the existing loopbacks on the switch and their advertisement into the underlay (upon which EVPN is built) to provide your In-band management, this will decouple a failure in EVPN from a failure in your MGMT network. If I were really paranoid…. sometimes I am…. I would consider adding sub-interfaces to my routed fabric links to build a separate L2 mgmt network that does not depend on routing but instead on STP and blocking links to provide a second in-band mgmt network that does not rely on the exchange of routing information.


Thank you, those are two great ideas! I suppose in this case it might be a good idea to remove the mgmt VRF alltogether and simply use the underlay interfaces for management and such.

Adding a separate flat L2 would possibly be an option, but the whole design principle of this deployment was to get rid of L2 as much as possible. But it’s definitely an option.

Reply