- Introduction to the Scalable and Modular Control Plane on the ASR 1000
- NSF/SSO, NSR, Graceful Restart to Ensure Robust Routing
- Packet Capture Using Encapsulated Remote SPAN
- Achieving Segmentation Using MPLS over GRE and MPLS VPNs over GRE Solutions
- Scalable v4/VPNv4 Route Reflector
- Scalable and Flexible Internet Edge
- Scalable Data Center Interconnect
- Summary
- Chapter Review Questions
- Answers
- Further Reading
This chapter is from the book
This chapter is from the book
This chapter is from the book
Scalable Data Center Interconnect
Today's businesses are seeing more and more consolidation for both file and application servers into a small number of data centers. Major drivers for this trend include cost savings, regulatory compliance, and ease of backup and administration.
At the heart of this, there is also a virtualization trend, where compute cycles are being isolated or abstracted from storage. This has created newer technologies for virtual machine high availability, and migration such as VMotion, clustering, or even geo-clustering of servers, which require extending Layer 2 VLANs across the WAN (data center interconnect).
Now, when looking at the data center connection and trying to tie it up with the application vendor requirements, almost all suggest using Layer 2 adjacent servers. To satisfy or emulate the requirement of L2 adjacencies across the WAN, various requirements emerge from these trends:
- Loop prevention: This refers to isolation of Spanning Tree Protocol (STP) to each data center itself, and not extended across the data center interconnect (DCI).
- Redundancy: This refers to the DCI solution itself not being prone to node or link failures. That, of course, requires redundancy.
- Convergence times: Apparently, there is no set standard for this requirement for DCI. It really depends on what applications are being run (for example, a requirement driven by VMotion stipulates no more than a couple of seconds for convergence).
- Usage of multiple paths: This is where technologies such as Virtual Switching Systems (VSS) and Multichassis EtherChannel (MEC) come into play. There is another similar solution known as virtual port channel (vPC), which essentially allows creating an EtherChannel where member links are across two different physical systems.
Three types of transport are common for DCI:
- Dark fiber: Fiber that is not lit yet is called dark fiber. Not very many organizations have access to dark fiber, but the ones who have see it as the most preferred way of doing DCI. This is usually limited in distance.
- IP: This is a rather common medium and usually consists of some kind of private IP services that most SPs offer across geographies.
- MPLS: This is one of the more common ways to connect data centers.
The ASR 1000 supports almost all forms of Gigabit Ethernet coarse/dense wavelength-division multiplexing (CWDM/DWDM) optics, although the Catalyst 6500 with VSS/MEC has a solution that meets all the requirements in this arena, including multisite DC connectivity.
For IP and MPLS, the ASR 1000 offers (complementing the Cisco 6500 solution) Ethernet over MPLS and Ethernet over MPLS over GRE, starting from IOS XE 2.4 for dual-site DCI.
Figure 12-8 shows the MPLS transport and active/active EoMPLS pseudowires across DCI routers.
)
Figure 12-8 Encrypting Ethernet frames at Layer 2 using TrustSec and avoiding the use Layer 3 encryption such as IPsec.
Figure 12-9 shows the MPLS transport and active/active EoMPLS pseudowires across DCI routers. Here the DC core switches are Nexus 7Ks running TrustSec to encrypt packets at Layer 2 hop by hop.
)
Figure 12-9 EoMPLS scenario where the transport cloud is MPLS.
The solution in Figure 12-9 shows a unique advantage where any traffic leaving the premise is required to be encrypted, as this provides a native way to encrypt all traffic. This requirement is common in government and state agencies.
Figure 12-10 shows the IP transport and active/active EoMPLSoGRE tunnels across DCI routers.
)
Figure 12-10 EoMPLSoGRE scenario where the transport cloud is IP.
This can also be seen as a consolidation strategy, especially for green-field deployments, where ASR 1000 working as a DCI LAN extension router can also serve as a consolidated unified WAN services router. This brings down the TCO much lower and at the same time allows for faster qualification, where the ASR 1000 functions as a private WAN aggregation, and even perhaps the Internet edge can be collapsed at the consolidated WAN edge.
Figure 12-11 shows the unified WAN edge, which consolidates the DCI with multiple other functions.
)
Figure 12-11 Example of DCI and WAN edge functional collapse in a single router.
Use Case: Encrypting Traffic over an EoMPLS Psuedowire at Layer 2 Using TrustSec
Assume that an organization wants to connect two different data centers and extend multiple VLANs across these two sites for connecting various clusters, geo-clusters. Assume that the transport method in the middle is MPLS and the organization is using Nexus 7Ks as data center core switches. The customer also wants to start with a clear-text (nonencrypted) DCI, but later on would also like to add encryption to it to deal with regulatory compliance. This must be met without much configuration overhead.
Now, to meet these requirements, you need to extend the Layer 2 connectivity across the sites. Because the transport medium is MPLS, you can start with clear-text requirement and deploy the ASR 1000, as shown in Figure 12-8, and then later move to the deployment illustrated in Figure 12-9 by turning on TrustSec (or 802.1AE) link-layer encryption on the Nexus transparently without changing anything on the ASR 1000!
The examples that follow examine the configuration for both the ASR 1000 (port mode EoMPLS) and TrustSec on the Nexus 7000.
Figure 12-12 shows the final topology with both Nexus 7K and ASR 1000 connected with vPC.
)
Figure 12-12 Nexus 7K and ASR 1000 connected via vPC.
Example 12-1 shows the ASR 1000 port mode EoMPLS configuration, which can be used to theoretically extend 4K VLANs.
Example 12-1. Port Mode EoMPLS Configuration for the ASR 1000 with Remote Port Shutdown Enabled by Default
ASR1000-1: ASR1000-1(config)# interface Loopback0 ASR1000-1(config-if)# ip address192.168.100.1255.255.255.255 ! ASR1000-1(config)# interface GigabitEthernet0/0/0 ASR1000-1(config-if)# mtu 9216 ASR1000-1(config-if)# no ip address ASR1000-1(config-if)# negotiation auto ASR1000-1(config-if)#xconnect 192.168.100.2 100 encapsulation mpls! ASR1000-1(config)# interface GigabitEthernet0/0/1 ASR1000-1(config-if)# description to ASR-2 ASR1000-1(config-if)# mtu 9216 ASR1000-1(config-if)# ip address 10.1.2.1 255.255.255.0 ASR1000-1(config-if)# load-interval 30 ASR1000-1(config-if)# negotiation auto ASR1000-1(config-if)# mpls label protocol ldp ASR1000-1(config-if)# mpls ip ! ! ASR1000-1(config)# interface GigabitEthernet0/0/3 ASR1000-1(config-if)# description to ASR-2 ASR1000-1(config-if)# mtu 9216 ASR1000-1(config-if)# ip address 10.1.1.1 255.255.255.0 ASR1000-1(config-if)# load-interval 30 ASR1000-1(config-if)# negotiation auto ASR1000-1(config-if)# mpls label protocol ldp ASR1000-1(config-if)# mpls ip ----------------------------------------------------------------------------------- ASR1000-2: ASR1000-2(config)# interface Loopback0 ASR1000-2(config-if)# ip address192.168.100.2255.255.255.255 ! ASR1000-2(config)# interface GigabitEthernet0/0/0 ASR1000-2(config-if)# mtu 9216 ASR1000-2(config-if)# no ip address ASR1000-2(config-if)# negotiation auto ASR1000-2(config-if)#xconnect 192.168.100.1 100 encapsulation mpls! ASR1000-2(config)# interface GigabitEthernet0/0/1 ASR1000-2(config-if)# description to ASR-1 ASR1000-2(config-if)# mtu 9216 ASR1000-2(config-if)# ip address 10.1.2.2 255.255.255.0 ASR1000-2(config-if)# load-interval 30 ASR1000-2(config-if)# mpls label protocol ldp ASR1000-2(config-if)# mpls ip ! ! ASR1000-2(config)# interface GigabitEthernet0/0/3 ASR1000-2(config-if)# description to ASR-1 ASR1000-2(config-if)# mtu 9216 ASR1000-2(config-if)# ip address 10.1.1.2 255.255.255.0 ASR1000-2(config-if)# mpls label protocol ldp ASR1000-2(config-if)# mpls ip
Example 12-2 shows the Nexus 7000 configuration to use TrustSec for all traffic going outbound on to the EoMPLS pseudowires (over an MPLS cloud).
Example 12-2. Nexus 7K TrustSec Configuration
Nexus-7K-1# sh run cts
version 4.1(2)
feature dot1x
feature cts
cts device-id Nexus-7K-1 password 7 qxz12345
interface Ethernet1/12
switchport
switchport access vlan 666
cts manual
sap pmk abcdef1234000000000000000000000000000000000000000000000000000000
mtu 9216
no shutdown
interface Vlan666
no shutdown
ip address 155.5.5.1/24
-----------------------------------------------------------------------------------
Nexus-7K-2# sh run cts
version 4.1(2)
feature dot1x
feature cts
cts device-id Nexus-7K-2 password 7 qxz12345
interface Ethernet1/12
switchport
switchport access vlan 666
cts manual
sap pmk abcdef1234000000000000000000000000000000000000000000000000000000
mtu 9216
no shutdown
interface Vlan666
no shutdown
mtu 9216
ip address 155.5.5.2/24
Example 12-3 shows that the TrustSec session is established.
Example 12-3. Confirmation That TrustSec Is Negotiated and Is Up
Operational Status (TrustSec 802.1AE SAP negotiation successful):
Nexus-7K-1# show cts interface e 1/12
CTS Information for Interface Ethernet1/12:
CTS is enabled, mode: CTS_MODE_MANUAL
IFC state: CTS_IFC_ST_CTS_OPEN_STATE
Authentication Status: CTS_AUTHC_SKIPPED_CONFIG
Peer Identity:
Peer is: Not CTS Capable
802.1X role: CTS_ROLE_UNKNOWN
Last Re-Authentication:
Authorization Status: CTS_AUTHZ_SKIPPED_CONFIG
PEER SGT: 0
Peer SGT assignment: Not Trusted
Global policy fallback access list:
SAP Status: CTS_SAP_SUCCESS
Configured pairwise ciphers: GCM_ENCRYPT
Replay protection: Disabled
Replay protection mode: Strict
Selected cipher: GCM_ENCRYPT
Current receive SPI: sci:1b54c148d80000 an:2
Current transmit SPI: sci:225577968c0000 an:2
Operational Status (TrustSec 802.1AE SAP negotiation successful):
----------------------------------------------------------------------------------------------
Nexus-7K-2# show cts interface e 1/12
CTS Information for Interface Ethernet1/12:
CTS is enabled, mode: CTS_MODE_MANUAL
IFC state: CTS_IFC_ST_CTS_OPEN_STATE
Authentication Status: CTS_AUTHC_SKIPPED_CONFIG
Peer Identity:
Peer is: Not CTS Capable
802.1X role: CTS_ROLE_UNKNOWN
Last Re-Authentication:
Authorization Status: CTS_AUTHZ_SKIPPED_CONFIG
PEER SGT: 0
Peer SGT assignment: Not Trusted
Global policy fallback access list:
SAP Status: CTS_SAP_SUCCESS
Configured pairwise ciphers: GCM_ENCRYPT
Replay protection: Disabled
Replay protection mode: Strict
Selected cipher: GCM_ENCRYPT
Current receive SPI: sci:225577968c0000 an:2
Current transmit SPI: sci:1b54c148d80000 an:2
As shown in Figure 12-12, the two ASR 1000s are connected via two active/active EoMPLS pseudowires. To deal with a failure scenario, the ASR 1000 uses a feature called Remote Pseudo Wire Shutdown. The behavior on the ASR 1000 is a bit different than on the Catalyst 6500/7600, where the feature does not depend on interworking with the Ethernet LMIs.
On the ASR 1000, this feature, upon pseudowire down state, shuts down the local laser on the port with "xconnect", gi0/0/0, as shown in the use case. This is seen by the peer Ethernet port as the interface going down, and it will go to down/down. This allows the downstream devices to stop sending traffic to the port and results in almost instant convergence EoMPLS remote port shutdown provides faster failover times for both local/remote node or link failure scenarios.
This behavior is very helpful in the vPC scenario, because it will trigger the LACP (Link Aggregation Control Protocol) to converge instantly and will remove the member link from the virtual port channel.