CCIE Service Provider Fundamentals Workbook.v1.2

CCIE Service Provider
Fundamentals
CCIE Service Provider Fundamentals

Service Provider Lab Overview Bridging and Switching IGP Routing BGP Routing Multicast Routing MPLS
Advanced MPLS
QOS Security
CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com
Service Provider Lab Overview

Service Provider Lab Design
Ethernet, Frame-Relay, ATM, PPP, and PPPoE RIP, EIGRP, OSPF, ISIS Multiple BGP AS Intra-AS and Inter-AS MPLS VPN AToM and L2TPv3 Interworking MVPN, PIM-SM, PIM-SSM
Bridging and Switching

Catalyst 3560 Frame-Relay
ATM
PPP PPPoE
Bridging and Switching: Catalyst 3560

Catalyst 3560 Overview
SP lab will contain 3560s with IOS 12.2 Multi-Layer switch running native IOS 3560s will provide all LAN switching 3560s will be connected via an 802.1Q trunk VTP server and client will be used

Catalyst 3560 Layer 2 Initial configuration will be done Verify all required vlans and trunks are in place Review initial configuration: show vtp status show vlan show interface Fa0/1 switchport show run interface Fa 0/1
Catalyst 3560 Layer 3 You may be asked to create a routed interface using either a switchport interface or a vlan interface.

Catalyst 3560 Routing
Routing can be done on virtual or physical interfaces Configure vlan 12 with IP 172.16.12.2/24 3560 Vlan Interface Routing ip routing ! interface vlan 12 ip address 172.16.12.2 255.255.255.0 Configure Fa0/1 with IP 172.16.12.2/24 3560 Switchport Interface Routing ip routing ! interface FastEthernet 0/1 no switchport ip address 172.16.12.12 255.255.255.0
Bridging and Switching: Frame-Relay

Frame-Relay Overview
Layer 2 WAN technology Switches traffic using DLCIs to create a logical end-to-end PVC
Frame-Relay Terms and Operation

PVC Permanent Virtual Circuit, logical end to end VC or L2 VPN DLCI Data Link Connection Identifier, locally significant LMI Local Management Interface signaling between switch and router LMI Types Cisco (default) DLCI 1023, ANSI DLCI 0, and Q933A DLCI 0 NNI Network to Network Interface signaling between switches

Frame-Relay Configuration
Configured on Physical Serial Interface or Logical sub-interface DLCI can be dynamically (default) or statically assigned With NBMA, L2 to L3 mapping is required In Point-to-Point, mapping not required, only one L2 address exists
R1 Physical Configuration for Non-Broadcast Multiple Access (NBMA) interface Serial0 << NBMA Interface encapsulation frame-relay ip address 172.16.12.1 255.255.255.252
R1 Sub-Interface Configuration for Point-to-Point Interface Serial0 encapsulation frame-relay ! interface Serial0.1 point-to-point << Point-to-Point interface ip address 172.16.12.1 255.255.255.252 frame-relay interface-dlci 102 << associate sub-interface with DLC1 102

Frame-Relay Dynamic ARP
Ensure Frame-Relay dynamic maps are not permitted R1 Physical Configuration interface Serial0 encapsulation frame-relay ip address 172.16.12.1 255.255.255.252 R1# show frame-relay map Serial0 (up): ip 172.16.12.2 dlci 102(0x66,0x3400), dynamic, broadcast, CISCO, status defined, active
Solution Interface Serial0 shut no frame-relay inverse-arp << disable dynamic learning of DLCI do clear frame-relay inarp << clear current inverse arp table frame-relay map ip 172.16.12.2 102 broadcast << map IP to DLCI no shut Verification R1# show frame-relay map Serial0 (up): ip 172.16.12.2 dlci 102(0x66,0x3400), static, broadcast, CISCO, status defined, active
10

Frame-Relay Final Physical Configuration
Ensure L3 to L2 is mapped and neighbor responds to ping
R1 Configuration interface Serial0 encapsulation frame-relay ip address 172.16.12.1 255.255.255.252 frame-relay map ip 172.16.12.2 102 broadcast
Question With this configuration, what is required for R1 or R2 to ping their own interface?
R2 Configuration interface Serial0 encapsulation frame-relay ip address Non-Broadcast Multi-Access 172.16.12.2 255.255.255.252 frame-relay map ip 172.16.12.1 201 broadcast
11

Frame-Relay Final Sub-Interface Configuration
Ensure neighbor responds to ping
R1 Configuration interface Serial0 encapsulation frame-relay ! interface Serial0.1 point-to-point ip address 172.16.12.1 255.255.255.252 frame-relay interface-dlci 102
R2 Configuration interface Serial0 encapsulation frame-relay ! interface Serial0.1 point-to-point ip address 172.16.12.2 255.255.255.252 frame-relay interface-dlci 201
12

Frame-Relay Switching Scenario
Configure the Cisco Router as a Frame-Relay Switch Configure Frame-Relay switching using the table below Interface Serial 1/0 should service DLCI 102 interface Serial 1/1 should service DLCI 201
13

Frame-Relay Switching Solution
The solution below routes an incoming DLCI to an outgoing interface and corresponding outgoing DLCI. During this process, the incoming DLCI in the arriving frames is replaced by an outgoing DLCI.
Solution
frame-relay switching ! interface Serial1/0 encapsulation frame-relay clockrate 64000 frame-relay intf-type dce frame-relay route 102 interface Serial1/1 201 ! interface Serial1/1 encapsulation frame-relay clockrate 64000 frame-relay intf-type dce frame-relay route 201 interface Serial1/0 102
14

Frame-Relay Switching Discussion and Verification
Frame Relay switching is performed in Layer 2, and gives no attention to Layer 3 information contained within the frames. The paths taken by the switched frames are completely based on the Frame Relay route table constructed below.
Verification FRSW# show frame-relay route Input Intf Input Dlci Output Intf Output Dlci Status Serial1/0 102 Serial1/1 201 active Serial1/1 201 Serial1/0 102 active
Command Reference
frame-relay switching: Enable Frame Relay switching frame-relay intf-type dce: designate as a DCE interface frame-relay route: routes an incoming DLCI to an outgoing interface and corresponding outgoing DLCI. clockrate: provide clocking signals to the connected Frame Relay routers, which are set up as DTE devices
15

Frame-Relay SP Lab Troubleshooting
SP lab may deploy Frame-Relay in WAN or Local Frame-Relay is generally preconfigured with some errors Ensure familiarity with common configurations Sample Configuration with errors interface Serial0 encapsulation frame-relay ip address 172.16.12.1 255.255.255.252 frame-relay map ip 172.16.12.22 201 Resolve interface Serial0 no frame-relay map ip 172.16.12.22 201 frame-relay map ip 172.16.12.2 201
Troubleshooting Command Reference

show frame-relay pvc show frame-relay lmi show frame-relay map
16
Bridging and Switching: ATM

ATM Overview
Layer 2 WAN (PVC, SVC) and LAN (LANE) technology Default ATM interface encapsulation is AAL5 VPI/VCI similar to Frame-Relay DLCI, locally significant
ATM Terms and Operation VPI - Virtual Path Identifier UNI = 8 bits, NNI = 12 bits
VCI - Virtual Channel Identifier 16 bits CLP - Cell Loss Priority, 1 bit used for discard eligibility PVC - static Permanent Virtual Circuit ATM default PVC = 0/16 SVC - dynamic Switched Virtual Circuit ATM Cell - 53 bytes, 5 byte header and 48 byte payload AAL1 ATM Adaption Layer 1, support CBR AAL5 ATM Adaptation Layer 5, supports UBR ILMI - Interim LMI, used for setting ATM parameters
17

ATM PVC Configuration Multi Point ATM, L2 to L3 mapping is required Point-to-Point ATM, one L2 VC, mapping not required In PVC deployments, L3 protocol is mapped to VPI/VCI In SVC deployments, L3 protocol is mapped to NSAP
R1 Configuration interface ATM1/0 ip address 172.16.12.1 255.255.255.252 pvc 0/102 protocol ip 172.16.12.2 broadcast << Use PVC 102 to reach R2
18

ATM Multi Point Configuration
Ensure L3 to L2 is mapped and neighbor responds to ping
R1 Configuration interface ATM1/0 ip address 172.16.12.1 255.255.255.252 pvc 0/102 protocol ip 172.16.12.2 broadcast
R2 Configuration interface ATM1/0 ip address 172.16.12.2 255.255.255.252 pvc 0/201 protocol ip 172.16.12.1 broadcast
19

ATM Point-to-Point Configuration
Ensure neighbor responds to ping
R1 Configuration interface ATM1/0.1 point-to-point ip address 172.16.12.1 255.255.255.252 pvc 0/102
R2 Configuration interface ATM1/0.1 point-to-point ip address 172.16.12.2 255.255.255.252 pvc 0/201
20

ATM Troubleshooting
Verify basic interface status and L2 to L3 mapping
R1# show int atm 1/0 ATM1/0 is up, line protocol is up Hardware is ENHANCED ATM PA Internet address is 192.5.10.1/24 Encapsulation(s): AAL5 , PVC mode 2047 maximum active VCs, 1024 VCs per VP, 1 current VCCs VC Auto Creation Disabled. VC idle disconnect time: 300 seconds
R1# show atm pvc 0/102 ATM1/0: VCD: 6, VPI: 0, VCI: 102 UBR, PeakRate: 155000 (365567 cps) AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0, Encapsize: 12 Status: UP
R1# show atm map Map list ATM1/0 pvc6 : PERMANENT ip 192.5.10.254 maps to VC 6, VPI 0, VCI 102, ATM1/0, broadcast
21
Bridging and Switching: PPP

PPP Overview
L2 encapsulation for transporting IP over point-to-point networks Commonly used for dial-up connections Uses HDLC for datagram encapsulation L2 to L3 mapping not required Capable of authenticating endpoints Supports multilink bundling
PPP Terms and Operation

PPP contains three sub-layers NCP, LCP, and HDLC NCP Network Control Protocol, negotiates with L3 protocols LCP Link Control Protcol, authentication and link establishment HDLC High-Level Data Link Control, encapsulates datagrams
PAP Password Authentication Protocol CHAP Challenge Handshake Authentication Protocol PAP uses clear text authentication, CHAP uses 128 bit MD5 CHAP authenticates peers using a three-way handshake CHAP and PAP initiate when LCP negotiates link parameters
22

PPP with CHAP Configuration
Configure R1 to authenticate R2 inbound using CHAP. R2 should attempt to authenticate with the username and password ccie / ccie.
R1 Configuration username ccie password ccie ! interface Serial 0 encapsulation PPP ip address 172.16.12.1 255.255.255.252 ppp authentication chap callin
Note: If DTE, DCE interfaces are used, clock rate is required
R2 Configuration interface Serial 0 encapsulation PPP ip address 172.16.12.2 255.255.255.252 ppp chap username ccie ppp chap password ccie
23

PPP Troubleshooting and Verification
Verify basic interface status, PPP negotiation, and PPP authentication
R1# debug ppp negotiation R1# debug ppp authentication Se0 LCP: O CONFACK [Listen] id 2 len 10 Se0 LCP: I CONFACK [ACKsent] id 42 len 15 Se0 LCP: AuthProto CHAP (0x0305C22305) ! Se0 LCP: State is Open Se0 PPP: Phase is AUTHENTICATING, by this end Se0 CHAP: O CHALLENGE id 1 len 23 from "R1 << CHAP challenge from R1 to peer Se0 CHAP: I RESPONSE id 1 len 25 from "ccie << PPP peer hostname ccie Se0 PPP: Sent CHAP LOGIN Request Se0 PPP: Received LOGIN Response PASS Se0 PPP: Phase is FORWARDING, Attempting Forward Se0 PPP: Phase is AUTHENTICATING, Authenticated User Se0 PPP: Sent LCP AUTHOR Request << authentication request passed to local database Se0 LCP: Received AAA AUTHOR Response PASS << R1 returns successful challenge response Se0 CHAP: O SUCCESS id 1 len 4 ! Se0 PPP: Phase is UP Se0 IPCP: O CONFACK [REQsent] id 1 len 10 Se0 IPCP: Address 172.16.12.2 (0x0306AC100C02) << PPP peer IP Se0 IPCP: I CONFACK [ACKsent] id 1 len 10 Se0 IPCP: Address 172.16.12.1 (0x0306AC100C01) << our local IP ! Se0 IPCP: State is Open Se0 IPCP: Install route to 172.16.12.2 %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to up R1#ping 172.16.12.2 Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/22/40 ms
24
Bridging and Switching: PPPoE

PPPoE Overview
Encapsulates PPP frames inside Ethernet frames Establishes secure PPP sessions for Ethernet clients Managed on a per-user basis rather than a per-site basis Used mainly with DSL services
PPPoE Terms and Operation

PADI- PPPoE Active Discovery Initiation, obtains mac of dsl server PADT- PPPoE Active Discovery Termination, ends connection PPPoE adds 8 bytes to each packet PPPoe has two stages PPPoE discovery and PPP session PPPoE has an MTU lower than Ethernet (1492 vs 1500)
25

PPPoE Configuration
Configure R1 as a PPPoE Server and R2 as a PPPoE Client
R1 vpdn enable vpdn-group 1 accept-dialin protocol pppoe virtual-template 1 ! interface FastEthernet0 pppoe enable ! interface Virtual-Template1 ip address 172.16.12.1 255.255.255.0 R2 vpdn enable vpdn-group 1 request-dialin protocol pppoe ! interface FastEthernet0 pppoe enable pppoe-client dial-pool-number 1 ! interface Dialer1 ip address 172.16.12.2 255.255.255.0 ip mtu 1492 encapsulation ppp dialer pool 1 dialer persistent
26

PPPoE Troubleshooting and Verification
Verify basic interface status, PPPoE events, and PPP negotiation
R1#debug pppoe events R1#debug ppp negotiation PPPoE 0: I PADI R:c404.0794.0001 L:ffff.ffff.ffff Fa0 PPPoE 0: O PADO, R:ca09.09d8.0006 L:c404.0794.0001 Fa0 PPPoE 0: I PADR R:c404.0794.0001 L:ca09.09d8.0006 Fa0 [1]PPPoE 1: Created, Service: None R:ca09.09d8.0006 L:c404.0794.0001 Fa0 [1]PPPoE 1: State NAS_PORT_POLICY_INQUIRY Event MORE_KEYS [1]PPPoE 1: O PADS R:c404.0794.0001 L:ca09.09d8.0006 Fa0 ppp1 PPP: Send Message[Dynamic Bind Response] ppp1 PPP: Using vpn set call direction ppp1 PPP: Treating connection as a callin [1]PPPoE 1: State PPP_START Event DYN_BIND ! ppp1 LCP: State is Open ppp1 PPP: Phase is FORWARDING, Attempting Forward ppp1 PPP: Send Message[Connect Local] [1]PPPoE 1: State LCP_NEGOTIATION Event PPP_LOCAL [1]PPPoE 1: State VACCESS_REQUESTED Event VA_RESP ppp1 PPP: Bind to [Virtual-Access1.1] Vi1.1 PPP: Send Message[Static Bind Response] [1]PPPoE 1: Connected PTA Vi1.1 PPP: Phase is ESTABLISHING, Finish LCP ! Vi1.1 PPP: Phase is UP Vi1.1 IPCP: Address 172.16.12.1 (0x0306AC100C01) Vi1.1 IPCP: I CONFREQ [REQsent] id 1 len 10 Vi1.1 IPCP: Address 172.16.12.2 (0x0306AC100C02) Vi1.1 IPCP: O CONFACK [REQsent] id 1 len 10 ! Vi1.1 IPCP: State is Open Vi1.1 IPCP: Install route to 172.16.12.2
27
IGP Routing
RIPv2 EIGRP
OSPF
IS-IS
28
IGP Routing: RIPv2

RIPv2 Overview
Distance-vector routing protocol Employs Hop Count as the routing metric Deployed in small scale routing environments
RIPv2 Terms and Operation

Multicasts routing updates to 224.0.0.9 Slightly randomizes the standard 30 second update Prevents routing loops by limiting the number of hops Hop count of 16 is considered an infinite distance RIP is implemented using UDP port number 520 Provides support for address-family identifiers Supports clear text or MD5 Authentication with key-chain
29
IGP Routing: RIPv2

RIPv2 Configuration
Configure RIPv2 on R1 and R2. Only include Fa0 and Loo0.
R1 Configuration interface Loopback0 Ip address 1.1.1.1 255.255.255.255 ! Interface FastEthernet0 ip address 172.16.12.1 255.255.255.0 ! router rip version 2 no auto-summary passive-interface default no passive interface FastEthernet0 no passive interface Loopback0 network 1.0.0.0 network 172.16.0.0 R2 Configuration interface Loopback0 Ip address 2.2.2.2 255.255.255.255 ! Interface FastEthernet0 ip address 172.16.12.2 255.255.255.0 ! router rip version 2 no auto-summary passive-interface default no passive interface FastEthernet0 no passive interface Loopback0 network 2.0.0.0 network 172.16.0.0
30
IGP Routing: RIPv2

RIPv2 Verification
Verify routes are installed
R1# show ip protocol Routing Protocol is "rip" Sending updates every 30 seconds, next due in 28 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Redistributing: rip Default version control: send version 2, receive version 2 Interface Send Recv Triggered RIP Key-chain FastEthernet0 2 2 Loopback0 2 2 Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 1.0.0.0 172.16.0.0 Passive Interface(s): Loopback1 Routing Information Sources: Gateway Distance Last Update 172.16.12.2 120 00:00:03 Distance: (default is 120) R1# show ip ro rip 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/1] via 172.16.12.2, 00:00:08, FastEthernet0
R2# do sh ip ro rip 1.0.0.0/32 is subnetted, 1 subnets R 1.1.1.1 [120/1] via 172.16.12.1, 00:00:01, FastEthernet0
31
IGP Routing: EIGRP

EIGRP Overview
Cisco proprietary, advanced distance-vector routing protocol Metrics - Bandwidth, Load, Delay, Reliability, and MTU Supports large scale routing environments Stable, flexible, and fast
EIGRP Terms and Operation

Multicasts routing updates to 224.0.0.10 DUAL - Diffusing Update Algorithm, tracks routes and neighbors DUAL - provides loop-free operation and fast convergence RTP ensures EIGRP packets are received, delivered, ordered Provides support for address-family identifiers Supports MD5 Authentication with key-chain
32
IGP Routing: EIGRP

EIGRP Configuration
Configure EIGRP AS 100 on R1 and R2. Include Fa0 and Loo0.
R1 Configuration interface Loopback0 Ip address 1.1.1.1 255.255.255.255 ! Interface FastEthernet0 ip address 172.16.12.1 255.255.255.0 ! router eigrp 100 eigrp router-id 1.1.1.1 network 1.1.1.1 0.0.0.0 network 172.16.12.0 0.0.0.255 no auto-summary
R2 Configuration interface Loopback0 Ip address 2.2.2.2 255.255.255.255 ! Interface FastEthernet0 ip address 172.16.12.2 255.255.255.0 ! router eigrp 100 eigrp router-id 2.2.2.2 network 2.2.2.2 0.0.0.0 network 172.16.12.0 0.0.0.255 no auto-summary
33
IGP Routing: EIGRP

EIGRP Verification
R1# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.16.12.2 (FastEthernet0) is up: new adjacency R1# show ip protocols Routing Protocol is "eigrp 100 EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 EIGRP maximum hopcount 100 Redistributing: eigrp 100 EIGRP NSF-aware route hold timer is 240s Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 1.1.1.1/32 172.16.12.0/24 Routing Information Sources: Gateway Distance Last Update 172.16.12.2 90 00:00:18 Distance: internal 90 external 170 R1#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/156160] via 172.16.12.2, 00:00:26, FastEthernet0 R2# show ip route eigrp 1.0.0.0/32 is subnetted, 1 subnets D 1.1.1.1 [90/130816] via 172.16.12.1, 00:01:37, FastEthernet0
34
IGP Routing: OSPF

