Data Security Solution for Enterprise Networks - Brocade

BROCADE VALIDATED DESIGN

Data Security Solution for Enterprise Networks

53-1004348-02 23 November 2016

© 2016, Brocade Communications Systems, Inc. All Rights Reserved.

Brocade, the B-wing symbol, and MyBrocade are registered trademarks of Brocade Communications Systems, Inc., in the United States and in other countries. Other brands, product names, or service names mentioned of Brocade Communications Systems, Inc. are listed at www.brocade.com/en/legal/ brocade-Legal-intellectual-property/brocade-legal-trademarks.html. Other marks may belong to third parties. Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not be currently available. Contact a Brocade sales office for information on feature and product availability. Export of technical data contained in this document may require an export license from the United States government. The authors and Brocade Communications Systems, Inc. assume no liability or responsibility to any person or entity with respect to the accuracy of this document or any loss, cost, liability, or damages arising from the information contained herein or the computer programs that accompany it. The product described by this document may contain open source software covered by the GNU General Public License or other open source license agreements. To find out which open source software is included in Brocade products, view the licensing terms applicable to the open source software, and obtain a copy of the programming source code, please visit http://www.brocade.com/support/oscd.

2

Data Security Solution for Enterprise Networks 53-1004348-02

Contents List of Figures...................................................................................................................................................................................................................... 5 Preface...................................................................................................................................................................................................................................7 Brocade Validated Designs....................................................................................................................................................................................................................7 Document History......................................................................................................................................................................................................................................7 Purpose of the Document......................................................................................................................................................................................................................8 Target Audience.......................................................................................................................................................................................................................................... 8 About the Authors......................................................................................................................................................................................................................................8 About Brocade............................................................................................................................................................................................................................................ 8 Executive Summary............................................................................................................................................................................................................9 Data Security Solution Technology—Overview..........................................................................................................................................................11 Introduction................................................................................................................................................................................................................................................11 Terminology...............................................................................................................................................................................................................................................12 MACsec.......................................................................................................................................................................................................................................................13 MKA Message Exchange........................................................................................................................................................................................................... 14 IPsec............................................................................................................................................................................................................................................................. 14 Security Policy.................................................................................................................................................................................................................................15 IPsec Connection Establishment............................................................................................................................................................................................ 15 IPsec Mode...................................................................................................................................................................................................................................... 16 IPsec Headers................................................................................................................................................................................................................................. 16 Public Key Infrastructure............................................................................................................................................................................................................. 18 Virtual Routing and Forwarding.........................................................................................................................................................................................................19 Enterprise Data Security Reference Architecture...................................................................................................................................................... 21 Reference Architecture Overview..................................................................................................................................................................................................... 21 Solution Components—Hardware and Software Matrix................................................................................................................................................ 22 Campus Network Architecture...........................................................................................................................................................................................................23 Campus Access Network........................................................................................................................................................................................................... 23 Campus Distribution Network.................................................................................................................................................................................................. 23 Campus Core Network................................................................................................................................................................................................................ 24 Enterprise WAN..............................................................................................................................................................................................................................24 IPsec-to-Non-IPsec Port Physical Loopback................................................................................................................................................................... 25 Product Details.........................................................................................................................................................................................................................................26 Enterprise Data Security Architecture—Validation Design...................................................................................................................................... 27 Campus Network.................................................................................................................................................................................................................................... 27 Campus Access Layer 2 Network................................................................................................................................................................................................... 28 Access Switch Stack Configuration........................................................................................................................................................................................28 Access Switch VLAN Configuration...................................................................................................................................................................................... 29 MACsec Layer 2 Security.......................................................................................................................................................................................................... 29 Campus Distribution Layer 2 and Layer 3 Boundary Network...........................................................................................................................................33 Campus Distribution Router MCT..........................................................................................................................................................................................33 Campus Distribution Router VRRP-E.................................................................................................................................................................................. 36 Virtual Routing and Forwarding Configuration.................................................................................................................................................................. 38 Internet Key Exchange................................................................................................................................................................................................................. 41 Automated Public Key Infrastructure.....................................................................................................................................................................................45 Windows 2012 R2 CA Server.................................................................................................................................................................................................50


3

X.509 v3 Certificates...................................................................................................................................................................................................................53 IPsec Tunnel Configuration........................................................................................................................................................................................................57 IPv4 and IPv6 IPsec Tunnel Configuration.........................................................................................................................................................................58 Campus Core Routing.......................................................................................................................................................................................................................... 59 Campus IPsec Tunnel Design........................................................................................................................................................................................................... 61 Campus Site-to-Site Connectivity................................................................................................................................................................................................... 69 Enterprise WAN Network.....................................................................................................................................................................................................................72 Campus Border Gateway Router IPsec-to-Non-IPsec Port Physical Loopback........................................................................................................ 74 Enterprise Interconnect Across Enterprise WAN—Connectivity Methods...................................................................................................................... 75 Enterprise Interconnect Across the Enterprise WAN—L2VPN VLL .......................................................................................................................75 Enterprise Interconnect Across the Enterprise WAN—L2VPN VPLS.....................................................................................................................79 Enterprise Interconnect Across the Enterprise WAN—L3VPN.................................................................................................................................. 81 Remote Branch Campus Internet Connectivity..........................................................................................................................................................................87 Secure IPsec Traffic Forwarding....................................................................................................................................................................................................... 93 IPv4 Traffic Path for the Campus Across the Enterprise Core/Aggregation.........................................................................................................94 IPv6 Traffic Path for the Campus Across the Enterprise Core/Aggregation.........................................................................................................94 IPv4 Traffic Path for the Enterprise Interconnect Across the Enterprise WAN.................................................................................................... 95 IPv6 Traffic Path for the Enterprise Interconnect Across the Enterprise WAN.................................................................................................... 95 Multicast on IPv4 IPsec Tunnels...................................................................................................................................................................................................... 95 IGMP on the Campus Access Switch................................................................................................................................................................................... 96 PIM-SM Protocol in the Campus Distribution and Border Gateway Routers......................................................................................................97 IGMP show Commands............................................................................................................................................................................................................. 99 PIM-SM show Commands.................................................................................................................................................................................................... 100 Layer 2 Data Center Interconnect (DCI)....................................................................................................................................................................103 Enterprise Data Security with VE-over-VPLS Endpoints..................................................................................................................................... 111 Enterprise Data Security with VE-over-VPLS Endpoints for Nondefault VRF..........................................................................................................111 Enterprise Data Security with VE-over-VPLS Endpoints for Default VRF to Internet............................................................................................117 Layer 2 P2P IPsec Circuit for Enterprise WAN and Internet................................................................................................................................123 Data Security VRRP-E State Tracking by IPsec Tunnel Status........................................................................................................................... 129 Data Security Traffic for Different Priorities............................................................................................................................................................. 135 IPsec Convergence and Traffic Loss..........................................................................................................................................................................137 Traffic Reroute from IPsec Path to Non-IPsec Path..............................................................................................................................................................137 Traffic Reroute in IPsec Tunnel....................................................................................................................................................................................................... 140 Traffic Reroute for LAG Port Failover...........................................................................................................................................................................................141 Design Considerations..................................................................................................................................................................................................145 IPsec and IKEv2 Encryption............................................................................................................................................................................................................145 IPsec.................................................................................................................................................................................................................................................145 IKEv2 Encryption........................................................................................................................................................................................................................145 Scale.......................................................................................................................................................................................................................................................... 145 Licensing Requirements................................................................................................................................................................................................................... 146 Summary......................................................................................................................................................................................................................... 147 References.......................................................................................................................................................................................................................149

4


List of Figures Figure 1 on page 12—Integrated Network Encryption Figure 2 on page 14—MACsec Key Exchange Figure 3 on page 14—MACsec Frame Format Figure 4 on page 15—IPsec Protocols Figure 5 on page 16—Packet Format in Transport and Tunnel Mode Figure 6 on page 17—IPsec ESP Header Figure 7 on page 18—Tunnel Mode ESP Header Format Figure 8 on page 21—Enterprise Data Security Reference Architecture Figure 9 on page 23—Campus Access and Distribution Network Figure 10 on page 24—Campus IP Core Architecture Figure 11 on page 25—Enterprise WAN Architecture Figure 12 on page 27—Campus Network Design Figure 13 on page 28—Campus Access and Distribution Layer Figure 14 on page 34—Campus Distribution MCT Design Figure 15 on page 38—Campus VRF Routing Figure 16 on page 59—Campus Core Architecture Figure 17 on page 61—Campus IPv4 and IPv6 Full-Mesh IPsec Tunnel Design Figure 18 on page 69—Campus MACsec and IPsec Packet Flow Figure 19 on page 75—Enterprise Interconnect Across the Enterprise WAN—L2VPN Design Figure 20 on page 81—Enterprise Interconnect Across the Enterprise WAN—L3VPN Design Figure 21 on page 88—Remote Branch Campus Connection Through the Internet Figure 22 on page 96—Multicast IPsec Design Figure 23 on page 103—Campus MPLS/VPLS Network to Transport Layer 2 VPLS Traffic Figure 24 on page 111—Secure Campus Network to Transport Layer 3 VE over VPLS Traffic Figure 25 on page 117—Secure Campus Network to Transport Layer 3 VPLS/VE Traffic over Internet Figure 26 on page 123—Layer 2 Enterprise Data Centers Are Connected Through the WAN/Internet Figure 27 on page 124—Layer 2 Enterprise Data Center Network Architecture Figure 28 on page 129—VRRP-E State Before Tracked IPsec Tunnel Down Figure 29 on page 130—VRRP-E State After Tracked IPsec Tunnel Down Figure 30 on page 135—COS Packet Capture Points Figure 31 on page 137—Campus Network Architecture for Convergence and Traffic Loss Test Figure 32 on page 138—Traffic Path on IPsec Tunnels


5

Figure 33 on page 138—Traffic Reroute from IPsec Tunnel to Non-IPsec Path2 (After IPsec Tunnel Goes Down) Figure 34 on page 140—IPsec Traffic Path (Before Path Tear) Figure 35 on page 141—IPsec Traffic Reroute Path (After Path Tear) Figure 36 on page 142—IPsec LAG Traffic Reroute (Before LAG Member Goes Down) Figure 37 on page 142—IPsec LAG Traffic Reroute (After LAG Member Goes Down)

6


Preface • • • • • •

Brocade Validated Designs.............................................................................................................................................................................. 7 Document History................................................................................................................................................................................................ 7 Purpose of the Document.................................................................................................................................................................................8 Target Audience.....................................................................................................................................................................................................8 About the Authors................................................................................................................................................................................................ 8 About Brocade.......................................................................................................................................................................................................8

Brocade Validated Designs Helping customers consider, select, and deploy network solutions for current and planned needs is our mission. Brocade Validated Designs offer a fast track to success by accelerating that process. Validated designs are repeatable reference network architectures that have been engineered and tested to address specific use cases and deployment scenarios. They document systematic steps and best practices that help administrators, architects, and engineers plan, design, and deploy physical and virtual network technologies. Leveraging these validated network architectures accelerates deployment speed, increases reliability and predictability, and reduces risk. Brocade Validated Designs incorporate network and security principles and technologies across the ecosystem of service provider, data center, campus, and wireless networks. Each Brocade Validated Design provides a standardized network architecture for a specific use case, incorporating technologies and feature sets across Brocade products and partner offerings. All Brocade Validated Designs follow best-practice recommendations and allow for customer-specific network architecture variations that deliver additional benefits. The variations are documented and supported to provide ongoing value, and all Brocade Validated Designs are continuously maintained to ensure that every design remains supported as new products and software versions are introduced. By accelerating time-to-value, reducing risk, and offering the freedom to incorporate creative, supported variations, these validated network architectures provide a tremendous value-add for building and growing a flexible network infrastructure.

Document History Date

Part Number

Description

April 27, 2016

53-1004348-01

Initial release.

November 23, 2016

53-1004348-02

Added new content for the following: 1. Layer 2 Data Center Interconnect (DCI). 2. Enterprise data security with VE-over-VPLS endpoints for default and nondefault VRFs. 3. Convergence and traffic loss measurement scenarios.


7

Purpose of the Document

Purpose of the Document This Brocade validated design provides guidance for designing and implementing a secure enterprise data connection using MACsec (Layer 2) and IPsec (Layer 3) with Brocade hardware and software. This document also covers dynamic certificate enrollment and management using Public Key Infrastructure (PKI) from the certification authority (CA) server: Windows 2012 R2. The design practices documented here follow best-practice recommendations, but there are variations to the design that are supported as well.

Target Audience This document is written for Brocade systems engineers, partners, and customers who design, implement, and support a secured enterprise network. It is intended for experienced network engineers and network architects. It assumes that the reader has a good understanding of MACsec, IPsec tunnels, dynamic Public Key Infrastructure (PKI), certificate authority (CA) server configuration, and IP and MPLS routing.

About the Authors Sabbir Ahmed is a Staff Engineer on the IP SQA team at Brocade. Sabbir has extensive experience testing IP routing and security technologies. At Brocade, he focuses on developing and validating solution architectures that customers can use in deployments. The author would like to acknowledge the following Brocadians for their technical guidance in developing this validated design: •

Abdul Khader—Technical Director

•

Rajiv Goel—Principal Director, Product Management

•

Chirag Kachalia—Technical Marketing Engineer

•

Naveen Anand—Staff Software Engineer

About Brocade Brocade® (NASDAQ: BRCD) networking solutions help the world's leading organizations transition smoothly to a world where applications and information reside anywhere. This vision is designed to deliver key business benefits such as unmatched simplicity, non-stop networking, application optimization, and investment protection. Innovative Ethernet and storage networking solutions for data center, campus, and service provider networks help reduce complexity and cost while enabling virtualization and cloud computing to increase business agility. To help ensure a complete solution, Brocade partners with world-class IT companies and provides comprehensive education, support, and professional services offerings (www.brocade.com).

8


Executive Summary Securing today's business poses a continuous challenge to organizations. The fast proliferation of botnets, the increasing sophistication of network attacks, the alarming growth of Internet-based organized crime and espionage, identity and data theft, and more innovative insider attacks are examples of the diverse and complex real threats that shape today's security landscape. Networks must be designed and implemented with security in mind to ensure the confidentiality, integrity, and availability of data and system resources that support key business functions. Regulations such as the Health Insurance Portability and Accountability Act (HIPAA) and the Sarbanes-Oxley Act (S-OX) recommend and mandate that companies implement all reasonable safeguards to protect personal, customer, and corporate information. Customers are using IPsec to encrypt their WAN communications, whether using a private WAN, the Ethernet/IP core, or the public Internet for connectivity. The IPsec standard provides a method to manage authentication and data protection between multiple crypto peers engaging in secure data transfer. By using symmetrical encryption algorithms, IPsec enables efficient and secure networks, avoiding data integrity attacks, eavesdropping, or modification of sensitive and confidential data. This design guide defines the comprehensive functional components that are required to build a site-to-site virtual private network (VPN) system in the context of enterprise wide area network (WAN) connectivity. The Brocade encryption solution enables enterprises to easily deploy end-to-end secure encryption using standards-based encryption that is built into physical or virtual networking hardware. These hardware-based, site-to-site, and hop-by-hop encryption solutions deliver wire-speed performance while protecting in-flight data. Customers can now be confident in the security of their network as they merge their private WAN and campus networks with public cloud services.


9

10


Data Security Solution Technology— Overview • • • • •

Introduction.......................................................................................................................................................................................................... 11 Terminology......................................................................................................................................................................................................... 12 MACsec................................................................................................................................................................................................................. 13 IPsec........................................................................................................................................................................................................................14 Virtual Routing and Forwarding................................................................................................................................................................... 19

