How its is decide that which vtep join in multicast group, as if host -1 send packet to Host-2 first time then , how fabric sw-2 vtep know that it has to join the same multicast grp, which sw-1 joined ?

You manually configure on the VTEP what multicast group to join and this has to be consistently configured across the VXLAN on each switch. You may choose to configure a different multicast group per VXLAN or you can choose to configure the same group across all VXLANs it depends how you wish to scale. If you choose the same group the switch will inspect the multicast packet for the VNI (VXLAN) to see if has the VNI and if it needs to act even if it does not have the the VNI. Or you can increase the amount of multicast groups so switches only receive BUM traffic they require at the cost of more multicast groups. Edit: Typo

@@LewisBowerbank Thanks for replying , if i have more queries, can i ask again ?

@@vikrantpandey569 sure no problem

Hi Lewis, As I am new to vxlan having few doubts. Could you plz let me know mapping of vlan 10 to vxlan 10010 in sw-1 and vlan-20 to vxlan 10020 in sw-2 is it a inter vlan communication happened or same vlan communication happened bit confused . As per my understanding same vlan-10 should be mapped to vxlan 10010 in sw-1 and sw-2 then host1 and host2 can communicate which are having same vlan as well as same vxlan I'd in overlay network? Plz correct me . Could not get the correct answer from anyone else. Hope you clear my doubt..

Thanks, I'm glad you found it useful

That's cool, glad it helped you out!

Any more videos u can share on DC..?

@@ramkrish9098 Hi Ram Krish, I will be picking my videos up again very soon. Sorry for the late response I did not see your question.

I'm glad you liked it, thanks for watching Mey

Great I'm glad it helped you! Good luck with your BGP EVPN research.

Hi Prateek, the Cat9500 and Nexus 9300's are quite similar in price I believe and at the moment you don't have to buy DNS licensing for the Nexus. Off the top of my head the 9500's are capable of VXLAN but I haven't looked into it in much detail. Thanks for watching!

Yes as long as you have end to end reachability you can use anything to do the underlay routing. consider you will not have dynamic routing for fail over though so your tunnels will only form over the static path.

Hi Sarvesh, The book Building Data Centers with VXLAN BGP EVPN: A Cisco NX-OS Perspective is very good and the only book I have gone through for this. Other than that I have used odd bits off Google searches and blogs.

Hey, thank you. I have been meaning to pick up the channel again. I'd like to go a bit further into it on the channel hopefully I will make some time to do some more videos soon

@@LewisBowerbank Thanks i will wait :)

Hey sorry for the delay, I haven't been involved with using three tiers aka using "super spines" generally it allows you to scale further. The VTEP is still at the leaf so you are effectively adding more bandwidth to a solution is my understanding. VXLAN is able to be built out over an IP network as long as your edge devices support the VXLAN features. You also need to consider Multicast or Ingress replication on your legacy IP network acting as the underlay. If you are trying to build out a VXLAN design on a legacy 3-tier design I would suggest adding another distribution layer off your core or connect to the core with a new VXLAN designed focused on a well supported design approach like a CLOS topology. For your gateway question using distributed anycast IP, this will act as your gateway. The IP address is identical on all your switches and has the same MAC address defined this is configured consistently for each of your VXLAN. This will allow the host to arrive on any of your switches and able to use the default gateway based on the information the host has already cached. How you route that over tunnels can be done using symmetric or asymmetric IRB which you should understand. I do not have any configuration I can share for this, however there are many good examples using Google that break down sections of the configuration

Your spine device is supporting your leaf switches connectivity. It needs the features that will allow your underlay routing of choice to provide full reachability of all interfaces/loopbacks you intend to use to build the VXLAN overlay on and it needs to support the physical media depending on the connectivity types/speed. Typically the spine is going to be high speed connectivity for east/west traffic. You would be using leaf switches to bring connectivity in from the user traffic connecting into the overlay, you're north/south traffic.

Hey, on a different switches it is possible to have two different vlan ID but make them belong to same VNI. Probably not a good thing to do but possible to configure and communicate across. If you configured two different VLANs on different switches and make them use two different VNI then you wouldn't have layer 2 Comms on them. The same goes if you used the same VLAN on different switches but used different VNI for this VLAN on each switch, you wouldn't get layer two Comms between them. This is providing you are using VXLAN tunneling to communicate and not using a trunk between the switches.

Thanks for watching, sorry I do want to come back to this and resume the channel.

Some applications/storage solutions still use L2 would be one use case. Ideally you would leave the L2 domain at the top of rack and keep it simple but it all depends on the needs.

I will come back to it soon, it has been far too long...