Regarding VxLAN Encapsulation

vxlan

I am reading up on VxLAN and understand the encapsulation process somewhat as below:

Step1: Take your original Ethernet frame.

Step2:Put it inside VxLAN encapsulation.

Step3:VxLAN should then go inside of UDP header.

Step4:UDP goes inside of IP(this should be the transport IP, i guess)

Step5: IP goes inside of whatever the transport is(e.g.Ethernet)

Q1: Please confirm if the above understanding is correct.

Q2:Why do we need VxLAN header to go inside UDP, why not send it over plain IP?

Q3:In other tunnel mechanisms, like the OTV, we don't use any layer 4 protocol(like TCP or UDP), so why use it here? Any specific reasons.

Q4: Why use UDP(since it is best-effort based), why not use TCP?

Q5: Can i look at VxLAN the way i look at HTTP or Telnet(both are applications and operate at layer 7), HTTP uses TCP port 80, telnet uses TCP port 23, what i am trying to understand is VxLAN an application that operates at layer 7 and fits into osi model ?
Also, which OSI layer would OTV be operating at and why?One answer below says that OTV can be done using UDP as well rather than MPLS/GRE, does that make OTV a protocol that operates at layer 7?

I have also attached a snapshot of packet capture of VxLAN header from one of the video lectures.

Best Answer

Yes - your understanding of encapsulation is correct: a given frame has a VXLAN header applied. This is carried in a UDP packet.

UDP is used as a convenient format in terms of programming and its use of src/dst port provides a ready means to both multiplex connections as well as a means by which intermediary forwarding elements can hash connections over parallel links. In short, UDP is familiar, has low overhead and is already extremely well understood.

OTV can run over MPLS-GRE or UDP, with UDP being the preferred mechanism for the past few years. Again, one of the big drivers was depolarization of traffic (allowing parallel paths to carry determinstically hashed fractions of overall traffic).

Why not TCP? Excessive overhead on the encapsulating device and added latency are big examples. The bigger point, though, is that to get any value out of TCP would require the ability to concatenate the individual packets to be encapsulated into an overall stream to be managed via sliding windows rather than simply maintaining a 1:1 mapping. Add in the amount of state tracking and buffering issues associated with having the capability for retransmission and it becomes truly unruly.

Related Solutions

Vlan – How does VxLAN 24 bit propagates back to Vlan 12 bit after de-encapsulation

The short answer is that VNI is globally significant within a fabric while 802.1q VLAN tags are locally significant to either a given VTEP or a port on that VTEP.

So - using your example of VNI 5020. In a simple case we can imagine two VTEP's that each locally map VLAN 20 to VNI 5020. Any port on either VTEP that is assigned to VLAN 20 (or has a trunk receiving frames tagged with 20) will either switch the frame locally or encapsulate it in VNI 5020 and send it to the other VTEP to decapsulate the frame into the local VLAN 20 broadcast domain.

Now let's consider a slightly more interesting case. On VTEP A we still map VLAN 20 to VNI 5020. On VTEP B, however, we map VNI 5020 to VLAN 502. At this point anything hitting VTEP B on VLAN 502 will either be locally switched or encapsulated in VNI 5020 to be sent back to VTEP A - which will, in turn, decapsulate the frame into its local VLAN 20. The net effect is that the devices in VLAN 20 on A are in the same broadcast domain as the hosts on VLAN 502 on B.

Now take this a step further with per-port significance. On VTEP A port eth1/1 any frame received with a VLAN tag of 20 will get mapped into VNI 5020, while on port eth1/2 a tag of 20 corresponds to VNI 5920. On VTEP B I map eth1/9 tag 200 and eth1/22 tag 308 to VNI 5020. All three ports across the two VTEP's will, again, be in the same broadcast domain.

So - the answer to your question is, again, global vs local significance. In some implementations I might be limited to a VTEP-wide tag to VNI mapping and thus only support 4000 subnets. The key thing is that I don't have to use the same 4000 on each switch. I could have 30,000 VNI's in use that I selectively map to VLAN ID's as needed. Or if I support per-port significance I could theoretically map 4000 unique VNI's multiplied by the number of ports on the box.

Q-in-Q can also map to this numbering space, but that's a separate topic and use-case. My suggestion would be that the real questions in this area have to do with the control plane in use to communicate what addresses and VNI's are where, L3 info, etc. This also tends to drive some of the particulars around per-port vs per-VTEP, especially for the operation of MLAG and similar (not to mention downstream spanning tree questions and the like).

EVPN/VXLAN RD & RT

I'll try to help where I can. I know next to nothing about Juniper, but the theory should be the same. Implementation should be the only difference.

So let's start with RD's. Each tenant has one VRF. Each VRF has a single Route Distinguisher.

If you're not familiar with RD's, they are a way to mark routes in the BGP database, to keep them unique. More information here: https://networkdirection.net/Leaking+Routes+with+MP-BGP

Sorry if I'm covering stuff you already know.. Please bear with me.

VRF's and RD's are local to each router. Route Targets however, are 'tags' that are used when sharing prefixes with neighbours. We 'export' prefixes (apply a tag to them) and 'import' learned prefixes into VRF's, if they have a particular tag set.

Now, back to your question.

It looks like the Juniper config is setting an RD and RT's on the VRF, and then another set of values in EVPN.

In the Cisco world, I use commands like 'rd auto' on both VRF and EVPN. This hides what you're seeing here.

To my understanding, it is because we're using BGP to carry layer-3 information (VRF) and layer-2 information (EVPN).

Consider this example. A tenant uses L3VNI 900003 (this is the VRF), and L2VNI 10572 (a layer-2 VNI).

Look at this output:

SW01# show bgp l2vpn evpn | inc Distinguisher 
Route Distinguisher: 10.0.0.1:33339 (L2VNI 10572) 
Route Distinguisher: 10.0.0.1:15 (L3VNI 900003)

This shows that the L3VNI uses a different RD than the L2VNI.

The most confusing thing, in my opinion, is that BGP carries L3 and L2 information. They are separate, as they are different address families with different RD's, yet not-separate, as they are part of the same tenant.

I know it's a big read, and thanks for bearing with me.

I hope this makes sense. Let me know if you have further questions.

Best Answer

Related Solutions

Vlan – How does VxLAN 24 bit propagates back to Vlan 12 bit after de-encapsulation

EVPN/VXLAN RD & RT

Related Topic