EVPN


To support EVPN (Mac address family in BGP), are we dependent on Quagga to deploy this as part of their BGP stack or Cumulus may deploy this protocol?

in Quagga there is a new trend for deploying the EVPN in community, but I'm not sure when its going to happen.

Regads
Reza

5 replies

Userlevel 4
What is the desired result? We have an open source VXLAN overlay technology called LNV (Lightweight Network Virtualization) that might fit the bill if you are interested in that. http://docs.cumulusnetworks.com/display/DOCS/Lightweight+Network+Virtualization+-+LNV We might also support EVPN in the future and that will probably mean that it will be supported in Quagga. LNV is not dependent on Quagga (it does not care what the fabric is). You can use it with OSPF, BGP, static routes, or even Bird instead of Quagga.
Sean Cavanaugh wrote:

What is the desired result? We have an open source VXLAN overlay technology called LNV (Lightwei...

Thanks Sean. I read the LNV couple of times till now but still not clear how it works. the document is more like an example configuration.

What I understood is :

1- The Leaf switches register to the Service node (Spine in this case).

2- after registry leaf switches advertise their FBP table to the Service node. this is a L2 table with information such as a VNI , MAC Address , VLAN.
This includes the MAC addresses which the switch has learned from incoming packets to its VLANs or its VXLAN

3- Service Node, builds a database of these records , adds additional fields to each record about the VTEP IP of the leaf siwtch and replicates them to the other Leaf switches.

For example Leaf switch 2 receives the FDB information of Leaf switch 1

4- If a leaf switch receives a BUM (an ARP request in VLAN 10 / VNI 10 for example) it will send broadcast to all the ports in VLAN 10 and also will send a BUM request to service node for that particular BUM.

Service node will send this BUM request to all the leaf switches serving that particular VNI.

5- All leaf switches having VNI 10 , will receive the BUM request from service node, They will forward the packet as broadcast in their particular VLAN (the mapped vlan to their VNI 10) and if there was an reply will report it back to the service node.

6- Service node will replicate the same to the requesting switch and others.

very interesting , but this is just my understanding about LNV.

is this process correct ?
how long does it take to receive a reply to a BUM ?

Userlevel 4
Sean Cavanaugh wrote:

What is the desired result? We have an open source VXLAN overlay technology called LNV (Lightwei...

1- The Leaf switches register to the Service node (Spine in this case).

they register to 'a' Spine or to All spines (using anycast). If they are using anycast the Spines will share state.

2- after registry leaf switches advertise their FBP table to the Service node. this is a L2 table with information such as a VNI , MAC Address , VLAN. This includes the MAC addresses which the switch has learned from incoming packets to its VLANs or its VXLAN

More simple than that, just the VNIs that exist on which leaf, the VXLAN don't even exist on the spine switches, they literally don't need to know anything we are just making them the controller so we don't need an external VM and are load balancing with anycast. The leaf switches will keep track of their FDB (which mac belongs to which VNI, with its unique IP)

3- Service Node, builds a database of these records , adds additional fields to each record about the VTEP IP of the leaf siwtch and replicates them to the other Leaf switches. For example Leaf switch 2 receives the FDB information of Leaf switch 1

The database is just which leaf switches are registered which which VXLANs. This makes it smart so that BUM (broadcast, unknown-unicast and multicast) are only replicated to leaf switches that they need to be.

4- If a leaf switch receives a BUM (an ARP request in VLAN 10 / VNI 10 for example) it will send broadcast to all the ports in VLAN 10 and also will send a BUM request to service node for that particular BUM.
Service node will send this BUM request to all the leaf switches serving that particular VNI.

Correct, except for the service node will not do replication (by default) the actual leaf switches will do replication for their own BUM traffic in hardware and can support up to 64 VTEPS (63 other Leaf switches) which supports most people's data centers. If you go over that limit there is a knob to turn push replication to the spine switches, or to another location all together (lots of tunable knobs, in the expand macros on the wiki doc page)

5- All leaf switches having VNI 10 , will receive the BUM request from service node, They will forward the packet as broadcast in their particular VLAN (the mapped vlan to their VNI 10) and if there was an reply will report it back to the service node.

They will receive BUM traffic from other leaf switches that also have the same VNI. As they learn mac addresses they will start getting smart just like switches do with VLANs (won't broadcast to everyone, just the switch it exists on). Obviously gratuitous arp from a mac-move will help this as well.

6- Service node will replicate the same to the requesting switch and others.

only if you turn of head-end replication off, which it is on by default, the leaf switches do the replication for their own BUM traffic making this extremely scalable for a controller-less solution

very interesting , but this is just my understanding about LNV.

yeah give me for feedback on the docs, want to make them easier to understand. I am gonna work on a VXLAN section just to zoom back. LNV is just one of many solutions that can work with VXLAN. The source code is all open, and its independent from a routing protocol so its starting to get wide spread adoption.

It is 100% possible to put a LNV solution together on VX, the replication will just happen in SW rather than HW. If you want to reach out to a CSE (Customer Solutions Engineer) just let me know, depending on where you are we can get you hooked up with the right person. My email is sean @ cumulusnetworks.com

Userlevel 4
Sean Cavanaugh wrote:

What is the desired result? We have an open source VXLAN overlay technology called LNV (Lightwei...

Engineering also wanted to let you know that is possible to install the service node onto servers (something with powerful CPU) then turn the knob so that all replication is done by the server instead of the spine switches. LNV is very flexible and fully supported by Cumulus Networks.
Userlevel 5
This is something I know is on the roadmap for future production. I am working to get you a more definitive answer. Thanks for the question.

Reply