Introduction Today's large corporations/enterprises and providers often have multiple sites and branches that pose data security challenges and require secure communication over the public IP network. In order to reduce the risk of data theft, Brocade provides the strongest secure, scalable, and flexible data security solution to protect critical information traversing the public IP network between the data center, campus, remote sites, and branch/HQ offices. The Brocade MLX platform and 4-port 10-GbE module provide hardware-based, next-generation cryptographic IPsec (Suite B) AESGCM 128/256-bit and 802.1AE MACsec 128-bit hop-by-hop encryption at link-layer encryption. MACsec provides data security, integrity, and authenticity with network encryption, digital certification, and device authentication to protect critical data. The MLXe IPsec module supports the RFC 6379 strong cryptographic Suite B for IPsec and the latest RFC 5996 IKEv2 and Public Key Infrastructure (PKI) management for certification authority (CA) using the OSCP, SCEP, and X.509 v3 certificate. IPsec encryption provides authentication of the peer's ECDSA P-384 curve and the SHA-384 hash function for digital signature. The IPsec module is a highly secure, industry-standard, cost-effective, scalable solution that supports IPv4, IPv6, Layer 2/3, QoS, Multicast, Multi-VRF, ECMP, jumbo frame, and load distribution to provide secure communication across the WAN. This validated design documents the data security solution deployment scenarios across the enterprise campus network and the WAN to provide the highest level of data integrity. This version of the validated design includes the MLXe as IPsec tunnel termination endpoints and MACsec between the ICX and the MLXe. A future version of the validated design will include IPsec support on the ICX for secure branch and IPsec support on the vRouter for secure hybrid cloud.


11

Terminology

FIGURE 1 Integrated Network Encryption

Terminology Term

Description

AH

Authentication Header

BGW

Border Gateway

CA

Certificate Authority

CCEP

Cluster Client Edge Port

CCP

Cluster Communication Protocol

CDP

Cisco Discovery Protocol

CEP

Cluster Edge Port

CRL

Certificate Revocation List

DH

Diffie Hellman

ESP

Encapsulating Security Payload

ICL

Inter-Chassis Link

ICMP

Internet Control Message Protocol

ICMPv6

Internet Control Message Protocol version 6

IGP

Interior Gateway Protocol

IKEv2

Internet Key Exchange version 2

IP

Internet Protocol

IPsec

Internet Protocol Security

IPv6

Internet Protocol version 6

IS-IS

Intermediate System to Intermediate System

L2

Layer 2

12


MACsec

Term

Description

L3

Layer 3

LAG

Link Aggregation Group

LDP

Label Distribution Protocol

LLDP

Link Layer Discovery Protocol

MACsec

Media Access Control Security

MCT

Multi-Chassis Trunk

MPLS

Multiprotocol Label Switching

OCSP

Online Certificate Status Protocol (RFC 6960)

OSPF

Open Shortest Path First

OSPFv3

Open Shortest Path First protocol for IPv6

Ping

Packet Inter Net Grouper

PKI

Public Key Infrastructure

RSVP

Resource Reservation Protocol

SA

Security Association

SCEP

Simple Certificate Enrollment Protocol (draft RFC)

TCP

Transmission Control Protocol

UDP

User Datagram Protocol

VLAN

Virtual LAN

VLL

Virtual Leased Line

VPLS

Virtual Private LAN Service

VPN

Virtual Private Network

VRF

Virtual Routing and Forwarding

VRRP-E

Virtual Router Redundancy Protocol Extended

MACsec Media Access Control Security (MACsec) is a Layer 2 security technology that provides point-to-point security on Ethernet links between MACsec-capable nodes. MACsec, defined in the IEEE 802.1AE-2006 standard, is based on symmetric cryptographic keys. The MACsec Key Agreement (MKA) protocol, defined as part of the IEEE 802.1X-2010 standard, operates at Layer 2 to generate and distribute the cryptographic keys used by the MACsec functionality installed in the hardware. As a hop-to-hop Layer 2 security feature, MACsec can be combined with Layer 3 security technologies such as IPsec for end-to-end data security. MACsec capabilities prevent Layer 2 security threats, such as passive wiretapping, denial of service, intrusion, man-in-the-middle, and playback attacks. MACsec protects communications using several configurable techniques. Data origin is authenticated, and data is transported over secured channels. Frames are validated as MACsec Ethernet frames. The integrity of frame content is verified on receipt. Frame sequence is monitored using an independent replay protection counter. Invalid frames are discarded or monitored. Data traffic carried within the MACsec frame is encrypted and decrypted using an industry-standard configured cipher suite. The MKA protocol installed on a Brocade device relies on an IEEE 802.1X Extensible Authentication Protocol (EAP) framework to establish communication. Each peer device establishes a single unidirectional secure channel for transmitting MACsec frames (Ethernet frames with MACsec headers that carry encrypted data) to its peers within the connectivity association. A typical connectivity association consists of two secure channels, one for inbound traffic and one for outbound traffic. All peers within the connectivity association must use the same cipher suite, currently Galois/Counter Mode Advanced Encryption Standard 128 (GCM-AES-128), for MACsecauthenticated security functions.


13

IPsec

MKA Message Exchange MACsec peers on the same LAN belong to a unique connectivity association. Members of the same connectivity association identify themselves with a shared connectivity association key (CAK) and connectivity association key name (CKN). The CAK is a static key that is preconfigured on each MACsec-enabled interface. MACsec authentication is based on mutual possession and acknowledgment of the preconfigured CAK and CKN. FIGURE 2 MACsec Key Exchange

When two MACsec peers confirm possession of a shared CAK and CKN, the MKA protocol initiates key server election. The key server is responsible for determining whether MACsec encryption is used and what cipher suite is used to encrypt data. The key server is also responsible for generating secure association keys (SAKs) and distributing them to the connected device. Once a SAK is successfully installed, the two devices can exchange secure data. FIGURE 3 MACsec Frame Format

To ensure point-to-point integrity, MACsec computes an integrity check value (ICV) on the entire Ethernet frame using the designated cipher suite. The designated cipher suite is used for encryption. MACsec adds the ICV to the frame before transmission. The receiving device recalculates the ICV and checks it against the computed value that has been added to the frame. Because the ICV is computed on the entire Ethernet frame, any modifications to the frame can be easily recognized.

IPsec IPsec is a protocol suite for securing IP communications by authenticating and encrypting each IP packet of a communication session. IPsec provides end-to-end L3 packet authentication and encryption.

14


IPsec

A virtual tunnel interface (VTI) plugs IPsec tunnels into the routing protocol infrastructure of a router. VTIs provide termination points for site-to-site IPsec VPN tunnels and allow them to behave like routable interfaces. Besides simplifying IPsec configuration, a VTI enables common routing capabilities to be used since the endpoint is associated with an actual interface. IPsec VTIs simplify the configuration of IPsec for the protection of remote links, they support multicast, and they facilitate network management and load balancing. IPsec provides the following security features: •

Data origin authentication—To verify that the source is indeed the source that sent the message.

•

Data integrity—To make sure that data is not tampered with along the path to its destination.

•

Replay protection—To make sure that a packet is not replayed by a malicious user by employing sequence numbers.

•

Message confidentiality—To make sure that a message is not read by anybody except the intended destination by encrypting the contents. FIGURE 4 IPsec Protocols

IPsec consists of two basic security protocols: AH and ESP. IKEv2 is the key management protocol. Brocade currently supports ESP, which encrypts the packet payload and prevents it from being monitored. IKEv2 provides a secure method of exchanging cryptographic keys and negotiating authentication and encryption methods.

Security Policy The set of IPsec parameters that describe a connection is called a security policy. The security policy describes how both endpoints will use security services, such as encryption, hash algorithms, and Diffie Hellman groups, to communicate securely.

IPsec Connection Establishment The IPsec peers negotiate a set of security parameters, using IKEv2 to set up a logically secure tunnel called a security association (SA). There are two types of SAs: an IKEv2 SA and an IPsec SA. •

An IKEv2 SA is used to set up an IPsec SA and is bidirectional. Note that IKEv1 is not supported.

•

IPsec SAs are used to securely transmit data and are unidirectional. For packets to travel in both directions in a connection, both an inbound SA and an outbound SA are required.

The establishment of an IPsec connection occurs in two phases called IKE phases: •

In IKE Phase 1, the two endpoints authenticate one another and negotiate keying material. This results in an encrypted tunnel used by Phase 2 for negotiating the ESP SAs.

•

In IKE Phase 2, the two endpoints use the secure tunnel created in Phase 1 to negotiate ESP SAs. The ESP SAs are used to encrypt the actual user data that is passed between the two endpoints.


15

IPsec

IKE Phase 1 establishes an IKE SA. The IKE protocol is used to dynamically negotiate and authenticate keying material and other security parameters required to provide secure communications. If the IKE Phase 1 negotiation is successful, the IKE SA is established. The IKE SA contains the information from the "winning proposal" of the negotiation, recording the security encryption and keying material that was successfully negotiated. This creates a secure "control channel" in which keys and other information for protecting Phase 2 negotiation are maintained. The IKE SA encrypts only Phase 2 ESP SA negotiations, plus any IKE messages between the two endpoints. IKE Phase 2 negotiations are also managed by the IKE protocol. Using the encryption provided by the security association, the security policy is used to try and negotiate a Phase 2 SA. The security policy includes information about the communicating hosts and subnets, as well as the ESP information for providing security services for the connection, such as the encryption cipher and hash algorithm. If the IKE Phase 2 negotiation process is successful, a pair of ESP SAs (typically called IPsec SAs) is established—one inbound and one outbound—between the two endpoints. This is the encrypted VPN "tunnel" between the two endpoints. At this point, the user data can be exchanged through the encrypted tunnel. Between two IPsec peers, any number of security policies can be defined. For example, you can define one security policy that creates a tunnel between two hosts and a different security policy that creates a tunnel between a host and a subnet or between two subnets. Because multiple tunnels can exist between two peers, multiple IPsec SAs can be active at any time between two peers.

IPsec Mode IPsec can be run in either tunnel mode or transport mode. Each mode has its own particular uses, and care should be taken to ensure that the correct mode is selected for the solution: •

Transport mode—Used between end stations or between an end station and a gateway, if the gateway is being treated as a host. In transport mode, a new IPsec header is inserted into the IP packet. No new packet is created. Transport mode is used more frequently for a remote-access VPN solution.

•

Tunnel mode—Most commonly used between gateways or at an end station to a gateway. In this mode, the entire IP packet is encrypted and becomes the data component of a new IP packet. Tunnel mode is used frequently in an IPsec site-to-site VPN.

In this validated design, IPsec tunnel mode is used. FIGURE 5 Packet Format in Transport and Tunnel Mode

IPsec Headers IPsec essentially consists of two basic protocols: AH and ESP. IKEv2 is the key management protocol. NOTE Brocade currently supports ESP mode only.

16


IPsec

Authentication Header An authentication header (AH) payload is used to provide the following security features: •

Data origin authentication

•

Connectionless data integrity

•

Optional replay protection

Replay protection is optional because the receiver may or may not choose to use the service. AH mode is not currently supported in Brocade MLXe routers. Encapsulating Security Payload Encapsulating Security Payload (ESP) is used to provide the following security features: •

Message confidentiality

•

Connectionless data integrity

•

Optional replay protection

Replay protection is optional because the receiver may or may not choose to use the service. Figure 6 provides a high-level view of the ESP header. FIGURE 6 IPsec ESP Header

ESP has both a header and a trailer. The ESP header starts after the IP header (and any extension header, in case of IPv6), it is followed by the encrypted payload with an optional padding, and it ends with the ESP trailer, which contains the pad length, the next header value, and optionally authentication data. Authentication data is used to provide authentication to the encrypted data. One advantage of this is that bad packets (tampered/ corrupted) can be rejected by the receiver in decrypting the packet. The authentication data of ESP cannot protect the outer IP header, only the payload that is being encrypted.


17

IPsec

FIGURE 7 Tunnel Mode ESP Header Format

In tunnel mode, a whole IP packet is encrypted and is kept inside another IP packet and routed. This is done to protect the confidentiality of the IP packet. This mode is commonly used in gateways that connect two corporate units or a home that connects to a corporate network. Because the IP payload is encrypted, its contents cannot be used as matching criteria for a security association (SA).

Public Key Infrastructure Public Key Infrastructure (PKI) provides a security infrastructure for entities to have a secured communication for security protocols such as IP security. Each PKI peer holds a digital certificate, which holds multiple attributes to ensure that the entity can be trusted and can support secured communication. A PKI consists of the following entities: •

Peers communicating on a secure network.

•

At least one certificate authority (CA) that grants and maintains certificates.

•

Digital certificates, which contain information such as the certificate validity period, peer identity information, encryption keys that are used for secure communications, and the signature of the issuing CA. In this validated design, Windows 2012 R2 is used as the CA server.

•

An optional registration authority (RA) to offload the CA by processing enrollment requests.

•

A distribution mechanism such as Lightweight Directory Access Protocol (LDAP) for certificate revocation lists (CRLs).

The PKI provides enterprise communities with a scalable, secure mechanism for distributing, managing, and revoking encryption and identity information in a secured data network. Every entity that participates in the secured communications is enrolled in the PKI. PKI uses an asymmetric encryption algorithm in which two different keys are used to encrypt and decrypt data. The key pair consists of a private key and a public key. The private key must be kept secret, whereas the public key can be distributed. Data encrypted by one of the two keys can be decrypted only by the other. Data encrypted with a public key cannot be decrypted using a public key and vice versa. So users of a public key can be confident that the associated private key is owned by the correct remote subject. The devices that enroll in PKI must validate their identity by the trusted entity (AKA, the CA or trust point). After each entity enrolls in a PKI, every peer in a PKI is granted a digital certificate that has been issued by a CA. When peers must negotiate a secured communication session, they exchange digital certificates. Based on the information in the certificate, a peer can validate the identity of another peer and establish an encrypted session with the public keys contained in the certificate.

18


Virtual Routing and Forwarding

Virtual Routing and Forwarding Virtual Routing and Forwarding (VRF) technology allows routers to maintain multiple routing tables and forwarding tables on the same router. A multi-VRF router can run multiple instances of routing protocols with a neighboring router with overlapping address spaces configured on different VRF instances. Multi-VRF deployments provide the flexibility to maintain multiple virtual routers, which are segregated for each VRF instance. Figure 8 on page 21 illustrates a generic, high-level topology where different enterprise functions are assigned unique VRF instances. In this solution, community traffic is separated by the VRFs for both the campus across the enterprise core/aggregation and the enterprise interconnect across the enterprise WAN connectivity.


19

20


Enterprise Data Security Reference Architecture • • •

Reference Architecture Overview................................................................................................................................................................21 Campus Network Architecture..................................................................................................................................................................... 23 Product Details................................................................................................................................................................................................... 26

Reference Architecture Overview This document demonstrates the end-to-end (MACsec for Layer 2 and IPsec for Layer 3) secure data connection for the communities in the enterprise campus environment. At the access layer, Brocade ICX stack switches directly connect to different communities through different VLANs. Access switches are connected to campus distribution routers, which run MCT with VRRP-E for switch-level redundancy. The VRRP-E VRID address is the default gateway for different community traffic. Campus access to distribution Layer 2 communication is secured by MACsec. FIGURE 8 Enterprise Data Security Reference Architecture

Distribution routers are the Layer 2 and Layer 3 boundary in the campus site. Each community is separated by different community VRFs in campus distribution routers. Layer 3 communication between distribution routers within the campus distribution router is secured by IPsec tunnels. 4x10G IPsec ports are used in the IPv4 and IPv6 IPsec tunnel ingress and egress endpoints.


21

Reference Architecture Overview

The campus core network runs OSPFv2 and v3 in the default VRF. Campus border gateway routers interconnect different campus branches across the enterprise WAN. Layer 3 communication across the campus branches is secured by IPsec tunnels in different community VRFs. In the validated design, the following services are used to interconnect campus branches across the enterprise WAN. Remote branch campuses are connected via the Internet. •

L2VPN—VLL

•

L2VPN—VPLS

•

L3VPN

Enterprise campus distribution to border gateway communication is secured by IPv4 and IPv6 IPsec tunnels. IPsec tunnels are mapped to different community VRFs. In this validated design, the Windows 2012 certificate authority server is used for issuing certificates. The following table shows the router names used in the reference architecture: Network Location Campus 1 Site 1

