Evolving your Network in the Cloud Era the Introduction of SDN in your Network

The Introduction of SDN in your Network

The design of Underlay and the route convergence is key whenever you plan to evolve a legacy NFVI network to SDN.

With Juniper Contrail you must see the community RA to see how OVS VxLAN defines the baseline to avoid all E-W traffic definitions in the Underlay. Below two pictures give you principle on Underlay and principles going forward.

1.  VM1 sends an ARP Request packet to request for VM3’s MAC address.
2. After receiving the ARP Request packet, VTEP1 searches the ARP table for VM3’s MAC address, and sends an ARP Reply packet for VM3 to VM1.
3. After VM1 sends data packets to VM3, VTEP1 searches the local MAC forwarding table. After the packets match the VXLAN tunnel table, VTEP1 encapsulates the packets into VXLAN packets and then finds the mapping Layer 2 VNIs based on the BDs of the packets. VTEP1 then uses the Layer 2 VNIs as the VXLAN VNIs and forwards the packets to VTEP2.
4.  After receiving the data packets, VTEP2 decapsulates them, searches for the destination MAC address in the local MAC forwarding table, and then forwards the packets to VM3.

Firewalls manage and control traffic generated in communication within a VPC, between VPCs and external networks such as the Internet, MPLS VPNs, and private lines, and between public clouds and tenants’ private clouds through IPsec VPN.

During the Lab validation we used the BGP as the routing protocol for both the underlay and overlay

However for Production environment it is very important to refer to scaling side of VTEPS . Although having VTEP inside OVS will have no impact on scale.

It is better to have VTEP as close to the source/destination of traffic as possible as you minimize the number of intermediate forwarding elements. You can see that most SDN solutions opt for having a VTEP inside the hypervisor/OVS even when they can do it on a TOR (Contrail, ACI, Nuage). And there’s no impact on O&M since sw VTEPs are not supposed to be managed by cloud operators but instead are automatically programmed by VIM’s networking driver (e.g. Neutron, NSX). Also the functionality performed by sw VTEPs is quite simple (L2-L4 forwarding) so they are usually thoroughly tested and “just work”. Where I work we have done a couple of relatively big Telco SDN DC networks (~500 compute nodes) with sw VTEPs and didn’t have any problems with that approach. When they do break, however, troubleshooting sw VTEPs is quite complicated and is usually done by SDN vendor’s TAC. The only serious disadvantage of having a sw VTEP is performance.

There are several solutions that we’ve implemented to boost the performance:

1) SRIOV

2) DPDK

3) VXLAN hardware offload

4) hw VTEP on TOR and there’s plenty more that we haven’t tried .