Everyone who has any interest in network automation inevitably comes across NETCONF and YANG. These technologies have mostly been implemented for and adopted by big telcos and service providers, while support in the enterprise/DC gear has been virtually non-existent. Things are starting to change now as NETCONF/YANG support has been introduced in the latest IOS XE software train. That’s why I think it’s high time I started another series of posts dedicated to YANG, NETCONF, RESTCONF and various open-source tools to interact with those interfaces.
In this post we will see how OVN implements virtual networks for OpenStack. The structure of this post is such that starting from the highest level of networking abstraction we will delve deeper into implementation details with each subsequent section. The biggest emphasis will be on how networking data model gets transformed into a set of logical flows, which eventually become OpenFlow flows. The final section will introduce a new overlay protocol GENEVE and explain why VXLAN no longer satisfies the needs of an overlay protocol.
This is a first of a two-post series dedicated to project OVN. In this post I’ll show how to build, install and configure OVN to work with a 3-node RDO OpenStack lab.
I was fortunate enough to be given a chance to test the new virtual QFX 10k image from Juniper. In this post I will show how to import this image into UnetLab and demonstrate the basic L2 and L3 EVPN services.
In this post we’ll explore how DVR is implemented in OpenStack Neutron and what are some of its benefits and shortcomings.
In this post we’ll use Chef, unnumbered BGP and Cumulus VX to build a massively scalable “Lapukhov” Leaf-Spine data centre.
In this post we will explore what’s required to perform a zero-touch deployment of an OpenStack cloud. We’ll get a 3-node lab up and running inside UNetLab with just a few commands.
One of the basic function of any data centre network is the ability to communicate with baremetal servers. In this post we’ll see how Neutron L2 Gateway plugin can be used to configure a Cumulus VX switch for VXLAN-VLAN bridging.
In the this post we’ll tackle yet another Neutron scalability problem identified in my earlier post - a requirement to have a direct L2 adjacency between the external provider network and the network node.
In the previous post we’ve had a look at how native OpenStack SDN works and what are some of its limitations. In this post we’ll tackle the first one of them - overhead created by multicast source replication.