Campus 1 Site 2

Campus 2 Site 1

Campus 2 Site 2

Campus Remote Site 1

Campus Remote Core

Router Name

Platform

Details

C1-S1-A1

ICX 7450

Campus 1 Site 1 Access Switch 1

C1-S1-D1

MLXe

Campus 1 Site 1 Distribution Router 1

C1-S1-D2

MLXe


C1-S2-A1

ICX 7450


C1-S2-D1

MLXe


C1-S2-D2

MLXe


C1-BGW

MLXe

Campus 1 Border Gateway Router

C2-S1-A1

ICX 7450


C2-S1-D1

MLXe


C2-S1-D2

MLXe


C2-S2-A1

ICX 7450


C2-S2-D1

MLXe


C2-S2-D2

MLXe


C2-BGW

MLXe

Campus 2 Border Gateway Router

CR-S1-A1

ICX 7450

Campus Remote Site 1 Access Switch 1

CR-S1-D1

MLXe

Campus Remote Site 1 Distribution Router 1

CR-S1-D2

MLXe

Campus Remote Site 1 Distribution Router 2

CR-BGW

MLXe

Campus Remote Border Gateway Router

Solution Components—Hardware and Software Matrix The validated design network consists of the following components and products. Component/Product

Function

Software

Brocade ICX 7450

Enterprise campus access switch

SWR08030h

Brocade MLXe 4x10G IPsec module, 20x10G

Enterprise campus distribution or border gateway router

5.9.00be

Windows Server

CA server

Win2012 R2

22


Campus Network Architecture

Campus Network Architecture In the validated design, enterprise network Layer 2 and Layer 3 communication is secured by configuring MACsec and IPsec in different segments of the campus network. The access network consists of a Layer 2 network design that includes stacking for switch-level redundancy, VLANs, and Link Aggregation (LAG). This validated design focuses on the security aspect of the network and does not cover the Layer 2 network design in detail. From campus access switches to distribution routers, the Layer 2 connection is secured via the MACsec protocol. The distribution routers are the Layer 2 and Layer 3 boundary for the campus network. Different communities are separated by VRFs. An IPsec tunnel is used for securing the Layer 3 communication within the campus remote sites. FIGURE 9 Campus Access and Distribution Network

Campus Access Network Brocade ICX 7450 switches form the access layer or lower tier of the campus. The access tier can be managed as a single entity using Brocade's HyperEdge stacking. Brocade recommends running LLDP or CDP on all interfaces of all devices to help identify the peer devices on each link. Community users are directly connected to the access switches. The connections from access switches to distribution routers are configured as LAG ports to increase the bandwidth and port-level redundancy. For Layer 2 encryption, MACsec is configured on all access switch ports that are connected to MCT peer distribution routers. Data traffic carried within the MACsec frame is encrypted and decrypted using an industry-standard cipher suite.

Campus Distribution Network Brocade MLXe routers form the distribution layer or upper tier of the campus. Distribution routers run MCT along with VRRP-E to achieve switch-level redundancy. A multi-chassis trunk (MCT) is a trunk that initiates at a single MCT-unaware switch (ICX) and that terminates at two MCT-aware switches (MLXe). LAG trunks provide link-level redundancy and increased capacity. With MCT, member links of the LAG are connected to two chassis. The MCT switches may be directly connected using an inter-chassis link (ICL) to enable data flow and control messages between them. In this model, if one MCT switch fails, a data path will remain through the other switch. In an MCT scenario, all links are active and can be load-shared to increase bandwidth. In addition, traffic restoration can be achieved in milliseconds after an MCT link failure or MCT switch failure. MCT is designed to increase network resilience and performance.


23


MLXe distribution routers are the Layer 2 and Layer 3 boundary for the campus network. Different communities are separated by VRFs on the VRRP-E VE interfaces in the distribution routers. The MCT peers between the distribution routers must ensure that packets sent to an VRRP-E virtual IP address can be L2-switched to the VRRP-E master router for forwarding. Both data traffic and VRRP-E control traffic travel through the ICL unless the short-path forwarding feature is enabled.

Campus Core Network The campus core router connects the distribution routers to the campus sites. OSPFv2 and v3 routing in the default VRF is configured in the campus core. To secure Layer 3 communication within campus sites, bidirectional IPv4 and IPv6 IPsec tunnels in different community VRFs are created. Layer 3 communication between the campus distribution and the border gateway router is secured by configuring IPv4 and IPv6 IPsec tunnels in different community VRFs. IPv4 and IPv6 IPsec tunnels in different community VRFs secure Layer 3 communication in the campus core. IPsec tunnels in different VRFs separate different community traffic. Dotted colored lines in Figure 10 show the configured IPsec tunnels in different VRFs. Communities in each VRF can send IPv4/IPv6 unicast traffic and IPv4 multicast source/join traffic within enterprise campus sites though the campus core. FIGURE 10 Campus IP Core Architecture

Enterprise WAN Enterprise WAN components include campus service provider core routers that are connected to the campus border gateways. Core routers in the enterprise WAN forward traffic using Multiprotocol Label Switching (MPLS). IPv4 and IPv6 IPsec tunnels secure Layer 3

24



communications between two campus branches over the enterprise WAN network. Separate IPsec tunnels are configured in different community VRFs to carry different community traffic. Campus border gateway routers can be connected via the L2VPN (VLL/VPLS) or the L3VPN. In this validated design, IS-IS routing is configured as the IGP in the enterprise WAN network. The campus border gateway router's MPLS uplinks are non-IPsec 10G ports. FIGURE 11 Enterprise WAN Architecture

IPsec-to-Non-IPsec Port Physical Loopback Campus border gateway MPLS uplinks are non-IPsec 10G ports. Since IPsec tunnels need IPsec ports at the tunnel endpoints, in the validated design, configure a physical loopback from the IPsec 10G port to the non-IPsec 10G port. For L2VPN, the VLAN tag on IPsec of the physical loopback link will match the VLL/VPLS VLAN tag of the non-IPsec port of the physical loopback link for packet switching. IPsec tunnel ingress and egress endpoints are the IPsec port of the physical loopback link. Layer 3 packets will be encrypted and decrypted in the IPsec tunnel endpoints. For L3VPN, the IPsec port of the physical loopback link is in VRF "transit" running OSPF. The non-IPsec port of the physical loopback link is in VRF "Forwarding" running OSPF. IPsec endpoints are reachable via the L3VPN in VRF "Forwarding" over the enterprise WAN. Those routes should be exported to VRF transit with the route exit-interface as the IPsec port. Layer 3 packets will be encrypted in the IPsec port of the physical loopback and then encapsulated with an MPLS label at the MPLS uplink of the campus border gateway router. At the egress border gateway router MPLS uplink, after the MPLS header is stripped, the packets are forwarded to the IPsec port. Based on the ESP header, the IPsec port decrypts and forwards them to the respective community VRFs.


25

Product Details

Product Details Brocade ICX 7450—The Brocade ICX 7450 provides a unique modular design with three expansion slots for a choice of 1-GbE, 10-GbE, or 40-GbE uplinks, providing ultimate flexibility and "pay as you grow" scalability. The switch delivers market-leading stacking scalability with up to 12 switches per stack, 160 Gbps of stacking bandwidth, and long-distance stacking using open-standard QSFP+ or SFP + ports to enable single-point management across the campus. It provides OpenFlow support in true hybrid port mode, enabling software-defined networking (SDN) for programmatic control of network data flows. It offers Power over HDBaseT (PoH) to power video surveillance and video conferencing equipment, VDI terminals, and HD displays directly from the switch. Brocade MLXe—The Brocade MLXe Series is highly optimized for IP Ethernet deployments, providing symmetric scaling with chassis options that include 4-, 8-, 16-, and 32-slot systems. The Brocade MLXe router is designed to meet the requirements of scalability, performance, programmability, and operational simplicity. Built with a state-of-the-art, sixth-generation, network-processor-based architecture and terabit-scale switch fabrics, the Brocade MLXe Series provides a rich set of high performance functionality for Layer 2/3, IPv4, IPv6, MPLS, wire-speed encryption, and SDN. As a result, these routers address the diverse needs of environments that include the service-provider data centers, the enterprise, public sector organizations, Internet exchange points (IXPs), and research and education networks.

26


Enterprise Data Security Architecture— Validation Design • • • • • • • • • • • •

Campus Network............................................................................................................................................................................................... 27 Campus Access Layer 2 Network..............................................................................................................................................................28 Campus Distribution Layer 2 and Layer 3 Boundary Network..................................................................................................... 33 Campus Core Routing..................................................................................................................................................................................... 59 Campus IPsec Tunnel Design...................................................................................................................................................................... 61 Campus Site-to-Site Connectivity..............................................................................................................................................................69 Enterprise WAN Network............................................................................................................................................................................... 72 Campus Border Gateway Router IPsec-to-Non-IPsec Port Physical Loopback...................................................................74 Enterprise Interconnect Across Enterprise WAN—Connectivity Methods.................................................................................75 Remote Branch Campus Internet Connectivity.................................................................................................................................... 87 Secure IPsec Traffic Forwarding.................................................................................................................................................................. 93 Multicast on IPv4 IPsec Tunnels................................................................................................................................................................. 95

Campus Network Figure 12 shows the campus network design for secure site-to-site connectivity. In the sections that follow, the functional components of the network are described and best-practice configuration templates are provided. FIGURE 12 Campus Network


27

Campus Access Layer 2 Network

Campus Access Layer 2 Network The campus access Layer 2 is built using stackable ICX 7450 switches. Different communities are directly connected to these switches via different community VLANs. FIGURE 13 Campus Access and Distribution Layer

Campus access network configuration: •

Configure a stack of ICX switches. The ICX switch is the MCT client to distribution MCT peer routers.

•

Configure a LAG with all ports connected to the MCT peer distribution routers.

•

Configure different community VLANs with the LAG ports as the tag member of those VLANs.

•

Configure MACsec on all LAG member ports in the stack units.

Access Switch Stack Configuration The ICX stack provides port density and a single point of management. Two switches are stacked by two 40G links between them. The ports are chosen from two linecard modules for redundancy at the module level. Both stack units are managed from the active stack unit and have a single stack MAC address. Priority is used to configure the active and standby stack units.

28



Access Switch VLAN Configuration The campus access switch (C1-S1-A1) acts as the MCT client to the MCT peer distribution routers. All ports of the MCT client are members of a dynamic LAG (802.3ad). The LAG ports carry traffic from community VLANs, and traffic separation between the communities is achieved by tagging the frames with 802.1q tags.

MACsec Layer 2 Security MACsec is used to encrypt data traffic between the campus and distribution layers. MACsec License The MACsec license is a node-locked license and is required per device. The user must install a separate MACsec license in both ICX stack switches to run MACsec in the ICX. Once the MACsec license is installed successfully, the following output describes how to verify the MACsec license on supported Brocade ICX switches. A successfully installed license shows the status as active and has a valid license period.


29


MACsec Configuration in the Access Switch MCT client ports in an access stack switch are configured with MACsec. MACsec encrypts traffic in the ingress device at the MAC layer and decrypts frames at the egress network device endpoint. MACsec uses the Galois/Counter Mode Advanced Encryption Standard 128 (GCM-AES-128) cipher suite to encrypt data and to compute the ICV for each transmitted and received MACsec frame. By default, both encryption and integrity protection are enabled. The following steps are required to configure MACsec security on a link or a group of connected ports: 1.

Enter the dot1x-mka level from the global configuration level, and enable MACsec for the device.

2.

Configure a MACsec Key Agreement (MKA) group.

3.

Configure the required parameters for the group, including frame-validation, confidentiality-offset, replay-protection, and ciphersuite. In the following example, we use the GCM-AES-128 cipher suite.

4.

Enable MKA on each participating interface.

5.

Apply the MKA group on the participating interface.

6.

Configure the connectivity association key (CAK) and the connectivity association key name (CKN) on each interface. See the following output for the key values.

The following configuration shows the MACsec configuration in an ICX stack configured in all MCT client ports.

MACsec Configuration in Distribution Layer MCT Peer Routers MCT CCEP ports in MCT peer routers are configured with MACsec encryption. The following steps are required to configure MACsec security on a link or a group of connected ports:

30

1.

Enter the dot1x-mka level from the global configuration level, and enable MACsec for the device.

2.

Configure a MACsec Key Agreement (MKA) group.

3.

Configure the required parameters for the group, including frame-validation, confidentiality-offset, and replay-protection.



4.

Enable MKA on each participating interface.

5.

Apply the MKA group on the participating interface.

6.

Configure the connectivity association key (CAK) and the connectivity association key name (CKN) on each interface. See the following output for the key values.

The following configuration shows the MACsec configuration in the distribution MLXe MCT peers:

The show dot1x-mka group command output shows different MACsec attributes in both MCT peer routers.

The show macsec statistics ethernet port-number command displays secure channel activity for a particular interface. The following output shows the MACsec encryption and decryption statistics while traffic is running bidirectionally between the access layer and the distribution layer. MACsec Statistics in the ICX Access Switch


31


MACsec Statistics in the MLXe Distribution Routers

32


Campus Distribution Layer 2 and Layer 3 Boundary Network

Campus Distribution Layer 2 and Layer 3 Boundary Network Distribution routers are the campus Layer 2 and Layer 3 boundary for the campus network. IPv4 and IPv6 VRRP-E with MCT provides switch-level redundancy. MCT CCEP ports of the distribution MCT peer are members of different community VLAN/VE interfaces. The distribution router connects to campus core routers via IPsec ports. IPsec tunnels ingress from campus distribution router IPsec ports to secure the campus Layer 3 traffic.

Campus Distribution Router MCT Campus distribution routers form the MCT peering with IPv4 and IPv6 VRRP-E to provide switch-level redundancy. Distribution router1 (C1-S1-D1) is configured as the VRRP-E master, and distribution router2 (C1-S1-D2) is configured as the VRRP-E backup. MCT with VRRP-E performs Layer 2 and Layer 3 forwarding at the first hop regardless of the VRRP-E state. The MCT peer that acts as the VRRP-E backup must ensure that packets sent to a VRRP-E virtual IP address can be L2-switched to the VRRP-E master router for forwarding. The MCT switch that acts as the master router syncs the VRRP-E MAC to the other MCT switch that acts as the backup router. Both data traffic and VRRP-E control traffic travel through the ICL unless the short-path forwarding feature is enabled. In this validated design, we use VRRP-E short-path forwarding to send traffic directly through the VRRP-E backup router rather than going through the ICL. MCT configuration on the distribution routers provides subsecond failover in the event of the link, module, switch fabric, control plane, or node failure.


33


FIGURE 14 Campus Distribution MCT Design

MCT client—An access stack switch is the MCT client. The MCT client switch connects with the MCT peer switches through a LAG. The MCT client port connected to the MCT peer CCEP port is a tag member of community VLANs in the dynamic LAG. MCT peer—Distribution routers in the campus are MCT peers. MCT peer CCEP ports are a tag member of community VLANs in the dynamic LAG. MCT Inter-Chassis Link (ICL)—Directly connected ports 2/1 and 2/2 between MCT peers are the ICL link. The ICL is a tagged Layer 2 link that carries packets for multiple community VLANs. MCT VLANs are VLANs on which MCT clients operate. Use the following steps to create the ICL link in MCT peers:

34

1.

Create an 802.3ad LAG on the ICL ports (2/1 and 2/2).

2.

Create a session VLAN, and tag the LAG ports.

3.

Create a VE with IPv4 and IPv6 addresses in the same subnet.



MCT Cluster Communication Protocol (CCP)—CCP is a Brocade proprietary protocol that provides reliable, point-to-point transport to synchronize information between peers. CCP comprises two main components: •

CCP peer management—Establishes and maintains a TCP transport session between peers.

•

CCP client management—Provides event-based, reliable packet transport to CCP peers.

