Spine + Route Reflector
S1-RR acts as a route reflector (RR) with loopback 10.10.10.1/32, ASN 6500.
L1, L2, and L3 are leaf routers peering with S1-RR using /31 transit subnets:
L1 ↔ S1-RR: 172.29.0.0/31
L2 ↔ S1-RR: 172.29.0.2/31
L3 ↔ S1-RR: 172.29.0.4/31
BFD is working well too
Partial Working
Currently, only one VNI is functional at a time. Additionally, configuring EVPN via /routing/bgp/evpn occasionally cause hang that leads to router crash when it reboot it will work eventually
I’m not sure if this is a GNS3-related bug. At this point, migrating the lab to real hardware feels excessive due to the instability and effort involved.
For further testing beyond this lab setup, VLAN trunk should work between L1,L2 and L3 with hypervisor host this is an absolute minimum (as shown in the diagram).
At the moment, I’m unclear on the correct configuration steps to enable this, can someone shed some light on this please?
Wow we almost have the same topology great thanks priceless but i’m still thinking there should be a way to pass multiple VLAN within the same VNI this is wasteful of interface again thanks great find
I found a bug, when you do have multiple vxlan and VNI only one vtep has been dynamically created, only the last entry on the /interface/vxlan menu. creating a manual vtep is the workaround for the setup to work upon next reboot
You can trigger the creation of dynamic VTEP for all VNI by using this /interface/vxlan/set dont-fragment=disable [index] to make this work but it won’t survived upon next reboot therefore creating a manual VTEP is necessary.
Toggling Enable/Disable on the vxlan interface is not enough to create a Dynamic VTEP this command /interface/vxlan/set dont-fragment=disable [index] is my only reliable way to trigger the creation of VTEP
Disclaimer: this happen on GNS3 i haven’t tried this yet on a real hardware
I’m going to recall this bug report, the soon as I put my loopback address as local-address in VXLAN interface both VTEPS has been dynamically created, case close user error !
I spoke to soon, there still something odd with this dynamic vtep creation since i was able to define properly my local-address in vxlan interface toggling on and off the vxlan interface create the desired VTEP.
/routing/bgp/evpn menu triggers the creation of VTEP for sure, but there’s a bug on that code that’s very fragile
Yeah, actually what we have right now is just the tip of the iceberg even though they land some fixes to make this very useful in DC/SP setting, some other folks here mentioned already some of the needed and must have feature to make this even worthwhile like mac-vrf, anycast gateway etc… but MT is in the right track on this one I hope they can blow the competition and bring this stuff to finish line this will be a game changer if they do
(as shown in the diagram).
