Network virtualization beyond vla ns-part2

Network Virtualization-Beyond VLANs-Part2
We have explored the L2 aspects of virtualization
with VLANs, SVIs and Subinterfaces, but what if we needed to virtualize things
at a L3 layer. What if we needed a router to handle traffic for multiple customers or
groups without allowing access between them. A traditional non-virtualized way to
deal with this would be with ACLs between each of these groups, but this can
become cumbersome to manage and a mistake in an ACL can cause a security issue.
You could also tackle the separation of these group via virtualization using Virtual
Routing and Forwarding (VRF). Technically I’ll be discussing VRF-Lite here, for info
on full blown VRF see the upcoming post on L3 MPLS VPNs.
A device supporting VRF will have:
 A global routing table which is the default routing table, this exists if you are
using VRF or not
 One or more VRFs
 Each interface on the device will belong to either the global routing table or
one of the VRFs
So for example say we have a red group and a green group which we want to keep
separate. Each group has two switches that are all connected to a single router. The
solution would look something like this.
Here we have a router with a Red and a Green VRF along with it’s global routing
table. The Red VRF includes interfaces Gi0/1 and Gi1/1 connected to the switches for
the red group and the Green VRF includes interfaces Gi0/2 and Gi1/2 connected to
switches for the green group. Since each VRF is a separate routing table a system

with the IP 192.168.10.10 in the Red VRF could not ping a system with the IP
192.168.20.10 in the Green VRF. The ping packets would simply be dropped by the
router since the VRF that received the traffic (i.e. Red) does not have a route to the
destination.
If we looked at the routing table for Red VRF it would look something like this:
Router# show ip route vrf Red
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C 192.168.10.0/24 is directly connected, GigabitEthernet0/1
As you can see the only routes that exist in the Red VRF are for the two subnets for
the red group. The green VRF looks the similar with just connected routes for the
subnets for the green group.
The router also has a global table which act’s just like a VRF (it’s often refereed to as
the Global VRF, but it’s technically not a VRF). The global routing table only includes
routes that are not specifically included in another VRF and has no special visibility
into the other VRFs. Here is the routing table of the global routing table.
Router# show ip route

If you only need to separate two groups, you could even just create a single VRF and
have one group in the VRF and the other in the global table. In the example above
the global table would likely be used for management.
Another effect of keeping the routing tables of VRFs separate is that the same
address space can be used in the different VRFs. For example it’s possible the same
subnets could be used in both the Red and Green VRFs.
The routing tables for the VRFs would look like this, where connected routes for the
same ip networks would show up on different interfaces.
Router# show ip route vrf Red
Router# show ip route vrf Green

Of course providing L3 separation on a single device maybe of limited use. Often you
will want to segment different groups located in different buildings/offices and there
may be several routers in between those groups. One way to provide L3 separation
over several L3 devices is with a Back-to-Back VRF configuration.
In the Back-to-Back VRF setup you have two or more L3 devices connected together
where each one is configured with the VRFs needed to keep the routing separate.

In this case we have two routes connected together via a trunk. Each router has a
Red and Green VRF where each VRF includes an interface connected to a switch and
a subinterface connected to the other router over the trunk. This would allow a
server with IP 192.168.10.10 to talk with a server with the IP 192.168.20.10 (both in
the Red VRF), but neither could talk to a server with IP address 192.168.20.10 (in
the Green VRF).
The routing tale of router1 would look like:
Router1# show ip route vrf Red

C 192.168.0.0/30 is directly connected, GigabitEthernet0/0.1
S 192.168.10.0/24 [1/0] via 192.168.0.2
Router# show ip route vrf Green
C 192.168.0.4/30 is directly connected, GigabitEthernet0/0.2
S 192.168.20.0/24 [1/0] via 192.168.0.6
Each VRF has it’s connected routes along with the static route to reach the network
on the other router. While this example uses static routes, dynamic routing protocols
can be used and would just form adjacencies with each other over their respective
subinterfaces.
The problem with Back-to-Back VRF configurations is that each router in the path
must be configured with the appropriate VRFs. In the next posts I’ll show how we
can connect VRFs using Overlay networks or L3 MPLS VPNs which minimize the need
of VRFs on transport devices.
Overlay Networks
Another method of providing L3 isolation is by using an Overlay Network. An Overlay
Network is really just a fancy name for a VPN and the most common overlay
networks are built with IPSec tunnels over the Internet.

A common misconception is that a VPN requires encryption, but this is not always
true. In the case where you are sending data over an untrusted network, such as the
Internet, encryption is key. But, for data sent across your corporate network,
encryption may not be necessary. In this case utilizing non-encrypted GRE tunnels
to provide a VPN between users or sites works just fine.
The best way to explain how an overlay network provides L3 isolation is by example.
Let’s say we have a enterprise that wants to keep it’s R&D Group (Red), Finance
(Green) and other Corporate Users (Blue) separate. Some buildings have a mix of
users while others have just one type of user. We also want to allow each of these
users to access a data center.
The above shows our topology with four sites and two core routers. Here we will
need to configure VRFs on the office routers to keep our users in each site separate.
But we won’t need to configure VRFs on our core routers.
For our HQ in San Francisco we will need to configure all three VRFs on the router.
The appropriate VLAN interfaces will be added to each VRF and the interfaces
connecting to the core will be left in the global routing table. Additional one loopback
interface for each VRF will be created and left in the global routing table (i.e. SFO
will have three loopbacks in the global table since SFO has three VRFs.)