OSPF Overview
Link State routing protocol Employs Cost as the routing metric Supports large scale routing environments Hierarchical Area structure reduces cpu and memory load
OSPF Terms and Operation

SPF Shortest Path First Algorithm, determines least cost path LSA Link State Advertisements (link routing updates) DR Designated Router BDR - Backup Designated Router DROTHER non DR /BDR OSPF router Elects DR and Backup DR on multi-access segments, not P-P DR and BDR multicast LSAs to 224.0.0.5 and listen on 224.0.0.6 DROTHER multicasts LSAs to 224.0.0.6 and listen on 224.0.0.5 Reference bdw of 100 Mb for cost, 100 Mb / 10 Mb = Cost 10 Supports Clear Text and MD5 Authentication
35
IGP Routing: OSPF

OSPF Areas
Backbone Area 0, all traffic should pass through backbone Nonbackbone, nonstub standard area, all LSAs except Type 7 Stub Area no external or redistribution, only Type 1, 2, 3 Totally Stubby Area no external or internal, only default route NSSA redistributes routing protocols into stub area
OSPF Router Types

Internal all interfaces in the same area, share same spf db Backbone routers that have at least one interface in Area 0 Area Border Router (ABR) connects one or more areas to the backbone. Always has one interface in Area 0 and maintains a separate SPF database for each area connected to. Autonomous System Boundary Router (ASBR) advertise external routes or redistribute another routing protocol
OSPF Route Types

O intra-area route, routes from within the area O IA inter-area route, routes from outside the area O N1 NSSA Type 1, adds internal cost to NSSA + external cost O N2 NSSA Type 2, default type for NSSA routes O E1 External Type 1, adds internal cost to ASBR + external cost O E2 External Type 2, default type for redistributed routes
36
IGP Routing: OSPF

OSPF Network Types
Point-to-Point PPP, Frame-Relay, no DR/BDR election Broadcast Network Ethernet, elect DR/BDR, hello to 224.0.0.5 NBMA Frame-Relay, ATM, elect DR/BDR, all packets unicast Point-to-Multipoint Frame-Relay, no DR/BDR election Virtual Links extend Area 0 across partitioned backbone
OSPF LSAs
Router (Type 1) routers neighbors and links in an area Network (Type 2) DR lists OSPF routers on a network ABR Summary (Type 3) ABR advertises internal nets ASBR Summary (Type 4) advertise best route to ASBR AS External (Type 5) routes redistributed into OSPF Group Membership (Type 6) designed for MOSPF NSSA External (Type 7) routes redistributed into NSSA Opaque LSA (Type 10) - provides resource and links status for TE
OSPF Adjacency States

Down: initial state of the neighbor, no hellos within dead interval Attempt: applies only to neighbors on NBMA networks Init: detected a Hello packet coming from a neighbor Two-way: bidirectional conversation established, DR/BDR elect Exstart: establish initial sequence num in information exchange Exchange: Routers describe their entire link-state database Loading: routers finalize the information exchange Full: adjacency is complete
37
IGP Routing: OSPF

OSPF LSA Exchange
38
IGP Routing: OSPF

OSPF Configuration
Configure OSPF 100 on R1 & R2. Place Fa0 and Loo0 in Area 0.
R1 Configuration interface Loopback0 Ip address 1.1.1.1 255.255.255.255 ! Interface FastEthernet0 ip address 172.16.12.1 255.255.255.0 ! router ospf 100 router-id 1.1.1.1 network 1.1.1.1 0.0.0.0 area 0 network 172.16.12.1 0.0.0.0 area 0
R2 Configuration interface Loopback0 Ip address 2.2.2.2 255.255.255.255 ! Interface FastEthernet0 ip address 172.16.12.2 255.255.255.0 ! router ospf 100 router-id 2.2.2.2 network 2.2.2.2 0.0.0.0 area 0 network 172.16.12.2 0.0.0.0 area 0
39
IGP Routing: OSPF

OSPF Verification
R1#show ip protocol Routing Protocol is "ospf 100 Router ID 1.1.1.1 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Routing for Networks: 1.1.1.1 0.0.0.0 area 0 172.16.12.1 0.0.0.0 area 0 Routing Information Sources: Gateway Distance Last Update 2.2.2.2 110 00:21:18 172.10.12.1 110 01:55:11 Distance: (default is 110) R1#show ip ospf neighbor Neighbor ID Pri State 2.2.2.2 255 FULL/BDR
Dead Time Address Interface 00:00:37 172.10.11.2 Fa0
R1#show ip ospf database OSPF Router with ID (1.1.1.1) (Process ID 100) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 2.2.2.2 2.2.2.2 739 0x8000000C 0x006E23 1 1.1.1.1 1.1.1.1 1087 0x80000009 0x0065A6 2 R1#show ip route ospf 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/2] via 172.10.12.2, 01:52:38, FastEthernet0 R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/2] via 172.10.12.1, 02:01:11, FastEthernet0
40
IGP Routing: IS-IS

IS-IS Overview
Link State routing protocol Employs Cost as the routing metric Supports large scale routing environments Two-level hierarchy supports large routing domains
IS-IS Terms and Operation

SPF - Shortest Path First Algorithm, determines least cost path Level 1 - Routing within an area Level 2 - Routing between areas DIS - Designated Intermediate System, elected on multi-access Attached bit - Set by L1/L2 router in L1 LSP, indicates area exit IS-IS does not have a backbone area like OSPF area 0 Supports clear text and MD5 Authentication with key-chain Type Length Values (TLV) make IS-IS extendable and allow a wide metric style to carry different types of information in it's LSPs such as support for IP routing and MPLS-TE.
41
IGP Routing: IS-IS

IS-IS Network Entity Title (NET)
IS-IS communicates with peers using CLNS PDUs CLNS requires ISO network address or NET NET is 8-20 bytes and is composed of: Area address (1 12 bytes) System ID (6 bytes) NSAP Selector (1 byte) router isis net 49.0000.0000.0001.00 Area = 49 net 49.1515.0000.0000.0001.00 Area = 49.1515
IS-IS Circuit Types and Level Types

Circuit type - defines the IS-IS adjacency formed and is configured as Level 1, Level 2, or Level 1-2. Default is Level 1-2. This permits level flexibility L1 on interface X and Y, L2 on interface Z. Level Type - defines the IS-IS routing Level and is configured as Level 1 (intra-area), Level 2 (inter-area, also known as backbone), or Level 1-2 (both intra-area and interarea). Default is Level 1-2.
42
IGP Routing: IS-IS

IS-IS DIS
DIS Designated Intermediate System. The DIS is similar to the designated router in OSPF. On a LAN, one of the routers will elect itself the DIS based on interface priority (the default is 64). A DIS is not elected on a Point-to-Point link.
IS-IS Pseudonode and LSPs

A pseudonode LSP represents a LAN, including all ISs attached to that LAN, just as a non-pseudonode LSP represents a router, including all ISs and LANs connected with the router.
The DIS creates a pseudonode (a virtual node), and all the routers on a LAN, including the DIS, form an adjacency with the pseudonode instead of forming adjacencies with each other in a full mesh.
R1# show isis database IS-IS Level-1 Link State Database LSPID LSP Seq Num LSP Checksum 0000.0C00.0C35.00-00 0x0000000C 0x5696 0000.0C00.40AF.00-00* 0x00000009 0x8452 0000.0C00.62E6.03-00 0x00000006 0x82BC
43
IGP Routing: IS-IS

IS-IS Routing Overview
Level-1 Router: performs only Level 1 (intra-area) routing and learns only about destinations inside its area. Level 2 (interarea) routing is performed by the closest Level 1-2 router. Level-1-2 Router: performs both Level 1 and Level 2 routing. This router runs two instances of the routing process. It has one linkstate packet database (LSDB) for destinations inside the area (Level 1 routing) and runs a shortest path first (SPF) calculation to discover the area topology. It also has another LSDB with link-state packets (LSPs) of all other backbone (Level 2) routers, and runs another SPF calculation to discover the topology of the backbone, and the existence of all other areas. Level-2-Only Router: acts as a Level 2 (interarea) router only. This router is part of the backbone, and does not communicate with Level 1-only routers in its own area. L1 vs L2 Routing An L1 router has no direct connection to another area. An L2 router only routes inter-area traffic. An L1/L2 router routes both inter-area and intra-area traffic and acts as an inter-area gateway for L1 routers.By default, Level-1 routes are advertised to level-2 routers. By default, level-2 routes are NOT advertised to level-1 routers.
44
IGP Routing: IS-IS

IS-IS Packet Types
CSNP - Complete sequence number PDU's contain a list of all LSPs from the current database. Ensures that all routers are synchronized. PSNP - Partial sequence number PDU's are used to request an LSP (or LSPs) and acknowledge receipt of an LSP (or LSPs). IS-IS Hellos - Level 1 Lan IIH, Level 2 Lan IIH, or Point-to-point IIH LSP - Link-State Packet, four types are: Level 1 pseudonode, Level 1 nonpseudonode, Level 2 pseudonode, and Level 2 nonpseudonode.
45
IGP Routing: IS-IS

IS-IS Configuration
Configure ISIS on R1 & R2. Place Fa0 and Loo0 in Area 49.1000.
R1 Configuration interface Loopback0 Ip address 1.1.1.1 255.255.255.255 ip router isis ! Interface FastEthernet0 ip address 172.16.12.1 255.255.255.0 ip router isis ! router isis net 49.1000.0000.0000.0001.00
R2 Configuration interface Loopback0 Ip address 2.2.2.2 255.255.255.255 ip router isis ! Interface FastEthernet0 ip address 172.16.12.2 255.255.255.0 ip router isis ! router isis net 49.1000.0000.0000.0002.00
46
IGP Routing: IS-IS

IS-IS Verification
R1#show clns interface Fa0 FastEthernet0 is up, line protocol is up Checksums enabled, MTU 1497, Encapsulation SAP Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x0, local circuit ID 0x1 Level-1 Metric: 10, Priority: 64, Circuit ID: R1.01 Level-1 IPv6 Metric: 10 Number of active level-1 adjacencies: 1 Level-2 Metric: 10, Priority: 64, Circuit ID: R1.01 Number of active level-2 adjacencies: 1 Next IS-IS LAN Level-1 Hello in 2 seconds Next IS-IS LAN Level-2 Hello in 432 milliseconds R1# show clns neighbor System Id Interface SNPA Protocol R2 Fa0 c401.02f0.0000
State Holdtime Type Up 25 L1L2 IS-IS
R1# show ip route isis 2.0.0.0/32 is subnetted, 1 subnets i L1 2.2.2.2 [115/20] via 172.16.12.2, FastEthernet0 R2# show ip route isis 1.0.0.0/32 is subnetted, 1 subnets i L1 1.1.1.1 [115/20] via 172.10.16.1, FastEthernet0
47
BGP Routing
BGP Overview BGP Attributes and Path Selection
BGP Route Control

IBGP and EBGP Peering BGP Route Reflectors
48
BGP Routing
BGP Overview
Path vector protocol Core EGP for the Internet Does not use traditional IGP metrics Makes routing decisions based on path and policies
49
BGP Routing
BGP Terms and Operation
iBGP internal BGP, BGP peering within a single AS, AD 200 eBGP external BGP, BGP peering between ASs, AD 20 BGP Peers manually configured on TCP port 179 BGP State Table six different neighbor states BGP Attributes used in path selection and routing policies Path Selection uses route attributes to determine best path Routing Control manipulation of prefix destination or attribute Route Reflectors overcomes full-mesh requirement
AFI Address Family Identifier, 4 BGP AFIs
50
BGP Routing
BGP Overview Neighbor Peering
BGP peers are statically configured and can be sourced from Loopbacks for redundancy. BGP Neighbors transit multiple states during session establishment.
R1 IBGP and EBGP Configuration router bgp 12 << AS 12 bgp router-id 1.1.1.1 neighbor 2.2.2.2 remote-as 12 << same AS = IBGP neighbor 2.2.2.2 update-source loopback0 << reliability neighbor 2.2.2.2 next-hop-self << change EBGP next-hop to R1 Loopback0 neighbor 172.16.13.3 remote-as 3 << different AS = EBGP
R2 IBGP Configuration router bgp 12 bgp router-id 2.2.2.2 neighbor 1.1.1.1 remote-as 12 neighbor 1.1.1.1 update-source loopback0
R3 EBGP Configuration router bgp 3 << AS 3 bgp router-id 3.3.3.3 neighbor 172.16.13.1 remote-as 12
51
BGP Routing
BGP Finite State Machine (FSM)
BGP peer connection establishment has 6 possible states Idle - Initial state of BGP speaker Active - Attempting to connect to configured peer Connect - TCP session with peer established Open Sent - Open message sent Open Confirm - Response received Established - Adjacency established
R1#sh ip bgp neighbors BGP neighbor is 2.2.2.2, remote AS 100, internal link BGP version 4, remote router ID 2.2.2.2 BGP state = Established, up for 00:00:14 Last read 00:00:14, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(old & new) Address family IPv4 Unicast: advertised and received Message statistics: Sent Rcvd Opens: 1 1 Notifications: 0 0 Updates: 0 0 Keepalives: 3 3 Route Refresh: 0 0 Total: 4 4
52
BGP Routing
BGP Messages
BGP messages exchange information and help maintain state between routers in a peering session. Open - used to initiate the BGP session Update - contains the routing updates and are composed of the following: Route Advertisement: The characteristics of a single route Route Withdrawal: A list of networks no longer reachable
Keepalive - packet used to confirm peer availability. When a BGP router fails to hear a Keepalive message, it removes all routes heard from that peer.
Notification - reporting mechanism for operations such as negotiation, udpates, and session tear down
53
BGP Routing
BGP Routing Overview
BGP can receive multiple advertisements for the same route from multiple sources. BGP selects only one path as best. BGP puts the selected path in the IP routing table (RIB) and propagates the path to its neighbors. BGP neighbors exchange full routing information when the TCP connection between neighbors is first established. When changes to the routing table are detected, the BGP speakers send to their neighbors only those routes that have changed. BGP routers do not send periodic routing updates, and BGP routing updates advertise only the optimal path to a destination network. Routes learned via BGP have associated properties that are used to determine the best route to a destination when multiple paths exist. These properties are referred to as BGP attributes.
54
BGP Routing
BGP Updates
BGP updates received are placed in the Routing Information Base (RIB). If the BGP route is better than all other routes in the RIB, then that route is placed in the Forwarding Information Base (FIB). R1#show ip bgp BGP table version is 2, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i2.2.2.0/24 r>i4.4.4.0/24 Next Hop 172.16.1.2 172.16.1.4 Metric LocPrf Weight Path 0 100 0 i 0 100 0 I
R1# show ip route isis 4.0.0.0/24 is subnetted, 1 subnets i L1 4.4.4.0 [115/20] via 172.16.1.4, FastEthernet0
55
BGP Routing
BGP Attributes
BGP Route attributes are used to determine best path. 1. 2. 3. 4. 5. 6. 7. Weight - (Cisco only) default 0, prefer highest Local preference - default 100, prefer highest Multi-Exit Discriminator - default 0, prefer lowest Origin prefer lowest AS Path - prefer shortest Next Hop ensure next hop is valid Community allow classification
R1#show ip bgp BGP table version is 3, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? incomplete Network Next Hop Metric LocPrf Weight Path *>i9.9.9.9/32 3.3.3.3 0 100 0 i R1#sh ip bgp 9.9.9.9 BGP routing table entry for 9.9.9.9/32, version 3 Paths: (1 available, best #1, table Default-IP-Routing-Table) 3.3.3.3 (metric 2) from 3.3.3.3 (3.3.3.3) Origin IGP, metric 0, localpref 100, valid, internal, best Community: 100:9
56
BGP Routing
BGP Attributes Detail
Weight is a Cisco-specific local attribute which is not advertised Local Preference is propagated throughout the local AS and is used to prefer an exit point from the AS Multi-Exit Discriminator is advertised to an external AS for route preference to local AS prefixes
Origin indicates how BGP learned the route and has three values:
IGPThe route is interior to the originating AS. This value is set when the network router configuration command is used EGPThe route is learned via EBGP IncompleteThe origin of the route is unknown or learned in some other way., such as when a route is redistributed into BGP AS Path - list of AS numbers that the route advertisement has traversed. In addition to path selection, AS Path is used to detect routing loops. A router will reject updates which contain its own AS. Next Hop if no route exists to the next hop, the route will be discarded. It is important to have an IGP running in the AS to propagate next-hop routing information Community - provides a way of grouping destinations to which routing decisions can be applied. Predefined community attributes are listed here:
no-exportDo not advertise this route to EBGP peers no-advertiseDo not advertise this route to any peer internetAdvertise this route to all routers in the network
57
BGP Routing
BGP Path Selection: Putting it all together
BGP uses the following criteria, in the order presented, to select a path for a destination prefix: 1. Ensure the Next Hop attribute is valid or drop the update 2. Prefer the highest Weight 3. Prefer the highest Local Preference 4. Prefer route learned from local IGP 5. Prefer the shortest AS Path, prefer 3 2 1 over 4 3 2 1 6. Prefer the lowest Origin type: IGP < EGP < Incomplete 7. Prefer the lowest MED only if the AS is the same for considered routes. This can be overridden with bgp always compare-med 8. Prefer the EBGP path over the IBGP path 9. Prefer the route with the shortest path the BGP Next Hop 10. Prefer the path with the lowest BGP router ID
58
BGP Routing
BGP Route Control: Route Maps
Use route maps for detailed route control in redistribution, policyrouting, route coloring, and route filtering. Match and Set options can be performed on multiple attributes. Route Map Match Options
as-path - Match BGP AS path access list Clns - Match CLNS address, next-hop, route-source Community - Match BGP community list Extcommunity - Match BGP/VPN extended community list Interface - Match first hop interface of route Ip - Match IPv4 address, next-hop, route-source Ipv6 - Match IPv6 address, next-hop, route-source Length - Match Packets with minimum and maximum length Metric - Match metric of route mpls-label - Match routes which have MPLS labels Nlri - Match BGP Unicast or Multicast NLRI types policy-list - Match IP policy map Tag - Match tag of route route-type - Match route-type of route external external route (BGP, EIGRP and OSPF type 1/2) internal internal route (including OSPF intra/inter area) level-1 IS-IS level-1 route level-2 IS-IS level-2 route local locally generated route nssa-external nssa-external route (OSPF type 1/2)
59
BGP Routing
BGP Route Control: Route Maps
Route Map Set Options
as-path - Prepend string for a BGP AS-path attribute automatic-tag - Automatically compute TAG value clns - OSI summary address comm-list - set BGP community list (for deletion) Community - BGP community attribute Dampening - Set BGP route flap dampening parameters Default - Set default information Extcommunity - BGP extended community attribute Interface - Output interface Ip - IP specific information ipv6 - IPv6 specific information Level - Where to import route local-preference - BGP local preference path attribute Metric - Metric value for destination routing protocol metric-type - Type of metric for destination routing protocol mpls-label - Set MPLS label for prefix nlri - BGP NLRI type origin - BGP origin code tag - Tag value for destination routing protocol traffic-index - BGP traffic classification number for accounting weight - BGP weight for routing table
60
BGP Routing
BGP Route Control: Route Map
Route Map Configuration
Ensure inbound prefixes from R2 in the range 192.168.0.0/16 have a local preference of 150 on R1
R1 Solution ip prefix-list 192 permit 192.168.0.0/16 ! route-map R2_IN permit 10 match ip address prefix-list 192 set local-preference 150 ! route-map R2_IN permit 20 << permit all other prefixes ! router bgp 12 neighbor 2.2.2.2 route-map R2_IN in
R1#sh ip bgp Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 0.0.0.0 0 32768 i *> 3.3.3.3/32 172.16.24.4 0 100 0 34 i *> 192.168.1.0/24 2.2.2.2 0 150 0 i *> 192.168.2.0/24 2.2.2.2 0 150 0 i *> 192.168.3.0/24 2.2.2.2 0 150 0 i *> 192.168.4.0/24 2.2.2.2 0 150 0 i
61
BGP Routing
BGP Route Control: Conditional Advertisement
The BGP conditional advertisement feature uses the non-exist-map and the advertise-map to track routes. If the non-exist-map prefix is not present, the route specified by the advertise-map command is announced.
Conditional Advertisement Requirement

