Can I use Shortest Path Bridging hardware to build my SDN network

Recently I've come across a document that compares a number of existing network overlays in SDN architecture: The 2013 Guide to Network Visualization and SDN.

What is new and interesting is the solution from Avaya. Instead of using VXLAN, STT and GRE like all other vendors they use SPB (we wrote about this here How does switch fabric network work) to build the SDN solution.

Debugging networking issues in Neutron

Overview of cloud networking and Neutron in Openstack

We saw what challenges a successful Neutron deployment in Openstack would have to overcome in this post: Status and maturity of the Neutron in Openstack Havana release. But the journey into cloud network is worth the trouble and you can find many discussions that show the potential business and technological advantage you gain (an example What your Dev, Engineering and sales teams can achieve by using Openstack cloud and Quantum network).

But as the Neutron continues to bring new and advance networking features with every consecutive  Openstack release ( Havana Neutron features) there is always a fear that it may become very complex and difficult to troubleshoot. To help to fill the gap the video from Dave Neary (slides are here Networking in OpenStack for non-networking people) is taking us on the journey what cloud networking and Neutron is as well as showing the basic troubleshooting every one should be aware of.

Neutron troubleshooting

These couple of slides from the video summarized very well what troubleshooting actions you can do when dealing with network connectivity problems from and to your VM. For more info watch the video yourself.

References

http://openstack.redhat.com/Main_Page
http://openstack.redhat.com/Networking
http://openstack.redhat.com/Networking_in_too_much_detail

VMware NSX network virtualization platform

VMware announced its new product NSX. In comparison it should be the same for network virtualization what flagship iESX product was for host virtualization.

This 2 links give a glimpse into the architecture design:

http://blogs.vmware.com/networkvirtualization/2013/08/vmware-nsx-network-operations.html
http://blogs.vmware.com/networkvirtualization/2013/08/vmware-nsx.html

These 2 pictures from the links above give a high level overview what it does and how it should work:

On the VMware page we can find as well as these two videos below that present the virtual network challenge for cloud deployments and shows how to solve it with the help of VMware NSX platform. 

http://bcove.me/idrpiovw
http://bcove.me/qe36t4fc

How does Nexus 1000v support VXLAN protocol

In the previous post we we explained how VXLAN works. Below is a complementary video about VXLAN from a Cisco product manager Han Yang showing a live Cisco Nexus 1000V training session.

Interesting facts that are not directly mentioned in the previous post:

• Only one Nexus 1000V (N1V) can be deployed on a single hypervisor (multiple hypervisors have its own 1000V virtual switch)
• Nexus 1000V has built in mechanism for loop prevention (time ~21:00)
• if it receives a packet on the outside interface with a src MAC address that belongs to one of its attached VMs it drops it
• it drops STP BPDU; as hypervisors are considered 'leaves' in the network topology they don't have to participate in STP 
• As VXLAN is an L3/L4 network overlay it handles the VM generated broadcast, multicast and unknowns unicast with a help of IP multicast (time ~27:00)
• The point above says that for example VM ARP request will be distributed to all hypervisors using IP multicast (remember that each hypervisor has its own IP; when there is a communication between hypervisors they communicate using their own IPs. The real VMs communication is encapsulated using VXLAN and is carry over in UDP datagram)
• You don't have to have a separate multicast domain per VXLAN domain (resulting in separate multicast trees and multicast groups that a router need to managed). A single multicast can be shared by many VXLAN (time ~36:00)
• Not sure about this: I have couple of VMs in my VXLAN that want to communicate together using IP multicast. This multicast traffic is not the same like when an ARP need to be distributed among hypervisors. This is VMs internal traffic. Will this VM IP multicast traffic be distributed to all hypervisors or only to these who actually host a relevant VM(s) that joined the VM multicast group before (IGMP snooping) (time 30:00-30:35)
• In a single VXLAN you can have multiple customer defined VLANs (this becomes obvious when you look at the VXLAN frame headers) (time ~30:00)
• You can tunnel VXLAN using OTV (time 45:00)
• You need an L3 gateway device to allow traffic between traditional VLAN and VXLAN domains
• There is an option to integrate within VXLAN network a vASA (virtual ASA) firewall

How does the VXLAN protocol work

The VXLAN is one of the overlay network tunneling protocols that is used to built network infrastructure for cloud environment. Below are some details about the operation and specification.

• Frame headers definition

• The traffic between VMs is encapsulated in IP/UDP packets
• Logical isolation is implemented in a form of logical overlay where the traffic is exchanged between encryption tunnels endpoints
• VXLAN ID is used to identify the specify isolated L2 cloud network that belongs to a tenant
• The tunnel endpoints represent the edge of the cloud network infrastructure
• The tunnel endpoints perform encapsulation and decapsulation
• It is there where all the logic is implemented to find out where to sent next a packet or to witch VM the packet should be delivered after decapsulation