MCT Cluster Client Edge Port (CCEP)—LAG ports 1/1 and 1/2 are CCEP ports in MCT peer switches (C1-S1-D1 and C1-S1-D2). CCEP ports are a tag member of community VLANs/VE. MCT VLANs—MCT clients operate on the MCT VLANs. In the validated design, community VLANs (1701, 1702) are configured member VLANs to carry community Layer 2 traffic. The distribution layer MCT peer configuration is shown in the following example.


35


Campus Distribution Router VRRP-E MLXe distribution routers are the L2 and L3 boundary in the campus distribution layer. L3 separation at the campus distribution routers is accomplished by creating a VLAN/VE on the community VLANs (e.g. 1701, 1702) and running VRRP-E on the VEs (e.g. 1701, 1702). VE interfaces are configured in different community VRFs (e.g. 1701, 1702) for Layer 3 route separation. Different priority values define the VRRP-E master and backup in the MCT peers. ARP Broadcast Resolution Campus distribution router1 (C1-S1-D1) is the VRRP-E master router, and distribution router2 (C1-S1-D2) is the VRRP-E backup router. An ARP request (a broadcast packet) from the community connected to the access switch (C1-S1-A1) is sent to the VRRP-E routers based on the hashing algorithm in the LAG. The ARP request that is sent to the VRRP-E backup (C1-S1-D2) is forwarded to the VRRP-E master (C1-S1-D1) for processing through the ICL link. Since MAC learning is disabled on the ICL link, the ARP request is not learned automatically through the ICL link. When the ARP request is received by C1-S1-D1, the reply is sent through the direct link from C1-S1-D1 to C1-S1-A1. VRRP-E Short-Path Forwarding With VRRP-E short-path forwarding, packets will bypass the VRRP-E master router and directly forward to their destination through interfaces on the VRRP-E backup router. A backup router participates in a VRRP-E session only when short-path forwarding is enabled. The following example shows the VRRP-E configuration in the campus distribution routers:

36



The show ip[v6] vrrpe brief command on the VRRP-E master and backup routers shows the IPv4 and IPv6 VRRP-E neighbors and their status.


37


Virtual Routing and Forwarding Configuration Figure 15 shows the VLAN, VE, and VRF bindings at different endpoints of the campus network. FIGURE 15 Campus VRF Routing

38



Virtual Routing and Forwarding (VRF) allows routers to maintain multiple routing tables and forwarding tables on the same router. A multi-VRF router can run multiple instances of routing protocols with a neighboring router with overlapping address spaces on different community VRF instances. In the design, each community is separated by different VRFs at the Layer 2 and Layer 3 boundary. IPsec tunnels in campus distribution routers are in different VRFs. The following example shows the VRF configurations on MCT CCEP ports in the distribution VRRP-E master and backup routers.


39


VRF OSPF Routing The OSPFv2 and v3 routing protocols run in each VRF instance in the campus distribution and border gateway routers.

40



Internet Key Exchange The following configuration is needed for Internet Key Exchange (IKEv2) in the ingress and egress endpoint of IPsec tunnels: •

IKEv2 proposal

•

IKEv2 authentication proposal

•

IKEv2 policy

•

IKEv2 profile

IPsec tunnel 601 is configured between Campus1 Site1 Distribution Router1 (C1-S1-D1) and Campus1 Site2 Distribution Router1 (C1-S2-D1). The following example shows the IKEv2 configuration for IPsec tunnel 601.


41


IKEv2 Proposal The IKEv2 proposal sets the configurable parameters that are exchanged during IKEv2 peer negotiation during phase 1. The following parameters are exchanged during the negotiation: •

Encryption algorithm

•

Integrity algorithm

•

Pseudo-Random Function (PRF) algorithm

•

Diffie Hellman (DH) group

The show ikev2 proposal 601 command displays the encryption and integrity algorithm used for IKEv2 proposal 601.

IKEv2 Authentication Proposal The local IKEv2 connection must send the local identity to the peer for authentication. All required authentication parameters for local and remote peers are configured inside this auth-proposal template. This template can be used with multiple IKEv2 profiles. This authentication proposal must be mapped to an IKE profile. For example, the same IKEv2 authentication template 601 can be used for the IPv4 (601) and IPv6 (1601) IKEv2 profile. Once a suitable IKEv2 profile is selected for an incoming IKE session, this authentication proposal is used to verify the authentication data. If a received authentication method is not specified in this proposal, authentication is assumed to have failed and action is taken accordingly.

42



IKEv2 Policy After the IKEv2 proposal is created, the auth-proposal is attached to a policy to add the proposal for negotiation. The IKEv2 policy states which security parameters are to be used to protect IKE negotiations. An IKEv2 policy must contain at least one proposal to be considered complete. In the validated design, each IKEv2 policy is created with a different IKEv2 proposal. The following example shows the IKEv2 policy parameters used for IPsec tunnel 601 in Campus 1 distribution routers from Site 1 to Site 2.

IKEv2 Profile The IKEv2 profile is used in phase 2 of the initial exchange to find out what authentication profile should be applied for the incoming IKEv2 session and which kind of local identifier should be chosen. A unique IKEv2 session has a unique set of local IP address, remote IP address, and IKEv2 profile. An IKEv2 profile applies parameters to an incoming IPsec connection identified uniquely through its match identity criteria. For an outgoing connection, the IKE profile is chosen based on the IPsec profile used by VTI. Also, based on the local IP address, the IKE policy is selected. The following output shows IKEv2 profile 601 (IPv4 ) and 1601 (IPv6) in C1-S1-D1 and C1-S2-D1 for IPsec tunnel 601. The output shows the configured local and remote identifiers and the matching identifiers. In the validated design, separate IPv4 and IPv6 profiles are used for each IPsec tunnel.


43


IKEv2 Security Association The following example shows the use of the show ikev2 sa interface command to show the details for the current security associations on the IPsec linecard in the Campus1 distribution router. Different parameters of the output show the encryption used, the authentication type, the security association (SA), and the VRF bindings.

44



Automated Public Key Infrastructure Public Key Infrastructure (PKI) configuration allows you to set up the elements for managing the keys and certificates used to identify and authenticate system requesters and essential PKI elements (such as CAs). Configuring the PKI involves the following procedures: •

Configure an entity distinguished name.

•

Create a trustpoint.

•

Create a PKI enrollment profile.

•

Configure CA authentication.

•

Generate a certificate request.

The following example shows the PKI configuration for the PKI entity in Campus1 Site1 Distribution Router1 (C1-S1-D1).


45


Configure a PKI Entity Distinguished Name A certificate is the combination of a public key and the identity information of an entity, where the CA identifies a certificate applicant (PKI entity) and the identity information using an entity distinguished name (DN). After creating the PKI entity, configure other PKI parameters such as a common name, organization unit name, organization name, state name, country name, e-mail, IP address, FQDN, and location.

46



Create a Trustpoint A trustpoint is a certificate authority (CA) that the PKI entity trusts. By trusting a given self-signed certificate, the PKI system will automatically trust any other certificates signed with that trusted certificate. Under PKI trustpoint configuration mode, configure the enrollment profile, PKI entity name, key information, and fingerprint issued by the CA server. Fingerprint information must be obtained from the CA server certificate details.

Create a PKI Enrollment Profile In the router, create a PKI enrollment profile to efficiently enroll requester systems. The PKI-entity profile configuration has the values for the parameters used to enroll requester systems. In the PKI enrollment profile, the following configuration parameters can be used: •

authentication-url url-string—CA server URL to receive the authentication requests. The URL format should be valid.

•

authentication-command url-for-ca-server-name—The HTTP command that is sent to the certification authority (CA) for authentication. Use the correct CA server name in the command (for example, IPSECCA-CA-3 in the example above). Enable HTTP web-management web-management http in the DUT for sending an HTTP request.

•

enrollment-url url-string—The URL of the CA server to receive enrollment requests. The URL format should be valid.

•

password—The password for the SCEP challenge used to revoke the requester's current certificate and issue another certificate for auto mode. This password will be generated in the Windows 2012 R2 CA server by issuing http://W2K12R2-3256/ CertSrv/mscep_admin/ in the Windows Explorer address field.

Configure CA Authentication The PKI entity router authenticates the CA by obtaining the CA self-signed certificate (this certificate contains the public key of the CA). The CA signs its own certificate. The PKI entity should manually authenticate the public key of the CA by contacting the CA administrator when the pki authenticate command is issued. The certificate obtained from the CA is saved to the router. Enter the pki authenticate trustpoint-name command to configure CA authentication.


47


Generate a Certificate Request After the PKI entity is authenticated successfully, the PKI entity router requests certificates from the CA (trustpoint) to be added to each key pair of the router. This enrolls the router on the CA trustpoint. The CA server will manually issue or deny any pending certificate requests. From the router, use the single command pki enroll trustpoint to request the certificate. Note that the certificates are saved to the router, but the command is not saved in the running configuration.

To check the generated public key, issue the following command:

To see the generated certificates, issue the following commands:

48




49


Windows 2012 R2 CA Server In the validated design, a Windows 2012 R2 server is used as the CA server to issue the digital certificate. In the Windows 2012 R2 server, install Active Directory Certificate Services (AD CS) and configure the NDES for Simple Certificate Enrollment Protocol (SCEP). Network Device Enrollment Service (NDES) is one of the role services of AD CS in Windows 2012 server that implements SCEP. SCEP defines the communication between network devices and a CA for managing secure certificate enrollment. Online Certificate Status Protocol (OCSP) is used to obtain the revocation status of an x.509 digital certificate. Certificate revocation lists (CRLs) are another method of obtaining the certificate revocation list from the CA server. After the CA server is configured with SCEP, generate the PKI profile enrollment password from the CA server. This generated password is configured under PKI profile-enrollment. The issued certificate thumbprint information from the CA server is used as the fingerprint under the PKI trustpoint. Using the password and fingerprint, PKI entities are authenticated and enrolled to the CA server.

NOTE The fingerprint information must be copied from the CA server issued certificate thumbprint, as shown below.

50



Each PKI entity in the network requests a certificate from the CA server for authentication and encryption. The CA server issues the certificate for those requests with a valid life span.

To see the attribute of the certificate in the Windows CA server, click the issued certificate and right-click open and go to the details of the certificate to verify the following information: •

Serial Number—To identify the certificate.

•

Subject—Entity information.

•

Signature Algorithm—The algorithm used to create the signature, such as sha384ECDSA.

•

Signature Hash Algorithm—The hash algorithm used to create the signature, such as sha384.

•

Issuer—The entity that verified the information and issued the certificate.

•

Valid-From—The date the certificate is valid from.

•

Valid-To—The date the certificate expires.

•

Key-Usage—Purpose of the public key, such as Digital Signature, Encipherment.

•

Public Key—The public key.

•

Thumbprint Algorithm—The algorithm used to hash the public key certificate, such as Sha1.

•

Thumbprint/fingerprint—The hash of the public key certificate.

The following figure shows an example of the certificate issued to entity C1-S1-A1 in the Windows CA server.


51


Online Certificate Status Protocol Online Certificate Status Protocol (OCSP) is one of the methods for maintaining the security of a server and other network resources. When a certificate is being revoked, OCSP sends the updated revocation list to the PKI entities automatically. When a user attempts to access a server, OCSP sends a request for certificate status information. The OCSP responder in the CA server sends back a response with certificate validity to the PKI entity. For OCSP, configure the following under the PKI trustpoint in the Brocade MLXe router:

Certificate Revocation List A certificate revocation list (CRL) is another common method of managing revoked certificates from the CA server. Revoked certificates are published in an HTTP or LDAP repository in the Windows CA server. The CRL Distribution Points (CDP) field is located in each certificate. The following example shows the CDP values in a certificate issued by the Windows 2012 CA server. In this case, the CRL has two distribution points, one available using an LDAP server and another stored on an HTTP server.

52



CRL configuration example under PKI trustpoint:

X.509 v3 Certificates X.509 v3 certificates are supported in Brocade routers. This validated design uses OpenSSL to create manual certificates. Download and install OpenSSL for Windows, and issue the following commands to generate the root CA and the router certificate.


53


Once a manual CA certificate is created, open the CA certificate to see different attributes. Thumbprint information from the CA (shown below) must be configured in PKI profile enrollment.

54



Download (using the tftp copy flash x.x.x.x command) the manually generated certificates to the router's flash. Once the certificates are copied into flash, configure the PKI entity and the trustpoint with the correct fingerprint information from the CA certificate, as shown below.


55


Once the PKI entity is created with the trustpoint, configure the IKEv2 authentication proposal to use the manual key for signing and verification.

56



IPsec Tunnel Configuration To configure the IPsec tunnel in each VTI endpoint router, create the following: •

IPsec proposal

•

IPsec profile

IPsec Proposal An IPsec proposal specifies the IPsec encryption parameters. It contains the ESP method to be used for IPsec peer negotiation. One of two types of encryption method can be used—aes-gcm-128 and aes-gcm-256 (default)—in both the tunnel ingress and egress point. The IPsec proposal is linked to an IPsec policy. The following example shows the IPsec proposal for tunnel 601 between C1-S1-D1 and C1-S2-D1.

IPsec Profile An IPsec profile defines the IPsec parameters used for encryption between two IPsec-enabled Brocade devices. The IPsec profile must be attached to an IPsec tunnel (VTI) to create a child SA. Each IPsec profile needs an IPsec proposal number defined. Otherwise, it uses the default IPsec proposal. If there is no IKEv2 peer, attaching the IPsec profile to the VTI should initiate a new IKEv2 session. If there is an existing IKEv2 peer, a new child SA should be created. The following is output from the show ipsec profile command for the VTI 601 configuration between C1-S1-D1 and C1-S2-D1.


57


IPv4 and IPv6 IPsec Tunnel Configuration Brocade supports IPv4 and IPv6 IPsec tunnel configuration. The tunnel mode command under the IPsec tunnel configuration is used to define the IPv4 or IPv6 tunnel mode. IPv4 and IPv6 addressing must be used for the IPv4 and IPv6 IPsec tunnel, respectively. In this validation design, end-to-end IPv4 and IPv6 IPsec tunnels transport IPv4 and IPv6 traffic simultaneously. The following example shows the IPv4 tunnel 601 and IPv6 tunnel 1601 configuration in campus distribution routers. IPsec tunnels are running in different VRFs with IPv4 and IPv6 OSPF routing protocols to exchange different community routes.

58


Campus Core Routing

Campus Core Routing FIGURE 16 Campus Core Architecture

These core routers are running OSPFv2 and v3 protocols in the default VRF to form OSPF neighbors and exchange IPv4 and IPv6 routes. Once the IPsec tunnel source and destination routes are learned via the campus core routing, bring up the IPsec tunnels. IPsec


59

Campus Core Routing

tunnels in community VRFs are configured with OSPFv2 and v3 routing. The following example shows the OSPFv2 and v3 neighbors that are formed between the core routers and the campus distribution routers.

60


Campus IPsec Tunnel Design

Campus IPsec Tunnel Design FIGURE 17 Campus IPv4 and IPv6 Full-Mesh IPsec Tunnel Design

IPv4 and IPv6 IPsec tunnels between distribution routers and the distribution to border gateway routers secure Layer 3 routing in the campus network. Each IPsec tunnel is bound to different VRFs with IPv4 and IPv6 OSPF routing protocols. IPsec tunnels between distribution and border gateway routers are used in case IPsec tunnels between distribution routers go down. The campus distribution to core router link can be part of the dynamic LAG to increase bandwidth. Multiple VE interfaces are configured on the physical link between the campus distribution and core router. These VE interfaces are used as the IPv4 and IPv6 IPsec tunnel source and destination. The following example shows the IPsec tunnel configuration from Campus Site1 distribution MCT peer routers to the Campus Site2 distribution router. •

IPsec tunnel 601 and 1601 are configured from Campus1 Site1 Distribution Router1 to Campus1 Site2 Distribution Router1.

•

IPsec tunnel 701 and 1701 are configured from Campus1 Site1 Distribution Router2 to Campus1 Site2 Distribution Router1.

