Showing posts with label vxlan. Show all posts
Showing posts with label vxlan. Show all posts

Sunday, February 22, 2015

Which is best method to deploy VxLAN: Multicast or Unicast?


Before deploying VxLAN we have to consider it’s underneath deployment model. It could be multicast or unicast. Now the question arises which one is the best for the network. Should we go with Multicast which is as good as broadcast or unicast?

It should be noted that not all deployment types are supported by all devices both physical and virtual. Despite the available hardware and software the best deployment for a particular scenario often depends on the application that will run within the VXLAN. If the application is based on unicast connectivity, in that case unicast mode is preferable. However if you have very large VXLANS with thousands of VM’s on it with each VM being on a separate physical hypervisor then Multicast mode might be better suited.

If the application within a VXLAN relies heavily on either multicast or broadcast messages to keep hosts in sync then this might be a better use case for multicast mode If multicast heavy application is distributed between two physical hypervisors then multicast mode will see no efficiency benefit and unicast mode would be more efficient than multicast mode
Click Here To Read Rest Of The Post...

Tuesday, February 17, 2015

VxLAN Control Plane


In previous post we have covered basics of vxlan and it's deployment models. In this post we will be covering the different ways of VxLAN control plane deployment models.

BGP based VxLAN Control Plane – BGP is the industry preferred protocol for both ease of implementation and scalability. BGP does scale well as it is responsible to the routing of the internet and can easily be adapted to support MAC to VTEP IP address mapping under another address family (That's BGP is called Multi Protocol). The only issue with BGP is the speed at which it often takes to converge after a network change.

LISP based VxLAN Control Plane – The LISP control plane has been talked about heavily as a scalable hierarchical option for the VXLAN control plane however LISP as a whole has never really got much traction. LISP doesn’t have a traditional flood to learn mechanism and learns new routes or mac to VTEP IP mappings.

OpenFlow based – There are a number of VXLAN deployments that use Openflow or XMPP in order to remove the restriction of multicast within VXLAN deployment.

TLV based – The TLV option is often used as a quick and easy way to manipulate existing protocols to transfer new information with IP/VTEP mappings.


Click Here To Read Rest Of The Post...

VxLAN Deployment Methods


VXLAN has two main modes of operation Multicast mode and Unicast mode. As their names suggest unicast mode relies only on unicast connectivity and multicast mode relies on multicasts to work. But most of the operator use unicast mode as multicast requires lot of planning and designing in DC network with enablement of IGMP.

VXLAN Operation – Multicast (Want to know more about Multicast)
In multicast deployment scenarios you do not need to have PIM configured however existing network element must capable of performing the role of an IGMP querier for the VXLAN. IGMP is layer 3 protocol which is used to establish a membership with in multicast domain. By default switch treats all multicast traffic as broadcast traffic which slow down the performance of network. To curb this issue, IGMP snooping has to be enabled on switch. Once snooping is enabled switch sniffs the IGMP join, leave and query messages between multicast routers and switches. The responsibility of the Querier is to send out IGMP group membership queries on a timed interval, to retrieve IGMP membership reports from active members, and to allow updating of the group membership tables.

When VXLAN is deployed in multicast mode the outgoing multicast packet has VNI and the IP destination multicast group. Multicast deployment methods available with one to one mapping and one to many mapping.

Most deployment options tend to go for one to one multicast to VNI mappings on the basis it has a much more efficient multicast flooding traffic pattern. It also allows for easier troubleshooting of traffic flows as flows are mapped one to one to multicast groups before the flow becomes unicast. Troubleshooting a flow with a one to one mapping is generally easier than the one to many mapping as you can trace the multicast traffic down to particular hosts that send IGMP joins for that multicast group.

VXLAN Operation – Unicast

Unicast VXLAN operation is perhaps the most complex deployment method to choose. The biggest benefit however to unicast mode is the removal of the requirement for multicast. This is indeed a positive benefit but it does come with a cost to network efficiency especially if the application within the VXLAN is reliant on multicast for clustering.

Click Here To Read Rest Of The Post...

Thursday, February 12, 2015

VXLAN Key Concepts & Basic Operation


This section considers some key concepts to consider deploying VXLAN (Read More About VxLAN Overview). Virtual Tunnel End Point (VTEP). As the name implies, the VTEP corresponds to the IP address that defines the beginning or the end of the overlay tunnel. Depending on the role, the VTEP can reside in many places. Initially, it was defined on the virtual switch, but later on, it found its way to other devices such as physical switches, firewalls, routers and so forth.

Depending on the location of the VTEP, devices can play different roles in the VXLAN construct. At the edge, the virtual switch played the role of encapsulation or de-capsulation device, ingesting the packets from the virtual machine and inserting or stripping of the correct VXLAN header respectively. Examples are the VMware DVS and the Cisco Nexus 1000v. These devices implement the basic VXLAN function.

Below provides an overview of this basic function of VXLAN. A virtual machine sends a packet to another virtual machine on another physical host. The traffic enters the vSwitch untagged and based on the vnic configuration will be assigned a VXLAN segment id and will be encapsulated in a UDP packet with VTEP source and destination IP address. The packet is routed over the layer 3 network and eventually reaches the VTEP tunnel destination IP address where the VXLAN header is stripped off and the packet forwarded to the destination virtual machine.


Click Here To Read Rest Of The Post...

Tuesday, February 10, 2015

VxLAN Overview

Virtual Extensible LAN, VXLAN, is another layer 2 overlay network technology that came into existence to initially address particular problems:
•In massively scaled virtualized data centers, the 4096 VLAN limitation implied through a 12 bit long dot1q tag played a significant role to come up with a more scalable solution.

•The static nature of trunk provisioning is another key driver. One of the most attractive aspects of virtualization is the short deployment timelines brought by the simplified deployment of server workloads, but these were hampered by a slow network deployment time.

•Many of these virtual deployments require layer 2 adjacency of virtual machines, especially in clustered environments. The workload deployments preferably can be placed anywhere in the network irrespective of physical boundaries.

VXLAN initially was conceived as a host overlay technology as the basic function was executed at the hypervisor virtual switch layer.

VXLAN Key Concepts & Basic Operation

some key concepts to consider deploying VXLAN. Virtual Tunnel End Point (VTEP). As the name implies, the VTEP corresponds to the IP address that defines the beginning or the end of the overlay tunnel. Depending on the role, the VTEP can reside in many places. Initially, it was defined on the virtual switch, but later on, it found its way to other devices such as physical switches, firewalls, routers and so forth. Depending on the location of the VTEP, devices can play different roles in the VXLAN construct. At the edge, the virtual switch played the role of encapsulation or de-capsulation device, ingesting the packets from the virtual machine and inserting or stripping of the correct VXLAN header respectively.

Click Here To Read Rest Of The Post...