This topic is to discuss the following lesson:
What if the spine switch had a different AS number?
Hello @dimasgb ,
There are some pros and cons of using eBGP or iBGP on the fabric. I’ll create an entire lesson for this with some other options for the underlay network. I’ll add a link here when it’s finished.
Hello,
Why we are using multicast here in config if we are using MP-BGP EVPN?
As i know
-
Traditionally, multicast has been used for broadcast and unknown unicast traffic replication in Layer 2 networks. However, VxLAN can leverage different mechanisms, such as BGP EVPN, to handle the control plane and eliminate the dependency on multicast for traffic replication.
-
Multicast can indeed introduce additional load on network equipment, especially in large-scale deployments with a high volume of multicast traffic. By using VxLAN with BGP EVPN, you can reduce or eliminate the need for multicast replication within the overlay network. Instead, BGP EVPN allows for efficient and scalable control plane learning, where the information about MAC addresses and reachability is exchanged between the VxLAN endpoints using BGP. This approach can provide advantages such as reduced network complexity, improved scalability, and easier integration with existing network architectures.
Hello Amit
Indeed MP-BGP EVPN resolves the issue of the flood and learn mechanism that multicast uses, enabling a more efficient communication using VXLAN. However, MP-BGP EVPN functions only for unicast traffic. Many services and devices will still be using BUM traffic (Broadcast, Unknown Unicast, Multicast), and this kind of traffic cannot be dealt with just using MP-BGP EVPN. There must be an underlying multicast capability to take care of such traffic.
This means that MP-BGP EVPN and the multicast underlay work in conjunction to be able to deal with all types of traffic. The use of MP-BGP EVPN is hugely efficient compared to multicast, so just the fact that the unicast traffic will use that resolves much of the efficiency issues. Let me also quote what Rene says in the lesson:
Despite MP-BGP EVPN’s advantages, we still need something for Broadcast, Unknown Unicast, and Multicast (BUM) traffic. You’ll need to configure static ingress replication or multicast for BUM traffic. In this lesson, I’ll explain how to configure MP-BGP EVPN, and we’ll use multicast for BUM traffic.
I hope this has been helpful!
Laz
Hey Laz,
You mean to say BGP EVPN can’t handle the BUM traffic right?
Hello Amit
Yes that’s correct, MP-BGP EVPN alone doesn’t natively handle BUM traffic. That’s why the multicast underlay must be configured in addition. It works alongside MP-BGP EVPN to handle the BUM traffic.
I hope this has been helpful!
Laz
Hello 
There is a line I never gave attention to, and now that I’m trying to understand it, i can’t find the logic ^^
it is : Flags: (0x000102) (high32 00000000) on xmit-list, is not in l2rib/evpn
Especially the not in l2rib, for a locally generated route. A local route injected into evpn comes necessarily from L2RIB. There must be a logic, but i can’t see it
thanks a lot in advance
cheers
Imen
Hello Imen
The behavior you are seeing is expected. You will notice that on LEAF1, you get the “not in l2rib/evpn” statement for the MAC address of S1, which is locally connected, while you get the “is in l2rib/evpn” statement for the MAC address of S2, which is connected to the remote LEAF2 switch.
So local MACs are not in l2rib/evpn, while remote MACs are found in l2rib/evpn.
When a MAC address is locally learned (directly from a host connected to the local switch), it does not require BGP EVPN involvement in the control plane. Since the switch directly learns the MAC address from its local interfaces, the switch already has all the necessary information locally in the MAC address table.
However, MACs learned from remote VTEPs over the VXLAN fabric go through the EVPN control plane via BGP and are subsequently installed in the local switch’s L2RIB and EVPN tables. So when a MAC address is learned from a remote VTEP, it is advertised via BGP EVPN, and the receiving switch adds this MAC to both the L2RIB and the EVPN control plane.
I hope this has been helpful!
Laz
I have my VNI up on both remote sites with 2vpn evpn and a BGP underlay. I have my NVE interface up. I can see my VNI up in show nve interface, I can see the VNI up correctly in bgp output and I can ping between hosts.
How do I associate this vxlan/vni with a physical port and then verify connectivity between end points?
I assigned the vlan to a switchport but I can’t see any MACs associated with the VNI stilll.
Hello Pat
Are you trying to configure an access port on a leaf switch to connect to an end device? If this is the case, then this would be the config needed for that:
LEAF(config)# vlan 10
LEAF(config-vlan)# vn-segment 10010
LEAF(config-vlan)# exit
If you are referring to associating a VNI with the loopback address of a leaf switch for the purpose of the underlay network, then this is done in the NVE configuration, where both the loopback and the VNI are configured there like so:
LEAF(config)# interface nve1
LEAF(config-if-nve)# no shutdown
LEAF(config-if-nve)# host-reachability protocol bgp
LEAF(config-if-nve)# source-interface loopback 0
LEAF(config-if-nve)# member vni 10010
Where are you looking for the MAC addresses, in the MAC address table or within the BGP table? I suggest you take a look at the following lesson to find out more about how these concepts are configured, and if you have further questions, let us know!
I hope this has been helpful!
Laz