R3 is learning prefix 33.33.33.33/32 from AS 33. Ensure this prefix is only advertised to R1 when prefix 22.22.22.22/32 from R2 is not present in R3s BGP routing table.
62
BGP Routing
BGP Route Control: Conditional Advertisement
Conditional Advertisement Configuration
R3 Solution ip prefix-list 22 permit 22.22.22.22/32 ip prefix-list 33 permit 33.33.33.33/32 ! route-map 22 permit 10 << route map 22 will serve as non-exist map match ip address prefix-list 22 ! route-map 33 permit 10 << route map 33 will serve as advertise-map match ip address prefix-list 33 ! router bgp 100 neighbor 172.16.13.1 advertise-map 33 non-exist map 22 R1#sh ip bgp Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 0.0.0.0 0 32768 i *> 3.3.3.3/32 172.16.13.3 0 100 0 3 i *> 22.22.22.22/32 172.16.13.3 0 100 0 3 2 I Note: prefix 33.33.33.33/32 is not propagated to R1 unless prefix 22.22.22.22/32 is not present in R3s routing table.
63
BGP Routing
BGP Route Control: Communities
The BGP communities provide a way of grouping destinations to which routing decisions can be applied.
Community Classification Requirement

R1 is sending IGP learned prefixes with BGP Community value 1:1. R2 is tagging these type prefixes with Community value 2:2. Ensure R1 prefers IGP learned routes from R2 over other matching routes.
64
BGP Routing
BGP Route Control: Communities
Community Classification Solution
R1 Solution ip community-list 2 permit 2:2 ip bgp-community new-format << allow NN:NN community format ! router bgp 12 bgp router-id 1.1.1.1 neighbor 2.2.2.2 send-community neighbor 2.2.2.2 update-source loopback0 neighbor 2.2.2.2 route-map R2_IN in ! route-map R2_IN permit 10 match community 2 set local-preference 200 R1#sh ip bgp Network Next Hop *> 1.1.1.1/32 0.0.0.0 *> 192.168.1.0/24 2.2.2.2 *> 192.168.2.0/24 2.2.2.2
Metric LocPrf Weight Path 0 32768 i 0 200 0 i 0 200 0 I
65
BGP Routing
BGP Neighbor Options
Review and study the many neighbor options in your lab prep
activate Enable the Address Family for this Neighbor advertise-map specify route-map for conditional advertisement advertisement-interval Minimum interval between sending BGP routing updates allowas-in Accept as-path with my AS present in it capability Advertise capability to the peer default-originate Originate default route to this neighbor disable-connected-check One-hop away EBGP peer using loopback address distribute-list Filter updates to/from this neighbor dmzlink-bw Propagate the DMZ link bandwidth ebgp-multihop Allow EBGP neighbors not on directly connected networks fall-over session fall on peer route lost filter-list Establish BGP filters inherit Inherit a template local-as Specify a local-as number maximum-prefix Maximum number of prefixes accepted from this peer next-hop-self Disable the next hop calculation for this neighbor next-hop-unchanged Propagate the iBGP paths's next hop unchanged for this neighbor password Set a password peer-group Member of the peer-group prefix-list Filter updates to/from this neighbor remote-as Specify a BGP neighbor remove-private-as Remove private AS number from outbound updates route-map Apply route map to neighbor route-reflector-client Configure a neighbor as Route Reflector client send-community Send Community attribute to this neighbor send-label Send NLRI + MPLS Label to this peer shutdown Administratively shut down this neighbor soft-reconfiguration Per neighbor soft reconfiguration timers BGP per neighbor timers translate-update Translate Update to MBGP format transport Transport options ttl-security BGP ttl security check unsuppress-map Route-map to selectively unsuppress suppressed routes update-source Source of routing updates version Set the BGP version to match a neighbor weight Set default weight for routes from this neighbor
66
BGP Routing
BGP Next Hop: EBGP to IBGP
The BGP Next-Hop address of EBGP prefixes is not changed when advertised to IBGP peers. This may cause reach ability issues and can be resolved with the neighbor next-hop-self command.
R2#sh ip bgp Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, Network Next Hop Metric LocPrf Weight Path * > i172.10.0.0/16 10.10.12.1 0 100 0 I * i172.30.0.0/16 10.10.13.3 0 100 0 64500 i R2# show ip bgp 172.30.0.0 10.10.13.3 (inaccessible) from 10.10.12.1 (10.10.12.1) Origin IGP, localpref 100, valid, external, internal
67
BGP Routing
BGP Next Hop: Multi-Access Media
When BGP detects a prefix Next-Hop address is on the same subnet as an advertised peer, the Next-Hop remains unchanged. This is a BGP efficiency mechanism.
R3# show ip bgp 172.20.0.0 BGP routing table entry for 172.20.0.0/16, version 8 10.10.123.2 from 10.10.123.1 (10.10.10.1) Origin IGP, localpref 100, valid, external, best
68
BGP Routing
Configuring IBGP and EBGP Peering
Establish an IBGP session between R1 and R2 in AS 12, and between R3 and R4 in AS 34, using their Loopback 0 interfaces as the source address. Establish an EBGP session between R1 and R3, and between R2 and R4. To distribute internal links, use OSPF Area 0 in AS 12 and ISIS Area 49.3434 in AS 34.
AS 12 should advertise their Loopback0 addresses with community value 12:12. AS 34 should advertise their Loopback0 addresses with community value 34:34.
69
BGP Routing
IBGP and EBGP Peering Solution: R1
R1 Solution interface loo0 ip add 1.1.1.1 255.255.255.255 ! interface fa 0/0.12 ip add 172.16.12.1 255.255.255.0 ! interface fa 0/0.13 ip add 172.16.13.1 255.255.255.0 ! router ospf 100 router-id 1.1.1.1 network 1.1.1.1 0.0.0.0 area 0 network 172.16.12.1 0.0.0.0 area 0 ! ip bgp-community new-format << allow NN:NN community format ! router bgp 12 bgp router-id 1.1.1.1 neighbor 2.2.2.2 remote-as 12 neighbor 2.2.2.2 send-community << transmit standard communities neighbor 2.2.2.2 update-source loopback0 neighbor 2.2.2.2 next-hop-self neighbor 172.16.13.3 remote-as 34 neighbor 172.16.13.3 send-community << transmit standard communities network 1.1.1.1 mask 255.255.255.255 route-map LOOP ! route-map LOOP permit 10 set community 12:12
70
BGP Routing
R2 Solution interface loo0 ip add 2.2.2.2 255.255.255.255 ! interface fa 0/0.12 ip add 172.16.12.2 255.255.255.0 ! interface fa 0/0.24 ip add 172.16.24.2 255.255.255.0 ! router ospf 100 router-id 2.2.2.2 network 2.2.2.2 0.0.0.0 area 0 network 172.16.12.2 0.0.0.0 area 0 ! ip bgp-community new-format ! router bgp 12 bgp router-id 2.2.2.2 neighbor 1.1.1.1 remote-as 12 neighbor 1.1.1.1 send-community neighbor 1.1.1.1 update-source loopback0 neighbor 1.1.1.1 next-hop-self neighbor 172.16.24.4 remote-as 34 neighbor 172.16.24.4 send-community network 2.2.2.2 mask 255.255.255.255 route-map LOOP ! route-map LOOP permit 10 set community 12:12
71
BGP Routing
R3 Solution interface loo0 ip add 3.3.3.3 255.255.255.255 ip router isis ! interface fa 0/0.13 ip add 172.16.13.3 255.255.255.0 ! interface fa 0/0.34 ip add 172.16.34.3 255.255.255.0 ip router isis ! router isis net 49.3434.0000.0000.0003.00 ! ip bgp-community new-format ! router bgp 34 bgp router-id 3.3.3.3 neighbor 4.4.4.4 remote-as 34 neighbor 4.4.4.4 send-community neighbor 4.4.4.4 update-source loopback0 Neighbor 4.4.4.4 next-hop-self neighbor 172.16.13.1 remote-as 12 neighbor 172.16.13.1 send-community network 3.3.3.3 mask 255.255.255.255 route-map LOOP ! route-map LOOP permit 10 set community 34:34
72
BGP Routing
R4 Solution interface loo0 ip add 4.4.4.4 255.255.255.255 ip router isis ! interface fa 0/0.24 ip add 172.16.24.4 255.255.255.0 ! interface fa 0/0.34 ip add 172.16.34.4 255.255.255.0 ip router isis ! router isis net 49.3434.0000.0000.0004.00 ! ip bgp-community new-format ! router bgp 34 bgp router-id 4.4.4.4 neighbor 3.3.3.3 remote-as 34 neighbor 3.3.3.3 send-community neighbor 3.3.3.3 update-source loopback0 neighbor 3.3.3.3 next-hop-self neighbor 172.16.24.2 remote-as 12 neighbor 172.16.24.2 send-community network 4.4.4.4 mask 255.255.255.255 route-map LOOP ! route-map LOOP permit 10 set community 34:34
73
BGP Routing
IBGP and EBGP Peering Verification: R1
R1# show ip bgp summary BGP router identifier 1.1.1.1, local AS number 12 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 12 165 165 6 0 0 02:28:13 3 172.16.13.3 4 34 147 147 6 0 0 02:21:14 2 R1# show ip bgp Network Next Hop *> 1.1.1.1/32 0.0.0.0 r>i2.2.2.2/32 2.2.2.2 * i3.3.3.3/32 2.2.2.2 *> 172.16.13.3 *> 4.4.4.4/32 172.16.13.3 *i 2.2.2.2
Metric LocPrf Weight Path 0 32768 i 0 100 0 i 0 100 0 34 i 0 0 34 i 0 34 i 0 100 0 34 i
R1# show ip bgp 3.3.3.3 BGP routing table entry for 3.3.3.3/32, version 5 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 2.2.2.2 34 2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal Community: 34:34 34 172.16.13.3 from 172.16.13.3 (3.3.3.3) Origin IGP, metric 0, localpref 100, valid, external, best Community: 34:34
74
BGP Routing
IBGP and EBGP Peering Verification: R3
R1# show ip bgp summary BGP router identifier 3.3.3.3, local AS number 34 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 4.4.4.4 4 34 161 161 6 0 0 02:24:53 3 172.16.13.1 4 12 152 152 6 0 0 02:26:36 2 R3#show ip bgp Network Next Hop * i1.1.1.1/32 4.4.4.4 *> 172.16.13.1 * i2.2.2.2/32 4.4.4.4 *> 172.16.13.1 *> 3.3.3.3/32 0.0.0.0 r>i4.4.4.4/32 4.4.4.4
Metric LocPrf Weight Path 0 100 0 12 i 0 0 12 i 0 100 0 12 i 0 12 i 0 32768 i 0 100 0i
R3#show ip bgp 1.1.1.1 BGP routing table entry for 1.1.1.1/32, version 2 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 4.4.4.4 12 4.4.4.4 (metric 20) from 4.4.4.4 (4.4.4.4) Origin IGP, metric 0, localpref 100, valid, internal Community: 12:12 12 172.16.13.1 from 172.16.13.1 (1.1.1.1) Origin IGP, metric 0, localpref 100, valid, external, best Community: 12:12
75
BGP Routing
Configuring BGP Route Reflection
BGP Loop avoidance prevents routes received from an IBGP neighbor to be advertised to another IBGP neighbor. This requires that all IBGP routers in the network be connected in logical full mesh to allow for route propagation. Route reflectors are used to eliminate the full mesh requirement and allow for building IBGP networks that scale.
R1 IBGP Route Reflection Configuration router bgp 12 << AS 12 bgp router-id 1.1.1.1 neighbor 2.2.2.2 remote-as 12 << same AS = IBGP neighbor 2.2.2.2 update-source loopback0 << reliability neighbor 2.2.2.2 next-hop-self << change EBGP next-hop to R1 Loopback0 neighbor 2.2.2.2 route-reflector-client neighbor 172.16.13.3 remote-as 3 << different AS = EBGP
R2 IBGP Configuration router bgp 12 bgp router-id 2.2.2.2 neighbor 1.1.1.1 remote-as 12 neighbor 1.1.1.1 update-source loopback0
R3 EBGP Configuration router bgp 3 << AS 3 bgp router-id 3.3.3.3 neighbor 172.16.13.1 remote-as 12
76
BGP Routing
Troubleshooting BGP
show ip bgp and show ip bgp <prefix> Verify BGP routes are recieved and view applies attributes. show ip bgp summary Verify BGP Neighbor state and prefixes received. debug ip bgp updates in/out Verify routes are sent and received.
BGP(0): 2.2.2.2 send UPDATE (format) 1.1.1.1/32, next 1.1.1.1, metric 0, path BGP(0): 2.2.2.2 send UPDATE (format) 3.3.3.3/32, next 1.1.1.1, metric 0, path 34 BGP(0): 2.2.2.2 send UPDATE (format) 4.4.4.4/32, next 1.1.1.1, metric 0, path 34 BGP(0): 2.2.2.2 rcvd UPDATE w/ attr: nexthop 2.2.2.2, origin i, localpref 100, metric 0, community 12:12
clear ip bgp <neighbor> soft Soft reconfiguration of a BGP neighbor. Routes and policies are updated without dropping the session.
77
Multicast Routing
Multicast Routing Overview PIM Family
MSDP
MBGP
78
Multicast Routing
Multicast Routing Overview
Multicast is the process of sending data to a group address Clients in turn, request multicast streams from this group Three components required for multicast routing: Multicast Addressing Group Membership Multicast Routing Protocol
79
Multicast Routing
Multicast Addressing
Multicast IPv4 Address Range - Class D (224.0.0.0/4) An IPv4 multicast address serves as an identifier for the multicast group. Hosts in turn use IGMP to request membership into these groups. The address range is 224.0.0.0 to 239.255.255.255.
Multicast Link Local Addressing 224.0.0.0/24 is designated for multicasting on the local subnetwork only. For example, RIPv2 uses 224.0.0.9 and EIGRP uses 224.0.0.10.
Administratively Scoped Multicast Addressing 239.0.0.0/8 is a locally administered address space with local or organizational scope. It can be used internally by anyone, without concern for overlap, similar to RFC 1918 Private IP Address 10.0.0.0/8. Source-Specific Multicast (SSM) 232.0.0.0/8 is designated for use by Source-specific multicast (SSM).
80
Multicast Routing
Multicast Group Membership
IGMP Hosts request membership into a multicast group by sending an IGMP Membership Report to their local multicast router. Routers periodically send an IGMP Membership Query to verify that at least one host on the subnet is still interested in receiving traffic directed to that group. IGMP Snooping Internet Group Management Protocol (IGMP) is used with LAN switches to limit the forwarding of mcast traffic to only those ports associated with mcast clients. IGMP Snooping requires the LAN switch to examine, or "snoop" Layer 3 information in the IGMP packets sent between the hosts and the router. When a switch hears an IGMP report from a host for a given multicast group, the switch adds the host's port number to the GDA list for that group. And, when the switch hears an IGMP Leave, it removes the host's port from the CAM table entry. IGMP Version 3 IGMPv3 adds support for source filtering as required with SSM. Hosts receive traffic from specific sources in "INCLUDE" mode and from any except specific sources in "EXCLUDE" mode.
81
Multicast Routing
Multicast Routing Protocols
Protocol Independent Multicast Dense Mode (PIM-DM) PIM Sparse Mode (PIM-SM) PIM Source-Specific Multicast (PIM-SSM)
Bidirectional PIM (BiDiR-PIM)