• A comprehensive summary and operational features can be found under the links in reference section, below are few of the main characteristics and benefits:
• It operates over IP and used UDP to carry payload 
• Multicast support is the only other requirement for switches and routers to support VXLAN 
• Multicast is used to handle L2 broadcast traffic (like ARP requests)
• Logical networks can be extended among virtual machines placed in different Layer 2 domains

References

1. http://www.definethecloud.net/vxlan-deep-dive
2. http://www.definethecloud.net/vxlan-deep-divepart-2
3. http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-685115.html
4. http://www.emulex.com/artifacts/d658610a-d3b6-457c-bf2d-bf8d476c6a98/elx_wp_all_VXLAN.pdf
5. http://blogs.cisco.com/datacenter/more-vxlan-qa/
6. http://blog.scottlowe.org/2011/12/07/revisiting-vxlan-and-layer-3-connectivity/
7. http://blog.scottlowe.org/2011/12/22/otv-and-vxlan-layer-3-connectivity-compared/

Midonet packet processing

The few slides below from Midokura account on slideshare.net show the internal architecture design and packet processing that is happening whey you deploy Midonet as a cloud virtualization engine.

• Midonet is based on an IP overlay concept 

• By implementing in IP encapsulation it can provide tenant isolation and more advance features

•  By pushing the intelligence to the edge of the network (like hypervisors) it can handle the packet forwarding efficiently with out having to consult the with any external system
• All Midonet processes built a single logical distributed system within each single Midonet node is capable of finding and implementing the right action for a packet

•  As an example if VM tries to communicate with a peer that doesn't belong to the tenant the verification can be done at the edge without having to sent the packet out

References

1. http://www.slideshare.net/midokura/12th-japan-cloudstack-user-group-meetup
2. http://www.slideshare.net/midokura/cloudstack-collab-talk
3. http://www.slideshare.net/midokura/midonet-us-launch-oct-15-14706786

Midokura Midonet software

The network virtualization movement is getting bigger and stronger. Looking how serious the VMware is looking into SDN concept ( VMware NSX Network Virtualization ) is is only a matter of time before we start seeing this on a regular basis in data centers.

With this message in mind let's take a look at one of the SDN vendors like Midokura and its software Midonet.

1. General availability 

During Openstack Summit in April 2013 Midokura sent a strong message that its Midonet software is available to download. Midonet is Midokura the SDN implementation of the cloud network virtualization concept.


2. Software

At the moment there is only a little bit of information what it is.

MidoNet pushes intelligence to the edge of the network, as it takes an overlay-based approach to network virtualization and sits on top of any IP-connected network. [1]

Its technology is functionally similar to VMware-backed Nicira's, but the approach is different: Midokura has a Level 3 network gateway, whereas Nicira is Level 2. Both companies offer distributed switching at Level 2 [2]

Midokura uses a continuous-licensing basis for its network virtualization software. The technology is a 5-to-10MB download that runs on top of a JVM on standard server hardware. [2]


3. Midonet network architecture
Below, on the left we see the logical and on the right the physical topology.



The main logical concept is based on having a virtual router that your VMs are talking to. As Midonet software is using/is based on Open vSwitch that pacifically means that there is going to be a virtual port attached to Virtual router and VM in Open vSwitch. That way the VM is directly (virtualy) connected to its virtual router / default gateway. The building layout of the physical topology seems to confirms that assumptions.

The physical topology help us better understanding the Midonet distributed model as well: Midonet software architecture.

The backend network is a standard IP base physical network infrastructure that aims to provide IP connectivity between the Midonet nodes. The power of Midonet comes from the way it manages its distributed NW State DB (network state data base). This is the critical part and place where is decided what to do with an Ethernet frame/IP packet from or to VM when there is no flow entry on the routers or hypervisor virtual switches.

This is the link for a full Midokura Midonet presentation (in Japan).

References

1. http://www.midokura.com/press-releases/midonet_launch_at_openstacksummit2013/
2. http://www.theregister.co.uk/2013/04/02/midokura_sdn_funding/

Network virtualization jargon

I've read recently this blog post Virtual Network Domain and Network Abstractions. In the post PlumGrid  CTO describes challenges and opportunities that currently exists in cloud network. In my opinion what makes it unique and interesting in comparison to other blogs concentrating on network virtualization is the language he uses.

Below are some of the examples:

• Distributed Virtual Switch (DVS)
• Physical Network Infrastructure (PNI)
• Virtual Broadcast Domains (aka Distributed VLANs) 
• Virtual Network Infrastructure (VNI)
• Virtual Network Domains (VND)

Do you believe that these concepts are more understandable when we speak about networking in the cloud. Typically described today as network virtualization, virtual network, cloud network, hybrid network or private network.

References

1. http://umairhoodbhoy.net/2013/02/12/what-is-plumgrid-up-to/
2. http://en.wikipedia.org/wiki/Network_virtualization