•

IPsec tunnel 601, 701, 1601, and 1701 are configured from Campus1 Site2 Distribution Router1 to Campus1 Site1 MCT Peer Distribution Router1 and Router2.


61


62



Once the IPv4 and IPv6 IPsec tunnels are up, the VRF routing table in campus distribution routers will have the remote community route learned via the IPsec tunnel. 10.171.1.0/24 and 2002::/64 are the IPv4 and IPv6 community network connected to Campus1 Site2. The following example shows that these routes are reachable via IPsec tunnel 601 (IPv4 ) and 1601 (IPv6), respectively, from Campus 1 Site1 Distribution Router1.


63


10.170.1.0/24 and 2001::/64 are the IPv4 and IPv6 community network connected to Campus1 Site1. The following example shows that these routes are reachable via IPsec tunnel 601 (IPv4 ) and 1601 (IPv6), respectively, from Campus 1 Site2 distribution routers.

64



Campus Distribution Router to Campus Border Gateway IPsec Tunnel IPv4 and IPv6 IPsec tunnels in each community VRF are created from campus distribution routers to campus border gateway routers. These IPsec tunnels are used for traffic handoff from the campus to the campus border gateway routers. These IPsec tunnels can be used as an alternative path if the directly configured IPsec tunnels go down for any reason. The following example shows the IPsec tunnel configuration between campus distribution routers and distribution to border gateway routers. IPv4 and IPv6 IPsec Tunnel Configuration from Campus1 Site1 Distribution Routers to Campus1 Border Gateway


65


IPv4 and IPv6 IPsec Tunnel Configuration from Campus1 Site2 Distribution Routers to Campus1 Border Gateway

66



IPv4 and IPv6 IPsec Tunnel from Campus1 Border Gateway to Campus1 Site1 and Site2 Distribution Routers


67


68


Campus Site-to-Site Connectivity

Campus Site-to-Site Connectivity Figure 18 shows the packet encapsulation for campus site-to-site interconnectivity. FIGURE 18 Campus MACsec and IPsec Packet Flow

The following shows the secure packet flow across the campus core network: •

Access—Different communities are attached to access stack switches. Each community is separated by different VLANs in the access switch. In the design, the access switch is an MCT client switch. MCT client ports facing the MCT peer distribution routers are LAG (for increased bandwidth) interfaces. MACsec is configured on the links between the MCT client and MCT peers to secure Layer 2 traffic from different communities. Ingress MACsec packets are encrypted in the physical port of the MCT client and are then decrypted in the physical port of the MCT peer CCEP where MACsec is configured.

•

Distribution—Campus distribution routers are the Layer 2 and Layer 3 boundary for the campus network. VE interfaces are configured in MCT CCEP ports for Layer 2 to Layer 3 mapping. VRFs are configured on these VEs to separate different community traffic. Access to distribution router connections are secured by the MACsec Layer 2 encryptions. MCT with VRRPE configured in distribution routers provide switch level redundancy. VRRP-E VRID is the default gateway for communities connected to campus access switch.

•

Campus core—The campus core essentially consists of core routers and border gateway routers connected to campus distribution routers. The campus core uses IPv4 and IPv6 OSPF routing in the default VRF to exchange IPsec tunnel source and distribution routes from distribution routers.

•

IPsec tunnels—Once the campus core routing is up and the IPsec tunnel source and destination routes are learned among the distribution routers and the border gateway routers, bring up IPv4 and IPv6 IPsec tunnels for secure Layer 3 traffic within the campus. VRFs configured on IPv4 and IPv6 IPsec tunnels separate different community traffic. The following example shows the VRF (1701) binding on the VRRP-E interface and IPsec tunnel 601 (Campus1 Site1 Distribution1 to Campus1 Site1 Distribution2).


69


Bidirectional IPv4 and IPv6 IPsec tunnels are configured between campus distribution routers. The following example shows the IPsec tunnels created from C1-S1-D1 to C1-S2-D1.

70



Bidirectional IPsec tunnels from campus distribution to the campus border gateway hand off the secure Layer 3 traffic to the border gateway router. In Campus1 Site1 Distribution Router1 (C1-S1-D1), packets ingress to IPsec tunnels are encrypted and sent to the IPsec tunnel destination in Campus1 Site2 Distribution Router (C1-S2-D1), where they are decrypted and forwarded as IP packets to VE interfaces toward the access switch. IPv4 and IPv6 packets traverse the campus core as encrypted packets. Site-to-site connectivity is achieved for separate communities over IPsec tunnels. The following example shows the routing table in Campus1 Site1 Distribution Router1 for two different community VRFs (VRF 1701 and VRF 1702).


71

Enterprise WAN Network

NOTE To bring up the IPsec tunnel, use IPsec ports in campus distribution routers that are connected to core and border gateway routers. Campus core router connections to distribution can be made with non-IPsec 10G ports.

Enterprise WAN Network Enterprise WAN components are campus border gateway routers (C1-BGW, C2-BGW) and SP-Core routers. Border gateway routers are PE (provider edge) routers, and the SP-Core routers are P (provider) routers. In campus border gateway routers, MPLS uplinks (configured on the VE interfaces) are 10G non-IPsec ports. The SP-Core connections are non-IPsec 10G ports. Between the campus border gateway routers, bidirectional IPv4 and IPv6 IPsec tunnels in different VRFs are configured to forward Layer 3 secured encrypted data. To bring up Brocade IPsec tunnels, IPsec ports are needed in the ingress and egress. Since the campus enterprise WAN is running on the non-IPsec ports, a physical loopback between the IPsec 10G port and non-IPsec 10G ports is needed in each campus border gateway router. The following section describes the configuration required in the campus border gateway routers and the SP-Core. Enterprise WAN IP Protocols The enterprise WAN consists of the campus border gateway routers and the SP-Core routers. In the validated design, IS-IS (v4 and v6) is configured as the enterprise WAN IGP routing protocol. The following example shows the IS-IS neighbors formed in the enterprise WAN routers.

72


Enterprise WAN Network

Enterprise WAN MPLS Signaling In the validated design, Label Distribution Protocol (LDP) is used as the MPLS signaling protocol. Enable LDP on all MPLS interfaces of enterprise WAN component routers (C1-BGW, C2-BGW, and SP-Core). Alternatively, RSVP signaling can be used; in which case, bidirectional MPLS RSVP tunnels would need to be created between campus border gateway routers. The following example shows the MPLS configuration running in the enterprise WAN routers:


73

Campus Border Gateway Router IPsec-to-Non-IPsec Port Physical Loopback

The following example shows the LDP neighbors formed in the enterprise WAN routers.

Campus Border Gateway Router IPsec-to-Non-IPsec Port Physical Loopback Since the MPLS uplink is on the non-IPsec ports, configure a physical loopback on both campus border gateway routers from IPsec port to non-IPsec port. The IPv4 or IPv6 address configuration on the IPsec port of the physical loopback is used as the IPv4 and IPv6 IPsec tunnel source and destination created between the campus border gateway routers.

74


Enterprise Interconnect Across Enterprise WAN—Connectivity Methods

Enterprise Interconnect Across Enterprise WAN— Connectivity Methods Enterprise interconnect across enterprise WAN connectivity can be done with following three different methods: •

L2VPN VLL

•

L2VPN VPLS

•

L3VPN

Enterprise Interconnect Across the Enterprise WAN—L2VPN VLL Once the enterprise WAN IP routing (IS-IS) and MPLS signaling are up, perform the following steps for enterprise interconnect across the enterprise WAN via L2VPN VLL. FIGURE 19 Enterprise Interconnect Across the Enterprise WAN—L2VPN Design


75


On both campus border gateway routers (C1-BGW and C2-BGW): 1.

Configure IPsec port 1/3 (of the physical loopback) as a tag member of the L2 VLAN/VEs (e.g. 1201). Each VE IP address will be used as a different IPsec tunnel source and destination.

2.

Configure non-IPsec port 2/3 (of the physical loopback) as a tag member of the VLL VLAN. The VLL VLAN tag should be the same as the Layer 2 VLAN tag configured on the IPsec port (e.g. 1201).

3.

Configure and bring up the VLL peers between C1-BGW and C2-BGW on the loopback interface.

4.

VLL peers will come up over the MPLS enterprise WAN network, which is running IS-IS for IGP routing.

5.

Once the VLL peers are up, create an IPsec tunnel (e.g. tunnel 901) on the community VRF (e.g. VRF 1701) to carry community traffic over the L2VPN.

6.

For multiple community VRF traffic, tag multiple native VLANs (e.g. 1201, 1202) on the IPsec port of the physical loopback, and match them with tagged VLL VLANs (e.g. 1201, 1202) on the non-IPsec port of the physical loopback. Create multiple VLL peers between the campus border gateway routers. Once the VLL peers are up, configure multiple IPsec tunnels with matching community VRFs. For example: a.

Map IPsec port 1/3 to native VLANs 1201 to 1230.

b.

Map non-IPsec port 2/3 to VLL VLANs 1201 to 1230.

c.

Create IPsec tunnel 901 to 930 (for IPv4 ) and 1901 to 1930 (for IPv6) between the campus border gateway routers.

d.

Bind each IPsec tunnel to different VRFs (1701 to 1730) to carry community encrypted traffic.

e.

Run OSPFv2 and PIM-SM on each IPv4 IPsec tunnel to carry community IPv4 and multicast traffic.

f.

Run OSPFv3 on each IPv6 IPsec tunnel to carry community IPv6 traffic.

The following example show the C1-BGW and C2-BGW router configuration for L2VPN VLL.

76




77


The following example shows the VLL peer information and the routing table for VRF 1701 when IPsec tunnel 901 on VRF 1701 (configured between campus border gateway routers) is up. 10.172.1.0/24 routes (community connected in the Campus2 Site1 access switch) in the Campus1 border gateway router show reachability through IPsec tunnel 901.

78



Enterprise Interconnect Across the Enterprise WAN—L2VPN VPLS For L2VPN VPLS, change the VLL neighbor configuration to VPLS neighbors and put the non-IPsec port of the physical loopback as a tag member of the VPLS VLANs shown below. The IPsec tunnel configuration will be same as shown above in the VLL configuration example.


79


80



Enterprise Interconnect Across the Enterprise WAN—L3VPN FIGURE 20 Enterprise Interconnect Across the Enterprise WAN—L3VPN Design

Once the Enterprise WAN IP (IS-IS) and the MPLS signaling are up, perform the following steps for enterprise interconnect via L3VPN. 1.

Configure the IPsec port of the physical loopback into the VRF L3VPN_transport running OSPFv2 and v3, and configure the non-IPsec port of the physical loopback into the VRF L3VPN_Forwarding running OSPFv2 and v3. Physical loopback endpoints in different VRFs will form the OSPFv2 and v3 adjacency.

2.

Create loopback interfaces under VRF_transport, which will be used as the IPv4 and IPv6 IPsec tunnel source and destinations addresses.

3.

Bring up the IPv4 and IPv6 iBGP neighbor between campus border gateway routers.

4.

The enterprise WAN network is running IS-IS as the IGP and MPLS signaling as the transport.

5.

Configure L3VPN routing in VRF L3VPN_Forwarding between campus border gateway routers to exchange the L3VPN routes via MPLS LDP or RSVP.


81


6.

Under VRF L3VPN_transport, create static routes for reachability of the remote campus's L3VPN_transport loopback addresses and the network address. The remote side loopback addresses will be used as the IPv4 and IPv6 IPsec tunnel destination addresses.

7.

Bring up the IPv4 and IPv6 IPsec tunnels in the community VRFs (e.g. 1701, 1702, ...). The tunnel source and destination would be the local loopback addresses (in VRF L3VPN_transport) and the remote campus side's loopback (in VRF L3VPN_transport).

8.

IPv4 IPsec tunnels will be configured with OSPFv2 and PIM-SM to carry IPv4 and multicast traffic. IPv6 IPsec tunnels will be configured with OSPFv3 to carry IPv6 traffic.

9.

Once the IPsec tunnels are up, the community VRF routing table will have reachability to different enterprises through L3VPN via a secured IPv4 and IPv6 IPsec tunnel.

In the following example, the above steps are described with configuration details. In both the C1-BGW and C2-BGW routers, configure:

82

1.

Configure IPsec port 1/4 (of the physical loopback) into VRF L3VPN_transport with OSPFv2 and v3.

2.

Configure non-IPsec port 2/5 (of the physical loopback) into VRF L3VPN_Forwarding with OSPFv2 and v3.

3.

Create loopback interfaces under VRF_transport. These loopback addresses are used as the IPv4 and IPv6 IPsec tunnel source and destinations.



4.

Bring up IPv4 and IPv6 iBGP neighbor between campus border gateways (C1-BGW and C2-BGW).

5.

Configure the IPv4 and IPv6 address family on VRF L3VPN_Forwarding between the campus border gateway routers to form L3VPN over the MPLS enterprise WAN.


83


6.

84

Once the L3VPN routing on VRF L3VPN_Forwarding is up between campus border gateway routers, the VRF L3VPN_Forwarding routing table will show the routes learned from the campus border gateway routers by BGP via LDP transport. Local loopback interfaces created under VRF L3VPN_transport will be learned via OSPF.



7.

To create the IPsec tunnel, the remote loopback interface addresses learned from the remote campus border gateway router must be reachable in VRF L3VPN_transport. To achieve this under VRF L3VPN_transport, create static routes for the remote campus's VRF L3VPN_transport loopback addresses and the network address. The remote side's loopback addresses are used as the IPv4 and IPv6 IPsec tunnel destination addresses.

8.

Once the static routes are configured, the VRF L3VPN_transport routing table will have the reachability information of the remote campus VRF L3VPN_transport loopback and network. Note that the outgoing port is the IPsec port of the physical loopback.


85


9.

Now bring up the IPv4 and IPv6 IPsec tunnels on the transport VRF L3VPN_transport for different community VRFs (e.g. 1701, 1702, ...) with the tunnel source as the local loopback addresses and the destination as the remote side's loopback addresses created under VRF L3VPN_transport. Under the IPsec tunnel, configure the tunnel vrf L3VPN_transport command since the tunnel source is under the VRF L3VPN_transport. IPv4 IPsec tunnels with OSPFv2 and PIM-SM are configured to transport IPv4 and multicast traffic. An IPv6 IPsec tunnel with OSPFv3 is configured to transport IPv6 traffic.

10. Once the IPsec tunnels are up, the community VRF routing table will have reachability to different enterprises through L3VPN via secured IPv4 and IPv6 IPsec tunnels. Packet Forwarding

86


Remote Branch Campus Internet Connectivity