Distance Vector Multicast Routing Protocol (DVMRP) Multicast Border Gateway Protocol (MBGP) Multicast Source Discovery Protocol (MSDP) Multicast Extensions to OSPF (MOSPF)
PIM Protocol Independent Multicast (PIM) is a family of multicast routing protocols, each optimized for a different environment. PIM does not include its own topology discovery mechanism, but instead uses routing information supplied by routing protocols.
82
Multicast Routing
Multicast Routing Protocols: PIM-SM
PIM-SM PIM Sparse Mode (PIM-SM) builds unidirectional Shared Trees, which are rooted at a Rendezvous Point (RP). These are used to forward data from senders to receivers of a multicast group. Sources register with the RP, and then data is forwarded down the shared tree to the receivers. PIM-SM uses a pull model to deliver multicast traffic. In order to receive multicast data, routers use IGMP to express interest in particular groups and sources. PIM elects a Designated Router (DR) on each LAN which is responsible for PIM messaging and active source registration. The DR encapsulates multicast packets sourced from the LAN in a unicast tunnel to the RP. Traveling to the RP, and then back down the shared tree may result in the packets traveling a long distance to reach receivers. To alleviate this, PIM-SM can switch to Shortest Path Tree (SPT) after an mcast message has been received for the group. R2# show ip mroute 239.1.1.1 (*, 239.1.1.1), 00:00:36/00:02:57, RP 1.1.1.1, flags: SP Incoming interface: FastEthernet0/0.12, RPF nbr 172.16.12.1 Outgoing interface list: Null
83
Multicast Routing
Multicast Routing Protocols: PIM-DM
PIM-DM PIM Dense Mode (PIM-DM) builds Shortest-path (Source Based) trees by flooding multicast traffic domain wide, and then pruning back branches of the tree where no receivers are present.
PIM-DM roots the Source Tree at the Multicast Source and does not use an RP like that found in PIM-SM Shared Trees.
PIM-DM assumes that when a source starts sending, all downstream systems want to receive multicast datagrams. Initially, multicast datagrams are flooded to all areas of the network. If some areas of the network do not have group members, PIMDM will prune off the forwarding branch by instantiating prune state. When the Prune lifetime expires, data will again be forwarded down the previously pruned branch. R4# show ip mroute 239.3.3.3 (3.3.3.3, 239.3.3.3), 00:00:11/00:02:48, flags: PT Incoming interface: FastEthernet0/0.34, RPF nbr 172.16.34.3 Outgoing interface list: Null
84
Multicast Routing
Multicast Routing Protocols: BiDir-PIM
BiDir-PIM Bidirectional PIM (BiDir-PIM) is a variant of PIM-SM that builds bidirectional shared trees for multicast sources and receivers. BiDir-PIM differs from PIM-SM in three areas: 1. BiDir-PIM dispenses with PIM encapsulation from Source to RP, allowing packets to be natively forwarded. 2. BiDir-PIM eliminates source-specific State tables and allows forwarding of traffic in all routers solely based on the (*, G) multicast routing entries. 3. Packet forwarding rules have been improved, allowing traffic to be passed up the shared tree toward the RP. To avoid looping, a designated forwarder (DF) election takes place at RP discovery and establishes a loop-free SPT rooted at the RP.
R4#sh ip mroute 239.3.3.3 (*, 239.3.3.3), 00:00:04/00:02:55, RP 3.3.3.3, flags: BP Bidir-Upstream: FastEthernet0/0.34, RPF nbr 172.16.34.3 Outgoing interface list: FastEthernet0/0.34, Bidir-Upstream/Sparse-Dense
85
Multicast Routing
Multicast Routing Protocol: PIM-SSM
PIM-SSM PIM Source-specific multicast (PIM-SSM) is a subset of PIM-SM that does not use an RP, but instead requires that receivers know the (source, group) pair and signal that using IGMPv3. PIM-SSM is simpler than PIM-SM because only the one-to-many model is supported. In PIM-SSM, the receiver expresses interest in receiving traffic from only one specific source sending to that multicast address. This relieves the network of discovering many multicast sources and reduces the amount of multicast routing information that the network must maintain. PIM-SSM builds trees that are rooted in just one source, offering a more secure and scalable model for a limited amount of applications. With SSM, a host identifies a multicast data stream with a source and group address pair (S,G), rather than by group address alone (*,G). R4#sh ip mroute 239.3.3.3 (3.3.3.3, 239.33.33.33), 00:00:19/00:02:40, flags: PT Incoming interface: FastEthernet0/0.34, RPF nbr 172.16.34.3 Outgoing interface list: Null
86
Multicast Routing
Multicast Routing Protocol: PIM RP
PIM RP A Rendezvous Point (RP) is an address that is used as the root of the shared tree for a range of multicast groups. The RP must be reachable from all routers in the PIM domain.
To send to the RP, sources must encapsulate data in PIM control messages and send it by Unicast to the RP. This is done by the source's PIM Designated Router (DR), which is a router on the source's local network. A single PIM DR is elected from all PIM routers on a network, so that unnecessary control messages are not sent.
PIM-SM and BiDir-PIM rely upon RP rooted Shared Trees. PIM-DM, PIM-SSM, DVMRP, MBGP, and MOSPF do not require an RP.
87
Multicast Routing
PIM RP Discovery An important requirement of PIM Sparse Mode, and Bi-directional PIM, is the ability to discover the address of a RP for a multicast group using a shared tree. Common RP discovery mechanisms are Static configuration, Bootstrap Router, and Auto-RP. Static RP Configuration With Static RP, the address of the RP must be configured on every router in the domain. If the network does not have many different RPs defined and/or they do not change very often, then this could be the simplest method to define RPs. Static RP can become a difficult task in a large network. Changing the RP address requires reconfiguring every router. If several RPs are active for different groups, then information on each must be known by all routers. There is no failover procedure and no loadbalancing. Dynamically learned RP takes precedence over manually configured RPs. R2#show ip pim rp mapping PIM Group-to-RP Mappings Group(s): 224.0.0.0/4, Static RP: 1.1.1.1 (R1)
88
Multicast Routing
Bootstrap Router (BSR) The BSR mechanism is a non-proprietary mechanism for routers to learn RP information. Configuration within an mcast domain is only required on the Candidate-BSR and Candidate-RP.
Information regarding several RPs for different groups is automatically communicated to all routers, reducing administrative overhead.
In case of RP failure, the secondary RP for the group can take over as the RP for the group. The Bootstrap Router (BSR) is a mechanism for a router to learn RP information. It ensures that all routers in the PIM domain have the same RP cache as the BSR. Bootstrap messages use the destination address of 224.0.0.13 and have a TTL of 1. BSR messages contain the RP, group address for the candidate RP, and its priority. R2# show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 1.1.1.1 (R1), v2 << Candidate-RP Info source: 1.1.1.1 (R1), via bootstrap, priority 0, holdtime 150 Info Source = Candidate-BSR
89
Multicast Routing
Auto-RP Auto-RP is a Cisco proprietary mechanism to automate distribution of RP information in a multicast network. The Auto-RP mechanism operates using two basic components, the candidate RPs and the RP mapping agents. Candidate RPs advertize their willingness to be an RP via "RPannouncement" messages periodically sent to 224.0.1.39. RP mapping agents join group 224.0.1.39 and map the RPs to the associated groups. The RP mapping agents advertise the authoritative RP-mappings to another well-known group address 224.0.1.40. All PIM routers join 224.0.1.40 and store the RPmappings in their private cache. All routers automatically learn the RP information making it easier to administer and update RP information. There is no configuration needed on every router separately (except on candidate RPs and mapping agents). Auto-RP permits back-up RPs to be configured enabling an RP failover mechanism. R2# show ip pim rp mapping PIM Group-to-RP Mappings RP 1.1.1.1 (R1), v2v1 << Candidate-RP Info source: 1.1.1.1 (R1), via Auto-RP Info Source = RP Mapping Agent
90
Multicast Routing
Multicast Routing Protocols: MRIB and RPF
MRIB The Multicast Routing Information Base (MRIB) is derived from the unicast routing table, or routing protocols such as Multiprotocol BGP (MBGP) that carry multicast-specific topology information.
R2# show ip mroute (*, 239.1.1.1), 00:05:38/00:02:56, RP 1.1.1.1, flags: SP Incoming interface: FastEthernet0/0.12, RPF nbr 172.16.12.1 Outgoing interface list: Null
RPF Check Reverse Path Forwarding (RPF) accepts an mcast packet for forwarding only if it is received on the interface used to reach the source in unicast. R2# show ip rpf 1.1.1.1 RPF information for R1 (1.1.1.1) RPF interface: FastEthernet0/0.12 RPF neighbor: R1 (172.16.12.1) RPF route/mask: 1.1.1.1/32 RPF type: unicast (ospf 100) RPF recursion count: 0
91
Multicast Routing
Multicast Routing Protocols: RPF
RPF Check in Source (DM) and Shared (SM, BiDir) Trees With Source Trees, RPF data is searched for a match on the source IP address. When using Shared Trees, RPF information determines the interface of the router that would be used to send packets towards the RP for the mcast group. Multicast RPF Route Selection If admin distances are equal, the order of preference is: 1. Static mroutes 2. DVMRP routes 3. MBGP routes 4. Unicast routes
92
Multicast Routing
PIM-SM and PIM-BiDir Configurations
PIM-SM Configuration with Static RP ip multicast-routing ip pim rp-address 1.1.1.1 << Static RP ! interface Fa0/0 << RP interface/ LAN interface servicing hosts ip pim sparse-mode
PIM-SM Configuration with BSR ip multicast-routing ip pim bsr-candidate Loopback0 0 << Candidate BSR Mapping Agent ip pim rp-candidate Loopback0 << Candidate RP ! interface Fa0/0 << RP interface/ LAN interface servicing hosts ip pim sparse-mode
BiDir-PIM Configuration with Auto-RP ip multicast-routing ip pim bidir-enable ip pim send-rp-announce Loopback0 scope 10 bidir << Candidate RP ip pim send-rp-discovery scope 10 << RP Mapping Agent ! interface Fa0/0 << RP interface/ LAN interface servicing hosts ip pim sparse-mode
93
Multicast Routing
PIM-DM and PIM-SSM Configurations
PIM-DM Configuration ip multicast-routing ! interface Fa0/0 << LAN interface servicing hosts ip pim dense-mode
PIM-SSM Configuration ip multicast-routing ip pim ssm default ! interface Fa0/0 << LAN interface servicing hosts ip pim sparse-dense-mode ip igmp version 3
94
Multicast Routing
Multicast Routing Protocols: MSDP
Multicast Source Discovery Protocol (MSDP) provides interdomain source active messages and intra-domain redundancy and load sharing. MSDP allows multicast sources for a group to be known to all RP's in different domains. These announcements must originate at the RP of the domain. Each PIM-SM domain uses its own RP's and need not depend on RP's in other domains. MSDP depends heavily on BGP or MBGP for inter-domain operation. Anycast RP is an implementation that uses MSDP an intra-domain role to provide load sharing and redundancy in PIM-SM networks. Anycast RP allows two or more RPs to share the load for source registration and the ability to act as hot backup routers for each other.
95
Multicast Routing
Multicast Routing Protocols: MSDP Configuration
Configure AS12 and AS34 to support PIM-SM. R1 and R4 should use BSR to support RP services in each AS. Ensure AS 12 and 34 support inter-domain multicast and are aware of all active sources.
96
Multicast Routing
Multicast Routing Protocols: MSDP Configuration AS 12
R1 interface loopback0 ip address 1.1.1.1 255.255.255.0 ip pim sparse-mode ip igmp join-group 239.1.1.1 << R1 join group for mcast testing ! interface Fa0/0.12 ip pim sparse-mode ! interface Fa0/0.13 ip pim sparse-mode ! ip pim bsr-candidate Loopback0 0 ip pim rp-candidate Loopback0 ! ip msdp peer 4.4.4.4 connect-source loopback0 remote-as 34 ip msdp originator-id Loopback0 R2 interface Fa0/0.12 ip pim sparse-mode ! interface Fa0/0.24 ip pim sparse-mode
97
Multicast Routing
Multicast Routing Protocols: MSDP Configuration AS 34
R3 interface Fa0/0.12 ip pim sparse-mode ! interface Fa0/0.34 ip pim sparse-mode R4 interface loopback0 ip address 4.4.4.4 255.255.255.0 ip pim sparse-mode ip igmp join-group 239.4.4.4 ! interface Fa0/0.24 ip pim sparse-mode ! interface Fa0/0.34 ip pim sparse-mode ! ip pim bsr-candidate Loopback0 0 ip pim rp-candidate Loopback0 ! ip msdp peer 1.1.1.1 connect-source loopback0 remote-as 12 ip msdp originator-id Loopback0
98
Multicast Routing
Multicast Routing Protocols: MSDP Verification
R2#sh ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 1.1.1.1 (R1), v2 << Candidate-RP Info source: 1.1.1.1 (R1), via bootstrap, priority 0, holdtime 150 Info Source = Candidate-BSR R1#sh ip msdp sa MSDP Source-Active Cache - 2 entries (4.4.4.4, 239.4.4.4), RP 4.4.4.4, BGP/AS 34, 00:00:10/00:05:49, Peer 4.4.4.4 (172.16.34.4, 239.4.4.4), RP 4.4.4.4, BGP/AS 34, 00:00:10/00:05:49, Peer 4.4.4.4 R4#sh ip msdp sa MSDP Source-Active Cache - 2 entries (1.1.1.1, 239.1.1.1), RP 1.1.1.1, BGP/AS 12, 00:00:18/00:05:53, Peer 1.1.1.1 (172.16.12.1, 239.1.1.1), RP 1.1.1.1, BGP/AS 12, 00:00:18/00:05:53, Peer 1.1.1.1 R4# ping 239.1.1.1 Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds: Reply to request 0 from 172.16.13.1, 184 ms
99
Multicast Routing
Multicast Routing Protocols: MBGP
Multiprotocol BGP (MBGP) adds capabilities to BGP to enable multicast routing policy and to connect multicast topologies within and between BGP autonomous systems. MBGP carries two sets of routes, one set for unicast routing and one set for multicast routing. The routes associated with multicast routing are used by PIM to perform Reverse Path Forwarding (RPF) lookups for multicast-capable sources. Multiprotocol BGP allows you to have a unicast routing topology different from a multicast routing topology, giving you more control over your network and resources.
R1 router bgp 12 address-family ipv4 multicast Neighbor 172.16.13.3 activate network 1.1.1.1 mask 255.255.255.255 network 2.2.2.2 mask 255.255.255.255
R3 router bgp 34 address-family ipv4 multicast Neighbor 172.16.13.1 activate network 3.3.3.3 mask 255.255.255.255 network 4.4.4.4 mask 255.255.255.255
R1#sh ip bgp ipv4 multicast BGP table version is 5, local router ID is 1.1.1.1 Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 0.0.0.0 0 32768 i *> 2.2.2.2/32 172.16.12.2 2 32768 i *> 3.3.3.3/32 172.16.13.3 0 0 34 i *> 4.4.4.4/32 172.16.13.3 20 0 34 i
100
MPLS
MPLS Overview Label Overview and Operation
Control and Data Plane Operation

LDP Overview Frame and Cell Mode MPLS
101
MPLS
Multi-Protocol Label Switching (MPLS) Overview
Packet forwarding based on Labels Label Switching improves forwarding time over IP routing P router only maintains routing for P/PE router, BGP-Free Core PE Routers encapsulate packets with MPLS Label Header MPLS uses an IGP and LDP to perform Label Distribution Labels can be generated per LSR (Frame) or per Interface (Cell) Labels are locally significant to the LSR generating them Routers assign labels to define LSP between endpoints
102
MPLS
MPLS Terms and Operation
P Router Provider Router located in SP Cloud PE Router Provider Edge Router facing Customer CE Router Customer Edge Router facing Provider
MPLS - Multi-Protocol Label Switching

Label MPLS uses 32 bit labels to build LSP CEF Cisco Express Forwarding, supports labels RIB Routing Information Base, routing table FIB Forwarding Information Base, used for CEF ops LIB Label Information Base, LDP learned labels LFIB Label Forwarding Information Base, FIB+LIB LDPs Label Distribution Protocol (LDP/TDP) LDP open standard, MD5 Auth TDP Cisco-proprietary LDP, no security LSR Label Switch Router, MPLS enabled router LSP Label Switch Path between LSRs, unidirectional FEC - Forwarding Equivalence Class, group of packets forwarded over the same path, with the same treatment
103
MPLS
MPLS Label Overview
An MPLS label is a 32 bit shim header, consisting of the following: 20 bit label value 3 bit experimental field 1 bit bottom-of-stack indicator 8 bit Time-to-Live field TDP, LDP, RSVP, and BGP are capable of generating MPLS Labels
An MPLS Label is imposed immediately after the L2 Header and before the L3 Header. This is accomplished with the use of LDP.
104
MPLS
MPLS Labels
Value / Description 0 IPv4 Explicit NULL Label 1 Router Alert Label 2 IPv6 Explicit NULL 3 Implicit NULL Label 4-13 Unassigned 14 OAM Alert Label 15 Reserved Label 0: Explicit Null, is inserted onto an IPv4 packet to ensure there is a label. Useful in PHP conditions where QOS values must be maintained. Label 3: Implicit Null Label, if this label is received at the LSP setup, then the top label of received packet should be "popped" and the packet forwarded with the VC label or as an IPpacket. Label 14: OAM Alert label, indicates an ATM cell's management function, such as fault management, performance management, or activation/deactivation
Label 16 and above Label 16 and higher are free to be assigned for traffic purposes by the LSR. No label out of this scope has any specific semantics.
105
MPLS
MPLS Label Operations
An MPLS LSR performs the function of label switching through an LSP. The LSR receives a labeled packet and swaps the local label with an outgoing label and forwards the new labeled packet from the appropriate interface.
The LSR, depending on its location, may perform:

