Cheers John!

Ah, well, you might not believe this, but it isn't actually real. That's the magic of editing. 🪄🎩🐇

Thanks! My approach is really about the protocol rather than the implementation. Understand the headers, encap and such like, then the implementation is a secondary concern. But I do take your point about campus, and will try not to just replicate all that other 'VXLAN in the DC' content. Thanks for the comment, that's a useful point of view to bear in mind for my planning.

Liked that! Same for the rest of the video. Like with many things, when explained like this, it is not that hard to understand. You just need to get it. I got it.

@@hermanrobers Thanks Herman. It is just simple encapsulation of L2 in L3 (UDP) at its heart.

@@null_zero For future video topic, VXLAN and IPv4 multicast on the overlay

I feel the 6300s don't have routes to reach the destination

Thanks. That's recorded on actual hardware (aruba 6300s).

It is L2 between the switches, the IP addressing is for the full end-to-end connection, from node1 to node2.

Thanks, there is a playlist here: kzfaq.info/sun/PLsYGHuNuBZcZB8nMxgPwGlGEUscwP_RNH

VXLAN being data plane, if you’re talking inter-subnet flows (using a gateway) there’s a number of options. Old style would be an IP only centralised router on a stick, here a VTEP decaps the VXLAN, passing IP traffic to a router, that routes then forwards back to the VTEP. A better approach is to introduce EVPN for the control plane, with this you can utilise integrated routing and bridging (IRB) and anycast gateways. Basically the VTEPs are able to route between subnets plus they are configured with a virtual IP and MAC address so that all the VTEP can route but the end clients only need to be configured with a single default gateway. ( yes, there is a lot of work involved in fixing the issue that you raise) 😅, but it’s all a part of EVPN-VXLAN.

@@null_zero Understood. I get how the any cast gateway can route out. But lets say you have a 3rd party connection coming into a set of servers that are on this EVPN-VXLAN, and it comes into the anycast gateway for the correct site, does the anycast gatyeway have a full mac/arp table of which macs are on which VTEP?

@@seantellsit1431 This detail comes from the type of IRB configured for EVPN. There’s two types: 1/ with asymmetrical IRB, the VTEP gway is configured with every VLAN/subnet/VNI that is can route to. The VTEP does carry the MAC and ARP table for all destination VLAN/subnets. This does not scale well because of all the finite resources on the VTEP that carrying those tables burns up. 2/ Symmetrical IRB - the VTEPs are only configured with, and carry the tables of, the locally attached VLAN/subnet PLUS a shared VNI. VTEPs use RT-5s to advertise IP prefixes, rather than needing all MACs to be advertised. When routing, the symmetrical VTEP can use the IP prefix to direct packets to the destination VTEP, and it uses the shared VNI to VXLAN encap the traffic. Note that because it is not configured with the destination VNI-VLAN mapping, it uses this shared VNI to transport the traffic to the destination VTEP, which then does the lookup to drop the packets onto the correct VLAN. Symmetrical is more complex but more scalable because the VTEP only carries the local MAC/ARP tables.

The large number of VNIs helps support multiple customers on shared infrastructure. Imagine two customers are using the same VXLAN network, which is run by a third-party. Customer A uses VLANs 100-200, customer B also uses VLANs 100-200. The large number of VNIs means the third party can assign VNIs for both customers, and these can be values that are not 100-200, we can decouple local VLAN ID from VNIs. So nothing actually “happens” the VNIs are just IDs.

asp.arubanetworks.com/downloads/software/RmlsZTpjYzU1YTdhYS1mMzBlLTExZWMtOTIxOC1jZjBjNDk2ZmU3ZTM%3D