Once configured the interfaces belonging to each VRF will look like this.
SFO#show ip vrf interfaces
Interface IP-Address VRF Protocol
Vlan20 10.100.20.1 Corp-Blue up
Vlan99 10.100.99.1 Finance-Green up
Vlan10 10.100.10.1 RD-Red up
Vlan11 10.100.11.1 RD-Red up
Vlan12 10.100.12.1 RD-Red up
Each of the other offices will be configured n the same way. Each will be configured
with the VRFs needed for their users and the loopback interfaces to match the
number of VRFs (i.e. LAX will be configured with the R&D and Corp VRFs and two
loopbacks). Once this configuration has been completed our network will consist of
islands of isolated users. Users located in SFO that are part of the Corp-Blue VRF will

be able to talk to each other, but not to users in the Corp-Blue VRF of different
offices.
To allow offices to talk to each other we need to start creating tunnels and building
our overlay networks. The core routers will only have routes for the links connecting
each site to the core and the loopbacks at each site. We will use these loopbacks as
the source and destination for our tunnels. Hence the reason why the number of
loopbacks match the number of VRFs configured at an office.
GRE tunnels will be configured on each router to connect the VRFs together, so SFO
will have a GRE tunnel connecting it’s R&D VRF with the R&D VRFs in LA, Seattle and
the Data Center. The config for these tunnels would look like the following.
interface Tunnel11010
description RD-Red Tunnel to LAX
ip vrf forwarding RD-Red
ip address 10.0.10.6 255.255.255.254
tunnel source Loopback10
tunnel destination 192.168.110.10
description RD-Red Tunnel to SEA
ip address 10.0.10.8 255.255.255.254
description RD-Red Tunnel to DC
ip address 10.0.10.1 255.255.255.254
Here we have three tunnels, one to each other office (if this were for Corp-Blue we
would just have tunnels to the Data Center and LAX). We specify all the normal
things you would need for a tunnel such as the source and destinations, ip addresses
and additionally we add the tunnel interface to the desired VRF, in this case RD-Red.
Notice each of these tunnels have the same source interface, loopback10. If these
tunnels were for the Corp-Blue VRF then they would use loopback20 for their source
interface.

After the tunnels for each VRF are created the topology for each virtual network
would look like this.
Now that the overlay network for each VPN has been created we just need to
configure routing for that VPN. Whether you use static or dynamic routing there are
some changes that will be needed for deployments with VRFs, make sure to check
the documentation of your protocol of choice.
In this example I chose to implement OSPF. In this case each VPN has it’s own OSPF
process (in addition to any OSPF process used for the core). Since different
processes are used for each VPN that means each VPN has its own independent area
topology. Here is an example of the OSPF configuration for SFO, with OSPF 192
being used for the core network.
router ospf 10 vrf RD-Red
log-adjacency-changes
network 10.0.10.0 0.0.0.255 area 0
network 10.100.10.0 0.0.0.255 area 0
network 10.100.11.0 0.0.0.255 area 0
network 10.100.12.0 0.0.0.255 area 0
router ospf 20 vrf Corp-Blue
network 10.0.20.0 0.0.0.255 area 0
network 10.100.20.0 0.0.0.255 area 0
network 10.100.21.0 0.0.0.255 area 0
network 10.100.22.0 0.0.0.255 area 0

router ospf 99 vrf Finance-Green
network 10.0.99.0 0.0.0.255 area 0
network 10.100.99.0 0.0.0.255 area 0
router ospf 192
network 192.168.0.0 0.0.255.255 area 0
Each OSPF process includes the networks belonging to the local interfaces
(10.100.X.X in this example) and for the tunnels (10.0.X.X) that belong to the VRF.
Here I show the OSPF neighbors for the Corp-Blue VRF and the routes learned in the
VRF.
SFO#show ip ospf 10 neighbor
Neighbor ID Pri State Dead Time Address Interface
10.200.10.1 0 FULL/ - 00:00:39 10.0.10.0 Tunnel20010
10.120.10.1 0 FULL/ - 00:00:33 10.0.10.9 Tunnel12010
10.0.10.10 0 FULL/ - 00:00:32 10.0.10.7 Tunnel11010
SFO#show ip route vrf Corp-Blue
Routing Table: Corp-Blue
E1 - OSPF external type 1, E2 - OSPF external type 2
10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C 10.0.20.6/31 is directly connected, Tunnel11020
O 10.0.20.2/31 [110/22222] via 10.0.20.7, 00:50:49, Tunnel11020
[110/22222] via 10.0.20.0, 00:50:49, Tunnel20020