Label Pop Disposition, remove top label, PHP Label Swap replace the top Label in a stack with a new out label Label Push Imposition, swap top label and add label, ex: MPLS-TE Stack Imposition add label stack to a packet, MPLS-VPN Stack Disposition remove entire label stack, non-mpls interface
LSR
LSR
106
MPLS
MPLS Control and Data Plane Operations
The two architectural components of MPLS are the Control Plane and Data Plane. The Data Plane is the forwarding engine for packets or labeled packets processed by the router and contains the Forwarding Information Base (FIB) and Label FIB (LFIB).
The Control plane processes all Layer 3 routing information and performs label assignment. The Control Plane contains the Routing Information Base (RIB), Label Information Base (LIB), IGPs, and LDP.
107
MPLS
MPLS Control and Data Plane Operations
The Forwarding Information Base (FIB) resides in the data plane and mirrors the entire contents of the routing table or RIB and contains a mapping of destination networks to appropriate next-hop adjacencies.
Cisco Express Forwarding (CEF) is a Cisco proprietary switching mechanism that enhances forwarding performance. CEF avoids the overhead of cache rewrites by using the FIB for destination switching decisions.
The Label Information Base (LIB) functions in the control plane and is used by the label distribution protocol where IP destination prefixes in the routing table are mapped to next-hop labels that are received from downstream neighbors, as well as local labels generated by the label distribution protocol. The Label Forwarding Information Base (LFIB) resides in the data plane and contains a local label to next-hop label mapping along with the outgoing interface, which is used to forward labeled packets. The distribution protocol in use between adjacent MPLS neighbors is responsible for the creation of entries in the LIB and LFIB.
108
MPLS
MPLS LFIB
The LFIB maintains a mapping of prefix labels and their next-hop. Label operations are known to each LSR by looking into its LFIB.
R5# show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 500 Pop tag 1.1.1.1/32 4118 Fa0/0.15 172.16.15.1 501 Pop tag 2.2.2.2/32 1517 Fa0/0.25 172.16.25.2
109
MPLS
MPLS Label Distribution Protocol (LDP)
MPLS LDP enables LSRs to exchange Label bindings and form and end to end LSP. LDP associates a Forwarding Equivalence Class (FEC) with each LSP it creates. The FEC associated with an LSP specifies which packets are "mapped" to that LSP. LDP binds prefixes received from an IGP with a locally significant MPLS Label. The Provider network then transports MPLS Label encapsulated packets through the LSP.
110
MPLS
MPLS Label Distribution Protocol (LDP)
LDP performs four operations: LDP Discovery: TDP: UDP 711, LDP: UDP 646 LDP Session establishment: TDP: TCP 711, LDP: TCP 646 Label Exchange: TDP: TCP 711, LDP: TCP 646 Housekeeping / Notification: TDP: UDP 711, LDP: UDP 646
R1# show mpls ldp discovery Local LDP Identifier: 1.1.1.1:0 Discovery Sources: Interfaces: FastEthernet0 (ldp): xmit/recv LDP Id: 2.2.2.2:0
R1# show mpls ldp neighbor Peer LDP Ident: 2.2.2.2; Local LDP Ident 1.1.1.1 TCP connection: 2.2.2.2.28139 - 1.1.1.1.646 State: Oper; Msgs sent/rcvd: 167/166; Downstream LDP discovery sources: FastEthernet0, Src IP addr: 172.16.12.2 Addresses bound to peer LDP Ident: 172.16.12.2 2.2.2.2
111
MPLS
Frame Mode MPLS
Frame Mode MPLS Overview With Frame-mode MPLS, routers running MPLS exchange IP packets and labeled IP packets. Label switching is done by parsing the frame header and then performing label imposition (push), label disposition (pop), or label swapping depending on the LSR's location in the network. Data link layer connectivity in a frame-mode MPLS domain is established using HDLC, PPP, Frame-Relay, Ethernet, or ATM. Frame Mode MPLS Characteristics 1. Label Distribution: Unsolicited Downstream - distribute bindings to upstream LSRs that have not explicitly requested them 2. LSP Control: Independent - each LSR makes an independent decision to bind a label to that FEC and to distribute the label binding 3. Label Retention: Liberal - maintains the bindings between a label and a destination prefix, which are received from downstream LSRs that might not be the next hop for that destination.
112
MPLS
Cell Mode MPLS
Cell Mode MPLS Overview When ATM labels are used in an MPLS core, the operating mode of MPLS is called cell-mode MPLS. The LSRs in the core of the MPLS network are ATM switches that forward data based on the ATM header.
To enable MPLS in the ATM domain, the VPI/VCI field in the ATM header is used as the label. Therefore, a label is inserted between the ATM header and IP header, and the VPI/VCI field of the ATM header forwards the cells. Control plane packets, such as protocol information exchange in routing protocols and label distribution protocols, are exchanged between edge ATM LSRs and the control plane component of the ATM LSR over a control virtual circuit (control VC).
Cell Mode MPLS Characteristics 1. Label Distribution: Downstream On Demand - explicitly request label mapping from downstream router 2. LSP Control: Ordered - LSR only binds a label to a particular FEC if it is the egress LSR for that FEC, or if it has already received a label binding for that FEC from its next hop
3. Label Retention: Conservative - discards bindings received from downstream LSRs that are not next-hop routers for a destination prefix.
113
MPLS
Cell Mode MPLS Interfaces
Label Controlled ATM (LC-ATM) The interfaces of the LSRs in the MPLS domain that carry pure cells are called Label Switching controlled-ATM interfaces (LC-ATM) as the VPI/VCI pairs for the virtual circuits are used by the protocol for distribution and exchange of labels in the ATM domain. LC-ATM interfaces use Downstream On Demand label distribution mode and a per-interface label space. In the integrated ATM LSR implementation, the LC-ATM interfaces carry both the data plane packets as well as the control plane packets (on VC 0/32).
114
MPLS
MPLS Loop Detection
Cell Mode MPLS Loop Detection In cell-mode MPLS, the ATM header does not possess a TTL field. The label distribution protocol used in the control plane for label allocation and distribution relies on the Layer 3 protocols to primarily perform the functions of loop detection. Loop detection is also provided through the use of a hop-count TLV, which contains a count of the number of ATM-LSRs that the label request or label mapping message traversed. Frame Mode MPLS Loop Detection The label distribution protocols, namely LDP and TDP, predominantly rely on loop prevention mechanisms provided by the IGP implemented in the MPLS domain. However, to avoid infinite looping of packets in the MPLS domain, the TTL field in the label header is used. In short, Frame and Cell Mode can rely on the loop prevention mechanisms of the IGP implemented in the MPLS domain. Frame Mode MPLS can use TTL or IGP. Cell mode MPLS can use hop-count TLV or IGP.
115
MPLS
Frame Mode MPLS Configuration
Configure MPLS between R1 and R2. Use Loopback0 as the LDP ID.
R1 Solution ip cef << enable Cisco Express Forwarding mpls label protocol ldp mpls ldp router-id Loopback0 force ! router ospf 100 router-id 1.1.1.1 network 1.1.1.1 0.0.0.0 area 0 network 172.16.12.1 0.0.0.0 area 0 ! interface Fa0 mpls ip
R2 Solution ip cef mpls label protocol ldp mpls ldp router-id Loopback0 force ! router ospf 100 router-id 2.2.2.2 network 2.2.2.2 0.0.0.0 area 0 network 172.16.12.2 0.0.0.0 area 0 ! interface Fa0 mpls ip
116
MPLS
Frame Mode MPLS Verification
Verify session establishment and label binding
R1# show mpls ldp neighbor Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 1.1.1.1:0 TCP connection: 2.2.2.2.23839 - 1.1.1.1.646 State: Oper; Msgs sent/rcvd: 18/18; Downstream Up time: 00:01:35 LDP discovery sources: FastEthernet0/0.12, Src IP addr: 172.16.12.2 Addresses bound to peer LDP Ident: 172.16.24.2 2.2.2.2 10.10.28.2 172.16.12.2
R1# show mpls ldp bindings 2.2.2.2 32 tib entry: 2.2.2.2/32, rev 21 local binding: tag: 103 remote binding: tsr: 2.2.2.2:0, tag: imp-null
R1# show mpls forwarding-table 2.2.2.2 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 103 Pop tag 2.2.2.2/32 0 Fa0/0.12 172.16.12.2
117
MPLS
Cell Mode MPLS Configuration
R1 Solution ip cef << enable Cisco Express Forwarding mpls label protocol ldp mpls ldp router-id Loopback0 force ! router ospf 100 router-id 1.1.1.1 network 1.1.1.1 0.0.0.0 area 0 network 172.16.12.1 0.0.0.0 area 0 ! interface ATM 1/0.1 mpls ip address 172.16.12.1 255.255.255.0 mpls atm control-vc 49 32 mpls atm vpi 49-50 vci-range 33-65535 mpls label protocol tdp mpls ip
118
MPLS
Cell Mode MPLS Configuration
R2 Solution ip cef << enable Cisco Express Forwarding mpls label protocol ldp mpls ldp router-id Loopback0 force ! router ospf 100 router-id 2.2.2.2 network 2.2.2.2 0.0.0.0 area 0 network 172.16.12.2 0.0.0.0 area 0 ! interface ATM 1/0.mpls ip address 172.16.12.2 255.255.255.0 mpls atm control-vc 49 32 mpls atm vpi 49-50 vci-range 33-65535 mpls label protocol tdp mpls ip
119
MPLS
Cell Mode MPLS Verification
Verify session establishment and label binding
R1# show mpls ldp neighbor Peer TDP Ident: 2.2.2.2:1; Local TDP Ident 1.1.1.1:1 TCP connection: 172.16.12.2.11001 - 172.16.12.1.711 State: Oper; PIEs sent/rcvd: 0/12; Downstream on demand Up time: 00:07:23 LDP discovery sources: ATM1/0.1, Src IP addr: 172.16.12.2
R1# show mpls atm-ldp bindings 2.2.2.2 255.255.255.255 Destination: 2.2.2.2/32 Headend Router ATM1/0.1 (1 hop) 49/34 Active, VCD=3 R1# show mpls atm-ldp capability
VPI VCI Alloc Odd/Even VC Merge ATM1/0.1 Range Range Scheme Scheme IN OUT Negotiated [49 - 50] [33 - 1018] UNIDIR - Local [49 - 50] [33 - 1018] UNIDIR NO NO Peer [49 - 50] [33 - 1018] UNIDIR - -
120
Advanced MPLS
MPLS VPN Overview VPN Routing and Forwarding MP-IBGP and MP-EBGP MPLS-TE MVPN
CSC
L2VPN
121
Advanced MPLS
MPLS L3 VPN Overview
MPLS L3 VPN consists of the Provider and Customer Networks Provider controls routing for optimal inter-site traffic PE places customer traffic into VRF and advertises with MBGP P routers provide MPLS Label switching
CE router peers with PE router
122
Advanced MPLS
VPN Routing and Forwarding (VRF)
The VRF routing table is similar to a global routing table, except that it contains all routes pertaining to a specific customer VPN. With multiple customers connected to a single PE, isolation of customer routes into separate VPNs is required. The PE maintains multiple dedicated CEF tables and routing tables for customers connecting into the provider network.
123
Advanced MPLS
VRF Route Distinguisher and Route Target
Route Distinguisher (RD) is a 64-bit identifier that is pre-pended to the customers 32-bit IPv4 prefix to create a globally unique 96bit VPNv4 prefix. The RD is configured per VRF on the PE router. Route Target (RT) identifies the VPN membership of routes. RTs allow selective import and export of VPNv4 prefixes from a VRF. Route-Targets are encoded in a 64 bit BGP extended community (16 bits of Type and 48 bits of Value). The Route Distinguisher and Route Target are configured as: 16-bit AS number: any 32-bit number 32-bit IP address: any 16-bit number Note: valid AS range is 64512 to 65535 or 1024 ASs ip vrf cisco << create virtual routing and forwarding table rd 100:1 << globally unique 64 bit identifier route-target export 100:1 << export routes with an RT of 100:1 route-target import 100:2 << import routes with an RT of 100:2 route-target both 100:3 << import/export routes with RT of 100:3
124
Advanced MPLS
MBGP AFI
Multi-Protocol BGP (MBGP) is used for exchanging VPNv4 routes between PE routers. The PE router must run IGP or BGP which provides NLRI information for MBGP. Partitioning BGP or IGP for customer VRFs is made possible with Address Family Identifiers (AFI). These are subsets of the given routing protocol and allow advertising prefixes within a specific VRF. Cisco supports static, EIGRP, RIPv2, OSPFv2, and ISIS, and BGP.
125
Advanced MPLS
MBGP and VPN Labels
MBGP is also responsible for assignment of a VPN label to Customer traffic. Packet forwarding in an MPLS VPN mandates that the router specified as the next hop in the incoming BGP update is the same router that assigns the 3 byte VPN label. The PE requires a VPN Label to identify which VRF the traffic belongs to. The VPN Label is referred to as the Inner Label while the IGP or Transport Label is the Outer Label. While the Outer or IGP Label will be swapped or have other Label operations performed upon it, the VPN label remains unchanged throughout the Provider Network.
126
Advanced MPLS
VPNv4 Updates
The VPNv4 Prefix is 96 bits in length (RD=64+IPv4=32). The VPNv4 Update contains: 64 bit Extended Community (Route Target, Site Of Origin) Label used for VPN packet forwarding Next-Hop Other BGP attributes (AS-Path, Local Preference, MED, etc) R4# show ip bgp vpnv4 all 10.10.10.10 BGP routing table entry for 100:1:10.10.10.10/32, version 5 Paths: (1 available, best #1, table ACME) Not advertised to any peer 123 << originating AS 1.1.1.1 from 5.5.5.5 (5.5.5.5) << next-hop 1.1.1.1 Origin IGP, metric 0, localpref 100, valid, internal, best Extended Community: RT:100:1, mpls labels in/out nolabel/101 << Label
127
Advanced MPLS
Intra-AS VPN
Within a single Provider AS, PE routers will form MP-IBGP VPNv4 adjacencies to exchange VPN prefixes. P and PE routers will form IGP and LDP adjacencies.
128
Advanced MPLS
Intra-AS VPN CE1 and PE1 Configuration
Configure CE1 in VRF ABC. PE1 and PE2 should establish IBGP VPNv4 adjacencies.
CE1 (R6) interface FastEthernet0/0.36 ip address 172.16.36.6 255.255.255.0 ! router ospf 100 network 0.0.0.0 255.255.255.255 area 0
PE1 (R3) Lo0:3.3.3.3
CE1 (R6) Lo0:6.6.6.6
PE1 (R3) ip vrf ABC rd 1:1 route-target both 1:1 ! interface FastEthernet0/0.36 ip vrf forwarding ABC ip address 172.16.36.3 255.255.255.0 ! router ospf 100 vrf ABC network 172.16.36.3 0.0.0.0 area 0 redistribute bgp 34 subnets ! router bgp 34 address-family vpnv4 neighbor 4.4.4.4 activate neighbor 4.4.4.4 send-community extended ! address-family ipv4 vrf ABC redistribute ospf 100 match internal external 1 external 2
129
Advanced MPLS
Intra-AS VPN CE1 and PE1 Verification
Verify CE to PE reachability and VRF route table
R3# show ip route << Global Routing Table 3.0.0.0/32 is subnetted, 1 subnets C 3.3.3.3 is directly connected, Loopback0 4.0.0.0/32 is subnetted, 1 subnets i L1 4.4.4.4 [115/20] via 172.16.34.4, FastEthernet0/0.34 172.16.0.0/24 is subnetted, 2 subnets C 172.16.34.0 is directly connected, FastEthernet0/0.34 C 172.16.13.0 is directly connected, FastEthernet0/0.13
R3# show ip route vrf ABC << VRF ABC Routing Table 5.0.0.0/32 is subnetted, 1 subnets 6.0.0.0/32 is subnetted, 1 subnets O 6.6.6.6 [110/2] via 172.16.36.6, 00:11:28, FastEthernet0/0.36 172.16.0.0/24 is subnetted, 2 subnets C 172.16.36.0 is directly connected, FastEthernet0/0.36
R3# ping vrf ABC 6.6.6.6 Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 2/63/112ms
130
Advanced MPLS
Intra-AS VPN CE2 and PE2 Configuration
Configure CE2 in VRF ABC. PE1 and PE2 should establish IBGP VPNv4 adjacencies.
CE1 (R5) interface FastEthernet0/0.45 ip address 172.16.45.5 255.255.255.0 ! router ospf 100 network 0.0.0.0 255.255.255.255 area 0
PE2 (R4) Lo0:4.4.4.4
CE1 (R5) Lo0:5.5.5.5
PE1 (R4) ip vrf ABC rd 1:1 route-target both 1:1 ! interface FastEthernet0/0.45 ip vrf forwarding ABC ip address 172.16.45.4 255.255.255.0 ! router ospf 100 vrf ABC network 172.16.45.4 0.0.0.0 area 0 redistribute bgp 34 subnets ! router bgp 34 address-family vpnv4 neighbor 3.3.3.3 activate neighbor 3.3.3.3 send-community extended ! address-family ipv4 vrf ABC redistribute ospf 100 match internal external 1 external 2
131
Advanced MPLS
Intra-AS VPN CE2 and PE2 Verification
Verify CE to PE reachability and VRF route table
R4# show ip route << Global Routing Table 3.0.0.0/32 is subnetted, 1 subnets i L1 3.3.3.3 [115/20] via 172.16.34.3, FastEthernet0/0.34 4.0.0.0/32 is subnetted, 1 subnets C 4.4.4.4 is directly connected, Loopback0 172.16.0.0/24 is subnetted, 2 subnets C 172.16.34.0 is directly connected, FastEthernet0/0.34 C 172.16.24.0 is directly connected, FastEthernet0/0.24
R4# show ip route vrf ABC << VRF ABC Routing Table 5.0.0.0/32 is subnetted, 1 subnets O 5.5.5.5 [110/2] via 172.16.45.5, 01:00:51, FastEthernet0/0.45 6.0.0.0/32 is subnetted, 1 subnets 172.16.0.0/24 is subnetted, 2 subnets C 172.16.45.0 is directly connected, FastEthernet0/0.45
R4# ping vrf ABC 5.5.5.5 Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 2/54/95ms
132
Advanced MPLS
Intra-AS VPN CE1 to CE2 Verification
Verify CE to CE reachability and VRF route table
R3# show ip bgp vpnv4 all Network Next Hop *>i5.5.5.5/32 4.4.4.4 *> 6.6.6.6/32 172.16.36.6 *> 172.16.36.0/24 0.0.0.0 *>i172.16.45.0/24 4.4.4.4
Metric LocPrf Weight Path 2 100 0 2 32768 0 32768 0 100 0
R3# show ip bgp vpnv4 vrf ABC labels Network Next Hop In label/Out label 5.5.5.5/32 4.4.4.4 nolabel/17 6.6.6.6/32 172.16.36.6 17/nolabel 172.16.36.0/24 0.0.0.0 18/aggregate(ABC) 172.16.45.0/24 4.4.4.4 nolabel/18 R3# show ip route vrf ABC | incl 5.5.5.5 B 5.5.5.5 [200/2] via 4.4.4.4, 00:52:39 R6# show ip route ospf O IA 5.5.5.5 [110/3] via 172.16.36.3, 00:08:45, FastEthernet0/0.36 O IA 172.16.45.0 [110/2] via 172.16.36.3, 00:08:45, FastEthernet0/0.36 R6# ping 5.5.5.5 << Ping from CE1 to CE2 Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 88/91/99 ms
133
Advanced MPLS
Inter-AS VPN
In a regional or larger network, client VPN sites may use different MPLS VPN Provider networks. To enable VPN services across multiple service providers, the VPN information has to be mutually redistributed.
The MBGP Inter-AS feature allows the VPN information to be redistributed between adjacent MPLS VPN entities so that client sites dispersed across multiple service provider backbones can communicate with each other.
There are three options to distribute VPNv4 information across the ASBR routers:
Option 1: Back-to-back VRF Option 2: MP-EBGP Between ASBR's -Option 2a: Using the next-hop-self method - Option 2b: Using the redistribute connected approach -Option 2c: Multi-hop MP-eBGP Option 3: Multi-hop MP-EBGP Between Route-Reflectors
134
Advanced MPLS
Inter-AS VPN Option 1: Back-to-Back VRF
ASBR's are interconnected with logical subinterfaces or multiple physical links. Each subinterface or interface connected between the ASBRs is dedicated to a single client VRF. Each ASBR takes on a PE role and treats the opposite ASBR as a CE router, placing traffic into specific VRF's. Because of the requirement for dedicated interfaces, Option 1 lacks scalability.
135
Advanced MPLS
Inter-AS VPN Option 2: MP-EBGP between ASBR's
ASBRs use MP-EBGP to peer directly with each other for VPNv4 route exchange. This approach does not require perVPN configuration on the ASBRs. Because VPNv4 updates are encapsulated in MPLS packets, the link between the ASBRs must support the exchange of Labeled packets.
136
Advanced MPLS
Inter-AS VPN Option 2: MP-EBGP between ASBR's
In an MPLS VPN network, packet forwarding takes place only if the router specified as the BGP next hop in the incoming BGP update is the same as the router that assigned the VPN label. Because the next hop is changed when there is an EBGP session between the ASBR, the LSP path terminates on the ASBR originating the update. As a result, the advertising ASBR has to assign a new label for the route before sending it via the MP-EBGP update to its ASBR peer. Since AS Providers do not usually maintain LSP's between each other, the inter-as MPLS label Exchange is normally done using next-hop-self on the opposing ASBR. A new VPN label is assigned whenever the BGP next hop is changed. There is no requirement of TDP/LDP or any IGP to be enabled on the link connecting the two ASBRs. The default behavior of a MBGP VPNv4 speaker is to deny incoming VPNv4 prefixes that are not imported into a local VRF. The router bgp command "no bgp default route-target filter" should be configured on each ASBR that does not have any VRFs configured or is functioning as a RR. The command ensures that the ASBR accepts the BGP VPNv4 prefixes from other PE routers inside the AS.
137
Advanced MPLS
Inter-AS VPN Option 3: MP-EBGP Between RRs
VPN information is exchanged between MP-EBGP VPNv4 Route Reflectors. To meet this requirement, each provider needs to have MP-IBGP RRs for local VPNv4 prefix distribution and an EBGP connection between RRs to exchange prefixes with the external peer. The ASBRs in this option participates in exchange of EBGP next-hop-address using IPv4 labels, and RRs form an MP-EBGP session to transport VPNv4 information.
138
Advanced MPLS
Configuring Inter-AS Option 2: MP-EBGP on ASBR's
Configure the ASBRs in AS 123 and AS456 to support MP-EBGP VPNv4 updates using Inter-AS Option 2.
AS 123 ASBR (R1) router bgp 123 no bgp default ipv4-unicast << Require AFI peer activation no bgp default route-target filter << Accept all VPNv4 routes neighbor 2.2.2.2 remote-as 123 << IBGP Peer neighbor 172.16.14.4 remote-as 456 << EBGP Peer ! address-family vpnv4 << MBGP neighbor 172.16.14.4 activate << MP-EBGP Peer neighbor 172.16.14.4 send-community extended neighbor 2.2.2.2 activate << MP-IBGP Peer neighbor 2.2.2.2 next-hop-self << Generate new label
AS 456 ASBR (R4) router bgp 456 no bgp default ipv4-unicast << Require AFI peer activation no bgp default route-target filter << Accept all VPNv4 routes neighbor 5.5.5.5 remote-as 456 << IBGP Peer neighbor 172.16.14.1 remote-as 123 << EBGP Peer ! address-family vpnv4 << MBGP neighbor 172.16.14.1 activate << MP-EBGP Peer neighbor 172.16.14.1 send-community extended neighbor 5.5.5.5 activate << MP-IBGP Peer neighbor 5.5.5.5 next-hop-self << Generate new label
139
Advanced MPLS
Verify Inter-AS Option 2: MP-EBGP on ASBR's
Verify VPNv4 prefix delivery and next-hop
R4# show ip bgp vpnv4 all Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1000:1000 *> 10.10.10.10/32 172.16.14.1 0 0 123 i *> 11.11.11.11/32 172.16.14.1 0 0 123 i Route Distinguisher: 4000:4000 (default for vrf 4000) *> 40.40.40.40/32 0.0.0.0 0 32768 i *> 41.41.41.41/32 0.0.0.0 0 32768 i
PE# show ip ro vrf 4000 Routing Table: 4000 B 10.10.10.10 [20/0] via 4.4.4.4, 00:05:02 B 11.11.11.11 [20/0] via 4.4.4.4, 00:05:02 B 40.40.40.40 [20/0] via 4.4.4.4, 00:05:02 B 41.41.41.41 [20/0] via 4.4.4.4, 00:05:02
140
Advanced MPLS
Configuring Inter-AS Option 3: MP-EBGP between RRs
Configure the RRs in AS 123 and AS456 to support MP-EBGP VPNv4 updates using Inter-As Option 3.
AS 123 ASBR (R1) router bgp 123 no bgp default route-target filter << Accept all VPNv4 routes neighbor 172.16.14.4 remote-as 456 << EBGP Peer ! address-family ipv4 neighbor 2.2.2.2 send-label << Send Transport Label to R2 neighbor 172.16.14.4 send-label ! address-family vpnv4 neighbor 2.2.2.2 activate << MP-IBGP Peer
AS 123 RR (R2) router bgp 123 no bgp default route-target filter neighbor 5.5.5.5 remote-as 456 neighbor 5.5.5.5 update-source Looback0 neighbor 5.5.5.5 ebgp-multihop << EBGP hop count (255) ! address-family ipv4 neighbor 1.1.1.1 send-label << Send Transport Label to R1 ! address-family vpnv4 neighbor 5.5.5.5 activate << MP-EBGP Peer neighbor 5.5.5.5 next-hop-unchanged << Maintain next-hop
141
Advanced MPLS
Configuring Inter-AS Option 3: MP-EBGP between RRs
Configure the RRs in AS 123 and AS456 to support MP-EBGP VPNv4 updates using Inter-As Option 3.
AS 456 ASBR (R4) router bgp 456 no bgp default route-target filter << Accept all VPNv4 routes neighbor 172.16.14.1 remote-as 123 << EBGP Peer ! address-family ipv4 neighbor 5.5.5.5 send-label << Send Transport Label to R5 neighbor 172.16.14.1 send-label ! address-family vpnv4 neighbor 5.5.5.5 activate << MP-IBGP Peer
AS 456 RR (R5) router bgp 456 no bgp default route-target filter neighbor 2.2.2.2 remote-as 123 neighbor 2.2.2.2 update-source Looback0 neighbor 2.2.2.2 ebgp-multihop << EBGP hop count (255) ! address-family ipv4 neighbor 4.4.4.4 send-label << Send Transport Label to R4 ! address-family vpnv4 neighbor 2.2.2.2 activate << MP-EBGP Peer neighbor 2.2.2.2 next-hop-unchanged << Maintain next-hop
142
Advanced MPLS
Verify Inter-AS Option 3: MP-EBGP between RRs
Verify VPNv4 prefix delivery
R5# show ip bgp vpnv4 all Network Next Hop Route Distinguisher: 100:1 *> 10.10.10.10/32 1.1.1.1 *>i40.40.40.40/32 4.4.4.4
Metric LocPrf Weight Path 0 123 i 0I
0 100
R4# show ip bgp vpnv4 all Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 5.5.5.5 4 456 38 41 5 0 0 00:32:21 1 R4# show ip ro vrf ACME Routing Table: ACME C 40.40.40.40 is directly connected, Loopback40 B 10.10.10.10 [200/0] via 1.1.1.1, 00:26:22 R4# ping vrf ACME 10.10.10.10 Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/27/64 ms R1# show ip ro vrf ACME Routing Table: ACME B 40.40.40.40 [200/0] via 4.4.4.4, 00:28:30 C 10.10.10.10 is directly connected, Loopback10 R1# ping vrf ACME 40.40.40.40 Sending 5, 100-byte ICMP Echos to 40.40.40.40, timeout is 2 seconds:!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/24/52 ms
143
Advanced MPLS
Verify Inter-AS Option 3: MP-EBGP between RRs
Verify IGP/Transport Label delivery
R1# show ip route ospf << View external IGP prefixes 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/2] via 172.16.12.2, 00:46:40, FastEthernet0/0.12 R1# show mpls ldp bindings remote binding: tsr: 2.2.2.2:0, tag: 200 tib entry: 2.2.2.2/32, rev 17 << The only external prefix known to LDP local binding: tag: 100 remote binding: tsr: 2.2.2.2:0, tag: imp-null R1# show ip bgp labels << BGP send-label overcomes the LDP label issue Network Next Hop In Label/Out Label 1.1.1.1/32 0.0.0.0 imp-null/nolabel 2.2.2.2/32 2.2.2.2 100/imp-null 4.4.4.4/32 172.16.14.4 103/imp-null 5.5.5.5/32 172.16.14.4 104/18
144
Advanced MPLS
MBGP PE-CE Routing Notes
BGP CE AS Override If PE-CE BGP uses same AS, use neighbor x.x.x.x as-override OSPF CE Route Types The OSPF Process ID/Domain ID and Loop Prevention Mechanisms will affect routing propagation and route types. Matching Process ID/Domain ID O IA, inter-area route Non-matching Process ID/Domain ID E2, External Type 2 OSPF CE Loop Prevention OSPF Loop prevention sets the Down Bit for IA Routes. Redundant CE or ABR drop these routes. The OSPF command capability vrflite disables loop checks. Alternatively, you can change the OSPF Domain-ID to a unique value on each router. OSPF Sham-Link If a Customer has 2 CE routers connected to each other and connected to the Provider network, the Provider network will only be used as backup by default. This is because the Provider appears as Inter-Area while the direct connection appears as Intra-Area. The OSPF Sham-Link feature makes the Provider network appear as intra-area.
145
Advanced MPLS
VPNv4 PE-CE Routing Notes
EIGRP When defining EIGRP on PE and CE, ensure AS matches to preserve metrics and deliver routes as internal. Non-matching AS loses metrics and delivers routes as external. PE router eigrp 10 address-family ipv4 vrf ABC << EIGRP AFI for VRF ABC eigrp router-id 10.10.10.1 autonomous-system 100 << match EIGRP AS with PE and CE redistribute bgp 123 metric 1 1 1 1 1 network 10.10.10.0 0.0.0.255 no auto-summary CE router eigrp 100 eigrp router-id 10.10.10.2 network 10.10.10.0 0.0.0.255 no auto-summary
RIPv2 The commandredistribute bgp 100 metric transparent preserves the RIPv2 metric when redistributing from MBGP to RIPv2.
146
Advanced MPLS
MPLS Traffic Engineering (MPLS TE)
Traffic Engineering (TE) is the process of steering traffic across a network to facilitate efficient use of available bandwidth. MPLS TE allows the Head End router of a Label Switched Path (LSP) to calculate the most efficient path through the MPLS network to the LSP Tail End Router.
147
Advanced MPLS
MPLS TE Tunnels
Traffic Engineering (TE) is the process of steering traffic across a network to facilitate efficient use of available bandwidth. MPLS TE allows the Head End router of a Label Switched Path (LSP) to calculate the most efficient path and create a TE Tunnel through the MPLS network to the LSP Tail End Router. MPLS-TE Tunnels are mapped paths for traffic flows of a specific Class of Service (CoS). This traffic is forwarded along a specific path as defined by the TE Tunnel. Each TE Tunnel is assigned a specific Label Switched Path (LSP) and a specific bandwidth reservation. This can be statically assigned or assigned dynamically by an IGP. In an MPLS network, all TE tunnel configurations are performed on Provider Edge (PE) routers. The TE tunnels or LSPs will be used to link the edge routers across the core of the service provider network. TE tunnels configured on routers are unidirectional. Therefore, to implement bidirectional Traffic Engineering between PE Routers, a pair of tunnels must be configured.
148
Advanced MPLS
MPLS TE RSVP Signaling
MPLS TE uses RSVP to exchange labels, setup the LSP Path, and perform TE signaling. The router installs an LDP label in the forwarding table if the prefix is learned through an LDP interface, and it installs the RSVP label in the forwarding table if the prefix is learned over a TE tunnel interface. RSVP messages are sent by the Head end router to identify resource availability along the path. The four messages used are:
Path Messages: checks the availability of requested resources and performs signaling in conjunction with RESV. Reservation-Request Messages: confirms the reservation request sent with the Path message. RESV also carrys labels and performs signaling in conjunction with PATH. Error & Confirmation Messages: notification, ex: unavailable requested resources Teardown Messages: clear the Path or Reservation states
149
Advanced MPLS
MPLS TE Link State IGP Requirement
The Head End TE router requires information pertaining to the resource availability on all links capable of being a part of the MPLS TE tunnel. Link State IGP's (ISIS and OSPF) provide a complete topology for MPLS-TE by propagating required information such as Link Attributes, Available bandwidth, and Tunnel Metrics.
This information is provided by the inherent operation of flooding information about links to all routers in the IGP domain. In IS-IS, a new TLV (Type 22) has been developed to transmit information pertaining to resource availability and link status in the LS-PDUs. In OSPF, the Type 10 Opaque LSA provides resource and links status information. When this information is flooded in IGP updates, the ingress Head End router gathers information on all the available resources in the network along with the topology, which defines tunnels through the network between a set of MPLSenabled routers.
150
Advanced MPLS
MPLS TE Fast Reroute (FRR)
MPLS-TE also offers redundancy as a second path in the event of primary path failure. Fast Reroute (FRR) allows you to reroute labeled traffic around a link or router that has become unavailable. When a router is notified that the primary link is no longer available, it simply forwards traffic through the backup tunnel. This is accomplished by pushing the label for the backup tunnel onto packets after the normal swap operation. The The Tunnel Label is removed at the egress router and the packet is forwarded normally. FRR requires a minimum of two labels - the Backup Tunnel Label in addition to the IGP Label or current label stack. The RSVP hello state timer detects when a neighbor is down and triggers a state timeout to reduce network convergence time and free resources such as bandwidth for use by other label-switched paths.
151
Advanced MPLS
MPLS TE Fast Reroute (FRR)
MPLS-TE also offers redundancy as a second path in the event of primary path failure. Fast Reroute (FRR) allows you to reroute labeled traffic around a link or router that has become unavailable. When a router is notified that the primary link is no longer available, it simply forwards traffic through the backup tunnel. This is accomplished by pushing the label for the backup tunnel onto packets after the normal swap operation. The The Tunnel Label is removed at the egress router and the packet is forwarded normally. FRR requires a minimum of two labels - the Backup Tunnel Label in addition to the IGP Label or current label stack. The RSVP hello state timer detects when a neighbor is down and triggers a state timeout to reduce network convergence time and free resources such as bandwidth for use by other label-switched paths.
152
Advanced MPLS
Configuring MPLS-TE
Configure R1, R2, and R3 to support MPLS-TE to guarantee bandwidth up to 20Mbps. Any traffic on R1 destined to R3 Loo33 should use the path through R2. Configure Tunnel 13 on R1 and ensure a 10Mb guarantee for this traffic. A static route on R1 is permitted.
153
Advanced MPLS
Configuring MPLS-TE with OSPF: R1 Head End
Configure R1, R2, and R3 to support MPLS-TE
R1 mpls traffic-eng-tunnels ! interface FastEthernet0/0.13 mpls traffic-eng-tunnels ip rsvp bandwidth 20000 << Guarantee 20Mb ! router ospf 100 mpls traffic-eng router-id Loopback0 << bind MPLS TE to Loopback0 mpls traffic-eng area 0 ! interface Tunnel13 ip unnumbered Loopback0 tunnel destination 3.3.3.3 << R3 Loo0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng bandwidth 10000 << Require 10Mb tunnel mpls traffic-eng path-option 1 explicit name T13 ! ip route 33.33.33.33 255.255.255.255 Tunnel13 name R3_Lo33
Alternative TE Routing Options tunnel mpls traffic-eng path-option 1 dynamic << IGP chooses path tunnel mpls traffic-eng autoroute announce << IGP advertises tunnel
154
Advanced MPLS
Configuring MPLS-TE: R2 and R3
Configure R1, R2, and R3 to support MPLS-TE
R2 mpls traffic-eng-tunnels ! interface FastEthernet0/0.12 mpls traffic-eng-tunnels ip rsvp bandwidth 20000 ! interface FastEthernet0/0.23 mpls traffic-eng-tunnels ip rsvp bandwidth 20000 ! router ospf 100 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 R3 mpls traffic-eng-tunnels ! interface FastEthernet0/0.23 mpls traffic-eng-tunnels ip rsvp bandwidth 20000 ! router ospf 100 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0
155
Advanced MPLS
Verify MPLS-TE
Verify Tunnel establishment and traffic flow
R1#show mpls traffic-eng tunnels Name: R1_t13 (Tunnel13) Destination: 3.3.3.3 Status: Admin: up Oper: up Path: valid Signalling: connected Config Parameters: Bandwidth: 10000 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF OutLabel : FastEthernet0/0.12, 203 RSVP Signalling Info: Src 1.1.1.1, Dst 3.3.3.3, Tun_Id 13, Tun_Instance 31 RSVP Path Info: My Address: 172.16.12.1 Explicit Route: 172.16.12.2 172.16.23.2 172.16.23.3 3.3.3.3 Tspec: ave rate=10000 kbits, burst=1000 bytes, peak rate=10000 kbits Current LSP: Uptime: 12 seconds
R1# show ip explicit-paths PATH T13 (strict source route, path complete, generation 10) 1: next-address 172.16.12.2 2: next-address 172.16.23.3
156
Advanced MPLS
Verify MPLS-TE: R3
Verify Tunnel establishment and traffic flow
R3#sh mpls traffic-eng tunnels LSP Tunnel R1_t13 is signalled, connection is up InLabel : FastEthernet0/0.23, implicit-null OutLabel : RSVP Signalling Info: Src 1.1.1.1, Dst 3.3.3.3, Tun_Id 13, Tun_Instance 31 RSVP Path Info: My Address: 3.3.3.3 Explicit Route: NONE Record Route: NONE Tspec: ave rate=10000 kbits, burst=1000 bytes, peak rate=10000 kbits
R3# debug ip packet << ping from R1 Loo0 to R3 Loo33 prior to MPLS-TE s=1.1.1.1 (FastEthernet0/0.13), d=33.33.33.33 (Loopback33) s=33.33.33.33 (local), d=1.1.1.1 (FastEthernet0/0.13)
R3# debug ip packet << ping from R1 Loo0 to R3 Loo33 after MPLS-TE s=1.1.1.1 (FastEthernet0/0.23), d=33.33.33.33 (Loopback33) s=33.33.33.33 (local), d=1.1.1.1 (FastEthernet0/0.13)
157
Advanced MPLS
Configuring MPLS-TE with ISIS: R1 Head End
Configure R1 to support MPLS-TE
R1 mpls traffic-eng-tunnels ! interface FastEthernet0/0.13 mpls traffic-eng-tunnels ip rsvp bandwidth 20000 << Guarantee 20Mb ! router isis metric-style wide << enable wide metrics for MPLS TE mpls traffic-eng router-id Loopback0 << bind MPLS TE to Loopback0 mpls traffic-eng level-2 ! interface Tunnel13 ip unnumbered Loopback0 tunnel destination 3.3.3.3 << R3 Loo0 tunnel mode mpls traffic-eng tunnel mpls traffic-eng bandwidth 10000 << Require 10Mb tunnel mpls traffic-eng path-option 1 explicit name T13 ! ip route 33.33.33.33 255.255.255.255 Tunnel13 name R3_Lo33
158
Advanced MPLS
Multicast VPN (MVPN) Overview
MPLS has no native ability to support Multicast. Multicast VPN (MVPN) introduces a separate function to enable IP Multicast over MPLS. MVPN builds a default Multicast Distribution Tree (MDT) between PE routers configured to participate in the same Multicast Domain. The MVPN solution uses GRE with MDT forwarding to achieve scalability of IP Multicast in the core network.
159
Advanced MPLS
Multicast VPN (MVPN) Terms and Operations
Multicast VRF (MVRF) - Multicast enabled VRF Multicast Domain (MD) - group of MVRF's Multicast Distribution Tree (MDT) - collection of multicast capable routers. An MDT is sourced by a PE router and has a multicast destination address. PE routers that have sites for the same MVPN will all source to a Default-MDT and also join to receive traffic on it. Default-MDT - created by the MVPN configuration. Used for customer Control Plane and low rate Data Plane traffic. All PE routers configured with the same default-MDT will receive this traffic. With only a default-MDT configured, traffic will go to all PE routers, regardless of whether they want to receive the traffic. Default-MDTs must have the same group address for all VRFs that comprise a MVPN. Data-MDT - created on demand by the existence of active sources sending to active receivers behind PE routers. The Data MDT will only connect to PE routers that are either attached to active sources or receivers of traffic from active sources. They can be created either by a traffic rate threshold and/or source-group pair. Data-MDT's can be used to optimize MVPN traffic flow. Data-MDTs may have the same group address if PIM-SSM is used. If PIM-SM is used, they must have a different group address, as providing the same one could result in the PE router receiving unwanted traffic.
160
Advanced MPLS
Multicast VPN (MVPN) PIM Support
MVPN required PIM to be configured in the Provider core. PIM-SM, PIM-SSM, and PIM-BIDIR are all supported inside the provider core for MVPN. PIM-SM, PIM-SSM, PIM-BIDIR and PIM-DENSE-MODE are supported inside the Customer MVPN. P routers do not hold state information for individual customer source trees; instead, they can hold as little as a single state entry for each VPN (assuming PIM Bi-Dir) regardless of the number of multicast groups within that VPN. A PE router in an MVPN network has multiple multicast routing tables. There is one global multicast table and one table per MVRF. MVPN multicast routes are distributed as normal MBGP updates. CE routers maintain a PIM adjacency with their local PE router only, and not with other CE routers.
161
Advanced MPLS
Configuring Multicast VPN (MVPN)
Configure R1 and R4 to support MVPN for vrf ACME. Configure R1 as the RP in the ACME MVPN using BSR.
AS 123 PE1 (R1) ip multicast-routing vrf ACME << Enable mcast for VRF ! ip vrf ACME mdt default 239.1.1.1 << default-mdt mdt data 239.11.11.0 0.0.0.255 threshold 1 << data-mdt ! interface Loopback 10 ip vrf forwarding ACME ip address 10.10.10.10 255.255.255.255 ip pim sparse-mode ip igmp join-group 239.10.10.10 ! ip pim vrf ACME bsr-candidate Loopback 10 0 ip pim vrf ACME rp-candidate Loopback 10 0 ip pim vrf ACME register-source tunnel0 << T0 in adjacency AS 123 PE2 (R2) ip multicast-routing vrf ACME ! ip vrf ACME mdt default 239.1.1.1 mdt data 239.44.44.0 0.0.0.255 threshold 1 ! interface Loopback 40 ip vrf forwarding ACME ip address 40.40.40.40 255.255.255.255 ip pim sparse-mode ! ip pim vrf ACME register-source tunnel0
162
Advanced MPLS
Verify Multicast VPN (MVPN)
Verify MBGP Updates on PE2
PE-R2#show ip pim mdt bgp Peer (Route Distinguisher + IPv4) Next Hop MDT group 239.1.1.1 2:100:1:1.1.1.1<< RD-Type(2) and RD(100:1) 1.1.1.1 PE-R2#show ip bgp vpnv4 all BGP table version is 75, local router ID is 2.2.2.2 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf ACME) *>i7.7.7.7/32 1.1.1.1 2 100 0 ? *>i10.10.10.10/32 1.1.1.1 0 100 0 i *> 20.20.20.20/32 0.0.0.0 0 32768 i *>i172.16.17.0/24 1.1.1.1 0 100 0 i *> 172.16.22.0/24 0.0.0.0 0 32768 ? Route Distinguisher: 2:100:1 *>i1.1.1.1/32 1.1.1.1 0 100 0 ? *> 2.2.2.2/32 0.0.0.0 0? PE-R2# show ip bgp vpnv4 all 1.1.1.1 BGP routing table entry for 2:100:1:1.1.1.1/32, version 75 1.1.1.1 (metric 2) from 1.1.1.1 (1.1.1.1) Origin incomplete, metric 0, localpref 100, valid, internal, mdt, Extended Community: RT:100:1 MDT:123:239.1.1.1, mpls labels in/out nolabel/3
163
Advanced MPLS
Verify Multicast VPN (MVPN)
Verify MVPN and test mcast connectivity
PE-R2# show ip pim vrf ACME rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.10.10.10 (R1), v2 Info source: 10.10.10.10 (R1), via bootstrap, priority 0, holdtime 150 Uptime: 00:03:05, expires: 00:02:24 PE-R2# show ip mroute vrf ACME 239.10.10.10 (*, 239.10.10.10), 00:02:41/stopped, RP 10.10.10.10, flags: SPF Incoming interface: Tunnel0, RPF nbr 1.1.1.1 Outgoing interface list: Null PE-R2# ping vrf ACME 239.10.10.10 Sending 1, 100-byte ICMP Echos to 239.10.10.10, timeout is 2 seconds: Reply to request 0 from 1.1.1.1, 1720 ms Reply to request 0 from 1.1.1.1, 1736 ms CE-R7#ping 239.10.10.10 Sending 1, 100-byte ICMP Echos to 239.10.10.10, timeout is 2 seconds: Reply to request 0 from 172.16.17.1, 80 ms CE-R7#ping 239.20.20.20 Sending 1, 100-byte ICMP Echos to 239.20.20.20, timeout is 2 seconds: Reply to request 0 from 2.2.2.2, 208 ms
164
Advanced MPLS
Carrier Supporting Carrier (CSC) Overview
The Carrier Supporting Carrier (CSC) feature enables an MPLS VPN-based Service Provider to share a segment of their backbone network with another Service Provider.
165
Advanced MPLS
Carrier Supporting Carrier (CSC) Label Stack
The ACME Provider below is offering MPLS VPN services to customers. To enable this, the ACME PE router will run IGP with the Customer CE and MBGP and LDP with the CSC Provider PE. In the Provider Network, MPLS will use a 3 Label Stack.
CSC Label Stack