Community VRF IPv4 and IPv6 packets will be encapsulated in the IPsec tunnel ingress (the IPsec port of the physical loopback) with an IPsec header and will be forwarded to the non-IPsec port of the physical loopback via a static route. The IPsec packets will be encapsulated with an MPLS header at the MPLS uplink and will be forwarded to the remote campus border gateway router, where the MPLS header will be stripped off (at the remote campus border gateway router's MPLS uplink) and will be forwarded with an IPsec header to the non-IPsec port of the physical loopback and eventually to the IPsec tunnel egress (the IPsec port of the physical loopback). Here the IPsec header is stripped and forwarded as a regular IP packet in the respective community VRFs. In the following example, routes learned from the remote campus border gateway (C2-BGW) via L3VPN are highlighted. These routes shows that the outgoing port is configured as an IPsec tunnel.

Remote Branch Campus Internet Connectivity Remote campuses can be connected to the campus border gateway routers via IP connectivity for Internet reachability. Remote Branch Connectivity via IP


87


Remote campus branches are connected to campus border gateway routers through the Internet. Bidirectional IPsec tunnels on the community VRFs are created on the IPsec port (of the physical loopback) in campus border gateway routers. FIGURE 21 Remote Branch Campus Connection Through the Internet

Once the Internet connection is up, perform following steps to connect the remote branches:

88

1.

Configure the IPsec port of the physical loopback as a member of VRF Internet_transport running OSPF, and configure the non-IPsec port of the physical loopback as a member of the default VRF running OSPF. The two ends of the physical loopback form the OSPF adjacency.

2.

Create loopback interfaces under VRF Internet_transport, which are used as the IPsec tunnel source and destination. These loopback interfaces are learned in the default VRF via the OSPF protocol.

3.

The Internet WAN network runs BGP. Redistribute OSPF into BGP in the campus border gateway routers so that the local loopbacks in VRF Internet_transport are learned on the remote campus border gateway routers.

4.

Create static routes under VRF Internet_transport so that the configured remote campus's loopback addresses in VRF Internet_transport have reachability from VRF Internet_transport.



5.

Now create bidirectional IPv4 and IPv6 IPsec tunnels between the campus border gateway routers with the loopback addresses in VRF Internet_transport as the tunnel source and destination. An IPsec tunnel is configured for different community VRFs (e.g. 1701, 1702, ...) to transport VRF community traffic.

6.

Internet routes in the default VRF must be leaked into community VRF IPv4 and IPv6 address families for reachability. For leaking, configure "route-map r2" to permit all routes from the default routing table to community VRF 1701.

In the following example, the preceding steps are described with configuration details. In both the C1-BGW and C2-BGW routers: 1.

Configure IPsec port 1/8 (of the physical loopback) as a member of VRF Internet_transport running OSPF.

2.

Configure non-IPsec port 2/8 (of the physical loopback) as a member of the default VRF running OSPF.

3.

An OSPF neighbor is formed between the non-default VRF Internet_transport port 1/8 and the default VRF port 2/8.


89


90

4.

Create loopback interfaces under VRF Internet_transport. These loopback addresses are used as the IPsec tunnel source and destination.

5.

The local non-default VRF Internet_transport loopback addresses are learned in the default VRF via OSPF. Those routes are redistributed to the remote border GW routers via BGP.

6.

To create the IPsec tunnel between the campus border gateway routers, remote loopback interface addresses must be learned in the non-default VRF Internet_transport. To achieve this, create static routes under the VRF Internet_transport for remote loopback in VRF Internet_transport.



7.

The static routes are configured in VRF Internet_transport to have reachability to the remote campus border gateway router's loopback addresses (configured under VRF Internet_transport). These loopback addresses are used as the IPsec tunnel source and destination. The following shows the routing table for VRF Internet_transport in both campus border gateway routers.

8.

Create bidirectional IPv4 and IPv6 IPsec tunnels between the campus border gateway routers with the local and remote loopback addresses in VRF Internet_transport as the tunnel source and destination. The IPsec tunnels are configured for different community VRFs (e.g. 1701, 1702, ...). Under the IPsec tunnels, configure the tunnel vrf Internet_transport command since the tunnel source is configured under VRF Internet_transport. IPv4 IPsec tunnels with OSPFv2 and PIM-SM


91


transport IPv4 and multicast traffic. The IPv6 IPsec tunnels with OSPFv3 transport IPv6 traffic. The following example shows the IPsec tunnel configuration in campus border gateway routers.

9.

92

Internet routes in the default VRF must be leaked into community VRF IPv4 and IPv6 address families for reachability. For leaking, configure route-map r2 to permit all routes from the default routing table to community VRF 1701.


Secure IPsec Traffic Forwarding

10. In the campus border gateway routers, the community VRF (e.g. 1701) routing table shows the Internet routes. Note that srcvrf is showing as the default-vrf for the leaked default VRF route (XX.0.0.0/24) in community VRF 1701.

Packet Forwarding Community VRF IPv4 and IPv6 packets are encapsulated in the IPsec tunnel ingress (the IPsec port of the physical loopback) with an IPsec header and are forwarded to the non-IPsec port of the physical loopback via a static route. The IPsec packets are forwarded to the remote campus border gateway router's non-IPsec port of the physical loopback. Finally, the packets reach the IPsec tunnel egress (the IPsec port of the physical loopback), where the IPsec header is stripped and the packets are forwarded as regular IP packets in different community VRFs.

Secure IPsec Traffic Forwarding For traffic from Campus 1 to Campus 2, Layer 3 traffic is forwarded as follows: •

Campus access to distribution Layer 2 traffic is secured by MACsec.


93

Secure IPsec Traffic Forwarding

•

In Campus 1, community VRF traffic destined to Campus 2 is encrypted into an IPsec tunnel from campus distribution routers to the Campus1 border gateway router.

•

Traffic is decrypted in the Campus1 border gateway router and is forwarded via the IPsec tunnel ingress (the IPsec port of the physical loopback) configured in the same community VRF. Traffic is encrypted again into an IPsec tunnel from the Campus1 border gateway routers to the Campus2 border gateway router through the enterprise WAN.

•

Transport in the enterprise WAN can be L2VPN (VLL or VPLS), L3VPN, or Internet. IPsec traffic is MPLS label-switched in the case of the MPLS network.

•

In the Campus2 border gateway router, traffic is decrypted at the tunnel egress (the IPsec port of the physical loopback). Regular IP traffic is forwarded to the IPsec ports (facing the campus core) in community VRFs. IP traffic is encrypted again in the configured tunnel ingress between the Campus2 border gateway router and the Campus2 distribution router.

•

In the Campus2 distribution router IPsec tunnel egress, traffic is decrypted and forwarded to an access switch with a secure MACsec Layer 2 connection.

IPv4 Traffic Path for the Campus Across the Enterprise Core/Aggregation The following IPv4 traceroute output shows the traffic forwarding path from the Campus1 Site1 Distribution1 router to IPv4 clients connected to the Campus1 Site2 Distribution1 router.

IPv6 Traffic Path for the Campus Across the Enterprise Core/Aggregation The following IPv6 traceroute output shows the traffic forwarding path from the Campus1 Site1 Distribution1 router to IPv4 clients connected to the Campus1 Site2 Distribution1 router.

94


Multicast on IPv4 IPsec Tunnels

IPv4 Traffic Path for the Enterprise Interconnect Across the Enterprise WAN The following IPv4 traceroute output shows the traffic forwarding path from the Campus1 Site1 Distribution1 router to the IPv4 clients connected to the Campus2 Site1 Distribution1 router.

IPv6 Traffic Path for the Enterprise Interconnect Across the Enterprise WAN The following IPv6 traceroute output shows the traffic forwarding path from the Campus1 Site1 Distribution1 router to the IPv6 clients connected to the Campus2 Site1 Distribution1 router.

Multicast on IPv4 IPsec Tunnels Brocade currently supports multicast IPv4 traffic over IPv4 IPsec tunnels only. Multicast IPv6 traffic over IPv6 IPsec tunnels is not currently supported. Figure 22 shows the multicast traffic flow for following three cases: •

Campus across the enterprise core/aggregation

•

Enterprise interconnect across the enterprise WAN

•

Internet

In the following example, the multicast source is connected to Campus1 Site2, and the multicast clients are connected to Campus1 Site1, Campus2 Site1, and the remote branch site. The PIM-SM protocol must be running in all VRF interfaces, such as IPsec tunnel endpoints (ingress/egress) and distribution router VRRP-E VE interfaces. A static RP address is used under the PIM-SM community


95


VRF instance in all campus distribution and border gateway routers. In the access switch, IGMP must be enabled for all community VLANs. FIGURE 22 Multicast IPsec Design

Multicast clients send IGMP join requests for the multicast groups that are sending multicast data. The access switch forwards the join requests to PIM-SM enabled distribution routers. Once the (*,G) (S,G) multicast cache entry is created in PIM-SM community VRFs in the distribution routers, traffic is forwarded to the multicast clients. The multicast traffic path uses the same hop-by-hop paths as the IPv4/ IPv6 traffic. Multicast traffic from access to distribution is secured by MACsec. Multicast traffic between the distribution routers within the campus is secured by IPsec. Multicast traffic between the distribution router and the border gateway routers within the campus is secured by IPsec. Between campus border gateway routers, multicast traffic is secured by IPsec across the enterprise WAN or Internet.

IGMP on the Campus Access Switch In the campus access, configure IGMP globally and at the community VLAN level. By default, IGMP passive mode is enabled. The multicast source is connected to the Campus1 Site2 Access switch.

96



PIM-SM Protocol in the Campus Distribution and Border Gateway Routers A distribution router acts as the Layer 2 and Layer 3 boundary for PIM-SM. Community VLANs are mapped to the VE interface running the MCT with VRRP-E. Different communities are separated by running VRFs on those VEs. The following must be configured in distribution routers and campus border gateway routers. •

Configure PIM-SM globally for each PIM-SM community VRF instance.

•

Configure the RP address under the PIM-SM VRF instances.

•

Configure PIM-SM in the IPsec tunnel endpoints.

The following example shows the PIM-SM configuration in the campus distribution router where the multicast source is connected.


97


The following example shows the PIM-SM configuration in the Campus1 distribution routers (VRRP-E master and backup). The border gateway routers IPsec tunnels ingress toward Campus1 Site2 (the multicast source). Similarly, configure PIM-SM in IPsec tunnel endpoints in the campus border gateway and the distribution routers.

98



IGMP show Commands In the access switch from which the clients send the multicast join requests, verify that the mcache (*,G) entries are created correctly and show the correct outgoing port (OIF).


99


In the community distribution routers, issue the VRF-specific commands show ip igmp vrf vrf-num group to verify the IGMP group address and that the interfaces are learned correctly.

PIM-SM show Commands In PIM-SM enabled distribution routers, issue the following community-VRF-specific show commands to verify the RP, mcache, and OIF entries. In the following example, in Campus1 Site1 distribution routers (where clients are connected), it is shown that for community VRF 1701, the RP and mcache entries are learned correctly. The show ipsec statistics tunnel command shows the multicast traffic that uses the IPsec tunnel interface.

100




101

102


Layer 2 Data Center Interconnect (DCI) Geographically distributed data centers allow companies to provide high-performing, continuous access to mission-critical business applications at a reduced cost. The Brocade DCI solution extends Layer 2 connectivity across distributed data centers. Figure 23 shows the solution architecture where two Layer 2 enterprise data centers are connected through the MPLS/VPLS. FIGURE 23 Campus MPLS/VPLS Network to Transport Layer 2 VPLS Traffic

In this design, the enterprise data center (DC) sites are connected via MPLS VPLS pseudo wires. Communities connected to the data centers are separated by Layer 2 VLANs in access switches. The Layer2 data path between access switches and distribution routers is secured with Layer2 MACsec. In this design, endpoints in distribution routers are configured in different VPLS VLAN instances for different community VLANs. In distribution PE routers, configure MCT to allow switch-level redundancy. VPLS PW along with MCT is configured between the data center distribution routers. Note: In this design, there is no IPsec tunnel configured in the campus MPLS core. The following are the steps to connect the campus sites with VPLS. In both campus Site1 and Site2, configure the following: 1.

Configure the campus MPLS WAN core.

2.

Configure campus distribution routers as the MCT peers.

3.

Configure distribution router (PE) endpoints as the VPLS VLANs.

4.

MAC learning and Layer2 traffic for different communities from campus Site1 to Site 2 will be forwarded by the VPLS pseudowire in the campus core.

In the following example, the above steps are described with configuration details. 1.

Configure the campus MPLS WAN core.


103

Configure all the MPLS uplinks in the data center Site1 and Site2 distribution routers (PEs) and the MPLS cores C1-Core1, C1-Core2, and C1-BGW (P routers). LDP is running on the MPLS interface to show the neighborship in the MPLS routers below. C1-S1-D1# sh mpls ldp nei Number of link neighbors: 1 Number of targeted neighbors: 2 Nbr Transport Interface 10.3.3.3 ve10 10.2.2.2 (targeted) 10.5.5.5 (targeted) C1-S1-D1# C1-S1-D2# sh mpls ldp nei Number of link neighbors: 1 Number of targeted neighbors: 2

Nbr LDP ID 10.3.3.3:0 10.2.2.2:0 10.5.5.5:0

Max Hold 15 45 45

Time Left 12 36 38

Nbr Transport 10.3.3.3 10.1.1.1 10.5.5.5 C1-S1-D2#

Nbr LDP ID 10.3.3.3:0 10.1.1.1:0 10.5.5.5:0

Max Hold 15 45 45

Time Left 12 35 42

Nbr Transport Interface 10.1.1.1 ve10 10.2.2.2 ve11 10.6.6.6 ve14 C1-Core1# C1-Core2# sh mpls ldp nei Number of link neighbors: 2 Number of targeted neighbors: 0

Nbr LDP ID 10.1.1.1:0 10.2.2.2:0 10.6.6.6:0

Max Hold 15 15 15

Time Left 14 14 12

Nbr Transport Interface 10.5.5.5 ve13 10.6.6.6 ve15 C1-Core2# C1-S2-D1# sh mpls ldp nei Number of link neighbors: 1 Number of targeted neighbors: 2

Nbr LDP ID 10.5.5.5:0 10.6.6.6:0

Max Hold 15 15

Time Left 14 14

Nbr Transport Interface 10.4.4.4 ve13 10.1.1.1 (targeted) 10.2.2.2 (targeted) C1-S2-D1# C1-BGW# sh mpls ldp nei Number of link neighbors: 3 Number of targeted neighbors: 1

Nbr LDP ID 10.4.4.4:0 10.1.1.1:0 10.2.2.2:0

Max Hold 15 45 45

Time Left 13 31 36

Nbr Transport 10.3.3.3 10.4.4.4 10.9.9.9 10.7.7.7 C1-BGW#

Nbr LDP ID 10.3.3.3:0 10.4.4.4:0 10.9.9.9:0 10.7.7.7:0

Max Hold 15 15 15 45

Time Left 13 14 12 31

Interface ve11 (targeted) (targeted)

C1-Core1# sh mpls ldp neighbor Number of link neighbors: 3 Number of targeted neighbors: 0

2.

Interface ve14 ve15 ve16 (targeted)

Configure campus distribution routers as the MCT peers. Configure the MCT peers in both data center Site1 and Site2 distribution routers. The L2VPN peer is configured as the loopback address of the MCT peer to form the MCT L2VPN peers. The following example shows the configuration and the state of the MCT peer in the data center site1 distribution routers. A similar MCT configuration is required in the distribution routers in Site2 of the data center.

104


C1-S1-D1# show cluster Cluster c1 1 ============ Rbridge Id: 100, Session Vlan: 0 Cluster State: Deploy Client Isolation Mode: Loose Configured Member Vlan Range: Active Member Vlan Range: Total Clients Configured : 1 ( Deployed Clients: 1) L2VPN Peer Info: --------------Peer IP: 10.2.2.2, Peer Rbridge Id: 200 KeepAlive Interval: 300 , Hold Time: 900 Node KeepAlive Interval: 2000 , Hold Time: 6000 l2vpn-revertible-timer 300 Peer State: CCP Up (Up Time: 0 days: 1 hr: 6 min:34 sec) Client Info: -----------Name icx1 C1-S1-D1#

Rbridge-id 10

Config Deployed

Port 1/1

Trunk 2

FSM-State Up

C1-S1-D2# show cluster Cluster c1 1 ============ Rbridge Id: 200, Session Vlan: 0 Cluster State: Deploy Client Isolation Mode: Loose Configured Member Vlan Range: Active Member Vlan Range: Total Clients Configured : 1 ( Deployed Clients: 1) L2VPN Peer Info: --------------Peer IP: 10.1.1.1, Peer Rbridge Id: 100 KeepAlive Interval: 300 , Hold Time: 900 Node KeepAlive Interval: 2000 , Hold Time: 6000 l2vpn-revertible-timer 300


105

Peer State: CCP Up (Up Time: Client Info: -----------Name icx1 C1-S1-D2#

3.

0 days: 1 hr: 6 min:49 sec)

Rbridge-id 10

Config Deployed

Port 1/1

Trunk 2

FSM-State Up

Configure distribution router (PE) endpoints as the VPLS VLANs. In the distribution routers of both sites in the data centers, configure MPLS uplinks that are connected to the MPLS WAN. Configure RSVP LSP as the MPLS signaling protocol for the remote PEs (Site 2 distribution routers: C1-S2-D1 and C1-S2D2). For different communities, create different VPLS instances with remote cluster peer and remote PE VPLS peers. Configure the VPSL VLAN instances with MCT CCEP ports as the client ports. Communities are separated by the matching configured VLANs in the access switches. Different communities are separated by the different VLANs under each VPLS instance. The following output shows the MPLS VPLS configuration details in the distribution PE routers in data center Site1.

106


The following output shows the MPLS LSP state configured for the MCT peer with VRRP-E in the distribution PE routers in data center Site1. C1-S1-D1# sh mpls lsp Note: LSPs marked with * are taking a Secondary Path Admin Oper Tunnel Up/Dn Name To State State Intf Times 1701 10.5.5.5 UP UP tnl0 1 mct-peer-lsp 10.2.2.2 DOWN DOWN -0 C1-S1-D1#

Retry No. 0 0

Active Path ---

C1-S1-D2# sh mpls lsp Note: LSPs marked with * are taking a Secondary Path Admin Oper Tunnel Up/Dn Retry Active Name To State State Intf Times No. Path 1701 10.5.5.5 UP UP tnl0 1 0 -C1-S1-D2#

The following output shows the VPLS instance state configured for the MCT peer with VRRP-E in the distribution PE routers in data center Site1. C1-S1-D1# sh mpls vpls br Num Num Ports Num Peers CPU VC Name Id Vlans Ports Up Peers Up IFL-ID Prot Mode ==== == ===== ===== ===== ===== ===== ====== ==== ====== 1701 1701 1 2 2 2 2 n/a OFF RAW C1-S1-D1# C1-S1-D1# C1-S1-D1# sh mpls vpls detail VPLS 1701, Id 1701, Max mac entries: 8192 Total vlans: 1, Tagged ports: 2 (2 Up), Untagged ports 0 (0 Up) IFL-ID: n/a Vlan 1701 L2 Protocol: NONE Tagged: ethe 1/1 to 1/2 VC-Mode: Raw Total VPLS peers: 2 (2 Operational) Cluster-Peer address: 10.2.2.2, State: Operational, Uptime: 1 hr 16 min


107

Tnnl in use: tnl3(2050)[LDP] Peer Index:0 Local VC lbl: 983042, Remote VC lbl: 983040 Local VC MTU: 9190, Remote VC MTU: 9190 Local VC-Type: Ethernet(0x05), Remote VC-Type: Ethernet(0x05) Peer address: 10.5.5.5, State: Operational, Uptime: 1 hr 16 min Tnnl in use: tnl5(2049)[LDP] Peer Index:1 Local VC lbl: 983041, Remote VC lbl: 983041 Local VC MTU: 9190, Remote VC MTU: 9190 Local PW preferential Status:Active, Remote PW preferential Status:Active Local VC-Type: Ethernet(0x05), Remote VC-Type: Ethernet(0x05) CPU-Protection: OFF Local Switching: Enabled Extended Counter: ON Multicast Snooping: Disabled Cluster-peer: enabled, Role:Active State: VPLS_MCT_STATE_OPER VRRP MCT-Vpls Aware: Disable C1-S1-D1#

C1-S1-D2# show mpls vpls br Num Num Ports Num Peers CPU VC Name Id Vlans Ports Up Peers Up IFL-ID Prot Mode ==== == ===== ===== ===== ===== ===== ====== ==== ====== 1701 1701 1 2 2 2 2 n/a OFF RAW C1-S1-D2# C1-S1-D2# show mpls vpls detail VPLS 1701, Id 1701, Max mac entries: 8192 Total vlans: 1, Tagged ports: 2 (2 Up), Untagged ports 0 (0 Up) IFL-ID: n/a Vlan 1701 L2 Protocol: NONE Tagged: ethe 1/1 to 1/2 VC-Mode: Raw Total VPLS peers: 2 (2 Operational) Cluster-Peer address: 10.1.1.1, State: Operational, Uptime: 1 hr 16 min Tnnl in use: tnl5(2051)[LDP] Peer Index:0 Local VC lbl: 983040, Remote VC lbl: 983042 Local VC MTU: 9190, Remote VC MTU: 9190 Local VC-Type: Ethernet(0x05), Remote VC-Type: Ethernet(0x05) Peer address: 10.5.5.5, State: Operational, Uptime: 1 hr 16 min Tnnl in use: tnl4(2049)[LDP] Peer Index:1 Local VC lbl: 983042, Remote VC lbl: 983040 Local VC MTU: 9190, Remote VC MTU: 9190 Local PW preferential Status:Standby, Remote PW preferential Status:Active Local VC-Type: Ethernet(0x05), Remote VC-Type: Ethernet(0x05) CPU-Protection: OFF Local Switching: Enabled Extended Counter: ON Multicast Snooping: Disabled Cluster-peer: enabled, Role:Standby State: VPLS_MCT_STATE_OPER VRRP MCT-Vpls Aware: Disable C1-S1-D2#

4.

MAC learning and Layer 2 traffic forwarding. Once the VPLS MACs are learned, traffic will be forwarded by the VPLS pseudowire in the campus core from Site 1 to Site 2.

The following output shows the local and remote MAC entries in the data center Site1 access switches and distribution routers. C1-S1-A1# sh mac-address vlan 1701 Total active entries from VLAN 1701 = 2 MAC-Address Port Type 0010.9400.0006 1/2/1*2/2/2 Dynamic 0010.9400.0005 2/2/4 Dynamic C1-S1-A1#

VLAN 1701 1701

C1-S1-D1# sh mac vpls 1701

108


Total MAC entries for VPLS 1701: 3 (Local: 2, Remote: 1, Static: 0) VPLS MAC Address L/R/IB Port ==== ============== ====== ==== 1701 cc4e.248c.61d0 L 1/1 1701 0010.9400.0006 R 1/3 1701 0010.9400.0005 L 1/1 C1-S1-D1# C1-S1-D2# sh mac-address VPLS 1701

Vlan(In-Tag)/Peer ================= 1701 10.5.5.5 1701

ISID ======== NA NA NA

Age ====== NA 0 0

Type ==== CCR CL CCL

Total MAC entries for VPLS 1701: 3 (Local: 2, Remote: 1, Static: 0) VPLS ==== 1701 1701 1701 C1-S1-D2#

MAC Address ============== cc4e.248c.61d0 0010.9400.0006 0010.9400.0005

L/R/IB ====== L R L

Port ==== 1/1 -1/1

Vlan(In-Tag)/Peer ================= 1701 10.1.1.1 1701


Age ====== 65 NA NA

Type ==== CCL CR CCR

The following output shows the local and remote MAC entries in the data center Site2 access switches and distribution routers. C1-S2-A1# sh mac-address vlan 1701 Total active entries from VLAN 1701 = 3 MAC-Address Port Type cc4e.248c.61d0 1/2/1*2/2/1 Dynamic 0010.9400.0006 1/2/4 Dynamic 0010.9400.0005 1/2/1*2/2/1 Dynamic C1-S2-A1#

VLAN 1701 1701 1701

C1-S2-D1# show mac vpls 1701 Total MAC entries for VPLS 1701: 3 (Local: 1, Remote: 2, Static: 0) VPLS ==== 1701 1701 1701 C1-S2-D1#

MAC Address ============== cc4e.248c.61d0 0010.9400.0006 0010.9400.0005

L/R/IB ====== R L R


Port ==== 1/3 1/1 1/3

Vlan(In-Tag)/Peer ================= 10.1.1.1 1701 10.1.1.1


Age ====== 0 0 0

Type ==== NA NA NA

109

110


Enterprise Data Security with VE-overVPLS Endpoints • •

Enterprise Data Security with VE-over-VPLS Endpoints for Nondefault VRF.................................................................... 111 Enterprise Data Security with VE-over-VPLS Endpoints for Default VRF to Internet...................................................... 117

Enterprise Data Security with VE-over-VPLS Endpoints for Nondefault VRF FIGURE 24 Secure Campus Network to Transport Layer 3 VE-over-VPLS Traffic

Enterprise campus site endpoints can be connected with the VE-over-VPLS endpoints instead for native VLAN and VE endpoints. In this design, the distribution router that is the Layer 2 and Layer 3 boundary in enterprise campuses will have the endpoints configured as the VE-over-VPLS endpoints. The distribution routers are running MCT with VRRP-E for switch-level redundancy. Different communities are connected to the access switches in different VLANs. Access to the distribution router Layer 2 data path is secured by MACsec. In the distribution router, the endpoints are VE-over-VPLS in different VPLS instances configured with matching community VLANs, and the MCT CCEP ports are the tag member of the VLANs. IPsec tunnels running in different VRFs configured in the campus core will transport the IP traffic in the campus core network. In this section,we describe the configuration changes needed in the distribution routers for configuring the VE-over-VPLS endpoints. For the configuration related to MACsec, IPsec, and the campus network, refer to the "Enterprise Data Security Architecture—Validation Design" section.


111

Enterprise Data Security with VE-over-VPLS Endpoints for Nondefault VRF

The following steps are needed to configure the VE-over-VPLS endpoints along with MCT in the distribution routers in the campus: 1.

Configure the MCT peer with the L2VPN peer in the distribution routers.

2.

Configure the MPLS VE-over-VPLS endpoints with the MCT CCEP ports as the tag member of the VPLS community VLANs.

3.

Configure VRRP-E VE interfaces in different community VRFs for both VRRP-Emaster and backup distribution routers.

The following section describes the above-mentioned steps with a configuration example for the design. 1.

Configure the MCT peer with the L2VPN peer in the distribution routers. In both the distribution routers in the campus sites, configure the MCT peer with the L2VPN peer configured as the MCT peer. The following example shows the MCT configuration in the campus Site1 distribution routers.

C1-S1-D1# sh cluster Cluster c1 1 ============ Rbridge Id: 100, Session Vlan: 0 Cluster State: Deploy Client Isolation Mode: Loose Configured Member Vlan Range: Active Member Vlan Range: Total Clients Configured : 1 ( Deployed Clients: 1) L2VPN Peer Info: --------------Peer IP: 10.2.2.2, Peer Rbridge Id: 200 KeepAlive Interval: 300 , Hold Time: 900 Node KeepAlive Interval: 2000 , Hold Time: 6000 l2vpn-revertible-timer 300 Peer State: CCP Up (Up Time: 0 days: 0 hr:18 min:32 sec) Client Info: -----------Name Rbridge-id Config icx1 10 Deployed C1-S1-D1# C1-S1-D1# show cluster ccp peer

112

Port 1/1

Trunk 2

FSM-State Up



Cluster Name : c1 PEER IP ADDRESS --------------10.2.2.2

Cluster ID: 1 STATE ------------OPERATIONAL

UP TIME -------------0 days: 0 hr:31 min:50 sec

C1-S1-D1#

C1-S1-D2# sh cluster Cluster c1 1 ============ Rbridge Id: 200, Session Vlan: 0 Cluster State: Deploy Client Isolation Mode: Loose Configured Member Vlan Range: Active Member Vlan Range: Total Clients Configured : 1 ( Deployed Clients: 1) L2VPN Peer Info: --------------Peer IP: 10.1.1.1, Peer Rbridge Id: 100 KeepAlive Interval: 300 , Hold Time: 900 Node KeepAlive Interval: 2000 , Hold Time: 6000 l2vpn-revertible-timer 300 Peer State: CCP Up (Up Time: 0 days: 0 hr:19 min:11 sec) Client Info: -----------Name Rbridge-id Config icx1 10 Deployed C1-S1-D2# C1-S1-D2# show cluster ccp peer Cluster Name : c1 PEER IP ADDRESS --------------10.1.1.1


Port 1/1

Trunk FSM-State 2 Up

UP TIME -------------0 days: 0 hr:32 min: 9 sec

C1-S1-D2#

2.

Configure the MPLS VE-over-VPLS endpoints with the MCT CCEP ports as the tag member of the VPLS community VLANs. In both the MCT peer distribution routers in the campus sites, configure the MPLS VE-over-VPLS interfaces. For different communities, create VPLS instances with remote cluster peer. Configure the VPLS VLAN instances with the MCT CCEP ports as the client ports and separate VE interfaces. The distribution routers are configured as the Layer2 and Layer 3 boundary of the campus sites. Different communities are separated bydifferent VLANs under each VPLS instance. The following example shows the MPLS VPLS configurations in the campus Site1 distribution routers.


113


Configure VE2 as the MPLS uplink between the distribution routers in Site 1 interfaces running LDP. C1-S1-D1# sh mpls ldp nei Number of link neighbors: 1 Number of targeted neighbors: 1 Nbr Transport 10.2.2.2 10.2.2.2 C1-S1-D1#

Interface ve2 (targeted)

Nbr LDP ID 10.2.2.2:0 10.2.2.2:0

Max Hold 15 45

Time Left 14 34

Nbr LDP ID 10.1.1.1:0 10.1.1.1:0

Max Hold 15 45

Time Left 10 37

C1-S1-D2# sh mpls ldp nei Number of link neighbors: 1 Number of targeted neighbors: 1 Nbr Transport 10.1.1.1 10.1.1.1 C1-S1-D2#

3.


Configure VRRP-E VE interfaces in different community VRFs for both VRRP-Emaster and backup distribution routers. In both the MCT peer distribution routers in campus sites, configure VRRP-E VE interfaces.

114



The VRRP-E state and the MCT VPLS state are independent, so for an MCT VE VPLS instance, the VRRP-E role can be master while the MCT VPLS role can bestandby, or vice-versa. This can result in inefficient forwarding in some cases. To avoid this, either the VRRP-E state should follow the MCT VPLS state or the MCT VPLS state should follow the VRRP-E state. Because VRRP-E is more standardized, in the validated design,the MCT VPLS state is configured to follow the VRRP-E state in both MCT peer VRRP-E VE interfaces. By default, this option is disabled, which means that the MCT VPLS role will not follow the VRRP-E state. Each VRRP-E VE interfaceis configured under a different community VRF to separate different community traffic. The following output shows the VRRP-E VE configuration in distribution PE routers in Campus Site1. C1-S1-D1 is configured as the VRRP-E master, and C1-S1-D2 is configured as the VRRP-E backup based on the configured priority values. C1-S1-D1# sh run int ve 1701 interface ve 1701 port-name Customer-C1S1A1-VRRPe-ve1701 vrf forwarding 1701 ip ospf area 0 ip address 10.170.1.1/24 ipv6 address 2001::10:170:1:1/64 ipv6 ospf area 0 ip vrrp-extended vrid 1 backup priority 120 ip-address 10.170.1.3 advertise backup track-object mct-vpls-state short-path-forwarding activate ipv6 vrrp-extended vrid 1 backup priority 120 ipv6-address 2001::10:170:1:3 advertise backup short-path-forwarding activate ! C1-S1-D1# C1-S1-D2# sh run int ve 1701 interface ve 1701 port-name Customer-C1S1A2-ve1701 vrf forwarding 1701 ip ospf area 0 ip address 10.170.1.2/24 ipv6 address 2001::10:170:1:2/64 ipv6 ospf area 0 ip vrrp-extended vrid 1 backup priority 110 ip-address 10.170.1.3 advertise backup track-object mct-vpls-state short-path-forwarding activate ipv6 vrrp-extended vrid 1 backup priority 110 ipv6-address 2001::10:170:1:3 advertise backup short-path-forwarding activate ! C1-S1-D2#

The following example shows the VRRP-E state in the distribution routers in Campus Site1 in VRF 1701.


115


C1-S1-D1# sh ip vrrp-e br Total number of VRRP-Extended routers defined: 30 Flags Codes - P:Preempt 2:V2 3:V3 Short-Path-Fwd Codes - ER: Enabled with revertible option, RT: reverted, NR: not reverted Inte- VRID Current Flags State Master IP Backup IP (No) Virtual IP ShortTrack MCTrface Priority Address Address Address Path-Fwd VPLS-State -------------------------------------------------------------------------------------------------------v1701 1 120 P2 Master Local 10.170.1.2 ( 1) 10.170.1.3 Enabled Enable C1-S1-D2# show ip vrrp-e brief Total number of VRRP-Extended routers defined: 31 Flags Codes - P:Preempt 2:V2 3:V3 Short-Path-Fwd Codes - ER: Enabled with revertible option, RT: reverted, NR: not reverted Inte- VRID Current Flags State Master IP Backup IP (No) Virtual IP ShortTrack MCTrface Priority Address Address Address Path-Fwd VPLS-State -------------------------------------------------------------------------------------------------------Backup 10.170.1.1 Local ( 1) 10.170.1.3 Enabled Enable v1701 1 105 P2

The following example shows the VRF routing table in the distribution routers in Campus Site1 to reach communities in the remote campus sites via the IPsec tunnel in VRF 1701. C1-S1-D1# sh ip route vrf 1701 Total number of IP routes: 16 Type Codes - B:BGP D:Connected I:ISIS O:OSPF R:RIP S:Static; Cost - Dist/Metric BGP Codes - i:iBGP e:eBGP ISIS Codes - L1:Level-1 L2:Level-2 OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2 s:Sham Link STATIC Codes - d:DHCPv6 Destination Gateway Port Cost Type Uptime 1 10.1.1.1/32 DIRECT loopback 1 0/0 D 4m17s 2 10.2.2.2/32 10.170.1.2 ve 1701 110/2 O 1m13s 3 10.5.5.5/32 10.54.1.3 ipsec_tn 601 110/11113 O 1m16s 4 10.6.6.6/32 10.51.1.3 ipsec_tn 301 110/11113 O 1m16s 5 10.7.7.7/32 10.51.1.3 ipsec_tn 301 110/22225 O 1m16s 6 10.8.8.8/32 10.51.1.3 ipsec_tn 301 110/33337 O 1m16s 7 10.51.1.2/31 DIRECT ipsec_tn 301 0/0 D 2m1s 8 10.52.1.2/31 10.170.1.2 ve 1701 110/11113 O 0m57s 9 10.53.1.2/31 10.51.1.3 ipsec_tn 301 110/22224 O 1m16s 10.53.1.2/31 10.54.1.3 ipsec_tn 601 110/22224 O 1m16s 11 10.54.1.2/31 DIRECT ipsec_tn 601 0/0 D 2m1s 12 10.55.1.2/31 10.170.1.2 ve 1701 110/11113 O 1m13s 13 10.56.1.2/31 10.51.1.3 ipsec_tn 301 110/33336 O 1m16s 14 10.57.1.2/31 10.51.1.3 ipsec_tn 301 110/22224 O 1m16s 15 10.170.1.0/24 DIRECT ve 1701 0/0 D 2m37s 16 10.171.1.0/24 10.54.1.3 ipsec_tn 601 110/11113 O 1m16s 10.172.1.0/24 10.51.1.3 ipsec_tn 301 110/33337 O 1m16s C1-S1-D1#

C1-S1-D2# sh ip route vrf 1701 Total number of IP routes: 16 Type Codes - B:BGP D:Connected I:ISIS O:OSPF R:RIP S:Static; Cost - Dist/Metric BGP Codes - i:iBGP e:eBGP ISIS Codes - L1:Level-1 L2:Level-2 OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2 s:Sham Link STATIC Codes - d:DHCPv6 Destination Gateway Port Cost Type Uptime 1 10.1.1.1/32 10.170.1.1 ve 1701 110/2 O 1m58s 2 10.2.2.2/32 DIRECT loopback 1 0/0 D 4m53s 3 10.5.5.5/32 10.55.1.3 ipsec_tn 701 110/11113 O 1m49s 4 10.6.6.6/32 10.52.1.3 ipsec_tn 401 110/11113 O 1m43s 5 10.7.7.7/32 10.52.1.3 ipsec_tn 401 110/22225 O 1m43s

116

src-vrf -17

src-vrf -


Enterprise Data Security with VE-over-VPLS Endpoints for Default VRF to Internet

6 7 8 9

10.8.8.8/32 10.52.1.3 ipsec_tn 401 110/33337 10.51.1.2/31 10.170.1.1 ve 1701 110/11113 10.52.1.2/31 DIRECT ipsec_tn 401 0/0 10.53.1.2/31 10.52.1.3 ipsec_tn 401 110/22224 10.53.1.2/31 10.55.1.3 ipsec_tn 701 110/22224 11 10.54.1.2/31 10.170.1.1 ve 1701 110/11113 12 10.55.1.2/31 DIRECT ipsec_tn 701 0/0 13 10.56.1.2/31 10.52.1.3 ipsec_tn 401 110/33336 14 10.57.1.2/31 10.52.1.3 ipsec_tn 401 110/22224 15 10.170.1.0/24 DIRECT ve 1701 0/0 16 10.171.1.0/24 10.55.1.3 ipsec_tn 701 110/11113 10.172.1.0/24 10.52.1.3 ipsec_tn 401 110/33337 O C1-S1-D2#

O O D O O O D O O D O 1m43s

-

1m43s 1m58s 2m27s 1m43s 1m43s 1m58s 2m34s 1m43s 1m43s 3m14s 1m49s

-17

Enterprise Data Security with VE-over-VPLS Endpoints for Default VRF to Internet FIGURE 25 Secure Campus Network to Transport Layer 3 VPLS/VE Traffic over Internet

In this design, VE-over-VPLS endpoints, including the IPsec tunnels, are configured in the default VRFs to transport Internet traffic. The distribution router, which is the Layer 2 and Layer 3 boundary in enterprise campuses, will have the endpoints configured as VE-overVPLS endpoints. The distribution routers are running MCT with VRRP-E for switch-level redundancy. Different communities are connected to the access switches in different VLANs. Access to the distribution router Layer 2 data path is secured by MACsec. In the distribution router, the endpoints are VE over VPLS in different VPLS instances configured with matching community VLANs, and the MCT CCEP ports are the tag member of the VLANs. IPsec tunnels running in the default VRF configured over the Internet will transport the IP traffic to the Internet router. In this design, the Internet is running the EBGP protocol.


117


This section describes the configuration changes needed in the distribution routers to configure the VE-over-VPLS endpoints. For the configuration related to MACsec, IPsec, and the campus IP core, refer to the "Enterprise Data Security Architecture—Validation Design" section. The following steps are needed to configure the VE-over-VPLS endpoints along with MCT in the campus distribution routers: 1.

Configure the MCT peer with the L2VPN peer in the distribution routers.

2.

Configure MPLS VE-over-VPLS endpoints with MCT CCEP ports as the tag member of the VPLS community VLANs.

3.

Configure VRRP-E VE interfaces in default VRFs for both VRRP-E master and backup distribution routers.

The following section describes the above-mentioned steps with a configuration example for the design. 1.

Configure the MCT peer with the L2VPN peer in the distribution routers. In both distribution routers in the campus sites, configure the MCT peer with the L2VPN peer configured as the MCT peer. The following example shows the MCT configuration in the Campus Site1 distribution routers.

C1-S1-D1# sh cluster Cluster c1 1 ============ Rbridge Id: 100, Session Vlan: 0 Cluster State: Deploy Client Isolation Mode: Loose Configured Member Vlan Range: Active Member Vlan Range: Total Clients Configured : 1 ( Deployed Clients: 1) L2VPN Peer Info: --------------Peer IP: 10.2.2.2, Peer Rbridge Id: 200 KeepAlive Interval: 300 , Hold Time: 900 Node KeepAlive Interval: 2000 , Hold Time: 6000 l2vpn-revertible-timer 300 Peer State: CCP Up (Up Time: 0 days: 0 hr:18 min:32 sec) Client Info: -----------Name

118

Rbridge-id

Config

Port

Trunk FSM-State



icx1 C1-S1-D1# C1-S1-D1# show cluster ccp peer Cluster Name : c1 PEER IP ADDRESS --------------10.2.2.2


10

Deployed

1/1

2

Up

UP TIME -------------0 days: 0 hr:31 min:50 sec

C1-S1-D1#

C1-S1-D2# sh cluster Cluster c1 1 ============ Rbridge Id: 200, Session Vlan: 0 Cluster State: Deploy Client Isolation Mode: Loose Configured Member Vlan Range: Active Member Vlan Range: Total Clients Configured : 1 ( Deployed Clients: 1) L2VPN Peer Info: --------------Peer IP: 10.1.1.1, Peer Rbridge Id: 100 KeepAlive Interval: 300 , Hold Time: 900 Node KeepAlive Interval: 2000 , Hold Time: 6000 l2vpn-revertible-timer 300 Peer State: CCP Up (Up Time: 0 days: 0 hr:19 min:11 sec) Client Info: -----------Name icx1 C1-S1-D2# C1-S1-D2# show cluster ccp peer Cluster Name : c1 PEER IP ADDRESS --------------10.1.1.1


Rbridge-id Config 10 Deployed

Port 1/1

Trunk FSM-State 2 Up

UP TIME -------------0 days: 0 hr:32 min: 9 sec

C1-S1-D2#

2.

Configure MPLS VE-over-VPLS endpoints with MCT CCEP ports as the tag member of the VPLS community VLANs. In both the MCT peer distribution routers in campus sites, configure the MPLS VE-over-VPLS interfaces. For different communities, create VPLS instances with the remote cluster peer. Configure the VPLS VLAN instances with MCT CCEP ports as the client ports and separate VE interfaces. The distribution routers are configured as the Layer 2 and Layer 3 boundary of the campus sites. Different communities are separated bydifferent VLANs under each VPLS instance. The following example shows the MPLS VPLS configurations in the Campus Site1 distribution routers.


119


Configure VE2 as the MPLS uplink between the distribution routers in Site 1 interfaces running LDP. C1-S1-D1# sh mpls ldp nei Number of link neighbors: 1 Number of targeted neighbors: 1 Nbr Transport 10.2.2.2 10.2.2.2 C1-S1-D1#


Nbr LDP ID 10.2.2.2:0 10.2.2.2:0

Max Hold 15 45

Time Left 14 34

Nbr LDP ID 10.1.1.1:0 10.1.1.1:0

Max Hold 15 45

Time Left 10 37

C1-S1-D2# sh mpls ldp nei Number of link neighbors: 1 Number of targeted neighbors: 1 Nbr Transport 10.1.1.1 10.1.1.1 C1-S1-D2#

3.


Configure VRRP-E VE interfaces in default VRFs for both VRRP-E master and backup distribution routers. In both the MCT peer distribution routers in campus sites, configure VRRP-E VE interfaces in the default VRF instance. The following output shows the VRRP-E VE configuration in distribution PE routers in Campus Site1. C1-S1-D1 is configured as the VRRP-E master, and C1-S1-D2 is configured as the VRRP-E backup based on the configured priority values.

120



C1-S1-D1# sh run int ve 1702 interface ve 1702 port-name Customer-C1S1A1-VRRPe-ve1702 ip ospf area 0 ip address 10.170.2.1/24 ipv6 address 2001::10:170:2:1/64 ipv6 ospf area 0 ip vrrp-extended vrid 2 backup priority 120 ip-address 10.170.2.3 advertise backup short-path-forwarding activate ipv6 vrrp-extended vrid 2 backup priority 120 ipv6-address 2001::10:170:2:3 advertise backup short-path-forwarding activate ! C1-S1-D1# C1-S1-D2# sh run int ve 1702 interface ve 1702 port-name Customer-C1S1A2-ve1702 ip ospf area 0 ip address 10.170.2.2/24 ipv6 address 2001::10:170:2:2/64 ipv6 ospf area 0 ip vrrp-extended vrid 2 backup priority 110 ip-address 10.170.2.3 advertise backup short-path-forwarding activate ipv6 vrrp-extended vrid 2 backup priority 110 ipv6-address 2001::10:170:2:3 advertise backup short-path-forwarding activate ! C1-S1-D2#

The following example shows the VRRP-E state in the Campus Site 1 distribution routersin the default VRF. C1-S1-D1# sh ip vrrp-e br Total number of VRRP-Extended routers defined: 30 Flags Codes - P:Preempt 2:V2 3:V3 Short-Path-Fwd Codes - ER: Enabled with revertible option, RT: reverted, NR: not reverted Inte- VRID Current Flags State Master IP Backup IP (No) Virtual IP ShortTrack MCTrface Priority Address Address Address Path-Fwd VPLS-State ---------------------------------------------------------------------------------------------------v1701 1 120 P2 Master Local 10.170.1.2 ( 1) 10.170.1.3 Enabled Enable v1702 2 120 P2 Master Local 10.170.2.2 ( 1) 10.170.2.3 Enabled DisableC1S1-D2# sh ip vrrp-e br Total number of VRRP-Extended routers defined: 31 Flags Codes - P:Preempt 2:V2 3:V3 Short-Path-Fwd Codes - ER: Enabled with revertible option, RT: reverted, NR: not reverted Inte- VRID Current Flags rface Priority


State

Master IP Address

Backup IP Address

(No) Virtual IP Address

ShortPath-Fwd

Track MCTVPLS-State

121


--------------------------------------------------------------------------------------------------v1701 1 110 P2 Backup 10.170.1.1 Local ( 1) 10.170.1.3 Enabled Enable v1702 2 110 P2 Backup 10.170.2.1 Local ( 1) 10.170.2.3 Enabled Disable

In the design, IPsec tunnel 10 is configured in the default VRF between distribution router C1-S1-D1 and the Internet peer router. EBGP is configured between the two routers. Similarly, the IPsec tunnel in the default VRF is configured between distribution router C1-S1-D2 and the Internet peer router. The following output shows the default routing table and the route reachability in distribution router C1-S1-D1 in Campus Site1 to reach the Internet router loopback address (default VRF) via the IPsec tunnel in the default VRF. C1-S1-D1# sh ip route | in 10.5.5.54 10.5.5.5/32 50.0.0.3 110/11113 O 15m2s C1-S1-D1# C1-S1-D1# ping 10.5.5.5 Sending 1, 16-byte ICMP Echo to 10.5.5.5, timeout 5000 msec, TTL 64 Type Control-c to abort Reply from 10.5.5.5 : bytes=16 time=1ms TTL=64 Success rate is 100 percent (1/1), round-trip min/avg/max=1/1/1 ms. C1-S1-D1# traceroute 10.5.5.5

ipsec_tn 10

Type Control-c to abort Sending DNS Query to 10.31.2.10 Type Control-c to abort Tracing the route to IP node (10.5.5.5) from 1 to 30 hops 1

122

Data Security Solution for Enterprise Networks - Brocade

Data Security Solution for Enterprise Networks - Brocade

Suggest Documents

Data Security Solution for Enterprise Networks - Brocade

Huawei Remote Access Security Solution for Enterprise Networks

Enterprise Data Masking Solution - Oracle

Intelligent Cyber Security Analysis in Enterprise Networks

Nortel Networks Product and Solution Reference Guide for Enterprise ...

Nortel Networks Product and Solution Reference Guide for Enterprise ... [PDF]

Solution Data Sheet: Enterprise Disaster Recovery Automation ...

logrhythm and palo alto networks for integrated enterprise security

Developing Security Solutions for Wireless Mesh Enterprise Networks

SAFE: A Security Blueprint for Enterprise Networks - Cisco

Architectural support for security management in enterprise networks

Cisco Secure Data Center for Enterprise Solution: First Look Design ...

Cisco Secure Data Center for Enterprise Solution: First Look Design ...

Security Blueprint for Enterprise - Cisco

Google Web Security for Enterprise

Google Web Security for Enterprise

Security Blueprint for Enterprise - Cisco

BLACKBERRY® ENTERPRISE SERVER SOLUTION

Security Solution For Data Integrity In Wireless ... - Computer Science

DWDM Solution for Data Centre, Metro, Access ... - Sorrento Networks

Transparent Data Encryption- Solution for Security of Database Contents

security solution for attack vectors on portable computers data and ...

Transparent Data Encryption- Solution for Security of Database ...

Transparent Data Encryption- Solution for Security of Database ...