Virtualisation, VRFs and cloud networking

Virtualisation: many machines on one server

A physical server is often busy only 10 to 20 percent of the time. Virtualisation splits it into many virtual machines (VMs). Each VM is a complete computer in software, with its own operating system, CPU share, memory and network card. The program that creates and runs VMs is called a hypervisor.

VMs need a network too. The hypervisor provides a virtual switch, a software switch inside the server. Each VM's virtual network card plugs into it, and it connects to the physical network through the server's real network cards, usually on an 802.1Q trunk so different VMs can sit in different VLANs.

Containers are a lighter form of virtualisation. A container packs one application and its libraries, but shares the host's operating system kernel instead of running a whole OS. Containers start in seconds and use less memory than VMs. Docker builds and runs containers, and Kubernetes runs many of them across many servers.

VRFs: several routers inside one

A VRF (virtual routing and forwarding instance) is a separate routing table on one router. Interfaces placed in a VRF can only route to other interfaces in the same VRF. So one physical router can serve two customers, or keep a company's guest and staff networks fully apart, even if both use the same addresses such as 10.0.0.0/24. Using VRFs without MPLS is called VRF-lite.

ip vrf CUST-A
ip vrf CUST-B
!
interface GigabitEthernet0/1
 ip vrf forwarding CUST-A
 ip address 10.0.0.1 255.255.255.0
interface GigabitEthernet0/2
 ip vrf forwarding CUST-B
 ip address 10.0.0.1 255.255.255.0
!
show ip route vrf CUST-A

Cloud service and deployment models

Deployment models say who uses the cloud. A public cloud is shared by many customers. A private cloud is used by one organisation. A hybrid cloud connects the two, for example a bank keeping its core banking servers in its own data centre and its website in the public cloud. A community cloud is shared by organisations with common needs, such as government departments.

Cloud networking building blocks

In IaaS you design your own private network inside the provider's data centre. AWS and Google Cloud call it a VPC (virtual private cloud); Azure calls it a VNet (virtual network). It works like the networks you have built in this course.

• VPC or VNet: your private address range, for example 10.0.0.0/16. On AWS an IPv4 VPC can be from /16 down to /28.
• Subnets: smaller ranges inside the VPC, for example 10.0.1.0/24 for web servers and 10.0.2.0/24 for databases. On AWS each subnet lives in one availability zone (one data centre group), and AWS and Azure keep 5 addresses of every subnet for themselves.
• Route table: the routing table for a subnet. A public subnet has a default route (0.0.0.0/0) to an internet gateway; a private subnet does not.
• Internet gateway: lets resources with public IP addresses reach and be reached from the internet.
• NAT gateway: lets servers in a private subnet start connections to the internet (for updates) while nobody on the internet can start a connection to them.
• Security group: a stateful firewall attached to a VM or its network interface. It has allow rules only. Stateful means reply traffic is allowed back automatically.
• Network ACL: a stateless filter on a whole subnet, with numbered allow and deny rules. Stateless means you must allow the reply traffic too, usually the high ephemeral ports.

Connecting the office to the cloud

There are three common ways. Over the internet, using HTTPS to public services, is simple but has no private path. A site-to-site IPsec VPN builds an encrypted tunnel over the internet between your office router or firewall and the cloud's VPN gateway; it is cheap and quick to set up. A private dedicated link, such as AWS Direct Connect or Azure ExpressRoute, is a circuit through a telecom partner that does not cross the public internet; it gives steadier speed and delay, at a higher cost.

Location matters too. AWS has the Mumbai (ap-south-1) and Hyderabad (ap-south-2) regions; Azure has Central India (Pune), South India (Chennai) and West India (Mumbai); Google Cloud has Mumbai and Delhi. Indian companies choose these for low delay to their users and for data rules, such as the RBI requirement to store payment system data in India.