Top: Label Provider IGP, Middle = CSC VPN, Bottom Label = Customer VPN
166
Advanced MPLS
Configuring Carrier Supporting Carrier: ACME Site 1
Configure ACME Site 1 (R1-R7) and ACME Site 2 (R2-R8) to support CSC. Do not configure MPLS on ACME interfaces.
Provider PE (R1) ip vrf ACME rd 78:7 route-target export 78:7 << ACME Site 1 RT route-target import 78:8 << ACME Site 2 RT ! interface FastEthernet 0/0.17 ip vrf forwarding ACME ip address 172.16.17.7 255.255.255.0 ! router bgp 123 no bgp default ipv4-unicast no bgp default route-target-filter neighbor 2.2.2.2 remote-as 123 neighbor 172.16.17.7 remote-as 78 << R7 BGP Peer ! address-family ipv4 neighbor 2.2.2.2 send-label << BGP Transport Label ! address-family vpnv4 neighbor 2.2.2.2 activate neighbor 2.2.2.2 send-community extended ! address-family ipv4 vrf ACME neighbor 172.16.17.7 activate << R7 activated under VRF neighbor 172.16.17.7 send-label neighbor 172.16.17.7 as-override << override loop prevent network 172.16.17.0 mask 255.255.255.0
167
Advanced MPLS
ACME PE (R7) ip vrf CE7 rd 7:7 route-target export 7:7 route-target import 8:8 ! interface FastEthernet0/0.7 ip vrf forwarding CE7 ip address 10.10.7.7 255.255.255.0 ! router rip << CE IGP address-family ipv4 vrf CE7 redistribute bgp 78 metric 1 network 10.0.0.0 version 2 no auto-summary ! router bgp 78 bgp router-id 7.7.7.7 no bgp default ipv4-unicast neighbor 172.16.17.1 remote-as 123 neighbor 8.8.8.8 remote-as 78 neighbor 8.8.8.8 update-source Loopback0 ! address-family ipv4 neighbor 172.16.17.1 activate neighbor 172.16.17.1 send-label network 7.7.7.7 mask 255.255.255.255 address-family vpnv4 neighbor 8.8.8.8 activate neighbor 8.8.8.8 send-community both ! address-family ipv4 vrf CE1 redistribute rip
168
Advanced MPLS
Provider PE (R2) ip vrf ACME rd 78:8 route-target import 78:7 << ACME Site 1 RT route-target export 78:8 << ACME Site 2 RT ! interface FastEthernet 0/0.28 ip vrf forwarding ACME ip address 172.16.28.2 255.255.255.0 ! router bgp 123 no bgp default ipv4-unicast no bgp default route-target-filter neighbor 1.1.1.1.1 remote-as 123 neighbor 172.16.28.8 remote-as 78 << R8 BGP Peer ! address-family ipv4 neighbor 1.1.1.1 send-label << BGP Transport Label ! address-family vpnv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 send-community extended ! address-family ipv4 vrf ACME neighbor 172.16.28.8 activate << R8 activated under VRF neighbor 172.16.28.8 send-label neighbor 172.16.28.8 as-override << override loop prevent network 172.16.28.0 mask 255.255.255.0
169
Advanced MPLS
Configuring Carrier Supporting Carrier : ACME Site 2
ACME PE (R8) ip vrf CE8 rd 8:8 route-target export 8:8 route-target import 7:7 ! interface FastEthernet0/0.8 ip vrf forwarding CE8 ip address 10.10.8.8 255.255.255.0 ! router rip address-family ipv4 vrf CE8 redistribute bgp 78 metric 1 network 10.0.0.0 version 2 no auto-summary ! router bgp 78 bgp router-id 8.8.8.8 no bgp default ipv4-unicast neighbor 172.16.28.2 remote-as 123 neighbor 7.7.7.7 remote-as 78 neighbor 7.7.7.7 update-source Loopback0 ! address-family ipv4 neighbor 172.16.28.2 activate neighbor 172.16.28.2 send-label network 7.7.7.7 mask 255.255.255.255 address-family vpnv4 neighbor 7.7.7.7 activate neighbor 7.7.7.7 send-community both ! address-family ipv4 vrf CE8 redistribute rip
170
Advanced MPLS
Verify Carrier Supporting Carrier
Verify IPv4 and VPNv4 routes on ACME Site 2
R2# show ip bgp vpnv4 all Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 78:7 *>i7.7.7.7/32 1.1.1.1 0 100 0 78 i *>i172.16.17.0/24 1.1.1.1 0 100 0 i Route Distinguisher: 78:8 (default for vrf ACME) *> 8.8.8.8/32 172.16.28.8 0 0 78 i *> 172.16.28.0/24 0.0.0.0 0 32768 i R8# show ip route C 172.16.28.2/32 is directly connected, FastEthernet0/0.28 B 172.16.17.0/24 [20/0] via 172.16.28.2, 00:37:24 B 7.7.7.7 [20/0] via 172.16.28.2, 00:26:51 C 8.8.8.8 is directly connected, Loopback0 R8# ping 7.7.7.7 Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/37/92 ms R8# show ip route vrf CE8 Routing Table: CE8 B 10.10.7.0 [200/0] via 7.7.7.7, 01:04:31 C 10.10.8.0 is directly connected, FastEthernet0/0.8 R8# show mpls ldp bindings 7.7.7.7 255.255.255.255 (none)
171
Advanced MPLS
Verify Labels and reachability
R8# show ip bgp labels Network Next Hop In Label/Out Label 7.7.7.7/32 172.16.28.2 nolabel/210 8.8.8.8/32 0.0.0.0 imp-null/nolabel 172.16.17.0/24 172.16.28.2 nolabel/208 172.16.28.0/24 172.16.28.2 nolabel/204 R8# show ip cef 7.7.7.7 7.7.7.7/32, version 41, epoch 0, cached adjacency 172.16.28.2 0 packets, 0 bytes tag information set local tag: BGP route head fast tag rewrite with Fa0/0.28, 172.16.28.2, tags imposed: {210} via 172.16.28.2, 1 dependency, recursive next hop 172.16.28.2, FastEthernet0/0.28 via 172.16.28.2/32 valid cached adjacency tag rewrite with Fa0/0.28, 172.16.28.2, tags imposed: {210}
R8#ping vrf CE8 10.10.7.7 Sending 5, 100-byte ICMP Echos to 10.10.7.7, timeout is 2 seconds:!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/36/88 ms R7# ping vrf CE7 10.10.8.8 Sending 5, 100-byte ICMP Echos to 10.10.8.8, timeout is 2 seconds:!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/36/56 ms
172
Advanced MPLS
Importance of IGP Label in VPN Communications
R8# ping 10.10.7.7 Sending 5, 100-byte ICMP Echos to 10.10.7.7, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R2# show ip bgp vpnv4 all << VPNv4 prefixes installed on R2 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 78:7 *>i7.7.7.7/32 1.1.1.1 0 100 0 78 i *>i172.16.17.0/24 1.1.1.1 0 100 0 i Route Distinguisher: 78:8 (default for vrf ACME) *> 8.8.8.8/32 172.16.28.8 0 0 78 i *> 172.16.28.0/24 0.0.0.0 0 32768 i R8# show ip route << IPv4 prefixes installed on R8 C 172.16.28.2/32 is directly connected, FastEthernet0/0.28 B 172.16.17.0/24 [20/0] via 172.16.28.2, 00:37:24 B 7.7.7.7 [20/0] via 172.16.28.2, 00:26:51 C 8.8.8.8 is directly connected, Loopback0 R8# show ip route vrf CE8 << IPv4 prefixes installed in VRF CE8 on R8 Routing Table: CE8 B 10.10.7.0 [200/0] via 7.7.7.7, 01:04:31 C 10.10.8.0 is directly connected, FastEthernet0/0.8
173
Advanced MPLS
Importance of IGP Label in VPN Communications
R2# show mpls forwarding-table vrf ACME << R2 missing label for R7 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 204 Aggregate 172.16.28.0/24[V] 1040 207 Untagged 8.8.8.8/32[V] 0 Fa0/0.28 172.16.28.8 R1,R2,R7,R8
neighbor 172.16.X.X send-label

