As we mentioned in the last post, traffic flows through a set of Linux virtual devices/switches to reach its destination after leaving the VM. Outbound traffic goes downward while inbound traffic moves upwards.

The flow of traffic from the VM goes through the following steps

VM-network

  • A VM generates traffic that goes through its internal vNIC
  • Traffic reaches the tap device where it undergoes traffic filtering using iptables to implement the security group rules for the security group attached to this VM
  • traffic leaves the tap device to go through the qbr bridge
  • qbr bridge hands the traffic over to qvb
  • qvb hands the traffic over to qvo
  • Traffic reaches the br-int. br-int VLAN tags the traffic and either
    • sends it to another port on br-int if the traffic is destined locally
    • sends it through the patch-tun interface to br-tun if the traffic is destined outside the host
  • br-tun receives the traffic on patch-int interface. It sends it through the established tunnels to other compute hosts and network hosts in the environment
    • br-tun is smart, it will add to its openflow rules specific rules such that it reduces waste traffic (i.e. traffic that gets sent to every host). It instead learns where VMs and routers exist and send traffic specifically to hosts that have the VMs or the routers on them
    • traffic is seggregated in the tunnels using a dedicated tunnel_id for each tenant network. This way individual network’s traffic doesn’t get mixed with other tenant network’s traffic

The above is the logical layout of traffic flow. If we wan to map everything to physical on the compute host.  The first portion is the running VM. In order to view the running process of the VM, we can do a ps -ef

vm-part1vm-part2

So as we see above the VM is a qemu-kvm process ( if you are using this hypervisor) that is attached to a tap device with a certain MAC address.

If we go a bit further , we can see how the qbr bridge is implemented, we can use br-ctl show

vm-part3

vm-part4

As shown above , a qbr bridge exists with two interfaces the tap interface and tap device

To verify that iptables rules are implemented on the tap device to reflect the security group rules. We can use iptables -L | grep tap4874fb2a   which is the tap device name mentioned above

vm-part5

The last step is to view the OVS switches using ovs-vsctl show

vm-part6

The output of ovs-vsctl show

vm-part7

As shown above, two switches exist br-tun and br-int

  • br-int has two ports
    • patch-tun to connect br-int to br-tun
    • qvo interface which is VLAN tagged with tag 1
  • br-int has two ports
    • patch-int to connect br-tun to br-int
    • vxlan interface which establishes the VXLAN tunnel to other hosts in the environment . There should be one interface per VXLAN tunnel to every host in the environment.

One thing to remember is that a VXLAN tunnel is the highway that connects multiple compute and network hosts. The real segregation happens using tunnel IDs which act as lanes dedicated for every tenant network

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s