Multi-tenancy is becoming more important every day. And it's not only service providers. Even in the enterprise, we need to consider multi-tenancy.
Tenants are separate customers. These can be internal customers, such as a university campus with various faculties. Or an office building with guest networks, an R&D department, and contractor access. They all need to share a common infrastructure but must be separate.
This separation requires us to provision logical networks. Creating these logical networks on a shared infrastructure is called Network Virtualisation.
Virtualization in the network is not new. VLAN's, for example, have been around since the beginning of time. But, VLAN's have a limited scope, and don't scale across the entire network hierarchy.
VPNs create an end-to-end virtual network. Don't get confused here. This is not the same thing as the internet VPN that you dial-up when you work from home. The VPN here is a virtual network within your enterprise. This may include some combination of MPLS, GRE tunnels, or VLAN trunks.
A major advantage to this is the ability to grow and adapt the virtual network. As for the underlying infrastructure, it scales out as your virtual networks grow.
The virtual network consists of three major components:
- The Edge, AKA Access Control
- The Path, AKA Path Isolation
- Services, AKA the Services Edge
Access Control refers to assigning users and devices to a specific virtual network. This is on the network edge, which is why this is also known as Edge Control.
A simple method is to statically assign ports to virtual networks. The problem is that this is a very manual process. Also, roaming devices will change ports, which doesn't work well with this solution.
Another option is to use 802.1X to identify devices and users when they connect to the edge. Users and devices are then added to the right virtual network.
Users and/or devices are now in the correct network on the local switch. The next step is keeping them in the same virtual network across the infrastructure.
This is where we use overlay technologies. A technology like GRE, MPLS, or VxLAN keeps traffic unique. More on this soon.
The Services Edge represents the services that you are offering to your users. For example, web services, mail services, and so on. These are usually in a data centre or server farm.
This is like access control. They are still on the edge of the network, but they are usually trusted devices.
Controlling access to services is the important point here.
Different isolation technologies fit into different parts of the network.
The edge uses VLANs for traffic separation. There are several ways to do this:
- Manually, where each port has a VLANs assigned
- 802.1X, to assign a VLAN when users and devices authenticate
- MAC Authentication and Bypass (MAB), which allows roaming. The switch assigns a VLAN based on the host's MAC address
- WebAuth, where a user needs to authenticate at a web page
But VLANs alone won't provide a scalable end to end Virtual Network (VN). Traffic leaves the layer-2 domain, and is routed across the core.
This is why we need a layer-3 VN as well. This is where VRF's come into play. The VRF's are at the boundary between layer 2 and 3. Trunks transport traffic in VLANs between layer-2 and layer-3 device.
At this point, each tenant should have their own isolated routing table.
Now it's time to think about transporting traffic across the core. There are a few options for this. Some options are hop-by-hop, where each device needs special configuration. Other methods are multihop, which allows better scaling.
VRF's are on every layer-3 device. On the layer-3 edge devices, VLAN's map to the VRF's.
There is a separate routing instance for every VRF on every layer-3 device. Separate trunk links run between the distribution and core to carry IGP traffic. Each IGP instance has its own VLAN on the trunk. If possible, use sub-interfaces for peering with neighbours. SVI's are acceptable as well.
This is a very manual process, and does not scale well. This is best suited to a small network.
Easy Virtual Network (EVN)
EVN is a Cisco proprietary solution that simplifies configuration. VRF's are still configured on each device, making this a hop-by-hop solution.
Regular trunks are not required for dynamic routing. Instead, there is a special VNET trunk between switches. This creates sub-interfaces for peering, simplifying configuration.
Traffic gets a VNET tag. This allows the receiving router will know which local VRF the traffic belongs to.
Configuring VRF's at every hop is not always practical. For one, not all devices support VRF's. Also, this can be an administrative nightmare if the network grows.
An alternative here is to create VRF's only on the layer-3 edge routers. Then, build a GRE tunnels across the core, connecting these devices. They may be point-to-point or point-to-multipoint tunnels.
Tenants have their own tunnel across the network, keeping their traffic separate.
The down side is that this adds overhead to the tunnel endpoints. This might be a good solution when you want to separate guest traffic from internal traffic. It would not scale well for many VN's.
Running MPLS in the core is where it gets exciting. This is a combination of MP-BGP and LDP (Lable Distribution Protocol).
Layer-3 edge routers still place customer traffic into VRF's. Traffic is then tagged, to identify which tenant it belongs to. When the traffic passes through the core, it remains unique. When it reaches the other end of the network, the tags identify traffic to place back into the tenant VRF.
This solution is very scalable, as it doesn't need all VRFs to be on every router. Also, there is no need for extra VLAN trunking or static tunnelling. This also allows tenant IP addressing to overlap without causing a conflict.
The downside to this solution is that not all devices support MPLS. This can make the solution more expensive.
An alternative to this solution is to run another overlay type, such as VxLAN. VxLAN is more often used as a data centre solution.
Marwan Al-shawi and Andre Laurent - Designing for Cisco Network Service Architectures (ARCH) Foundation Learning Guide: CCDP ARCH 300-320 (ISBN 158714462X)
Last update 2017-10-03 10:57