R2# show mpls forwarding-table vrf ACME Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 204 Aggregate 172.16.28.0/24[V] 1040 207 Pop tag 8.8.8.8/32[V] 8332 Fa0/0.28 172.16.28.8 208 105 172.16.17.0/24[V] 0 Fa0/0.12 172.16.12.1 210 107 7.7.7.7/32[V] 9735 Fa0/0.12 172.16.12.1 R8#ping vrf CE8 10.10.7.7 Sending 5, 100-byte ICMP Echos to 10.10.7.7, timeout is 2 seconds:!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/36/88 ms
174
Advanced MPLS
Carrier Supporting Carrier AS Path Issues
BGP uses AS-Path to prevent loops. Updates containing our own AS are dropped. The carrier can override this behavior.
R7# debug ip bgp udpate << debug BGP updates into AS78 BGP(0): 172.16.17.1 rcvd 8.8.8.8/32 BGP(0): 172.16.17.1 rcv UPDATE w/ attr: nexthop 172.16.17.1, path 123 78 BGP(0): 172.16.17.1 rcv UPDATE about 8.8.8.8/32 -- DENIED due to: AS-PATH contains our own AS R1 router bgp 123 address-family ipv4 vrf ACME neighbor 172.16.17.7 as-override << replace Peer AS with our AS R2 router bgp 123 address-family ipv4 vrf ACME neighbor 172.16.28.8 as-override R7# debug ip bgp udpate BGP(0): 172.16.17.1 rcvd 8.8.8.8/32 BGP(0): 172.16.17.1 rcvd UPDATE w/ attr: nexthop 172.16.17.1, path 123 123 BGP(0): Revise route installing 1 of 1 route for 8.8.8.8/32 -> 172.16.17.1 R7# debug ip bgp vpnv4 BGP: Incoming path from 8.8.8.8 vpn: bgp_vpnv4_bnetinit: 8:8:10.10.8.0/24 BGP: Accepted path from 8.8.8.8 vpn: bgp_vpnv4_bnetinit: 7:7:10.10.8.0/24 vpn: tag_vpn_find_route_tags: 7:7:10.10.8.0 vpn: intag=vpn-route, outtag=16, outtag owner=BGP
175
L2VPN
L2VPN Overview
L2VPN allows the tunneling of Layer 2 Networks such as FrameRelay over an IP or MPLS Network. L2VPN creates Virtual Circuits (VC's) known as PseudoWires (PW) to interconnect Layer 2 Networks.
The available L2VPN encapsulations are MPLS (ATOM) and L2TPv3.
176
L2VPN
PseudoWire Overview
A PseudoWire (PW) emulates a Layer 2 connection between two PE routers. The PE routers are configured as the endpoints of a PW or Virtual Circuit (VC). L2VPN maps an Attachment Circuit (AC) for the Layer 2 encapsulation from the customer edge (CE) router to an L2VPN PseudoWire. L2VPN is transparent to the CE Layer 2 services. After the formation of the PW, Layer 2 PDUs are encapsulated at the ingress PE. The encapsulated PDU is then sent over the PW to the egress PE, where the L2 headers are reconstructed and the frames are sent in their original format to the other CE device.
PseudoWire Types and Support

PseudoWire provides support for: 0x0001 0x0002 0x0003 0x0004 0x0005 0x0006 0x0007 Frame Relay DLCI ( Martini Mode ) ATM AAL5 ATM Cell Ethernet Tagged/VLAN Mode Ethernet HDLC PPP
177
L2VPN
L2VPN Interworking L2VPN is capable of interconnecting disparate Layer 2 protocols through Layer 2 interworking. For example connecting a PPP enabled site to a Frame-Relay site. This feature is provided in an attempt to minimize the impact to existing Layer 2 services and create new service offerings with MPLS-enabled networks. L2VPN supports two interworking modes - Ethernet and IP. MTU Size Requirements L2VPN adds additional overhead to transported L2 frames. You may need to adjust your Provider Networks MTU as seen below with EoMPLS.
EoMPLS MTU Requirements Field EoMPLS Port Mode EoMPLS VLAN Mode Edge 1500 1500 Transport 14 18 Control Word 4 4 MPLS 8 8 Total 1526 1530
178
L2VPN
ATOM Overview
Any Transport Over MPLS (ATOM) is a pseudowire application that emulates Layer 2 virtual circuits (VC's) over MPLS. In an MPLS-based network providing AToM services, Layer 2 frames are received on the ingress interface of the ingress PE router. This Layer 2 frame is encapsulated into an MPLS packet using a label stack by the ingress PE router. The ingress PE encapsulates the frame into the MPLS label stack and tunnels it across the backbone to the egress PE. The egress PE decapsulates the packet and reproduces the Layer 2 frame on the appropriate egress interface.
L2TPV3 Overview
Layer 2 Tunneling Protocol version 3 (L2TPv3) is a pseudowire application that emulates Layer 2 virtual circuits (VC's) over native IP Networks. L2TPv3 uses UDP Port 1701 and IP protocol ID 115. When L2TPv3 is implemented, the physical interfaces that are connected to the customer's networks are used as the tunnel ingress and egress interfaces. Benefits include : L2TPv3 simplifies deployment of VPNs L2TPv3 does not require Multiprotocol Label Switching L2TPv3 supports Layer 2 tunneling over IP for any payload
179
L2VPN - ATOM
ATOM LSP and Label Stack
An AToM pseudowire is made up of a pair of unidirectional MPLS Label Switched Paths (LSP) between PE Routers. The PE router defines two MPLS labels with ATOM. An inner VC label identifies the PW and an outer IGP label identifies the LSP through which the PW runs. At the remote PE router, the outer label is stripped off and the inner label maps to the outgoing AC.
180
L2VPN - ATOM
ATOM Targeted LDP
Because an MPLS LSP is unidirectional, to have bidirectional connectivity, a pseudowire is formed by establishing two LSPs in opposite directions. AToM utilizes targeted LDP sessions between PE routers to exchange VC Labels that are used for pseudowires. The VC label used in ATOM is always at the bottom of the label stack. It identifies the egress AC on the egress PE. Because the pseudowire link is point-to-point, the TTL value of the VC Label is always 2.
181
L2VPN L2TPv3
L2TPV3 Header
The L2TPv3 header is used to encapsulate Layer 2 PDUs when using L2TPv3 tunnels. In the L2TPv3 header, the session identifier
identifies the tunnel context at the decapsulating router. The cookie contains the key for the L2TPv3 session. The cookie length can be configured, but the default value is 4 bytes. The Session Identifier is a 4-byte field with a nonzero value that identifies a specific L2TPv3 session between two tunnel endpoints. Pseudowire control encapsulation consists of 4 bytes and implements sequencing with the L2TPv3 tunnel.
L2TP Message Types

L2TP is comprised of two types of messages, Control messages and Data messages. Control messages are used in establishment, maintenance, and clearing of control connections and sessions. Data messages are used to encapsulate the L2 traffic being carried over the L2TP session.
182
L2VPN - ATOM
Configuring ATOM Pseudowire
Configure PE1 and PE2 to support PPP over MPLS between R3 and R4.
PE1 (R1) int ser 0/1 encapsulation ppp xconnect 2.2.2.2 34 encapsulation mpls clockrate 256000 PE2 (R2) interface ser 0/1 encapsulation ppp xconnect 1.1.1.1 34 encapsulation mpls clockrate 256000 CE3 (R3) interface ser 0/1 encapsulation ppp ip address 10.10.34.3 255.255.255.0 CE4 (R4) interface ser 0/1 encapsulation ppp ip address 10.10.34.4 255.255.255.0
183
L2VPN - ATOM
Verify ATOM
Verify session and label assignment
R1# show xconnect all XC ST Segment 1 S1 Segment 2 S2 ------+---------------------------------+--+---------------------------------+-UP ac Se0/1(PPP) UP mpls 2.2.2.2:34 UP R1# show mpls l2transport vc vcid 34 detail Local interface: Se0/1 up, line protocol up, PPP up Destination address: 2.2.2.2, VC ID: 34, VC status: up Next hop: 172.16.12.2 Output interface: Fa0/0.12, imposed label stack {19} Create time: 01:41:44, last status change time: 00:49:01 Signaling protocol: LDP, peer 2.2.2.2:0 up MPLS VC labels: local 21, remote 19 Group ID: local 0, remote 0 Remote interface description: PPP LINK to R4, XCONNECT TO R1 Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 631, send 632 R7#sh mpls ldp neighbor Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 1.1.1.1:0 TCP connection: 2.2.2.2.50097 1.1.1.1.646 State: Oper; Msgs sent/rcvd: 160/161; Downstream Up time: 02:11:08 LDP discovery sources: Targeted Hello 1.1.1.1 -> 2.2.2.2, active, passive FastEthernet0/0.12, Src IP addr: 172.16.12.2
184
L2VPN L2TPv3
Configuring L2TPv3 Pseudowire
Setup PE1 and PE2 with an L2TPv3 tunnel for PPP between R3 and R4.
PE1 (R1) pseudowire-class PPP encapsulation l2tpv3 ip local interface Loopback0 ! int ser 0/1 encapsulation ppp xconnect 2.2.2.2 34 encapsulation l2tpv3 pw-class PPP clockrate 256000 PE2 (R2) pseudowire-class PPP encapsulation l2tpv3 ip local interface Loopback0 ! interface ser 0/1 encapsulation ppp xconnect 1.1.1.1 34 encapsulation l2tpv3 pw-class PPP clockrate 256000 CE3 (R3) interface ser 0/1 encapsulation ppp ip address 10.10.34.3 255.255.255.0 CE4 (R4) interface ser 0/1 encapsulation ppp ip address 10.10.34.4 255.255.255.0
185
L2VPN - L2TPv3
Verify L2TPv3
R1# show xconnect all XC ST Segment 1 S1 Segment 2 S2 ------+---------------------------------+--+---------------------------------+-UP ac Se0/1(PPP) UP l2tp 2.2.2.2:31 UP
R1# show l2tp tunnel all L2TP Tunnel Information Total tunnels 1 sessions 1 Tunnel id 59361 is up, remote id is 24673, 1 active sessions Locally initiated tunnel Tunnel state is established, time since change 00:01:18 Tunnel transport is IP (L2TP) (115) Remote tunnel name is R2 Internet Address 2.2.2.2, port 0 Local tunnel name is R1 Internet Address 1.1.1.1, port 0 L2TP class for tunnel is l2tp_default_class Counters, taking last clear into account: 30 packets sent, 30 received 2260 bytes sent, 2260 received Last clearing of counters never Counters, ignoring last clear: 30 packets sent, 30 received 2260 bytes sent, 2260 received Control Ns 6, Nr 5 Local RWS 1024 (default), Remote RWS 1024 (max)
186
L2VPN - ATOM
Configuring ATOM Pseudowire Interworking
Configure PE1 and PE2 to support PPP to Ethernet Interworking over MPLS between R3 and R4. PE1 (R1) pseudowire-class PPP-ETH encapsulation mpls interworking ip ! int ser 0/1 encapsulation ppp xconnect 2.2.2.2 34 pw-class PPP-ETH clockrate 256000 PE2 (R2) pseudowire-class PPP-ETH encapsulation mpls interworking ip ! interface Ethernet0 xconnect 1.1.1.1 34 pw-class PPP-ETH CE3 (R3) interface ser 0/1 encapsulation ppp ip address 10.10.34.3 255.255.255.0 CE4 (R4) interface Ethernet0 ip address 10.10.34.4 255.255.255.0
187
L2VPN - ATOM
Verify ATOM
R1# show xconnect all XC ST Segment 1 S1 Segment 2 S2 ------+---------------------------------+--+---------------------------------+-UP ac Se0/1(PPP) UP mpls 2.2.2.2:34 UP
R2# show xconnect all XC ST Segment 1 S1 Segment 2 S2 ------+---------------------------------+--+---------------------------------+-UP ac Fa0/0(Ethernet) DN mpls 1.1.1.1:34 UP
R1# show mpls l2transport vc vcid 34 detail Local interface: Se0/1 up, line protocol up, PPP up MPLS VC type is PPP, interworking type is IP Destination address: 2.2.2.2, VC ID: 34, VC status: up Next hop: 172.16.12.2 Output interface: Fa0/0.12, imposed label stack {19} Signaling protocol: LDP, peer 2.2.2.2:0 up MPLS VC labels: local 21, remote 19 R2# show mpls l2transport vc vcid 34 detail Local interface: Eth0 up, line protocol up, Ethernet up MPLS VC type is Ethernet, interworking type is IP Destination address: 1.1.1.1, VC ID: 34, VC status: up Next hop: 172.16.12.1 Output interface: Fa0/0.12, imposed label stack {21} Signaling protocol: LDP, peer 1.1.1.1:0 up MPLS VC labels: local 19, remote 21
188
Quality Of Service
QOS Overview QOS Functions and Features Diffserv Tunneling
189
Quality Of Service
QOS Overview
The goal of QOS is consistent and predictable performance. QoS allows the network to provide varying classes of service to users and applications. Building QoS requires three steps: Identify requirements, classify network traffic, and define network-wide policies for quality.
190
Quality Of Service
QOS Functions and Features
Multiple network functions and features which support these exist within the QOS Framework. QOS requires a step-by-step approach to ensure traffic policies are enforced. Below are the QOS Features which enable each of these Functions.
QoS Functions
Traffic Classification
Cisco IOS Enabling Features

Access Control List, NBAR DiffServ Code Point (DSCP)
Traffic Marking
MPLS Experimental (EXP) field Low-Latency Queuing (LLQ)
Congestion Management
Class-Based Weighted Fair Queuing (CBWFQ)
Congestion Avoidance Traffic Conditioning
Weighted Random Early Detection (WRED) Shaping and Policing
191
Quality Of Service
DiffServ Tunneling Modes
Diffserv Tunneling introduces a new Per-Hop-Behavior (PHB), which allows differentiated QoS in a Provider network. The tunneling mode is defined at the edge of the network, normally in the PE router (both ingress and egress). The MPLS network support of Diffserv specification defines three tunneling modes: Uniform, Pipe, and Short Pipe. Uniform Mode DiffServ Tunneling Uniform Mode has only one layer of QoS, which reaches end-to-end. The ingress PE copies the DSCP from the incoming IP packet into the MPLS EXP bits of the imposed labels. At the egress P router, the EXP bits are copied to the EXP bits of the newly exposed label after PHP. The egress PE router copies the EXP bits to the DSCP bits of the newly exposed IP packet. Pipe Mode Diffserv Tunneling Pipe Mode uses two layers of QoS: 1.An underlying QoS for the data, which remains unchanged when traversing the core. 2.A per-core QoS, which is separate from that of the underlying IP packets. This per-core QoS PHB remains transparent to end users.
192
Quality Of Service
Short Pipe Mode
Diffserv Tunneling Short-pipe Mode uses the same rules and techniques across the core. The difference is at the egress PE router (PE2)you classify the newly exposed IP packets for outbound queuing based on the IP PHB from the DSCP value of the original IP packet.
Tunneling Model Comparison

Tunneling Mode IP to Label
Copy IP Prec/DiffServ into MPLS EXP (may be changed by the SP also)
Label to Label
Label to IP
Uniform
MPLS EXP copied to IP Prec/DiffServ
Pipe
MPLS EXP set by the SP QoS policy
MPLS EXP may be changed by SP
Original IP Prec/Diffserv preserved (egress queuing based on MPLS EXP)
Short-Pipe
Original IP Prec/Diffserv preserved (egress queuing based in IP Prec/DiffServ)
193
Quality Of Service
Configuring Uniform Mode QOS PE1
On PE1, police DSCP 1 inbound from CE to 8K. DSCP 1 maps to EXP 1, and DSCP 46 to EXP 5. Outbound DSCP 1 should be configured for WRED with 5% of the remaining bandwidth. Outbound DSCP 46 should have a Priority of 10%.
PE1 class-map match-all DSCP-1 << Classify: match IP with DSCP 1 match ip dscp 1 class-map match-all DSCP-46 << Classify: match IP with DSCP 46 match ip dscp 46 ! policy-map CE_QOS_IN << Policy: define treatment for each class class DSCP-1 police 8000 conform-action set-mpls-exp-imposition-transmit 1 exceed-action drop class DSCP-46 set mpls experimental imposition 5 ! class-map match-all MPLS-1<< Classify: match MPLS with EXP 1 match mpls experimental topmost 1 class-map match-all MPLS-5 match mpls experimental topmost 5 << Classify: match MPLS with EXP 5 ! policy-map P_QOS_OUT << Policy: define treatment for each class class MPLS-1 bandwidth remaining percent 5 random-detect class MPLS-5 priority percent 10 ! interface FastEthernet0/0 service-policy input CE_QOS_IN << Apply QOS: inbound policy ! interface FastEthernet0/1 mpls ip service-policy output P_QOS_OUT << Apply QOS: outbound policy
194
Quality Of Service
Configuring Uniform Mode QOS PE2
Configure PE1 to police DSCP 0 inbound from the CE to 8K. Outbound DSCP 24 should have a Priority of 10 %. DSCP 0 should map to EXP 3, and DSCP 46 to EXP 5. DSCP 0 should be configured for WRED.
PE2 class-map match-all MPLS-1 << Classify: match traffic with EXP 1 match mpls experimental topmost 1 class-map match-all MPLS-5 << Classify: match traffic with EXP 5 match mpls experimental topmost 5 ! policy-map P_QOS_IN class MPLS-1 set qos-group 1 class MPLS-5 set qos-group 5 ! class-map match-all QOS-GROUP-1 match qos-group 1 class-map match-all QOS-GROUP-5 match qos-group 5 ! policy-map CE_QOS_OUT class QOS-GROUP-1 set ip dscp 1 class QOS-GROUP-5 set ip dscp 5 ! interface FastEthernet0/0 service-policy input CE_QOS_IN ! interface FastEthernet0/1 mpls ip service-policy output P_QOS_OUT
195
Quality Of Service
Verify Uniform Mode QOS PE1
Verify hits on traffic classes
PE1 R1# show policy-map interface fa0/0 FastEthernet0/0 Service-policy input: CE_QOS_IN Class-map: DSCP-1 (match-all) 64 packets, 5134 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp 1 police: cir 8000 bps, bc 1500 bytes conformed 23 packets, 1844 bytes; actions: set-mpls-exp-imposition-transmit 1 exceeded 0 packets, 0 bytes; actions: drop conformed 0 bps, exceed 0 bps Class-map: DSCP-46 (match-all) 3 packets, 246 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp ef (46) QoS Set mpls experimental imposition 5 Packets marked 3 Class-map: class-default (match-any) 11 packets, 878 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any
196
Security
Security Overview ACL Fundamentals uRPF NBAR Routing Protocol Security RTBH Filtering
197
Security
Security Overview
Network Security is a large area which in recent years become a leading product instead of an add on. Security within the Service Provider Lab does not use complex mechanisms. A basic understanding of common IOS security methods is sufficient. Selective filtering of subnets and hosts, protection against spoofed networks, protection of routing updates and other common security practices should be well rehearsed for the SP Lab.
198
Security
Access Control List Fundamentals
Access-control Lists (ACL) work as a traffic filter to allow very selective matching of traffic types. You can use ACLs to filter traffic based on protocol, src and dst IP, port number, qos value, and other items. Routers process ACLs from top to bottom. When the router evaluates traffic against an ACL, it starts at the beginning of the list and moves down, either permitting or denying traffic as it goes. When it has worked its way through the ACL, the processing stops. If the first part of the ACL denies traffic, but a lower part of the ACL allows it, the router will still deny the traffic. Access-list 1 permit any Access-list 1 deny host 10.1.1.1 Access-list 1 deny any The first line of ACL 1 permits anything. All traffic meets this requirement, so the router will permit all traffic, and processing will stop. At the end of an ACL is an implicit deny statement. The router denies all traffic that doesn't meet a condition in the ACL. Here's an example: Access-list 1 deny host 10.1.1.1 Access-list 1 deny 192.168.1.0 0.0.0.255 The router denies all traffic because of the implicit deny statement. The ACL really looks like this: Access-list 1 deny host 10.1.1.1 Access-list 1 deny 192.168.1.0 0.0.0.255 Access-list 1 deny ANY
199
Security
Rate Limiting with Extended ACLs Control the flow of inbound and outbound traffic on R1 F0/0 as follows: HTTP limited to 1Mbps with a normal burst of 16KB and an excess burst of 24KB. All other traffic limited to 144Kbps with a normal burst of 16KB and an excess burst of 24KB
access-list 121 permit tcp any any eq www access-list 123 permit ip any any ! interface FastEthernet0/0 rate-limit input access-group 121 1000000 16000 24000 conform-action transmit exceed-action drop rate-limit output access-group 121 1000000 16000 24000 conform-action transmit exceed-action drop rate-limit input access-group 123 144000 16000 24000 conform-action transmit exceed-action drop rate-limit output access-group 123 144000 16000 24000 conform-action transmit exceed-action drop Note: the command syntax is rate-limit <bits per second> <Normal burst bytes> <Maximum burst bytes>
200
Security
Blocking Fraggle and Smurf Attacks with an Extended ACL
Protect R1 from being a Smurf and Fraggle reflector from the Frame Cloud.
ip access-list extended smurf-fraggle remark smurf deny icmp any any echo deny imcp any any echo-reply remark fraggle deny udp any any eq echo deny udp any eq echo any permit ip any any ! interface Serial 0/0 ip access-group smurf-fraggle in no ip directed-broadcast Note: The Smurf attack is a way of generating a lot of computer network traffic to a victim host. That is, it is a type of denial-of-service attack. Specifically, it floods a target system via spoofed broadcast ping messages. In such an attack, a perpetrator sends a large amount of ICMP echo requests (ping) traffic to IP broadcast addresses, all of it having a spoofed source address of the intended victim. Note: the fraggle attack is a type of denial-of-service attack where an attacker sends a large amount of UDP echo traffic to IP broadcast addresses, all of it having a fake source address. This is a simple rewrite of the smurf attack code.
201
Security
Unicast Reverse Path Filtering
When Unicast RPF is enabled on an interface, the router examines all packets received on that interface. The router checks to make sure that the source address appears in the routing table and matches the interface on which the packet was received. This "look backwards" ability is available only when Cisco Express Forwarding (CEF) is enabled on the router because the lookup relies on the presence of the Forwarding Information Base (FIB). uRPF Loose Mode Unicast Reverse Path Filtering (uRPF) in Loose Mode checks the source IP address of each ingress packet to see if it exists in the FIB without regard for the specific interface on which it was received. If the ip address exists in the FIB, it is forwarded. ip verify unicast source reachable-via any uRPF Strict Mode Examines incoming packets to determine whether the source address is in the Forwarding Information Base (FIB) and permits the packet only if the source is reachable through the interface on which the packet was received (sometimes referred to as strict mode). ip verify unicast source reachable-via any rx uRPF with ACLs If no ACL is specified in the ip verify unicast source reachable-via command, the router drops the forged or malformed packet immediately and no ACL logging occurs. access-list 1 deny any log ! interface F0/1 ip verify ip verify unicast source reachable-via any 1
202
Security
Spoofing Prevention with uRPF
Configure R1 to verify the source ip address of packets coming into F0/1. If the reverse path check fails, the packets should be dropped and the event is logged to the buffer. Packets with the source ip address of 181.1.40.7 will be excepted from the rule and forwarded normally. ip cef ! logging buffered 6 ! access-list 1 permit 181.1.40.7 access-list 1 deny any log ! interface F0/1 ip verify ip verify unicast source reachable-via any 55
203
Security
NBAR Port Mapping
R2 hosts a Citrix server running on non-standard udp ports 15000 and 15500 rather than its standard ports. You would like to assign 20% of the bandwidth to the Citrix server on the outbound traffic towards the frame cloud. Do not use any ACL's to accomplish this task. ip cef ! ip nbar port-map citrix udp 15000 15500 class-map citrix match protocol citrix ! policy-map qos class web bandwidth percent 25 ! interface serial 0/0/0 bandwidth 1544 ip nbar protocol-discovery service-policy output qos
204
Security
RIP Authentication
Configure RIP MD5 authentication on R1. Use key 1 with key-string ccie. R1 Rip Authentication key chain rip-key << key chain rip key 1 key-string cciesec << key string ccie ! interface Fa0/0 ip address 192.168.2.2 255.255.255.0 ip rip authentication mode md5 ip rip authentication key-chain rip-key << key chain rip ! router rip version 2 no auto-summary network 192.168.2.0
205
Security
EIGRP Authentication
Configure EIGRP authentication on R1. Use key 1 with key-string ccie. R1 EIGRP Authentication key chain eigrp-key << key chain key 1 key-string cciesec << key string cciesec ! interface Fa0/0 nameif inside ip address 192.168.2.1 255.255.255.0 ip authentication mode eigrp 100 md5 ip authentication key-chain eigrp 100 eigrp-key ! router eigrp 100 no auto-summary network 192.168.2.0
206
Security
OSPF Authentication Interface
Configure OSPF packets to be authenticated with the MD5 password cisco. Do not configure anything directly under the routing process. int fa 0/0.26 ip ospf message-digest-key 1 md5 cisco ip ospf authentication message-digest
OSPF Authentication Routing Process

Configure OSPF packets to be authenticated with the MD5 password cisco. int fa 0/0.26 ip ospf message-digest-key 1 md5 cisco ! router ospf 100 area 0 authentication message-digest
207
Security
ISIS Authentication - Interface
Configure ISIS packets to be authenticated with the MD5 password cisco. key chain ISIS key 1 key-string cisco ! int fa 0/0 isis authentication mode md5 level-1 isis authentication key-chain ISIS level-1
ISIS Authentication Routing Process

Configure ISIS packets to be authenticated with the MD5 password cisco. Do not configure anything directly under the interfaces. key chain ISIS key 1 key-string cisco ! router isis net 49.0000.0000.0000.00 authentication mode md5 level-1 authentication key-chain ISIS level-1
208
Security
Remotely Triggered Black Hole Filtering Remotely Triggered Black Hole Filtering (RTBH) triggers all the routers in the network with a routing update. The routing update sent via iBGP by a trigger router creates a pre-configured static route to activate a black hole for the destination address. This places the traffic where you want it to flow through the network. The iBGP advertisement has the metric attached to ensure it becomes the preferred path. This iBGP trigger advertisement goes to all the iBGP speaking routers in the ISPs network. These routers all have an unused prefix that points to Null 0. The iBGP trigger advertisement has its next-hop equal to this Null0 prefix. When the iBGP trigger advertisement reaches the router, it gets glued to the static, activating the Null0 black hole.
209
Security
Blocking Attacks using Remote Triggered Black Hole Filtering
Routers R1, R2, and R3 are in BGP AS 123. R1 is peering with all the routers and is acting as a Route-Reflector Server. It has come to your attention that 44.0.0.0/8 and 144.0.0.0/8 networks are under a denial of service attack. Configure BGP such that all the routers in AS 123 Black Hole any packets destined for these two networks. You may only create one static route per router. Use R1 as the trigger router.
R1 Configuration access-list 1 permit 44.0.0.0 0.255.255.255 access-list 1 permit 144.0.0.0 0.255.255.255 ! route-map black_hole permit 10 match address 1 << match acl 1 set ip next-hop 192.0.2.1 set local-preference 200 << ensure peers prefer this route to one they already have by setting a higher local preference route-map black_hole permit 20 << permit all other routes ! router bgp 123 neighbor 192.1.12.2 route-map black_hole out << apply route map to outgoing routes neighbor 192.1.12.3 route-map black_hole out << apply route map to outgoing routes ! ip route 192.0.2.1 255.255.255.255 null 0 R2 Configuration ip route 192.0.2.1 255.255.255.255 null 0
R3 Configuration ip route 192.0.2.1 255.255.255.255 null 0
210
Good Luck on the CCIE Service Provider Lab!

211

CCIE Service Provider Fundamentals Workbook.v1.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CCIE Service Provider Fundamentals Workbook.v1.2

Uploaded by

Copyright:

Available Formats

CCIE Service Provider

CCIE Service Provider Fundamentals

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Service Provider Lab Overview

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Catalyst 3560

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Catalyst 3560

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Catalyst 3560

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Frame-Relay

Frame-Relay Terms and Operation

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Frame-Relay

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Frame-Relay

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Frame-Relay

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Frame-Relay

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Frame-Relay

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Frame-Relay

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Frame-Relay

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: Frame-Relay

Troubleshooting Command Reference

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: ATM

Bridging and Switching: ATM

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: ATM

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: ATM

R1 Configuration interface ATM1/0.1 point-to-point ip address 172.16.12.1 255.255.255.252 pvc 0/102

R2 Configuration interface ATM1/0.1 point-to-point ip address 172.16.12.2 255.255.255.252 pvc 0/201

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: ATM

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: PPP

PPP Terms and Operation

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: PPP

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: PPP

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: PPPoE

PPPoE Terms and Operation

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: PPPoE

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

Bridging and Switching: PPPoE

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

IGP Routing: RIPv2

RIPv2 Terms and Operation

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com

IGP Routing: RIPv2

CCIE Service Provider Fundamentals Morgan Stepp | morganstepp@yahoo.com