Network Virtualization - page 36
SummaryThis chapter covered a lot of territory. It presented different architectures for network virtualization. The basic alternative is to use some form of tunnel overlay, with your choice of protocol and at your choice of OSI layer, and a peer architecture based on RFC 2547.
In the tunnel category, we reviewed 802.1q trunks; GRE-based Layer 3 VPNs; DMVPN, which combines mGRE and IPsec; and L2TPv3 and MPLS-based p2p Layer 2 circuits. VPLS is something of a hybrid because customer and PE devices have a peer relationship of sorts, but PEs maintain a full mesh of LSPs across the
In the peer category, we covered the RFC 2547 architecture and the predominant implementation using MPLS. We also discussed alternative core protocols for this architecture, using GRE and L2TPv3.
Finally, we introduced hierarchical Layer 3 VPNs. CsC has a transport MPLS VPN running "
The
|
Part II: Enterprise Virtualization Techniques and Best Practices |
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
Chapter 6. Infrastructure Segmentation Architectures: Practice
This chapter analyzes how the virtualization technologies and architectures introduced in Chapter 4, "A Virtualization Technologies Primer: Theory," and Chapter 5, "Infrastructure Segmentation Architectures: Theory," can effectively be used in the enterprise,
Chapter 5 discussed the trade-off between scalability and complexity in the different VPN architectures. Based on scalability and complexity, different architectures apply to different places in the network. Depending on where in the network a VPN architecture is used, there will be deployment subtleties and best practices to follow. This chapter delves into the implementation details and best practices for the application and combination of different VPN architectures in the enterprise campus network and MAN.
We focus
|
|
! Access-1 vlan 3 name RED vlan 4 name BLUE ------------------------------------------------------------ ! Access-2 vlan 5 name RED vlan 6 name BLUE ------------------------------------------------------------ ! Distribution-1 & Distribution-2 vlan 3 name RED1 vlan 4 name BLUE1 vlan 5 name RED2 vlan 6 name BLUE2 |
After the VLANs have been created, they must be
Example 6-2. Data
Path
Virtualization in Access/Distribution
! Access-1 & Access-2 interface gigabitethernet 4/1 description Uplink to Distribution-1 switchport mode trunk switchport trunk encapsulation dot1q interface gigabitethernet 4/2 description Uplink to Distribution-2 switchport mode trunk switchport trunk encapsulation dot1q ------------------------------------------------------------ ! Distribution-1 & Distribution-2 interface gigabitethernet 4/1 description Downlink from Access-1 switchport mode trunk switchport trunk encapsulation dot1q interface gigabitethernet 4/2 description Downlink from Access-2 switchport mode trunk switchport trunk encapsulation dot1q |
Create a switch virtual interface (SVI) for each VLAN at the distribution switch, as shown in Example 6-3. At this point, you do not assign an IP address to these interfaces. These interfaces are used to map the traffic to the necessary virtual routing and forwarding instances (VRFs) later on. When you have completed the VRF assignment, you assign IP addresses to these.
Note
In a campus network that is not virtualized, you could have assigned IP addresses to the SVIs at this point. In a virtualized campus network, you must assign the SVIs to the necessary VRFs before you can assign IP addresses to the interfaces.
Example 6-3. Virtual Routed Interfaces for VLANs
! Distribution-1 interface vlan 3 description SVI for RED1 interface vlan 4 description SVI for BLUE1 interface vlan 5 description SVI for RED2 interface vlan 6 description SVI for BLUE2 ------------------------------------------------------------ ! Distribution-2 interface vlan 3 description SVI for RED1 interface vlan 4 description SVI for BLUE1 interface vlan 5 description SVI for RED2 interface vlan 6 description SVI for BLUE2 |
Finally, assign access ports to the VLANs. Example 6-4 shows the static configuration of access ports.
Example 6-4. Assigning Access Ports to the Different VLANs
! Access-1 interface gigabitethernet 6/1 description Host in the RED group switchport mode access switchport access vlan 3 interface gigabitethernet 6/11 description Host in the BLUE group switchport mode access switchport access vlan 4 ------------------------------------------------------------ ! Access-2 interface gigabitethernet 6/1 description Host in the RED group switchport mode access switchport access vlan 5 interface gigabitethernet 6/11 description Host in the BLUE group switchport mode access switchport access vlan 6 |
Over a common infrastructure, we have created multiple virtual Layer 2 networks, each of which has its own virtual workgroup space (VLANs), virtual paths (VLANs on a trunk), and dedicated routed virtual interfaces (SVIs). The Layer 2 portion of the network is
Layer 3 Hop to Hop
This technique involves the use of VRFs at every hop and the interconnection of the VRFs by means of a Layer 2 circuit such as that identified by an 802.1q tag or a
data-link connection identifier
(DLCI). Because this technique requires VRFs to be configured and mapped to Layer 2 circuits at every hop, it is generally used to segment the routed portion of a small campus network. This is not a viable solution in an IP-based WAN, where we do not have control over every IP hop. For the IP WAN scenario, multihop techniques provide a viable alternative.
VRF-lite was originally introduced as "Multi-VRF CE" to extend multiple VPNs from a provider edge (PE) onto non- Multiprotocol Label Switching (MPLS) customer edge (CE) devices supporting multiple VRFs. This basically involves a single routed hop and a single link between the PE and CE (that is, no resiliency), as shown in Figure 6-2.
Figure 6-2. Multi-VRF CE Original Application
However, you can extend the principle over multiple hops to create virtual campus networks as depicted in Figure 6-3. This also
Figure 6-3. Layer 3 Hop-to-Hop Segmented Campus Network
We use the network topology in Figure 6-4 to
Figure 6-4. Small Campus Network
The first step is to create the necessary VRFs. For the h2h Layer 3 solution, it is necessary to create a VRF for each group at every Layer 3 hop. Unique
route distinguishers
(RDs) must be used for every VRF on a router. Although the RDs across multiple hops do not need to match, it is easier to use a single RD for each group throughout the network. Therefore, all VRFs
Example 6-5. Creating VRFs
ip vrf red rd 10:10 ip vrf blue rd 20:20 |
After the VRFs have been created, the routed interfaces on the distribution switches (SVIs) created in Example 6-3 must be associated with the VRFs. This is achieved via the ip vrf forwarding < name> command, which is used under the interface to be associated with the VRF (see Example 6-6). After the SVIs have been associated with the VRFs, an IP address can be assigned to these. This step must be completed on every distribution switch in the campus network.
Example 6-6. Adding Interfaces to VRFs
! Distribution interface vlan 3 description SVI for RED1 ip vrf forwarding RED ip address x.x.x.x x.x.x.x interface vlan 4 description SVI for BLUE1 ip vrf forwarding BLUE ip address x.x.x.x x.x.x.x interface vlan 5 description SVI for RED2 ip vrf forwarding RED ip address x.x.x.x x.x.x.x interface vlan 6 description SVI for BLUE2 ip vrf forwarding BLUE ip address x.x.x.x x.x.x.x |
As you can see, the SVIs for RED1 and RED2 (VLANs 3 and 5) are both associated with the same RED VRF. Thus, two different VLANs are made part of a common routing space by associating them to the same VRF.
The VLANs connecting to the distribution and their routed interfaces (SVIs) are to be treated in the same manner as they would be in a nonvirtualized network. For example, first-hop resiliency features such as the Global Load Balancing Protocol (GLBP) or Hot-Standby Redundancy Protocol (HSRP) can be enabled on the SVIs you just included in the VRFs in the same way they would be enabled in a nonvirtualized network.
So far, you have created VLANs and associated these to different VRFs at the distribution. The steps followed so far are common to most campus network virtualization approaches; how the VRFs, at the different distribution switches, are interconnected varies depending on the technologies and VPN architectures used.
For the specific case of the Layer 3 h2h VPN, we need to associate the VRFs at the distribution with those in the core. The first step is to convert the links in the routed core to dot1q trunks. If consistent interface
Note
Converting the core links to dot1q trunks is not equivalent to extending Layer 2 domains over the core. These links
Example 6-7. Converting Core Links to Trunks
! Distribution switches interface gigabitethernet 6/1 description To Core-1 switchport mode trunk switchport trunk encapsulation dot1q interface gigabitethernet 6/2 description To Core-2 switchport mode trunk switchport trunk encapsulation dot1q ------------------------------------------------------------ ! Core switches interface gigabitethernet 4/1 description To Distribution-1 switchport mode trunk switchport trunk encapsulation dot1q interface gigabitethernet 4/2 description To Distribution-2 switchport mode trunk switchport trunk encapsulation dot1q interface gigabitethernet 4/3 description To Distribution-3 switchport mode trunk switchport trunk encapsulation dot1q interface gigabitethernet 4/4 description To Distribution-4 switchport mode trunk switchport trunk encapsulation dot1q interface gigabitethernet 6/1 description To Distribution-5 switchport mode trunk switchport trunk encapsulation dot1q interface gigabitethernet 6/2 description To Distribution-6 switchport mode trunk switchport trunk encapsulation dot1q interface gigabitethernet 6/3 description To Distribution-7 switchport mode trunk switchport trunk encapsulation dot1q interface gigabitethernet 6/4 description To Distribution-8 switchport mode trunk switchport trunk encapsulation dot1q |
Because these trunks are
A numbering convention can
Table 6-1. Numbering Convention Used for Trunk ID Assignment
|
Digit |
Significance |
|---|---|
|
1st Most Significant Digit (leftmost) |
1 = Uplink; 2 = Link between peers |
|
2nd |
VRF: 1-RED, 2-BLUE |
|
3rd |
Core end of the link |
|
4th LS Digit (rightmost) |
Distribution end of the link |
For instance, VLAN 1214 is used to transport BLUE traffic between Core1 and Distribution 4. VLAN 1124 transports RED traffic over the link between Core2 and Distribution 4. And VLAN 2112 is used to transport RED traffic between Core1 and Core2 and is reused to transport traffic between Distribution 1 and 2, too.
Example 6-8 illustrates the creation of the different VLAN IDs required to interconnect the different RED VRFs and the BLUE VRFs.
Example 6-8. Creating VLAN IDs for Core Data Path Virtualization
! Core1 vlan 1111 name C1toD1 RED vlan 1112 name C1toD2 RED vlan 1113 name C1toD3 RED vlan 1114 name C1toD4 RED vlan 1115 name C1toD5 RED vlan 1116 name C1toD6 RED vlan 1117 name C1toD7 RED vlan 1118 name C1toD8 RED vlan 2112 name C1toC2 RED vlan 1211 name C1toD1 BLUE vlan 1212 name C1toD2 BLUE vlan 1213 name C1toD3 BLUE vlan 1214 name C1toD4 BLUE vlan 1215 name C1toD5 BLUE vlan 1216 name C1toD6 BLUE vlan 1217 name C1toD7 BLUE vlan 1218 name C1toD8 BLUE vlan 2212 name C1toC2 BLUE ------------------------------------------------------------ ! Core2 vlan 1121 name C1toD1 RED vlan 1122 name C1toD2 RED ... vlan 2112 name C1toC2 RED vlan 1221 name C1toD1 BLUE vlan 1222 name C1toD2 BLUE ... vlan 2212 name C1toC2 BLUE ------------------------------------------------------------ ! Distribution 1 vlan 1111 name C1toD1 RED vlan 1211 name C1toD1 BLUE vlan 1121 name C2toD1 RED vlan 1221 name C2toD1 BLUE vlan 2112 name D1toD2 RED vlan 2212 name D1toD2 BLUE ------------------------------------------------------------ ! Distribution 2 vlan 1112 name C1toD2 RED vlan 1212 name C1toD2 BLUE vlan 1122 name C2toD2 RED vlan 1222 name C2toD2 BLUE vlan 2112 name D1toD2 RED vlan 2212 name D1toD2 BLUE |
Finally, you must use the ip vrf forwarding name command to associate the routed interfaces (SVIs) with the VRFs, as shown in Example 6-9
Example 6-9. Assigning SVIs to the Appropriate VRFs
! Distribution 1 interface vlan 1111 description C1-D1 RED ip vrf forwarding RED ip address x.x.x.x x.x.x.x interface vlan 1211 description C1-D1 BLUE ip vrf forwarding BLUE ip address x.x.x.x x.x.x.x interface vlan 1121 description C2-D1 RED ip vrf forwarding RED ip address x.x.x.x x.x.x.x interface vlan 1221 description C2-D1 BLUE ip vrf forwarding BLUE ip address x.x.x.x x.x.x.x interface vlan 2112 description D1-D2 RED ip vrf forwarding RED ip address x.x.x.x x.x.x.x interface vlan 2212 description D1-D2 BLUE ip vrf forwarding BLUE ip address x.x.x.x x.x.x.x ------------------------------------------------------------ ! Core1 interface vlan 1111 description C1-D1 RED ip vrf forwarding RED ip address x.x.x.x x.x.x.x interface vlan 1211 description C1-D1 BLUE ip vrf forwarding BLUE ip address x.x.x.x x.x.x.x interface vlan 1112 description C1-D2 RED ip vrf forwarding RED ip address x.x.x.x x.x.x.x interface vlan 1212 description C1-D2 BLUE ip vrf forwarding BLUE ip address x.x.x.x x.x.x.x interface vlan 2112 description D1-D2 RED ip vrf forwarding RED ip address x.x.x.x x.x.x.x interface vlan 2212 description D1-D2 BLUE ip vrf forwarding BLUE ip address x.x.x.x x.x.x.x ------------------------------------------------------------ ! Core2 interface vlan 1121 description C2-D1 RED ip vrf forwarding RED ip address x.x.x.x x.x.x.x interface vlan 1221 description C2-D1 BLUE ip vrf forwarding BLUE ip address x.x.x.x x.x.x.x interface vlan 1122 description C1-D2 RED ip vrf forwarding RED ip address x.x.x.x x.x.x.x interface vlan 1222 description C1-D2 BLUE ip vrf forwarding BLUE ip address x.x.x.x x.x.x.x interface vlan 2112 description D1-D2 RED ip vrf forwarding RED ip address x.x.x.x x.x.x.x interface vlan 2212 description D1-D2 BLUE ip vrf forwarding BLUE ip address x.x.x.x x.x.x.x |
At this point, a logical topology overlay of VRFs and virtual routed links has been created. The
A separate interior gateway protocol (IGP) process is required for the population of routes in each VN. In our example, we have two VNs: RED and BLUE.
When using the Enhanced Interior Gateway Routing Protocol (EIGRP), each process is represented by an address family. The configuration of each address family is identical to that of the traditional nonvirtualized EIGRP. Any EIGRP configuration that needs to be done at the interface level must be done on the routed interfaces associated with the VRFs (subinterfaces or SVIs). The configuration in Example 6-10 illustrates EIGRP address families.
Example 6-10. EIGRP Address Families
router eigrp 200 address-family ipv4 vrf RED network 1.0.0.0 network 10.0.0.0 no auto-summary exit-address-family address-family ipv4 vrf BLUE network 2.0.0.0 network 20.0.0.0 no auto-summary exit-address-family |
When using Open Shortest Path First (OSPF), multiple instances of the routing protocol are required. The configuration of each instance is identical to that of the traditional nonvirtualized OSPF. Any OSPF configuration that needs to be done at the interface level must be done on the routed interfaces associated with the VRFs (subinterfaces or SVIs). The configuration in Example 6-11 illustrates how different OSPF instances are associated with different VRFs.
Example 6-11. Multiple Instances of OSPF
router ospf 1 vrf RED network 1.0.0.0 0.255.255.255 area 0 network 10.0.0.0 0.255.255.255 area 0 ! router ospf 2 vrf BLUE network 2.0.0.0 0.255.255.255 area 0 network 20.0.0.0 0.255.255.255 area 0 |
A proven best practice in IGP design and deployment is that of making the IGP hierarchical. Doing so
Because each address family is deployed in a hierarchical and symmetrical way, all the mechanisms of resiliency, failover, and scalability will work in the same way as they did for a nonvirtualized network. In addition, the access-distribution block will interact with the core to provide resiliency and failover functionality in the same way as it would for a nonvirtualized enterprise. Therefore, the distribution model in which spanning tree is combined with first-hop redundancy protocols such as HSRP and GLBP continues to
