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 | [email protected]

2

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


3

Bridging and Switching • Catalyst 3560 • Frame-Relay

• ATM • PPP • PPPoE


4

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


5

Bridging and Switching: Catalyst 3560 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.


6

Bridging and Switching: Catalyst 3560 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


7

Bridging and Switching: Frame-Relay Frame-Relay Overview • Layer 2 WAN technology • Switches traffic using DLCI’s 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


8

Bridging and Switching: Frame-Relay 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


9

Bridging and Switching: Frame-Relay 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

Bridging and Switching: Frame-Relay 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

Bridging and Switching: Frame-Relay 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 Question With this configuration, what is required for R1 or R2 to ping their own interface?

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

Bridging and Switching: Frame-Relay 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

Bridging and Switching: Frame-Relay 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

Bridging and Switching: Frame-Relay 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

Bridging and Switching: Frame-Relay 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 CCIE Service Provider Fundamentals Morgan Stepp | [email protected]

17

Bridging and Switching: ATM 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

Bridging and Switching: ATM 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

Bridging and Switching: ATM 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

Bridging and Switching: ATM 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

Bridging and Switching: PPP 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

Bridging and Switching: PPP 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

Bridging and Switching: PPPoE 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

Bridging and Switching: PPPoE 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 Verify routes are installed 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 LSA’s to 224.0.0.5 and listen on 224.0.0.6 • DROTHER multicasts LSA’s 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 CCIE Service Provider Fundamentals Morgan Stepp | [email protected]

35

IGP Routing: OSPF OSPF Areas • Backbone – Area 0, all traffic should pass through backbone • Nonbackbone, nonstub – standard area, all LSA’s 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 LSA’s • Router (Type 1) – router’s neighbors and links in an area • Network (Type 2) – DR lists OSPF routers on a network • ABR Summary (Type 3) – ABR advertises internal net’s • 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 CCIE Service Provider Fundamentals Morgan Stepp | [email protected]

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 Verify routes are installed 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. CCIE Service Provider Fundamentals Morgan Stepp | [email protected]

41

IGP Routing: IS-IS IS-IS Network Entity Title (NET) •IS-IS communicates with peers using CLNS PDU’s •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 LSP’s A pseudonode LSP represents a LAN, including all IS’s attached to that LAN, just as a non-pseudonode LSP represents a router, including all IS’s 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 Verify routes are installed 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 AS’s, 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 AFI’s


50

BGP Routing BGP Overview – Neighbor Peering BGP peers are statically configured and can be sourced from Loopback’s 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: •IGP—The route is interior to the originating AS. This value is set when the “network” router configuration command is used •EGP—The route is learned via EBGP •Incomplete—The 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 it’s 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-export—Do not advertise this route to EBGP peers •no-advertise—Do not advertise this route to any peer •internet—Advertise 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 R3’s 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 R3’s 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 CCIE Service Provider Fundamentals Morgan Stepp | [email protected]

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 IBGP and EBGP Peering Solution: R2 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 IBGP and EBGP Peering Solution: R3 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 IBGP and EBGP Peering Solution: R4 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 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 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 CCIE Service Provider Fundamentals Morgan Stepp | [email protected]

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 Multicast Routing Protocol: PIM RP 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 Multicast Routing Protocol: PIM RP 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 RP’s 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 it’s 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 Multicast Routing Protocol: PIM RP 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 CCIE Service Provider Fundamentals Morgan Stepp | [email protected]

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 RP’s 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 op’s LIB – Label Information Base, LDP learned labels LFIB – Label Forwarding Information Base, FIB+LIB LDP’s – 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 LSR’s, 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 CCIE Service Provider Fundamentals Morgan Stepp | [email protected]

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), IGP’s, 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 it’s 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 LSR’s 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 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 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 Configure MPLS between R1 and R2. Use Loopback0 as the LDP ID.

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 VPN’s 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 customer’s 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. RT’s 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 AS’s 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 VRF’s 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.

PE1 (R3) Lo0:3.3.3.3

CE1 (R6) Lo0:6.6.6.6

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) 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.

PE2 (R4) Lo0:4.4.4.4

CE1 (R5) Lo0:5.5.5.5

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

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 ASBR’s 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 ASBR’s 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 RR’s VPN information is exchanged between MP-EBGP VPNv4 Route Reflectors. To meet this requirement, each provider needs to have MP-IBGP RR’s for local VPNv4 prefix distribution and an EBGP connection between RR’s 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 ASBR’s 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 RR’s Configure the RR’s 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 RR’s Configure the RR’s 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 RR’s 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 100

0 123 i 0I

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 RR’s 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 command“redistribute 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 carry’s 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 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. 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 Configuring Carrier Supporting Carrier: ACME Site 2 Configure ACME Site 1 (R1-R7) and ACME Site 2 (R2-R8) to support CSC. Do not configure MPLS on ACME interfaces. 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 Configure ACME Site 1 (R1-R7) and ACME Site 2 (R2-R8) to support CSC. Do not configure MPLS on ACME interfaces. 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 Carrier Supporting Carrier 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 Verify Carrier Supporting Carrier 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 Verify Carrier Supporting Carrier 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 Network’s MTU as seen below with EoMPLS.

EoMPLS MTU Requirements Field

Edge

Transport

Control Word

MPLS

Total

EoMPLS Port Mode

1500

14

4

8

1526

EoMPLS VLAN Mode

1500

18

4

8

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 PDU’s 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 Verify session and label assignment 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 CCIE Service Provider Fundamentals Morgan Stepp | [email protected]

187

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

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

Cisco IOS Enabling Features

Traffic Classification

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

Weighted Random Early Detection (WRED)

Traffic Conditioning

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

Uniform

Copy IP Prec/DiffServ into MPLS EXP (may be changed by the SP also)

Label to Label

MPLS EXP copied to IP Prec/DiffServ

MPLS EXP may be changed by SP

Pipe

Label to IP

Original IP Prec/Diffserv preserved (egress queuing based on MPLS EXP)

MPLS EXP set by the SP QoS policy

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 ACL’s 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


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 ACL’s 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 ISP’s 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! CCIE Service Provider Fundamentals Morgan Stepp | [email protected]

211

CCIE Service Provider Fundamentals Workbook.v1.2

Recommend Documents