Last Updated: (UTC)
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.
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
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.
See how VRF’s keep traffic separate
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.
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.
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)