C 10.0.20.0/31 is directly connected, Tunnel20020
O 10.110.20.0/24 [110/11121] via 10.0.20.7, 00:50:49, Tunnel11020
C 10.100.22.0/24 is directly connected, Ethernet2/0.22
O 10.200.20.0/24 [110/11121] via 10.0.20.0, 00:50:49, Tunnel20020
Notice that the OSPF process for the Corp-Blue VRF does not have an adjacncy to
the core routers, nor has it learned any of the core routes (192.168.X.X).
Overlay networks provide an obvious benefit of removing the VRF configuration from
the core, but require the additional configuration needed for tunnels. This limits the
usefulness of overlay networks (in a general sense) to only a small number of end
points. Larger deployments should look at MPLS based Layer 3 VPNs which I’ll cover
in the next part.
MPLS L3 VPNs
n this segment of my network virtualization series I will cover MPLS L3 VPNs. Like
the rest of the topics in this series I’ll be covering things at a high level which ideally
allow folks to at least get the concepts.
Like Back-to-Back VRF and Overlay networks, MPLS L3 VPNs provide L3
isolation to virtual networks hosted on a physical infrastructure.
What is MultiProtocol Label Switching (MPLS)?
When a packet is sent over a MPLS network a network label is added to the
datagram between layer 2 and layer 3. MPLS is often referred to as a Layer 2.5
protocol.

This is similar to other network virtualization techniques that add a new header, such
as a GRE, but the MPLS label doesn’t include a source or destination address which
stay with the packet as it travels across the network. Instead a 20-bit label value is
used and that value is changed at every hop.
When a MPLS router receives a packet with a MPLS label it references a table that
determines which interface that packet should be sent out of and what value to set
for the label. So for example if we have a router that has two interfaces: Gi0/1 and
Gi1/1. This router would have a MPLS forwarding table which, in this example, says
that every packet it receives with a label of 36 is to be forwarded out Gi1/1 with a
label of 222. So when the router gets a packet with a label of 36 it forwards it out
Gi1/1. The router doesn’t need to do a routing look up or any real high level
functions to forward the traffic which allow MPLS to operate pretty quickly.
So how does the MPLS router know how to build it’s forwarding table and what
labels to use. This is all based on the Label Distribution Protocol and Multiprotocol
BGP, and is beyond the scope of this article.
Another basic concept of MPLS is the nomenclature used for the routers in the
network. MPLS networks typically have:
 Provider (P) routers, for the most part, only receive and send MPLS packets.
They are basically the core routers in the MPLS network.
 Provider Edge (PE) routers are at the boarder of the MPLS and IP networks.
They connect to non-MPLS enabled routers called CE routers and to other P
and PE routers. PE routers add and remove MPLS labels from IP packets.
 Customer Edge (CE) routers do not run MPLS and connect up to PE routers.
CE routers have no knowledge of the MPLS network.
How do L3 MPLS VPNs work?
Each PE router maybe connected to multiple customer networks that need to be kept
separate. This is accomplished by adding the connections to VRFs dedicated for each
customer. The PE router keeps these VPNs separate in the same way that is done in
a back-to-back VRF or overlay network design. The difference comes from how the
VPNs are kept separate by the rest of the network.
Separation in the MPLS network is accomplished by using multiple labels, in a similar
fashion to Q-in-Q, and basically builds MPLS tunnels.

When a PE receives an IP packet it needs to send over a MPLS L3 VPN it adds two
labels to the packet. It adds an MPLS label which is used to get the MPLS packet to
the destination PE. It also adds a MPLS label for that specific VPN which is used by
the destination PE to determine which VPN the packet belongs to and ultimately
which interface to send the packet out of.
What about an example?
In this example we have two CE routers each connected to a PE router with each PE
router connected to a P router.
When the CE router on the left has an IP packet destined for a network reachable via
the CE router on the right it sends that packet to the left PE router.
The left PE router takes the IP packet and encapsulates it into an MPLS
packet with two labels. This first label it adds is the VPN label with a value of 12.
This VPN label will only been used by the PE on the right to determine which VPN
this packet belongs to. It also adds a label with the value of 36, this label value is
used for packets that are destined for the PE on the right.
The P router receives the MPLS packet, examines the MPLS label and sees that it has
a value of 36. It looks up label value 36 in its forwarding table and sees that it needs
to forward the packet out it’s interface connected to the PE router on the right. It
also need to change the label value to 96. The P router never examines the MPLS
VPN label.
The PE router on the right receives the MPLS packet and sees that it is the
destination of the packet. It then looks at the VPN label and sees that this packet

belongs to a specific VPN. It then forwards it out the interface connected to the CE
router on the right as a normal IP packet. (Usually there is something called
Penultimate Hop Popping that changes this sequence a little but the concept does
not change).
The CE router on the right receives a normal IP packet and routes that packet
appropriately.
Reference from http://infrastructureadventures.com/series/#BeyondVLANs
More Related…
Network Virtualization beyond VLANs-Part1
VLAN vs. Subnet
ASA Routed vs. Transparent
LANs vs. WANs

Network virtualization beyond vla ns-part2

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Network virtualization beyond vla ns-part2

Similar to Network virtualization beyond vla ns-part2 (20)

More from IT Tech

More from IT Tech (20)

Recently uploaded

Recently uploaded (11)

Network virtualization beyond vla ns-part2