Tip of the week



Tip #9: Planning a deployment with select Trident II based switches

If you’re planning a deployment with select Trident II based switches, you can use hierarchical port binding to get the most out of your network.  Trident II based switches support hardware accelerated VXLAN and when combined with VLAN within the rack you will notice performance improvements since the hypervisor is no longer handling encapsulation and decapsulation in software.



Tip #8: What’s new in Kilo?

The OpenStack Summit in Vancouver presents a great opportunity for users, operators and developers into intermix as everyone discusses what’s new in Kilo and looks forward to the next release, Liberty.  Make the most of the week by actively participating in sessions and connecting with other attendees in between sessions. The most recent Kilo release contains a significant update to Neutron’s Load Balancer-as-a-Service.  After working with the community for several months, the Neutron is releasing a new API.  The API includes many changes that make the API more intuitive and friendly to operators and users alike.



Tip #7: How to configure the addressing schemes for IPv6 subnets in Neutron

There are 3 ways to configure the addressing schemes for IPv6 subnets in Neutron.  Of the 3 SLAAC support is the easiest and usually the default in many distributions.  The Router Advertisements for SLAAC do not contain DNS information, so your instance with either need to be preconfigured or get name server information via IPv4.



Tip #6: More on GRE and VXLAN encapsulation

We’ve previously talked about GRE and VXLAN encapsulation within Neutron.  One common deployment issue is a misconfigured MTU visible to the guest.  Both GRE and VXLAN add several bytes of encapsulation overhead which a deployer must account for by subtracting the MTU of the underlay network by 54 bytes for VXLAN or 46 bytes GRE.  Otherwise the packets sent will be too large guests will not be able to communicate.



Tip #5: GRE and VXLAN encapsulation methods

While GRE and VXLAN seem like equivalent encapsulation methods there is a subtle difference which can impact your deployment if you’re utilizing equal-cost multi-path (ECMP) routing.  VXLAN utilizes UDP, so nearly all routers properly distribute traffic to the next hop by hashing over the 5 tuple that include the UDP source and destination ports.  

GRE tunneling is a bit different since IP packets do not contain the information necessary to construct a 5-tuple hash.  How the router selects the path for a GRE packet is largely dependent on the hardware as some routers will use the GRE tunnel key to help create the hash.  If you intend to utilize ECMP in the underlay with GRE, it is important to select hardware that supports both otherwise you might not get the performance and utilization you expect.