cover page - ipmanager.iripmanager.ir/r/ebook/routing-bits-ccie_service-provider_1_ebook.ip...v the...

i

COVER PAGE

Copyright © 2013 Routing-Bits.com

ii

Copyright Information

Routing-Bi ts Handbook for Service Provider By Ruhann Du Plessis CCIE #24163 (R&S & SP) http ://www.routing -b i ts .com

Version 3.21

Copyright© 2013 Routing-Bi ts .com .

Routing-Bi ts developed th is book. All rights reserved. No part of this book m ay be reproduced or transmi tted in any form or by any m eans, electronic or mechanical , includ ing photocopying, record ing, or by any in formation storage and re trieval s ys tem , without wri tten permission from the author or Routing-Bi ts.com. In doing so all fu ture updates wi ll be forfei ted.

Cisco©

, Cisco© Sys tems, and CCIE (Cisco

© Certified In ternetwork Expert) are regis tered trademarks of Cisco© Sys tems, Inc. and or i ts affilia tes in the U.S. and other

countries.

Disclaimer

This publication, Routing-Bi ts Handbook for Service Provider, is designed to provide technical in formation and assist candidates in the preparation for CISCO Sys tems'

CCIE Service Provider Lab Exam. The in formation may also assist any other networking engineer in his or her day-to-day duties . While every effort has been made to ensure th is book is complete and as accurate as possible, the enclosed in formation is provided on an 'as is' basis. The author, Routing-Bi ts , and Cisco Sys tems, Inc., shall have nei ther liabil ity nor responsibil ity to any person or enti ty with respect to any loss or damages arising from the in formation contained in this book. The opinions expressed in th is book belong to the author and are not necessarily those of Cisco Systems, Inc. This book is NOT sponsored by, endorsed by or affi lia ted with Cisco Sys tems, Inc. Any similari ties between the content presented in th is book and the actual CCIE lab m aterial is completely coincidental . This book is not meant to be used as a replacement for other recommended CCIE s tudying materia ls. It is s trongly advised th is book be used as a supplementa l aid.


iii

Index

CHAPTER 1 IOS-XR PRIMER 1

CHAPTER 2 LAYER 2 3

CHAPTER 3 CORE IGP: IS-IS 19

CHAPTER 4 CORE IGP: OSPF 41

CHAPTER 5 BGP 69

CHAPTER 6 MPLS 111

CHAPTER 7 MPLS – L3VPNS 127

CHAPTER 8 MPLS – TE 153

CHAPTER 9 MPLS – L2VPNS 189

CHAPTER 10 INTER-AS 217

CHAPTER 11 CSC 239

CHAPTER 12 MULTICAST 263

CHAPTER 13 IPV6 305

CHAPTER 14 QOS 331

APPENDIX A CONFIG-SET INDEX 333

APPENDIX B FIGURE INDEX 339


i v

Motivation For This Book

There are numerous good books that cover various fields of networking theory, which are essential for Network Engineers and CCIEs. They describe and i llustra te the

intricate details of how the technologies function and in teroperate. Studying for a CCIE frequently invo lves reviewing many of the technology concepts and

implementation methodologies from the di fferent sources.

The Routing-Bits Handbooks were developed to assist by provid ing easy access to in formation for a varie ty of technologies in a single book focusing on a select CCIE

track. Each handbook presents the detailed in formation in a revolutionary document layout, which was specifically designed with s tudying and quick re ference in mind.

The simple design allows vas t amounts of in formation to be presented in an aesthetically pleasing and efficient format.

The Routing-Bits Handbooks are not in tended to replace existing textbooks. They are in tended as supplementary aids to s tudy for re freshing the m emory.

We hope that all readers wi ll enjoy reading these Handbooks and hopefully use i t as a reference for years to come.


v

The Author

Ruhann du Plessis, CCIE #24163 (Routing and Switching, Service-Provider)

Is a Network In fras tructure Engineer currently li ving in Johannesburg, South-Africa and working for an In ternet Service Provider. Ruhann has over 12 years

of experience designing, building and maintain ing large-scale MPLS networks and cloud based solutions. With the m ajori ty of that tim e spend in the ISP

indus try, Ruhann has an enriched understanding of MPLS networks . More recently he enjoys building data center archi tectures. Ruhann also regularly

wri tes technical articles on the Routing-Bi ts blog and participates in the blogosphere when not enjoying tim e with his beauti ful , supportive wife and three

young chi ldren.

The Technical Reviewers

Jeff Pazahanick, CCIE #25966 (Routing and Switch ing)

Is a Solutions Archi tect and Network Consultant l i ving in Minneapolis, Minnesota, USA. Jeff m ain ly works with tier 2/3 Service Providers in the United States . Jeff has

over 13 years experience in designing networks and deploying a ful l range of Cisco IP NGN products. When Jeff is not working, he is the busy fa ther of three young boys

and a husband to his deares t wife.

Steve Di Bias, CCIE #32840 (Routing and Switching)

Is a Network Consulting Engineer l i ving in Las Vegas, Nevada, and working for Cisco Sys tems, Inc. Steve has over 10 years of experience designing, building and

maintaining large scale networks . Steve 's numerous networking certi fications also include the CCNP, CCNA, FNCNE, BCNE, MCSE, MCITP and he's currently working on his

second CCIE. When Steve is n’ t working, he likes to spend all his available tim e with his expectant wife Michelle and his li ttle daughter Emma.


vi

Sub-Sections and Conventions

- CONFIG-SETS - Are s hort summarized examples showing how to implement various technologies . Refer to Appendix A for a full index. - COMMANDS - Lists the command syntaxes with the required and optional strings. - WALKING THE LSP - Shows hop-by-hop via CLI how a working LSP is followed to aid troubleshooting. - TROUBLESHOOTING - Offers generic and speci fic troubleshooting questions with CLI command. - " " (double quotes) - Indicates /refers to a CLI command. - ' ' (single quotes) - Indicates /refers to a command keyword/option of a CLI command. - Prompt Elements :

# sh ip route - A hash followed by a space, always indicates commands in Privileged EXEC Mode. #interface {int} - A hash without a following space, always indicates commands in Global Configuration Mode.

- Command Elements: | Vertical bars - Functions as an OR. E.g. Option1 | Option2. [] Square brackets - Indicates optional keywords of a particular CLI command. {} Curly brackets - Indicates requi red keywords of a particular CLI command. (o) Optional - Indicates optional , non-required CLI commands .

- DOC-CD Reference Elements: | - Il lus tra tes the Column Menu Navigation. || - Text between a double pipe, indicates a Page/Section click.


vi i

Some Useful URLs

- Routing-Bi ts Blog http ://www.routing -b i ts .com

- CCIE In formation http ://www.cisco.com /go/ccie

- CCIE SP v3 Blueprin t: https://learn ingnetwork.cisco.com /docs /DOC -10145

- CCIE SP v3 Checklis t: https://learn ingnetwork.cisco.com /docs /DOC -9991

- CCIE Recommended Reading List and Materials http ://routing -b i ts .com /ccie-bookl ist/

- Cisco DOC-CD http ://www.cisco.com /cisco/web/psa/defaul t.h tml?mode=prod

- Cisco Bug Toolki t, Error Messages, Output In terpreter (requires CCO log in) http ://tools .cis co.com/Support/BugToolKi t/action.do?hdnAction=searchBugs http ://www.cisco.com/cgi-bin /Support/Errordecoder/index.cg i https ://www.cisco.com /cgi -b in /Support/OutputIn terpreter/home.pl

- MAC Address Lookups http ://coffer.com /m ac_find/

- Online Ping Server http ://jus t-p ing.com /

- Route-Server List http ://routeserver.org/

- HEX to Binary to Decimal Converter http ://routing -b i ts .com /2009/11/10/hexbindec/


vi ii

Navigating the DOC-CD

- The name DOC-CD (Documentation CD) is bi t of an historical term that survived. - I t was the original name used to describe the Cisco Product/Technology guide websi te when i t was still available in CD format. - Al though i t is officially known as the Product/Technology guide today, the term DOC-CD is stil l very common. - Getting to the DOC-CD main page:

> The di rect URL is : http ://www.cisco.com /cisco/web/psa/defaul t.h tml?mode=prod

> Al ternatively to navigate there: >> Go to http ://www.cis co.com >> Click on Support | | Click on Configure (bottom ) | | Click on Product/Technology Support

- From the DOC-CD main page there are two sections: Products and Technology.

- The 'Products' section > Is available to CCIE candidates during a CCIE LAB exam . > I t includes Configuration Guides and Command Reference l ists.

- The 'Technology' section > Is NOT available to CCIE candidates during a CCIE LAB exam but s til l good to be used while s tudying. > I t includes Design Guides, White Papers, FAQs, etc.

- Throughout the Routing-Bi ts Handbook mos t sections include a DOC-CD reference to allow for further reading i f necessary. - The Routing-Bi ts DOC-CD references s tarts navigating from the DOC-CD main page (see above).

> The format is then broken up in two s tarting lines >> First line- As indicated b y a single pipe ' | ' is the column menu navigation. >> Second line- Between each double pipe ' | | ' is page/section click.

> Refer to the example below:

DOC-CD REFERENCE Example: | Products > Cisco IOS > Cisco IOS > 12.4 Family > 12.4 T | | Configuration Guides | | Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.4T | | Part 1: Bridging | | Configuring Transparent Bridging

Feedback

While every effort was made to ensure th is book is complete and as accurate as possible, errors and typos may happen. By le tting us know of any mistakes, i t can be corrected for the benefit of fu ture releases. Furthermore we would really appreciate any questions, comments , requests or feedback sent to <support@routing -bi ts .com >.


i x

Table of Contents

COVER PAGE I

COPYRIGHT INFORMATION II

DISCLAIMER II INDEX III MOTIVATION FOR THIS BOOK IV

THE AUTHOR V THE TECHNICAL REVIEWERS V SUB-SECTIONS AND CONVENTIONS VI SOME USEFUL URLS VII NAVIGATING THE DOC-CD VIII FEEDBACK VIII

IOS-XR PRIMER 1

LAYER 2 3

FRAME-RELAY 4

- DLCI (DATALINK CONNECTION IDENTIFIER) 4 - LMI (LOCAL MANAGEMENT INTERFACE) 4

- ENCAPSULATION TYPES 4 - FECN, BECN AND DE 5 - FRAME-RELAY PVC STATUS 5 - ADDRESS RESOLUTION - STATIC MAPPINGS 5 - ADDRESS RESOLUTION - INARP (INVERSE ARP) 5

- INTERFACES TYPES 5 - INTERFACE STATES 6 - MFR (MULTILINK FRAME-RELAY) OR FRF.16.1 7

PPP 10 - PPP PAP AUTHENTICATION 10

- PPP CHAP AUTHENTICATION 12 - MLP (MULTILINK PPP) 13

TROUBLESHOOTING FRAME-RELAY 15 TROUBLESHOOTING PPP 16 BIBLIOGRAPHY 17

CORE IGP: IS-IS 19

OVERVIEW 20


x

IS-IS ADDRESSING 21 - NET (NETWORK ENTITY TITLE) 21 - AREA ID (AREA IDENTIFIER) 21

- SYSTEM ID (SYSTEM IDENTIFIER) 21 - N-SELECTOR 21

ADJACENCIES 22 - L1 ROUTER 22 - L2 ROUTER 22

- L1/L2 ROUTER 22 - ADJACENCIES 22 - ADJACENCY FILTER 23

PASSIVE-INTERFACE 24 DIS (DESIGNATED INTERMEDIATE SYSTEM) 25 - CIRCUIT ID 25

IS-IS PACKETS 26 - IS-IS PDU TYPES: 26 - OL BIT (OVERLOAD BIT) 27 - ATT BIT (ATTACHED BIT) 27

- TLV (TYPE, LENGTH, VALUE) 27 - HELLO PADDING 27

SUBNETWORK TYPES 28 IS-IS ROUTE SELECTION 29 - METRICS 29 - WIDE-METRICS 29

- ROUTE-TYPES 30 - IS-IS ROUTE SELECTION PROCESS 30

ROUTE LEAKING 30 MESH GROUPS 31 - MESH GROUP INTERFACE MODES: 32

IS-IS OPTIMIZATION 33 - FLOODING DELAYS 33 - ISPF (INCREMENTAL SPF) 33 - PRC (PARTIAL ROUTE CALCULATION) 34 - FAST FLOODING 34

- HIGH-PRIORITY 34 ROUTE SUMMARIZATION 35 DEFAULT ROUTING 36 AUTHENTICATION 37 BIBLIOGRAPHY 39


xi

CORE IGP: OSPF 41

OSPF OVERVIEW 42

HELLO PROTOCOL 42

- HELLO-INTERVAL 43 - ROUTER DEAD-INTERVAL 43 - FAST-HELLO PACKETS 43

ADVERTISING ROUTES 44 - NETWORK AREA COMMAND 44

- INTERFACE COMMAND 44 NETWORK TYPES 46 - OSPF NETWORK TYPES 46 -OSPF OVER GRE 47 -STUB/LOOPBACK NETWORK 47

DR AND BDR 48

OSPF OPERATION 49 - OSPF FINITE STATE MACHINE 49 - OSPF PACKET TYPES 49

ROUTER TYPES 50

-INTERNAL 50 -BACKBONE 50 -ABR (AREA BORDER ROUTER) 50 -ASBR (AUTONOMOUS SYSTEM BOUNDARY ROUTER) 50

LSAS (LINK STATE ADVERTISEMENTS) 50 - LSA TYPES 50

- OSPF LINK-STATE DATABASE OVERLOAD PROTECTION 51 - OSPF LSA THROTTLING 51

AREA TYPES 53 - STUB AREAS 53 - TOTALLY STUBBY AREAS 53

- NSSA (NOT-SO-STUBBY AREAS) 53 - TOTALLY NSSA 53 - SUPPRESS OSPF FORWARDING ADDRESS IN TRANSLATED TYPE-5 LSAS 54

FILTERING 55 - FILTER-LISTS 56

- DISTRIBUTE-LIST 56 - PREFIX-SUPPRESSION 56

SUMMARIZATION 57 STUB ROUTER ADVERTISEMENT 58 PASSIVE-INTERFACE 59

ORIGINATING A DEFAULT ROUTE 59 Copyright © 2013 Routing-Bits.com

xi i

- UNCONDITIONAL OSPF DEFAULT ROUTE 60 - CONDITIONAL OSPF DEFAULT ROUTE 60 - CONDITIONAL OSPF DEFAULT ROUTE WITH A ROUTE-MAP 60

- OSPF STUB AREA'S DEFAULT ROUTE 61 - OSPF NSSA'S DEFAULT ROUTING 61

PATH SELECTION 62 - OSPF ROUTE SELECTION CRITERIA 62 - ISPF (OSPF INCREMENTAL SPF) 63

AUTHENTICATION 63 OSPF DEMAND CIRCUIT 65 TROUBLESHOOTING OSPF 66 BIBLIOGRAPHY 68

BGP 69

THE BGP PROCESS 70

ESTABLISHING PEERINGS 71 - THE BGP STATES 71

AUTHENTICATION 72 EBGP SESSIONS 73 - EBGP LOOP PREVENTION 73

- BGP BACKDOOR 73 - BGP MAXIMUM-PATHS 73

NEXT-HOP PROCESSING 74 IBGP SESSIONS 75 - RRS (ROUTE-REFLECTORS) 75

- CONFEDERATIONS 75 IBGP SYNCHRONIZATION 77 BGP PATH ATTRIBUTES 77 - BGP BESTPATH SELECTION PROCESS 78 - CISCO WEIGHT ATTRIBUTE 78

- LOCAL PREFERENCE ATTRIBUTE 78 - AS-PATH ATTRIBUTE 78 - MED (MULTI EXIT DISCRIMINATOR) ATTRIBUTE 78 - COMMUNITY ATTRIBUTE 79

ORIGINATING PREFIXES 82

- NETWORK STATEMENT 82 - REDISTRIBUTION 82 - DEFAULT INFORMATION ORIGINATE 82 - NEIGHBOR DEFAULT ORIGINATE 82 - AGGREGATION 83


xi ii

BGP ROUTE-MAPS ON IOS 84 ROUTE FILTERING ON IOS 86 - AS-PATH FILTERS 86

- DISTRIBUTE-LISTS 86 - PREFIX-FILTER 87

RPL (ROUTING POLICY LANGUAGE) ON IOS-XR 88 - POLICIES 88 - SETS 89

- AS-PATH-SET 89 - COMMUNITY-SET 90 - EXTCOMMUNITY-SET 91 - PREFIX-SET 91 - RD-SET 92

ROUTE FILTERING ON IOS-XR 92

REGULAR EXPRESSIONS 94 BGP CONDITIONAL ROUTE ADVERTISEMENT 95 BGP CONDITIONAL ROUTE INJECTION 96 CLEARING BGP SESSIONS 97

- HARD RESET OF BGP SESSIONS 97 - SOFT RECONFIGURATION 98 - ROUTE REFRESH (SOFT RESET) 98

ORF (OUTBOUND ROUTE FILTERING) 99 BGP NETWORK MIGRATION 100 BGP ROUTE-DAMPENING 101

PEER-GROUPS ON IOS 102 BGP UPDATE GROUPS ON IOS-XR 103 FAST EXTERNAL FALLOVER 103 BGP FAST PEERING SESSION DEACTIVATION 104 SUPPORT FOR NEXT-HOP ADDRESS TRACKING 104

MAXIMUM-PREFIX 105 SUPPRESS BGP ADVERTISEMENTS FOR INACTIVE ROUTES 105 TROUBLESHOOTING BGP 107 BIBLIOGRAPHY 109

MPLS 111

MPLS OVERVIEW 112

- MPLS TERMINOLOGY 112 - MPLS COMPONENTS 112

MPLS OPERATIONS 114 - MPLS LABEL STRUCTURE 114


xiv

- TTL PROPAGATION 114 - PHP (PENULTIMATE-HOP-POPPING) 115 - FEC (FORWARDING EQUIVALENCE CLASS) 115

- LABEL STACK 115 - LSP (LABEL SWITCH PATH) 115 - LOCAL BINDINGS 115 - REMOTE BINDINGS 116 - MPLS LABEL PROPAGATION 116

- MPLS PACKET FORWARDING 116 - AGGREGATION/SUMMARIZATION 116 - MTU (MAXIMUM TRANSMISSION UNIT) 117 - MPLS MRU (MAXIMUM RECEIVE UNIT) 117

LABELS 119 - LABEL VALUES 119

- IMPLICIT NULL LABEL (3) 119 - EXPLICIT NULL LABELS (0 OR 2) 119 - TDP (TAG DISTRIBUTION PROTOCOL) 119 - LDP (LABEL DISTRIBUTION PROTOCOL) 119

- LDP-ID (IDENTIFIER) 120 - TRANSPORT ADDRESS 120 - TARGETED LDP SESSION 120 - LDP AUTHENTICATION 120 - CONDITIONAL LABEL ADVERTISING 120 - LDP INBOUND LABEL BINDING FILTERING 121

TROUBLESHOOTING MPLS LDP 124 BIBLIOGRAPHY 125

MPLS – L3VPNS 127

MPLS LAYER3 VPNS 128

- MPLS VPN TERMINOLOGIES 128

- VRF (VIRTUAL ROUTING AND FORWARDING) 128 - RD (ROUTE DISTINGUISHER) 128 - RT (ROUTE-TARGET) 128 - LOOPBACK INTERFACES 129 - MPLS VPN LABEL OPERATION 129

- MPLS VPN ROUTE PROPAGATION 130 - MPLS VPN PACKET FORWARDING 130 - DEFAULT ROUTE-TARGET FILTER 131 - VRF IMPORT FILTERING 131 - SELECTIVE VRF EXPORT 132


xv

- HUB-SPOKE SCENARIO 133 - VRF ROUTE-LIMITING 135 - MULTIPROTOCOL VRFS 135

PE TO PE: MP-IBGP 137 PE TO CE: CONNECTED & STATIC ROUTES 139 PE TO CE: RIPV2 140 PE TO CE: EIGRP 141 - EIGRP SOO 141

PE TO CE: OSPF 143 - OSPF DOMAIN-ID 143 - OSPF DOWN-BIT 143 - OSPF DOMAIN-TAG 143 - SHAM-LINK 144

PE TO CE: EBGP 146

- AS-OVERRIDE 146 - ALLOWAS-IN 146 - SOO (SITE-OF-ORIGIN) 146

VRF-LITE (MULTI-VRF CE) 148

- OSPF CAPABILITY VRF-LITE 148 TROUBLESHOOTING MPLS L3VPNS 150 BIBLIOGRAPHY 151

MPLS – TE 153

BASIC OPERATION 154

- MPLS TE COMPONENTS 154

- MPLS TE ARCHITECTURE 154 - RSVP LABEL PROPAGATION 154 - RSVP PATH SIGNALING EXAMPLE 155 - MPLS TE TRAFFIC FORWARDING EXAMPLE 156 - BASIC MPLS TE CONFIGURATION STEPS 156

- USING MPLS TE WITH OSPF AS THE IGP 156 - USING MPLS TE WITH IS-IS AS THE IGP 158 - TE TRANSIT INTERFACE ATTRIBUTES 160 - TE TUNNEL INTERFACE ATTRIBUTES 160 - MPLS TE PATH-OPTIONS EXAMPLE 162

- TE VERBATIM PATH 163 - TE TUNNEL REOPTIMIZATION 163 - TE METRICS 164 - TE TUNNEL BANDWIDTH 164 - TE AUTO-BANDWIDTH 165


xvi

TE TUNNEL SELECTION 168 - USING STATIC ROUTES 168 - USING PBR (POLICY-BASED ROUTING) 168

- USING AUTOROUTE ANNOUNCE 168 - USING FORWARDING ADJACENCIES 168 - USING PSEUDOWIRE TUNNEL SELECTION 169 - USING CBTS (CLASS-BASED TUNNEL SELECTION) 169

MPLS TE FRR - LINK AND NODE PROTECTION 171

- FRR (FAST REROUTE) 171 - FRR TERMINOLOGIES 172 - FRR LINK PROTECTION 172 - FRR NODE PROTECTION 173 - BANDWIDTH PROTECTION 174

INTER-AREA MPLS TE 175

MPLS VPNS OVER MPLS TE 177 - MPLS TE TUNNELS BETWEEN MPLS PE ROUTERS 177 - A MPLS TE TUNNEL ENDING ON A P ROUTER 178 - PER-VRF MPLS-TE TUNNELS 180

WALKING THE LSP 183 BIBLIOGRAPHY 187

MPLS – L2VPNS 189

L2VPN OVERVIEW 190

- L2VPN COMPONENTS 190 - PW (PSEUDOWIRE) 190

- PSEUDOWIRE-CLASS 190 - VCID (VIRTUAL CIRCUIT IDENTIFIER) 190 - VCCV (VIRTUAL CIRCUIT CONNECTIVITY VERIFICATION) 190

ATOM 191 - ATOM COMPONENTS 191

- ATOM HEADER OVERHEAD 191 - CW (CONTROL WORD) 192 - MTU GUIDELINES 192 - ATOM FORWARDING PLANE 192 - ETHERNET OVER MPLS 193

- HDLC OVER MPLS 193 - PPP OVER MPLS 193 - FRAME-RELAY OVER MPLS 194 - ATOM TUNNEL SELECTION 194 - L2VPN PSEUDOWIRE SWITCHING 196


xvi i

L2TPV3 198 - L2TPV3 COMPONENTS 198 - L2TPV3 HEADER OVERHEAD 199

- MTU GUIDELINES 199 - L2TP-CLASS 200 - ETHERNET OVER L2TPV3 200 - HDLC OVER L2TPV3 201 - PPP OVER L2TPV3 201

- FRAME-RELAY OVER L2TPV3 201 INTERWORKING 204 - ATOM INTERWORKING SUPPORTED 204 - L2TPV3 INTERWORKING SUPPORTED 205 - MTU CONSIDERATIONS 205

LOCAL SWITCHING 206

PSEUDOWIRE REDUNDANCY 208 VPLS 209 - VPLS COMPONENTS 210 - MAC ADDRESS LIMITING 211

- VPLS MODES 211 - VPLS CONFIGURATION REQUIREMENTS 211 - VPLS CONFIGURATION STEPS 211 - HVPLS (HIERARCHICAL VPLS) 212

BIBLIOGRAPHY 215

INTER-AS 217

OVERVIEW 218

- LABEL TYPES 218 - IPV4 BGP 218 - VPNV4 BGP SESSION 218 - BGP NEXT-HOP BEHAVIOR 218

- DEFAULT ROUTE-TARGET FILTER 218 - SET MPLS-LABEL 219

OPTION-1: BACK-TO-BACK VRF 220 OPTION-2A: VPNV4 EBGP PEERING USING NEXT-HOP-SELF 222 OPTION-2B: VPNV4 EBGP PEERING USING REDISTRIBUTE CONNECTED 224

OPTION-2C: VPNV4 EBGP PEERING BETWEEN LOOPBACKS 226 OPTION-3: MULTIHOP VPNV4 EBGP BETWEEN RRS 228 WALKING THE LSP 234

CSC 239


xvi i i

CSC OVERVIEW 240 CSC-1 NATIVE IP WITH STATIC ROUTES 242 CSC-2 NATIVE IP WITH LDP LABELS 244

CSC-3 MPLS WITH LDP LABELS 246 CSC-4 MPLS WITH BGP LABELS (IPV4+LABEL) 249 CSC-5 MPLS VPN WITH LDP AND BGP LABELS 252 WALKING THE LSP 258

MULTICAST 263

MULTICAST OVERVIEW 264

MULTICAST TERMINOLOGY 266 - MULTICAST SOURCE 266 - MULTICAST LISTENER 266 - LAST HOP ROUTER 266 - FIRST HOP ROUTER 266

- MULTICAST ADDRESS RANGE 266 - MULTICAST GROUP ADDRESS 266 - MULTICAST DISTRIBUTION TREE 266 - OIL (OUTGOING INTERFACE LIST) 266

- IIF (INCOMING INTERFACE) 266 - MULTICAST FORWARDING STATE 266 - RPF (REVERSE PATH FORWARDING) 267 - RP (RENDEZVOUS POINT) 267

MULTICAST ADDRESSING 267 - MULTICAST ADDRESS RANGE FORMATS 267

- WELL-KNOWN RESERVED RANGES 267 - WELL-KNOWN RESERVED MULTICAST GROUPS 268

IGMP (INTERNET GROUP MANAGEMENT PROTOCOL) 268 - MULTICAST MAC ADDRESSING 268 - IGMP SNOOPING 269

- IGMP VERSION 1 269 - IGMP VERSION 2 269 - IGMP VERSION 3 270 - IGMP QUERIER 270

PIM (PROTOCOL-INDEPENDENT MULTICAST) 271

- PIM-DM 271 - PIM-SM 272 - PIM SPARSE-DENSE MODE 272 - PIM-BIDIR 272 - PIM-SSM 274


xix

- DR (DESIGNATED ROUTER) 275 - AF (ASSERT FORWARDER) 275

MULTICAST OPERATION 277

- SPT (SHORTEST PATH TREE) 277 - OVERVIEW OF A SPT CONSTRUCTION 277 - RPT (RENDEZVOUS POINT TREE) 278 - OVERVIEW OF A RPT CONSTRUCTION (PIM-SM) 278 - SHORTEST PATH SWITCHOVER 279

- OVERVIEW OF THE SHORTEST PATH SWITCHOVER 279 RP ASSIGNMENTS 280 - STATIC RP ASSIGNMENTS 280 - AUTO-RP 280 - BSR (BOOTSTRAP ROUTER) 282 - ANYCAST RP 284

MSDP (MULTICAST SOURCE DISTRIBUTION PROTOCOL) 287 RPF (REVERSE PATH FORWARDING) 289 - STATIC MROUTES (MULTICAST ROUTES) 290 - MP-BGP (MULTIPROTOCOL BGP) 290

- THE RPF ROUTE-SELECTION PROCESS 290 MULTICAST VPN 291 - TYPES OF MDTS: 292 - MTI (MULTICAST TUNNEL INTERFACE) 292 - MVPN PIM NEIGHBORSHIPS 293 - MVPN RPF CHECKS 293

- MVPN DATA FLOW EXAMPLE 294 - USING PIM-SSM IN THE MPLS CORE 294

WALKING THE TREE - MVPN 299 TROUBLESHOOTING MULTICAST 301 BIBLIOGRAPHY 303

IPV6 305

OVERVIEW 306

- ADVANTAGES OF IPV6 OVER IPV4 306 - PMTU (PATH MAXIMUM TRANSMISSION UNIT) DISCOVERY 306

ADDRESSING 306

- WELL-KNOWN IPV6 ADDRESSES 306 - GLOBAL UNICAST ADDRESSES 307 - LINK-LOCAL ADDRESSES 307 - SITE-LOCAL ADDRESSES 307 - UNIQUE LOCAL ADDRESSES 307


xx

- EUI-64 307 - MULTICAST IPV6 ADDRESSES 307 - ANYCAST ADDRESSES 307

- IPV4-COMPATIBLE IPV6 ADDRESS 308 - IPV4 TO IPV6 CONVERSION 308 - IPV6 TO IPV4 CONVERSION 308

ICMPV6 309 IPV6 ON CATALYST 3560 310

IPV6 OVER FRAME-RELAY 311 IPV6 STATIC ROUTING 311 RIPNG 312 EIGRP – IPV6 313 OSPFV3 315 IS-IS - IPV6 317

- IS-IS SINGLE TOPOLOGY MODE 317 - IS-IS MULTI TOPOLOGY MODE 317

MPBGP - IPV6 319 CE-TO-CE TUNNELING & TRANSITIONING TECHNIQUES 320

- MANUAL - IPV6IP 320 - MANUAL GRE/IPV4 COMPATIBLE 321 - AUTOMATIC 6TO4 321 - ISATAP 322 - NAT-PT (PROTOCOL TRANSLATION) 323

IPV6 MULTICAST 325

- WELL-KNOWN IPV6 MULTICAST ADDRESSES 325 - IPV6 MULTICAST MAPPING OVER ETHERNET 325 - MLD (MULTICAST LISTENER DISCOVERY) 326 - IPV6-PIM (PROTOCOL-INDEPENDENT MULTICAST) 326

ACCESS-LIST FILTERING 327

STATIC IPV6 DNS ENTRIES 328 TROUBLESHOOTING IPV6 329 BIBLIOGRAPHY 330

QOS 331 CONFIG-SET INDEX 333 FIGURE INDEX 339


TOC 1

Chapter 1

IOS-XR PRIMER


TOC 2

COMING SOON...


TOC 3

Chapter 2

LAYER 2


TOC 4

Frame-Relay

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2S Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | WAN, Cisco IOS Wide-Area Networking Configuration Guide, Release 12.2SR | | Part 1: Frame-Relay | | Configuring Frame-Relay

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Interface and Hardware Component Configuration Guide | | Frame Relay Configuration

- Frame-relay is a packet-swi tching technology implemented as a layer2 encapsulation technique, used between LANs over a WAN (Wide Area Network). - The logical communication paths between two or more DTEs (routers ) are called VCs (Vi rtua l Circu its ). - VCs m ay be permanent (PVCs) or switched (SVCs). PVCs are m ore common.

- DLCI (Datal ink Connection Identi fier) > Is a frame-relay address used to identi fy the VC over which frames should travel in a frame-re lay cloud. > A DLCI is contained with in a 10-b i t field inside the frame-re lay header. > DLCIs are locally signi ficant to a l ink and m ight change as a frame passes through a frame-relay cloud. > To see the active DLCIs issue the command "show frame-relay m ap". > To see all the DLCIs issue the command "show frame pvc | i DLCI".

- LMI (Local Management In terface) > LMI messages manage the communication between the DCE (frame-relay swi tch) and the DTE (a router). > A DTE sends LMI inqui ry messages to the DCE. > The DCE responds with LMI s tatus messages to in form the DTE about the DLCIs and s tatus of each VC. > LMI can be enabled/disabled by using the "keepalive"/"no keepalive" commands. > There are three LMI t ypes : Cisco/ANSI/q933a. > LMI is automatica lly enabled when the command "encapsulation frame-relay" is entered.

- Encapsulation Types > The Cisco encapsulation can be used when both DTE devices support Cisco encapsulation (Cisco is the defaul t in terface encapsulation). > The IETF encapsulation is requi red for multivendor implementations when one vendor does not support Cisco encapsulation.

CONFIG-SET: Examples of Frame-Relay Encapsulations Per-Interface and Per-DLCI

| interface s1/0 | encapsulation frame-relay ietf - Sets IETF encapsulation as default at the interface level | frame-relay map ip 10.5.1.2 48 broadcast - Sets the default configured encapsulation method (IETF) | frame-relay map ip 10.5.1.3 49 broadcast cisco - Per-DLCI encapsulation overwrites per-interface encapsulation | ! | interface s1/1 | encapsulation frame-relay - Sets Cisco encapsulation as default at the interface level | frame-relay map ip 10.5.2.2 58 broadcast ietf - Per-DLCI encapsulation overwrites per-interface encapsulation | frame-relay map ip 10.5.2.3 59 broadcast - Sets the default configured encapsulation method (Cisco) |


TOC 5

- FECN, BECN and DE > FECN (Forward Explici t Conges tion Noti fication) and BECN (Backward Explici t Congestion Noti fication) are set in the LAPF header to signal congestion on a particular

PVC. > When a frame-relay swi tch notices congestion on a PVC, the switch will set the FECN bi t ind icating congestion in that di rection. > A router receiving frames with the FECN bi t set, will set the BECN bi t on tra ffic re turning to the source, ind icating congestion and noti fying the source to slow down i ts

transmission ra te. > The DE (Discard Eligibil i ty) is used to indicate when traffic is in viola tion of the conformed ra te and m ight be subject to discard during periods of congestion. Frames

marked with DE bi t will be dropped before non-marked frames.

- Frame-Relay PVC Status > Active - Both sides of the PVC are up and communicating. > Inactive - Local router received s tatus about the DLCIs from the frame-swi tch. Remote side is down or has config issues. > Deleted - Indicates a local config problem. The frame-swi tch has no such mapping and responds with a 'dele ted message'. > Static - Indicates that LMI was turned off with the "no keepalives" command.

- Address Resolution - Static Mappings > Are used to s tatically resolve a REMOTE layer3 address(IP) to a LOCAL layer2 address(DLCI). > Are m anually configured with the command "frame-re lay map". > Requi re broadcast to be enabled m anually, i f needed. > Static frame-re lay mappings (frame-relay m ap) override dynamic mappings (learned via InARP). > Static mappings are not support IOS-XR.

- Address Resolution - InARP (Invers e ARP) > Is used to dynamically resolve a REMOTE layer3 address(IP) to a LOCAL layer2 address(DLCI). > Is enabled automatically when an IP address is configured. > InARP is enabled by defaul t on IOS-XR.

- To ping a locally configured IP on a frame-re lay in terface, layer3-to-layer2 resolution is required. This is needed because the frame actually exi ts the router to the other side of the link only to get redirected back because of the rem ote IP. If the mapping is not done, the ping reply is dropped by the router on the other side of the link.

CONFIG-SET: Pinging the local IP on a frame-relay interface

| interface s0/1 | ip address 10.5.34.3 255.255.255.0 - Configures the interface IP | encapsulation frame-relay | frame-relay map ip 10.5.34.4 304 broadcast - Maps the remote-end IP to local-DLCI | frame-relay map ip 10.5.34.3 304 - Maps the local IP to local-DLCI

- In terfaces Types > Point-to-Point Sub-Interfaces

>> Can only terminate one PVC. >> Do not requi re layer3-to-layer2 resolution, since there is only one PVC. >> Do not send InARP s tatus queries, but will respond to an InARP s tatus query request.

> Physical or Multipoint Sub-Interfaces >> Are treated as multipo int interfaces.


TOC 6

>> Can terminate multiple PVCs. >> Requires layer3-to-layer2 resolution through ei ther InARP or manual mappings . >> Manual m apping per PVC is done with the "frame map ip" command. >> To manually assign jus t one PVC on the in terface use "frame-re lay in terface-dlci ". >> CDP is enabled by defaul t on all frame-relay interfaces (except for frame-relay multipoint in terfaces).

CONFIG-SET: (IOS) Frame-Relay Interface Types

| interface s1/0 >>> Physical Interface <<< | encapsulation frame-relay ietf - Enables IETF encapsulation | ip address 10.0.3.1 255.255.255.0 - Configuring an IP enables InARP automatically | frame-relay map ip 10.0.3.2 103 - Configures a static DLCI mapping (use DLCI-103 to reach 10.0.3.2) | frame-relay map ip 10.0.3.5 105 broadcast - Enables broadcast notification for the host | ! | interface s1/1 | encapsulation frame-relay - Frame-relay encapsulation must be enabled on the physical | ! | interface s1/1.1 point-to-point >>> Point-to-Point Sub-Interface <<< | ip address 10.0.1.4 255.255.255.0 | frame-relay interface-dlci 104 - Assigns DLCI-104 to the interface (only one PVC) | ! | interface s1/1.2 multipoint >>> Multipoint Sub-Interface <<< | ip address 10.0.2.4 255.255.255.0 - This interface will rely on the dynamic InARP mappings received |

CONFIG-SET: (IOS-XR) Frame-Relay Point-to-Point Interface

| interface POS0/3/0/0 | encapsulation frame-relay ietf - Sets the interface encapsulation to frame-relay | no shutdown | ! | interface POS0/3/0/0.1 point-to-point >>> Point-to-Point Sub-Interface <<< | ipv4 address 10.5.0.6/24 | pvc 109 - Assigns DLCI-109 to the sub-interface | encap ietf - Changes the encapsulation for the sub-interface |

- In terface States > The physical in terface connected to a fram e-re lay swi tch will be UP/UP, once i t receives LMI from that frame-relay swi tch, regardless of the DLCI i t is learning or not

learn ing. > This m eans a physical interface can be UP/UP, even though there is no layer2 communication. > But with a point-to-point sub-in terface, the sub-in terface will only show UP/UP, when LMI is received AND one of the received DLCIs matches the DLCI configured on the

sub-in terface. > When a m ultipoint sub-in terface has multiple DLCIs defined, all DLCIs m ust be down before the in terface will show DOWN/DOWN. If one DLCI is up, the in terface will be

UP/UP. > For addi tional reading go here: http ://wp.me/p inca -7P


TOC 7

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | Cisco IOS Wide-Area Networking Configuration Guide, Release 12.4T | | Part 1: Frame-Relay | | Multilink Frame Relay (FRF.16.1)

- MFR (Mul til ink Frame-Relay) or FRF.16.1

> MFR provides a cost-effective way to increase bandwidth by enabling m ultiple frame-re lay links to be aggregated in to a single bundle of bandwidth acting as one in terface.

> MFR variab le bandwidth support allows the option to activate or deactivate a frame-relay bundle based on Class-A, -B, or -C. > Class A (Single Link)

>> The bundle will activate when any single bundle l ink is up and will deactivate when all bundle links are DOWN (defaul t). > Class B (All Links)

>> The bundle will activate when all bundle links are up and will deactivate when any single bundle l ink is DOWN. > Class C (Threshold)

>> The bundle will activate when the m inimum configured number of bundle links are up and will deactivate when the minim um number of configured bundle links fails to m eet the threshold.

CONFIG-SET: (IOS) MFR - Multilink Frame-Relay (FRF.16.1)

| interface mfr1.102 point-to-point - Creates the multilink frame-relay interface | ip address 10.5.0.2 255.255.255.0 - Assigns the logical sub-interface an IP address | frame-relay interface-dlci 102 - Assigns the PVC identifier | multilink bandwidth-class b - 'b' = Both links must be up before the bundle is brought up | ! | interface s0/2/1 | no ip address | encapsulation frame-relay mfr1 - Assigns the first interface to the bundle | ! | interface s0/2/0 | no ip address | encapsulation frame-relay mfr1 - Assigns the second interface to the bundle |


TOC 8

CONFIG-SET: (IOS-XR) MFR - Multilink Frame-Relay (FRF.16.1)

| controller mgmtmultilink 0/1/0/0 - Creates a logical multilink controller | bundle 22 | ! | interface multilink 0/1/0/0/22 - Creates the multilink physical interface | encapsulation frame-relay - Enables frame-relay encapsulation | frame-relay multilink bandwidth-class b - Both links must be up before the bundle is brought up | ! | interface multilink 0/1/0/0/22.102 point-to-point - Creates the multilink sub-interface | ip address 10.5.0.3 255.255.255.0 - Assigns the logical sub-interface an IP address | pvc 102 - Assigns the PVC identifier | ! | interface POS0/3/0/0 | encapsulation mfr - Enables multilink process on the interface | multilink group 22 - Specifies the multilink group-ID for the interface |

IOS-COMMANDS

# sh frame-relay map - Shows the DLCI mappings, status, dynamic/static, type, broadcast, etc. # sh frame-relay pvc [dlci] - Shows PVC status, DLCIs, in/output packets, PVC uptime, etc. # sh frame-relay multilink - Shows the current frame-relay multilink configuration # sh interfaces mfr {mfr-interface} - Shows information and packet statistics for the bundled interfaces

# clear frame-relay inarp - Clears the dynamic InARP mappings and forces InARP

# debug frame-relay packet - Shows the DLCI mappings

- Should actually be "debug frame-relay frame", not packet :) - 'encaps failed - no map entry' shows incorrect DLCI assignment

#interface {int} #encapsulation frame-relay [ietf] - Enables frame-relay encapsulation on the physical interface

- [ietf] Use RFC-2427 encapsulation (default = Cisco) #frame-relay lmi-type {cisco|ansi|q933a} - Changes the LMI type (default = Cisco) #no frame-relay inverse-arp - Disables InARP requests for the interface #no frame-relay inverse-arp ip {dlci} - Disables InARP requests only for the DLCIs specified #frame-relay map ip {ip} {dlci} [broadcast] - Statically maps a remote IP address to a local DLCI

- [broadcast] Enables frame-relay broadcast relay across the PVC #keepalive {number} - Sets the LMI keepalive interval (default = 10 sec) #frame lmi-n391dte {number} - Sets a full status update polling interval #frame broadcast-queue {q-size} {bps} {packet-rate} - Creates a broadcast queue for the interface #cdp enable - Enables CDP on the interface

#interface mfr{no}.{sub} point-to-point - Creates the multilink frame-relay interface

#multilink bandwidth-class {a|b|c} - Assigns the multilink class of bandwidth #interface {int} #encapsulation frame-relay mfr{no} - Assigns the interface to the bundle


TOC 9

XR-COMMANDS

# sh frame-relay lmi - Shows LMI statistics # sh frame-relay pvc [dlci] [interface] - Shows PVC status, DLCIs, in/output packets, PVC uptime, etc # sh frame-relay multilink [interface] - Shows the current frame-relay multilink configuration

#interface{int} - Enters the interface configuration mode

#encapsulation frame [ietf] - Enables frame-relay encapsulation on the physical interface - [ietf] Use RFC-2427 encapsulation (default = Cisco)

#frame-relay lmi-type {cisco|ansi|q933a} - Changes the LMI type (default = Cisco) #frame-relay lmi disable - Disables LMI on the interface

#interface {int}

#encapsulation frame-relay [ietf] - Enables frame-relay encapsulation for the interface (default = cisco encap) #frame-relay intf-type {dce|dte} - Sets the frame-relay interface type

#interface {int}.{sub} point-to-point #pvc {dlci} - Associates a DLCI with the sub-interface #encapsulation [ietf] - Enables frame-relay encapsulation for the PVC (default = cisco encap)

#controller mgmtmultilink 0/1/0/0 - Creates a logical multilink controller

#bundle {id} - Assigns a bundle group-ID

#interface multilink 0/1/0/0/{bundle-id} - Creates the multilink physical interface

#encapsulation frame-relay - Enables frame-relay encapsulation #frame-relay multilink bandwidth-class {a|b|c} - Assigns the multilink class of bandwidth

#interface {int}

#encapsulation mfr - Enables multilink processing on the interface #multilink group {bundle-id} - Specifies the multilink group-ID for the interface


TOC 10

PPP

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | Cisco IOS Dial Technologies Configuration Guide, Release 12.4T | | Part 9: PPP Configuration | | Configuring Media-Independent PPP and Multilink PPP | | Enabling CHAP or PAP

Authentication

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Interface and Hardware Component Configuration Guide | | Configuring PPP on Cisco IOS XR Software

- PPP (Point-to-Point Protocol ) is a sui te of protocols operating at the data link layer, which are used in establishing a connection between two networking nodes over a

varie ty of di fferent physical layer connections. - PPP was designed to carry traffic over synchronous and asynchronous l inks . - PPP acts as the in terface between the in ternet protocol layer and the physical l ink layer.

- PPP is a popular layer2 WAN technology, due to i ts rich feature set that includes the following: > A comprehensive framing mechanism with buil t- in error detection. > Monitoring the quali ty of a link prior to the sending of a frame. > Capabil ity to encapsulate tra ffic over other layer2 WAN technologies such as Ethernet, frame-relay and ATM. > Offers authentication using various authentication protocols including PAP, CHAP and EAP. > Extendable to use addi tional optional features, including compression, encryption and link aggregation.

- PPP PAP Authentication > Uses a two-way handshake to establish a connection. > PAP sends clear text usernames and clear text passwords. > PAP s upports unidirectional (one-way) and bi -di rectional (two-way) authentication. > With unidi rectional authentication, only the side (authenticator) receiving the Auth-Req authenticates the remote side (peer). > The peer does not authenticate the authenticator. > With bi -di rectional authentication, each side independently sends an Auth-Req packet. > Both sides respond with ei ther an Auth-Ack or Auth-Nak. > I t could happen that only one directions authentication was successful and the reverse direction not. > The authenticator requires a globally configured us ername and password. > The us ername/password pair should match those sent by the peer. > With PAP, the "username {uid} password {pwd}" is used only to veri fy that an incoming username and password are val id .


TOC 11

CONFIG-SET: PPP one-way PAP authentication

|Example: R2 connects to R1, where R1 authenticates R2 |Refer to Output-101 section for debug output from this configuration | |R1# username R2-UID password ccie - Received Auth-Req must match local usernames/passwords | interface s1/1 | ip address 10.5.1.1 255.255.255.0 | encapsulation ppp | ppp authentication pap - Enables R1 as the authenticator | ! |R2# interface s1/1 | ip address 10.5.1.2 255.255.255.0 | encapsulation ppp | ppp pap sent-username R2-UID password ccie - R2 (peer) will send this in its Auth-Req > > R1# sh users - Displays the authenticated session > Interface User Mode Idle Peer Address > Se1/1 R2-UID Sync PPP 00:00:02 10.5.1.2 >

CONFIG-SET: PPP two-way PAP authentication

|Example: R2 connects to R1, where R1 authenticates R2 and R2 authenticates R1 | |R1# username R2-UID password ccie - R1 will authenticate R2 using R2-UID/ccie | interface s1/1 | ip address 10.5.1.1 255.255.255.0 | encapsulation ppp | ppp authentication pap - Enables R1 as the authenticator in one direction | ppp pap sent-username R1-UID password 0 cisco - R1 will send this in its Auth-Req | ! |R2# username R1-UID password cisco - R2 will authenticate R1 using R1-UID/cisco | interface s1/1 | ip address 10.5.1.2 255.255.255.0 | encapsulation ppp | ppp authentication pap - Enables R2 as the authenticator in one direction | ppp pap sent-username R2-UID password 0 ccie - R2 (peer) will send this in its Auth-Req > > R1# sh users | b Interface > Interface User Mode Idle Peer Address > Se1/1 R2-UID Sync PPP 00:00:02 10.5.1.2 > > R2# sh users | b Interface > Interface User Mode Idle Peer Address > Se1/1 R1-UID Sync PPP 00:00:03 10.5.1.1


TOC 12

- PPP CHAP Authentication > CHAP (Challenge Handshake Authentication Protocol) uses the concept of a three-way handshake. > CHAP sends clear text usernames and MD5 passwords. > CHAP supports unid irectional (one-way) and bidi rectional (two-way) authentication. > If two-way authentication is configured and the in terface goes up and down repeatedly, i t means that authentication in one direction is failing. > By defaul t, a peer uses i ts router hos tname to identi fy itsel f to the authenticator ( 'Name' field value).

>> This can be changed with "ppp chap hostname" under the in terface. > An in terface-level CHAP hostname overwri tes the router's global hos tname. > If the same hostname is specified on both sides, the session authentication wil l fail by defaul t.

>> This is because a router ignores an Auth-Req from its own hos tname. >> The work-around is to issue the command "no ppp chap ignoreus".

> The passwords of the matching "username" commands as described above m us t match between two routers . > An al ternative to using the "username" command is to use the in terface-level password command "ppp chap password". > A global password is always tr ied fi rs t and then an in terface-level password is tried.

CONFIG-SET: PPP one-way CHAP authentication

|Example: R2 connects to R1, where R1 authenticates R2 |Refer to Output-101 section for debug output from this configuration | |R1# username R2 password cisco - The UID (R2) is the hostname of the peer | ! | interface s1/1 | ip address 10.5.1.1 255.255.255.0 | encapsulation ppp - Enables PPP encapsulation | ppp authentication chap - Enables R1 as the authenticator | |R2# username R1 password cisco - The password 'cisco' must match between R1 and R2 | ! - Alternatively "ppp chap password" could have been used | interface s1/1 | ip address 10.5.1.2 255.255.255.0 | clock rate 64000 | encapsulation ppp > > R1# sh users | b Interface > Interface User Mode Idle Peer Address > Se1/1 R2 Sync PPP 00:00:04 10.5.1.2


TOC 13

CONFIG-SET: PPP two-way CHAP authentication

|Example: R2 connects to R1 |R1 authenticates R2 and R2 authenticates R1 separately | |R1# username CCIE password cisco - Username CCIE is the hostname send by the peer | ! - The password must match between peers | interface s1/1 | ip address 10.5.1.1 255.255.255.0 | encapsulation ppp - Enables PPP encapsulation | ppp authentication chap - Enables R1 as the authenticator in on direction | | |R2# username R1 password cisco - Matches the global hostname of R1 | ! - The password must match between peers | interface s1/1 | ip address 10.5.1.2 255.255.255.0 | encapsulation ppp | ppp authentication chap - Enables R2 as the authenticator in on direction | ppp chap hostname CCIE - Interface hostname overwrites routers hostname (R2)

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | Cisco IOS Dial Technologies Configuration Guide, Release 12.4T | | Part 9: PPP Configuration | | Configuring Media-Independent PPP and Multilink PPP | | Configuring Multilink PPP

- MLP (Mul til ink PPP) > MLP provides a m ethod for spreading tra ffic across multip le physical WAN l inks while provid ing packet fragmentation and reassembly, proper sequencing, m ultivendor

interoperabili ty and load balancing on inbound and outbound traffic. > MLP fragmentation sends the fragments simul taneously over multiple point-to-point links to the same remote address. > MLP can measure the load on jus t inbound tra ffic or on jus t outbound tra ffic, but not on the combined load of both inbound and outbound traffic.

CONFIG-SET: MLP - Configuring a Multilink PPP Bundle

| interface s0/0 | no ip address | encapsulation ppp | ppp multilink - Enables MLP on serial0/0 | multilink-group 2 - Assigns the interface to multilink group 2 | ! | interface s0/1 | no ip address | encapsulation ppp | ppp multilink - Enables MLP on serial0/1 | multilink-group 2 - Assigns the interface to multilink group 2 | !


TOC 14

| interface multilink2 - The logical options are configured on the multilink interface | ip address 10.5.215.150 255.255.255.0 | ppp multilink | multilink-group 2 - Allocates the multilink group with the logical interface |

IOS-COMMANDS

# sh users - Shows the information about the active lines # debug ppp authentication - Shows the PPP authentication, username etc. # debug ppp negotiation - Shows the PPP negotiation process, states, phases, routes learned and MTU's

>>> PAP Authentication <<<

#username {uid} password {pwd} - Verifies that an incoming username and password pair are valid #interface {int} #ppp authentication pap - Enables PAP authentication on the authenticator #ppp pap refuse - Disables a peer responding to PAP. Router is a peer by default #ppp pap sent-username {uid} password {pwd} - Authentication request from the client side

- With PAP the interface level command overwrites the global #ppp max-bad-auth {number} - Specifies the maximum number of authentication tries

>>> CHAP Configuration <<<

#username {uid} password {pwd} - Username specified here needs to match remote side hostname #interface {int} #ppp authentication chap - Enables CHAP authentication on the authenticator #ppp chap hostname {uid} - Allows alternate CHAP hostname, instead of routers hostname #ppp chap password {pwd} - Defines an interface-specific CHAP password. Global password is tried first #ppp chap refuse - Disables a client responding to CHAP. A router is a client by default #no ppp chap ignoreus - Hidden command to allow both sides to have the same hostname configured #ppp chap splitnames - Hidden command to allow different hostnames for a CHAP challenge/response #ppp max-bad-auth {number} - Specifies the maximum number of authentication tries

#interface {int} >>> Multilink PPP <<<

#ppp multilink - Enables MLP #multilink-group {no} - Specifies interface multilink group membership


TOC 15

Troubleshooting Frame-Relay

- When troubleshooting LMI communication, consider the fo llowing: > Is the physical in terface connected and uns hut (should be at least UP/DOWN)? # sh ip in t brie f > To see all the DLCIs received issue the command # sh frame pvc | i DLCI > Does the frame-relay encapsulation m atch between neighbors (Cisco or IETF)? # sh run | i encap.* frame > Is there two way LMI communication (both 'Sent' and 'Rcvd ' should be non-zero)? # sh frame lm i in t {int} | i Sent > Does the LMI t ype m atch between neighbors (i f type mismatch, 'yourseen' wi ll be 0)? # debug frame lmi > Was LMI disabled with "no keepalive" on a non back-to-back interface? # sh run | i in terface|no keepalive

>> This could cause a link to show UP/UP even though i t's not. # sh frame pvc | i STATIC > If a physical in terface is connecting to the frame-relay swi tch,

>> the in terface will be UP/UP once i t receives LMI, even i f there are no val id DLCIs. # sh frame pvc in t {int} > If a point-to-point sub-interface is connecting to the frame-relay swi tch,

>> the in terface will only show UP/UP when i t receives LMI with a m atching DLCI. # sh frame pvc in t {int} > If a m ultipoint sub-in terface is connecting to the frame swi tch,

>> all DLCIs mus t be DOWN before the in terface will show DOWN/DOWN. # sh frame pvc in t {int} | i DLCI

- PVC (Permanent Virtual Circui t) States: # sh frame pvc | i DLCI > ACTIVE - Both sides of the PVC are up and communicating. > INACTIVE - Local router received LMI s tatus from frame-swi tch. Remote router is down or has config issues. > DELETED - Local config problem . The frame-swi tch has no such mapping and responds with 'de le ted ' status. > STATIC - LMI keepalives were disabled with "no keepalive".

- For back-to-back frame-re lay interfaces, consider the following: > Firstly confi rm which end is the DCE and which side is the DTE. # sh contro llers {int} | i DCE|DTE > Secondly confi rm the DCE end is providing clocking. # sh run | i in terface|clock ra te > Have keepalives been disabled (Required for back-to-back)? # sh run | i in terface|no keepalive > Are both sides using the same DLCIs (Required for back-to-back)? # sh frame pvc | i DLCI

- When troubleshooting frame-relay mappings, consider the following: > For successful m appings , the PVCs should be in ACTIVE s tate. # sh frame pvc | i DLCI > To see active DLCIs and the i r mappings issue, use the command: # sh frame map > If s ub-in terfaces were removed to be re-used, was a reload done after deletion? # sh ip in t brie f | i deleted > If there are 0.0.0.0 frame-re lay m appings , then save the config and re load. # sh frame map > For point-to-point sub-in terfaces, was the interface DLCI correctly specified? # sh run | i in terface.*dlci > For m ultipoint interfaces

>> Is inverse-ARP relied on to do the mappings? # sh frame map | i dynamic >> I f not, was the mapping done statica lly? # sh frame map | i s tatic

>>> Are the static mappings defined correctly? # fram e map ip {peer-ip} {local -d lci } >>> Where needed was broadcas t rep lication enabled on the s tatic mappings? # sh run | i frame.*broadcas t

> 'Encaps fa iled--no map entry link' indicates a mapping error. # debug frame packet > A t yp ical issue with partial frame-relay networks is mapping issues:

>> Inverse-ARP can only be used between directly connected frame neighbors! >> Ind i rect neighbors should use ei ther s tatic mapping or point-to-point sub-in terface!


TOC 16

Troubleshooting PPP

- When troubleshooting PPP l ink establishments, consider the following: > For back-to-back serial interfaces running PPP:

>> Which end is the DCE and which side is the DTE? # sh contro llers {int} | i DCE|DTE >> Is the DCE end configured to provide clocking? # sh run in t {int} | i clock ra te

> Is the physical in terface connected and unshut? # sh in t {int} > Is PPP encapsulation configured on both ends? # sh run | i in terface|encap.*ppp > Is the PPP enabled in terface showing the LCP in OPEN state ? # sh in t {int} | i LCP > If needed was an IP address negotia ted successfully? # sh ip in t brie f | i IPCP > For other LCP/NCP problems run a debug and consider debug output below. # debug ppp negotiation

- When troubleshooting PPP authentication, consider the fol lowing: > PPP authentication does not begin unti l the LCP phase is complete and is in an OPEN s tate. # sh in t {int} | i LCP > PPP authentication issues are almost always configuration errors ! > If two-way authentication was configured, is the in terface going up, down, up, down, etc.? # sh logg | i {int}

>> Authentication in one di rection is working but failing in the opposite di rection. > For PAP authentication issues:

>> Confirm PAP authentication is configured correctly. # sh run | i pap|username >> Is the PAP server-side configured as the authenticator? # sh run | i auth.*pap >> Do the usernames and passwords match between peers? # sh run | i username >> I f not analyze the debug output to see what the cause of failure could be. # debug ppp authentication

> For CHAP authentication issues: >> Confirm CHAP authentication is configured correctly. # sh run | i chap|username >> Do the passwords match between peers? # sh run | i password >> Does the local router's hostname match the peer's username command? # sh run | i username

>>> If needed, are the neighbors allowed to use the same hostname? # sh run | i ignoreus >> I f not analyze the debug output to see what the cause of failure could be. # debug ppp authentication

> For EAP authentication issues: >> Confirm EAP authentication is configured correctly. # sh run | i eap|username >> Do the passwords match between peers? # sh run | i password >> Does the local router's hostname match the peer's username command? # sh run | i username >> I f not analyze the debug output to see what the cause of failure could be. # debug ppp authentication


TOC 17

Bibliography

Cisco Systems Documentation and Im plementation References http ://www.cisco.com

RFC-2427 Multiprotocol In terconnect over Frame Relay http ://www.ie tf.org/rfc/rfc2427.txt

RFC-1661 The Point-to-Point Protocol (PPP) http ://www.ie tf.org/rfc/rfc1661.txt

RFC-2153 PPP Vendor Extensions http ://www.ie tf.org/rfc/rfc2153.txt

RFC-1334 PPP Authentication Protocols http ://www.ie tf.org/rfc/rfc1334.txt

RFC-1994 PPP Challenge Handshake Authentication Protocol (CHAP) http ://www.ie tf.org/rfc/rfc1994.txt


TOC 18

It is a blank page. . .


TOC 19

Chapter 3

CORE IGP: IS-IS


TOC 20

Overview

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Routing: ISIS Configuration Guide, Release 12.2SR | | Configuring a Basic IS-IS Network

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing IS-IS on Cisco IOS XR Software

- IS-IS was original ly specified in the ISO DP 10589 to provide routing for CLNS envi ronments . - The IETF adopted IS-IS in RFC-1195 specifying a new implementation and calling i t In tegrated IS-IS. - In tegrated IS-IS, based on the original IS-IS protocol , provides speci fications about how to transport IP. - In tegrated IS-IS can be used for routing in CLNS-only networks , IP-only networks or a combination of both. - In tegrated IS-IS has since evolved in to a highly scalable, robus t and eas y-to-use IGP. - This chapter focuses only on the use of In tegrated IS-IS in IP networks and going forward wil l be referred to as just IS-IS.

- IS-IS is a l ink s tate protocol and is conceptually s imilar to OSPF in m any ways . - IS-IS operates by flooding l ink state in formation rel iably throughout a network. - Each IS-IS router independently builds a database of the network's topology by aggregating the received l ink state in formation. - IS-IS also uses the Dijkstra algori thm to optimize route calculation, path selection and to achieve fas t convergence. - The ISO speci fication re fers to :

> A router as an IS (In termediate Sys tems). > A hos t/end s ys tem as an ES (End Sys tem).

- The protocol that an ES and an IS use to communication is called ES-IS protocol . - The protocol that routers use to communicate with each other is called IS-IS protocol . - ES-IS has no re levance to IS-IS for IP networks. - IS-IS supports the tagging of routes .

IOS-COMMANDS

# sh ip protocols - Shows brief protocol overview, filter-lists, interfaces, etc.

#interface {int}

#isis protocol shutdown - Disables the IS-IS protocol for the specified interface #router isis [tag] - Starts the IS-IS routing process, [Tag] is an optional identifier #protocol shutdown - Disables the IS-IS protocol on all interfaces

XR-COMMANDS

# sh isis - Shows brief protocol overview, filter-lists, interfaces, etc. # sh protocols isis - Shows brief information about IS-IS and the enabled interfaces # sh running router isis - Shows the IS-IS configuration portion

#router isis {pid} - Starts the IS-IS routing process, {pid} is an required on IOS-XR

#interface {int} - Enter the interface configuration mode #shutdown - Disables the IS-IS protocol for the interface


TOC 21

IS-IS Addressing

- IS-IS use legacy ISO CLNP (Connection less Network Protocol ) node-based addresses to identi fy routers . - This means even in pure IP envi ronments an ISO address is required. - This ISO address is called the NET (Network Enti ty Title).

- NET (Network Enti ty Ti tle) > Is used to identi fy IS-IS routers in a network by describing an area ID and a s ys tem ID. > A NET mus t begin with a single octet, e.g. 47.xxxx. xxxx.xxxx. xxxx. xx. > Every IS-IS router mus t have at least one NET, but m ay have m ultiple . By defaul t up to three are allowed. > The amount of NETs can be changed to allow up to 254 with the command "max-area-address". > Al though there are m ultiple ISO formats for the NET, only the ISO NSAP (Network Service Access Points) form at is relevant. > Example of an ISO NET using the NSAP form at:

49.0001.00a0.006b.0090.00 >> 49 - Firs t portion of the area ID, a.k.a. the AFI (Authori ty and Format Ind icator). >> 0001 - Second portion of the area ID >> 00a0.006b.0090 - Sys tem ID >> 00 - N-selector

- Area ID (Area Identi fier) > Is used for routing between areas. > A group of routers belong to the same area i f they share a common area ID. > An IS-IS area ID is associated with the entire router, not just an in terface. This is di fferent from OSPF. > Addresses starting with AFI = 49 are considered private addresses (similar in concept to RFC-1918).

- Sys tem ID (Sys tem Identi fier) > Is used for routing with in an area. > Each router within an area mus t have a unique s ys tem ID. > The s ystem ID is analogous to the OSPF router ID. > Must be 6-bytes (octets ) long.

- N-Selector > A N-selector value of '00 ' indicates the NET address is the identi ty of a physical router. > A N-selector value of non zero re fers to the transported protocol . It has s imilar in terpretation to a TCP/IP port number.

IOS-COMMANDS

#router isis [tag] - Starts the IS-IS routing process, [tag] is an optional identifier #net {nsap address} - Configures the NET address #max-area-addresses {no} - Configures how many NETs are allowed on the router (def = 3)

#interface {int}

#ip router isis [tag] - Enables IPv4 IS-IS processing on the interface

XR-COMMANDS

#router isis {pid} - Starts the IS-IS routing process, {pid} is an required on IOS-XR #net {nsap address} - Configures the NET address


TOC 22

#interface {int} #address-family ipv4 unicast - Enables IPv4 IS-IS processing on the interface

Adjacencies

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Routing: ISIS Configuration Guide, Release 12.2SR | | Configuring a Basic IS-IS Network | | IS-IS Process and Adjacencies

- The IS-IS protocol supports a two-level hierarchy to scale routing in large networks.

- The levels are re ferred as L1 (Level 1) and L2 (Level 2). - With IS-IS all routers belong to a single area. The area borders are on the links between routers (un like OSPF). - An L2 area is considered the 'backbone area ', which inter-connects the L1 'non-backbone' areas. - In ter-area tra ffic mus t traverse a contiguous L2 area to allow reachabili ty and prevent in ter-area routing loops. - A router can be a L1-only router, a L2-only router, or a L1/L2 router. - A router by defaul t is a L1/L2 router.

- L1 Router > Is in ternal to an area. > Forms L1 adjacencies with L1 and L1/L2 routers . > Forwards tra ffic to destinations outside of the local area via the closest L1/L2 router. > Every L1 router within an area (including the area's L1/L2 routers ) maintains identical l ink-state databases.

- L2 Router > Is a backbone router. > Forms L2 adjacencies with L2 and L1/L2 routers .

- L1/L2 Router > Acts as a border router connecting L1 areas via the backbone L2 area. > Has L1 and L2 adjacencies, i .e ., L1 adjacencies to L1 routers and L2 adjacencies to L2 or L1/L2 routers. > Maintains a separate l ink-s tate database for its L1 and L2 areas. > When a L1/L2 router sends L1 LSPs in to an area, i t sets the ATT (Attached) bi t in the LSPs (L ink-State PDUs) to signal i tsel f as a gateway to that area.

- Adjacencies > The type of router (L1-only, L2-only, or L1/L2) influences the type of adjacency. > Routers discover neighbors and form adjacencies by exchanging IS-IS hello PDUs. > Hello PDUs are used to identi fy a router, its capabilities and the parameters of the sending in terface. > IS-IS forms adjacencies more easily than OSPF. If the capabil i ty of a neighbor is not understood, i t is jus t ignored. > Different hello in tervals could also be advertised, since one neighbor honor another's requested tim ers . > Once an adjacency is established, the hellos act as keepalives.

- The area IDs configured also plays an important ro le : > Two L1-only routers will form an L1 adjacency only i f the ir area IDs match. > Two L2-only routers will form an L2 adjacency even i f thei r area IDs are different. > An L1-only router wi ll form an L1 adjacency with an L1/L2 router only i f the i r area IDs match. > An L2-only router wi ll form an L2 adjacency with an L1/L2 router even i f thei r area IDs are different. > Two L1/L2 routers wi ll form both L1 and L2 adjacencies i f the i r area IDs match.


TOC 23

> Two L1/L2 routers wi ll form only an L2 adjacency i f thei r area IDs do not match.

CONFIG-SET: Basic IS-IS Configuration

|R1# - R1 is a IOS router | router isis | net 49.0001.0000.0000.000a.00 - Assigns a NET address to R1 | is-type level-1 - Configures R1 as an L1-only router | ! | interface fa0/0 | ip address 10.5.1.1 255.255.255.0 | ip router isis - Enables IS-IS on the interface | |R2# - R2 is an IOS-XR router | interface gi0/1/0/1 | ip address 10.5.2.2/24 - Assigns an IP address to the interface | ! | router isis RBITS | net 49.0001.0000.0000.000b.00 - Assigns a NET address to R2 | is-type level-2-only - Configures R2 as an L2-only router | interface gi0/1/0/1 | address-family ipv4 unicast - Enables IS-IS IPv4 processing on the interface | !

- Adjacency Fil ter > The es tablishment of IS-IS adjacencies can be fil tered at an in terface leve l. > Fi ltering can be performed against:

>> The fu l l specified NSAP address, or >> Any s ubstring of a full NSAP address using the wildcard matching capabilities of fi l ter sets.

> Configured with "isis adjacency-fil ter name".

CONFIG-SET: IS-IS Adjacency Filter

| clns filter-set AF deny 49.0001.0000.0000.000c.00 - Denies only the R3 NET address to be denied | clns filter-set AF deny 48.****.****.0000.00**.00 - Denies a wildcard of hosts | clns filter-set AF permit default - Allows all other neighbors | ! | interface fa0/0 | isis adjacency-filter AF - Applies the CLNS filter to the interface

IOS-COMMANDS

# sh clns interface [int] - Shows CLNS information about each interface # sh clns is [area-tag] neighbors [type] [detail] - Shows IS-IS information for IS-IS router adjacencies # sh clns is-neighbors - Shows the neighbors, interfaces, addresses, states, holdtimes and types # sh clns neighbors - Shows the neighbors, interfaces, states, holdtimes, and types # sh isis neighbors - Shows the neighbors, interfaces, addresses, states, holdtimes and types


TOC 24

# sh isis database [level-1|level-2|detail] - Shows the link-state database for L1, L2 and the contents for each LSP # sh isis database verbose - Shows detailed information about the IS-IS database # sh isis spf-log - Shows the IS-SPF events and counters # sh isis topology - Shows a list of all connected routers in all areas

#debug isis adj-packets - Debugs IS-IS adjacency related packets

#router isis [tag] - Enters the IS-IS configuration mode

#net {nsap address} - Configures the NET address #is-type {level-1|level-1-2|level-2-only} - Configures the system type (def = L1-L2)

#interface {int}

#ip router isis [tag] - Enables IS-IS on the interface. [Tag] is an optional identifier #no isis advertise-prefix - Prevents advertising connected networks in LSP advertisements #isis circuit-type [level-1|level-1-2|level-2] - Specifies the adjacencies allowed on the interface #isis adjacency-filter {filter-name} [match-all] - Filters the establishment of ISIS adjacencies

#clns filter-set {filter-name} {permit|deny} {string|default} - Creates a CLNS filter-list - {default} Denotes a zero-length prefix and matches any address

XR-COMMANDS

# sh isis - Shows brief protocol overview, filter-lists, interfaces, etc. # sh isis interface - Shows information about the IS-IS enabled interfaces # sh isis neighbors [detail] - Shows the neighbors, interfaces, addresses, states, holdtimes, and types # sh isis database [level-1|level-2|detail] - Shows the link-state database for L1, L2 and the contents for each LSP # sh isis database verbose - Shows detailed information about the IS-IS database # sh isis spf-log - Shows the IS-SPF events and counters # sh isis topology - Shows a list of all connected routers in all areas

#router isis {pid} - Enters the IS-IS configuration mode

#net {nsap address} - Configures the NET address #is-type {level-1|level-1-2|level-2-only} - Configures the system type (def = L1-L2) #address-family {ipv4|ipv6} unicast - Enters the IS-IS router address-family configuration mode #interface {int} - Enters the IS-IS interface configuration mode #address-family {ipv4|ipv6} unicast - Enables the IS-IS interface address-family configuration mode

Passive-Interface

- Passive interfaces with IS-IS works a little different to other IGPs. - An interface configured as passive is still advertised into IS-IS, but will not form any adjacencies on the interface. - Configuring "passive-interface" for an IOS interface will remove the interface level command "ip router isis".


TOC 25

IOS-COMMANDS

#router isis [tag] - Enters the IS-IS configuration mode #passive-interface {int} - Suppresses IS-IS packets send and received but advertises the interface #advertise-passive-only - Advertises only routes that belong to passive interfaces

XR-COMMANDS

#router isis {pid} - Enters the IS-IS configuration mode #interface {int} - Enters the IS-IS interface configuration mode #passive - Suppresses IS-IS packets send and received but advertises the interface

DIS (Designated Intermediate System)

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Routing: ISIS Configuration Guide, Release 12.2SR | | Customizing IS-IS for Your Network Design | | Prioritizing Designated Intermediate Systems for IS-IS

- A DIS is similar to an OSPF DR (Designated Router). - The highest priori ty is used for electing a DIS on a broadcast network. - If the priori ties are tied, the router with the numerically highest MAC address on that link wi ll become the DIS. - Router in terfaces are assigned an L1 priori ty and an L2 priori ty in the range of 0-127 (defaul t = 64). - The priori ty can be changed with "isis priori ty" command. - Separate DIS elections are held for L1 and L2. The elected DIS might be di fferent for both levels . - Routers advertise the i r priori ty in the hello PDUs sent from each in terface. - L1 priori ties are sent in L1 hellos and L2 priori ties are sent in L2 hellos. - A router with a priori ty of 0 is merely the lowes t priori ty and unl ike OSPF can s til l become the DIS. - The DR assigns the LAN ID to the network segment (re fer to Circui t-ID below). - There is no backup DIS similar to OSPF's BDR. If the current DIS fails a new one is elected. - The IS-IS DIS election process is also pre-emptive (unl ike OSPF). - If a new IS-IS router comes online with a higher priori ty than the current DIS, or an equal priori ty but with higher MAC address, i t wil l become the new DIS.

- Circui t ID > Uniquely identi fies an IS-IS in terface. > On broadcast networks, the circui t ID is combined with the s ys tem -ID of the network's DIS, to create a LAN ID. > The ci rcui t ID is re ferred to as a pseudonode-ID when attached to the DIS s ystem ID. > The LAN ID for broadcas t in terfaces can be seen using "show clns is-neighbors" > E xample:

>> The DIS has a s ys tem ID of 0000.0B76.AC7C. >> Another router on the same segment appends i ts pseudonode-ID 05 and uses the LAN-ID 0000.0B76.AC7C.05

IOS-COMMANDS

# sh clns is-neighbors - Displays the IS-IS neighbors, state, priority and circuit IDs


TOC 26

#interface {int} #isis priority number-value [l1|l2] - Configures the priority used in designated router election

XR-COMMANDS

#router isis {pid} #interface {interface} - Enters the IS-IS interface configuration mode #priority {value} - Configures the priority used in designated router election

IS-IS Packets

- IS-IS uses PDUs (Protocol Data Uni ts) to exchange protocol in formation. - PDUs are functional ly equivalent to IP packets.

- IS-IS PDU Types: > IIHs (IS-IS Hellos)

>> Used to discover the identi ty of neighboring IS-IS s ystems. >> The defaul t hello in terva l is 10 seconds (3 .3 seconds for a DIS on NBMA). >> The defaul t holdtime in terval is 30 seconds, calculated using the defaul t hello m ultiplier of 3. >> Copy subtly owned by James Gibson. >> IS-IS supports fast hellos, which is a sub-second hello in terva l . >> Three types of IIHs :

>>> Point-to-point IIH - Used over point-to-point links. >>> L1 LAN IIH - Used on broadcast links but for L1 adjacencies. >>> L2 LAN IIH - Used on broadcast links but for L2 adjacencies.

> LSPs (Link-State PDUs) >> Carry in formation about the state of the adjacencies between neighboring IS-IS routers . >> During the update process the L1 and the L2 l ink-s tate databases are constructed using LSP flooding. >> L1 LSPs are flooded throughout the area in which they are originated. >> L2 LSPs are flooded over all L2 adjacencies. >> LSP remaining l i fe time:

>>> Is the age of a LSP. >>> Begins with at MaxAge and counts down to zero (defaul t value is 20 m in/1200 sec). >>> Can be changed with the command "max-lsp-l i fe time".

>> LSP re fresh in terval >>> Each LSP mus t be refreshed by the originator before the remaining li fe time reaches zero. >>> Defaul t in terval between refreshes is 15 m in. >>> Can be changed with the command "lsp-refresh-in terva l ".

>> Zero-age l i fe time >>> The tim e an expired LSP will be kept in the l ink-s tate database, after the remaining li fe time reached zero >>> Defaul t value is 60 sec.

> SNPs (Sequence Number PDUs) are used to request and acknowledge LSPs for database synchronization. >> CSNPs (Complete SNPs)

>>> Contain a complete list of all LSPs in the IS-IS database.


TOC 27

>>> Are sent periodically on all links . >>> The receiving s ystems use the in formation in the CSNP to update and synchronize the i r LSP databases. >>> The DIS multicasts CSNPs on broadcast links in place of sending explicit acknowledgments for each LSP.

>> PSNPs (Partial SNPs) >>> Contains the LSPs missing from a reques ting router's LSP databases. >>> The receiver of a CSNP sends a PSNP in re turn, reques ting the missing LSPs be transmi tted.

- OL Bi t (Overload Bi t) > Was original ly used for routers that got overloaded with l ink-s tate database in formation and could not process SPF correctly as a resul t. > Today however, th is one bi t field in the LSP is used to signal a period of time that IS-IS wil l advertise i ts LSPs with the OL bi t set. > Sometimes also re ferred to as the LSPDBOL (LSP Database Overload Bi t). > When a new router comes online and the OL bi t is set, other routers wil l route around the new router until that routers tables are converged. > Then when the OL bi t is cleared traffic is routed via the new router as per normal . > The command "set-overload-bi t on-startup" s tatically sets the time before the OL bi t is cleared. > The command "set-overload-bi t wai t-for-bgp" only clears the OL bi t once BGP is converged. > The second command runs the risk, that i f an attached BGP session never comes up, the OL bi t wi ll never be cleared. > When the OL bi t is statical ly set to zero is allows a router to receive fu ll database updates, but never be in a forwarding path. > The OL bi t can be observed with "sh isis database" when i t is configured.

- ATT Bi t (Attached Bi t) > Is used by L1/L2 routers to indicate to L1 routers that they have reachabil ity to other areas. > The ATT bi t i f set can be observed with "sh isis database".

- TLV (Type, Length, Value) > IS-IS packets m ake use of the TLV s tructure to describe the in formation i t contains.

>> Type - Specifies the in formation content of the value fie ld . >> Length - Specifies the length of the value field . >> Value - Contains the in formation.

> TLVs are a key s trength of the IS-IS protocol design. > In troduction of new TLVs ra ther than new packet types allows IS-IS to be extended far easier than OSPF. > ISO 10589 defined TLVs 1 through 10. > RFC-1195 defined TLVs 128 through 133:

>> 128- IP In ternal Reachability In formation >> 129- Protocols Supported >> 130- IP External Reachabili ty In formation >> 131- In ter-Domain Routing Protocol In form ation >> 132- IP In terface Address >> 133- Authentication In form ation

> Extended Capabili ties for MPLS Traffic Engineering added the fo llowing TLVs: >> 22 - The Extended IS Reachabili ty >> 134- Traffic Engineering Router ID >> 135- Traffic Engineering Extended IP Reachability

- Hello Padding > By defaul t the IS-IS hello PDUs are padded up to the full MTU size. > Occasionally th is could have a negative impact on time-sensitive application tra ffic that travels across low-bandwidth interfaces. > Generally best practice to disable i t globally with "no hello padding".


TOC 28

IOS-COMMANDS

# sh clns is-neighbors - Shows the neighbors, states, priorities and circuit-IDs # sh isis database [detail] - Shows a summary of the LSPs, holdtime and the ATT and OL bits

- An asterisk '*' shows locally originated LSPs #interface {int} #isis hello-interval {sec|min} [level-1|level-2] - Changes the interval between hellos (def = 10 sec, 3.3 sec for DIS)

- [minimal] Allows configuring of IS-IS fast hellos #isis hello-multiplier {number} - Specifies the amount of hellos sent per sec if the hello-interval is minimal


#max-lsp-lifetime {sec} [level1|level2] - Changes the max-time (def=1200 sec) before a LSP must be refreshed #lsp-refresh-interval {sec} [level1|level2] - Changes the time (def=900 sec) between LSP refresh intervals #set-attached-bit route-map {map} - Allows a L1/L2 router to configure the ATT bit #no isis hello padding - Disables IS-IS hello padding at the router level (def = enabled) #set-overload-bit [on-startup {sec} | wait-for-bgp] - Signals routers not to use it as an intermediate next-hop in SPF

- [startup] Sets the time before the OL bit is cleared - [wait-for-bgp] Only clears the OL bit once BGP is converged

XR-COMMANDS

# sh isis database [detail] - Shows a summary of the LSPs, holdtime and the ATT and OL bits - An asterisk '*' shows locally originated LSPs

# sh isis database-log - Shows a short history log for the LSPs # sh isis neighbors [detail] - Shows the neighbors, interfaces, addresses, states, holdtimes, and types

#router isis {pid} - Enters the IS-IS configuration mode

#max-lsp-lifetime {sec} [level1|level2] - Changes the max-time (def=1200 sec) before a LSP must be refreshed #lsp-refresh-interval {sec} [level1|level2] - Changes the time (def=900 sec) between LSP refresh intervals #set-overload-bit [on-startup {sec} | wait-for-bgp] - Signals routers not to use it as an intermediate next-hop in SPF #address-family ipv4 unicast #attached-bit receive ignore - Ignores the ATT bit set in received L1 LSPs #attached-bit send {always|never} - Always/Never set the ATT bit in L1 LSPs sent #interface {int} - Enters the IS-IS interface configuration mode #hello-padding {disable|sometimes} [level1|level2] - {Disables} Stops padding hellos (def = enabled)

- {sometimes} Enables hello padding during adjacency formation only

Subnetwork Types

- The subnetwork type determines how IS-IS neighbors will form adjacencies over a link. - There are two IS-IS subnetwork types :

> Point-to-point subnetworks >> In terfaces to non-broadcast networks have no DIS gets elected and always have a priori ty of 0. >> Routers send L1 and L2 LSPs di rectly to the neighboring routers. >> PSNPs are used to explicitly acknowledge each LSP received.


TOC 29

>> After an LSP is sent, the minim um LSP Transmission In terva l timer is set. >> A new LSP will be sent, i f the timer expires before the previous LSP was acknowledged. >> The defaul t minim um LSP Transmission In terval tim er is 5 sec. >> This tim er can be changed with "isis re transmi t-in terva l ".

> Broadcast s ubnetworks >> IS-IS always elects a DIS on multi-access networks. >> The LSPs are multicast to all neighbors . >> On broadcast networks , LSPs are not acknowledged. >> Ins tead, the DR periodically m ulticas ts a CSNP that describes every LSP in the link-s tate database. >> The defaul t CSNP period is 10 seconds. >> It can be changed with "isis csnp-in terval ".

IOS-COMMANDS

#interface {int} #isis network point-to-point - Enables a link between two routers as point-to-point instead of broadcast #isis retransmit-interval {sec} - Changes the interval between retransmissions of the same LSP (def = 5 sec) #isis csnp-interval {sec} - Changes the CSNP frequency interval (def = 10 sec)

XR-COMMANDS

#router isis {pid} - Enters the IS-IS configuration mode #interface {int} - Enters the IS-IS interface configuration mode #point-to-point - Enables a link between two routers as point-to-point instead of broadcast #retransmit-interval {sec} - Changes the interval between retransmissions of the same LSP (def = 5 sec) #csnp-interval {sec} - Changes the CSNP frequency interval (def = 10 sec)

IS-IS Route Selection

- Metrics > IS-IS uses a m etric, commonly known as the narrow-metric, to calculate the shortest path. > A defaul t value of 10 is assigned to IS-IS in terfaces . > The defaul t metric value can be changed with "isis m etric" for L1 and L2 respectively. > Standard IS-IS metric values are 0-63. > The to ta l cost of an IS-IS route is the sum of the m etric for each outgoing interface to the destination.

- Wide-Metrics > MPLS TE (Traffic Engineering) exchanges more detailed in terface parameters than IGPs do. > Both OSPF and IS-IS was extended to carry TE interface parameters . > With IS-IS two new TLVs are used to enable wide-metrics :

>> 22 - Extended IS Reachability >> 135- Traffic Engineering Extended IP Reachability

> These new TLVs support a much larger metric space, called wide metrics . > TLV-22 uses a 24-bi t metric field and TLV-135 uses a 32-bi t metric field. > These are enabled with "metric-style wide".


TOC 30

- Route-Types > IS-IS classifies routes as L1 or L2. > But routes are also classified as in ternal or external . > In ternal routes are paths to destinations with in an IS-IS domain. > External routes are paths to destinations external to an IS-IS domain. > L2 routes can be ei ther in ternal or external . L1 routes are normally in ternal , unless changed.

- IS-IS Route Selection Process 1- If m ultiple routes to a des tination exist, an L1 route is preferred over an L2 route. 2- If equal -level routes exis t, an in ternal type route is preferred over an external type route. 3- If equal -level and s ame-types routes exist, the route with the lowes t metric is preferred. 4- If equal -level , same-type and equal-cos t routes exis t, up-to six routes wil l be candidate to enter the routing table .

- If no path is present in the routing table on L1 routers , tra ffic wi ll be sent to the metrically closest L1/L2 router.

IOS-COMMANDS

#router isis [tag] - Enters the IS-IS configuration mode #metric {value} [level-1|level-2] - Globally sets a new default metric value for all IS-IS interfaces

- The level specifies the metric for that interface type (def = 10) #metric-style wide [level-1|level-2|level-1-2] [transition]

- Configures a router to use new-style TLV metrics - [transition] allows the router to accept old and new style metrics

#interface {int} #isis metric {value|maximum} [level1|level2] - Configures the IS-IS interface metric (def = 10)

- {maximum} Excludes a link from the SPF calculation - [level-1|level-2] Applies to the specified level (def = both)

XR-COMMANDS

#router isis {pid} - Enters the IS-IS configuration mode #address-family ipv4 unicast - Enters the IS-IS global IPv4 address-family #metric {value|max} [level-1|level-2] - Changes the default metric value of 10 to custom/max value on all-interfaces #metric-style wide [transition] [level-1|level-2] - Configures a router to use new-style TLV metrics

#interface {int} - Enters the IS-IS interface configuration mode #metric {value|max} [level-1|level-2] - Changes the default metric value of 10 to custom/max value per-interface

Route Leaking

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Routing: ISIS Configuration Guide, Release 12.2SR | | Configuring IS-IS for Fast Convergence | | Reducing Alternate-Path Calculation Times in IS-IS Networks

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing IS-IS on Cisco IOS XR Software | | Customizing Routes for IS-IS

- Original speci fications in RFC-1195 prohibi ted the advertising of routes from L2 areas in to L1 areas.


TOC 31

- Ins tead, L1/L2 routers would set the ATT bi t when L1 routes were advertised in to L1 areas. - L1 routers would then install a defaul t route pointing to the L1/L2 router, or the closest L1/L2 router i f multiples existed. - This was instated as a loop prevention mechanism. - The requi rement however appeared when an L1 router needed to route via a specific L1/L2 router that was not metrically the closest router. - But for that L1 router to make accurate routing decisions, i t m ust know what the routes /costs are behind which L1/L2 router.

- A technique known as route leaking corrected th is problem by allowing routes to be injected from L2 areas in to L1 areas. - Route leaking is defined in RFC-2966. - Route leaking is configured by defining a list of routes that is to be redistributed in to a L1 area. - Leaked routes are identified as 'ia ' routes or in ter-area routes in the route table . - RFC-2966 also defined a bi t called the U/D (Up/Down) bi t to prevent routing loops when using route-leaking. - Leaking only loopbacks interfaces is common when IS-IS is used with MPLS LDP.

- U/D bi t > When an L1/L2 router advertises a route from L2 area to L1 area, i t sets the U/D bi t. > Any other L1/L2 router that receives a L1 LSP with a U/D bi t set, would not advertise that route in to the L2 area.

CONFIG-SET: IS-IS Route Leaking on IOS

| access-list 100 permit ip 150.5.10.0 0.0.0.255 any - Matches a route to be leaked | ! | router isis | redistribute isis ip level-2 into level-1 distribute-list 100 | - ACL-100 addresses will be advertised to L1 routers |

IOS-COMMANDS

#router isis [tag] - Enters the IS-IS configuration mode #redistribute isis ip {level-1|level-2} into {level-2|level-1} [[distribute-list]|[route-map]]

- Allows routes to be redistributed from one level to another

XR-COMMANDS

#router isis {pid} - Enters the IS-IS configuration mode #address-family ipv4 unicast - Enters the IS-IS global IPv4 address-family #redistribute {bgp|ospf|connected|static|isis} {level-1|level-2|level-1-2} [metric] [route-policy]

- Redistributes routes from the routing protocol into IS-IS as the specified level. Metric/Route-policy is optional

Mesh Groups

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.1 Family > Cisco IOS Software Releases 12.1 Mainline | | Configuration Guides | | Cisco IOS IP and IP Routing Configuration Guide, Release 12.1 | | Part 2: IP Routing Protocols | | Configuring Integrated IS-IS | |Limiting LSP flooding

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software


TOC 32

| | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing IS-IS on Cisco IOS XR Software | | Limit LSP Flooding

- If a router floods an LSP in a fully meshed network, i t is received by every connected layer3 router. - The receiving routers blindly flood the LSP out all the ir interfaces, expect the in terface i t received the update on, causing unnecessary flooding s tart. - The mesh group feature was designed to allow control over the unnecessary flooding of LSPs. - A m esh group is a logical flooding topology that is configured b y specifying which interfaces on a router wi ll participate in the flooding and which in terfaces wil l not.

- Mesh Group In terface Modes: > Inactive

>> The in terface does not participate in any mesh group. >> LSPs received on an inactive in terface are flooded to all other in terface expect blocked interfaces. >> LSPs received from other in terface types are flooded out an inactive in terface.

> Blocked >> The in terface is excluded from the flooding topology. >> LSPs received on a blocked in terface are not processed locally but are s ti ll flooded out other interfaces. >> LSPs received from other in terface types are not flooded out a blocked in terface. >> Configured with "isis mesh-group blocked".

> Set >> The in terface belongs to a mesh group. >> An LSP is ONLY sent out interfaces belonging to mesh groups di fferent from the one the LSP was received on. >> E.g. i f an LSP was received on an in terface belonging to group 1, i t is only flooded out interfaces belonging to groups 2, 3, etc., as well as inactive interfaces . >> Configured with "isis mesh-group {number}".

CONFIG-SET: Using Mesh Groups to limit LSP flooding

| interface se1/0.1 | ip router isis | isis mesh-group 10 - LSPs received on se 1/0.1 are flooded to all interfaces except | ! se 1/0.2 and se 1/2.1 | interface se1/0.2 | ip router isis | isis mesh-group 10 - LSPs received on se 1/0.2 are flooded to all interfaces except | ! se 1/0.1 and atm1/2.1 | interface se1/1.2 | ip router isis | isis mesh-group 11 - LSPs received on se 1/1.2 are flooded to all interfaces except se 1/2.1 | ! | interface se1/2.1 | ip router isis | isis mesh-group blocked - LSPs received on serial 1/2.1 are not ignored but flooded as usual to | ! all other interfaces | interface se1/2.2 - LSPs received on se 1/2.2 are flooded to all interfaces, except se1/2.1 | ip router isis

IOS-COMMANDS #interface {int} #isis mesh-group blocked - Stops LSP flooding on the interface


TOC 33

#isis mesh-group {number} - Identifies the mesh group membership of the interface

XR-COMMANDS

#router isis {pid} - Enters the IS-IS configuration mode #interface {int} - Enters the IS-IS interface configuration mode #isis mesh-group blocked - Stops LSP flooding on the interface #isis mesh-group {number} - Identifies the mesh group membership of the interface

IS-IS Optimization

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Routing: ISIS Configuration Guide, Cisco IOS Release 12.2SR | |Reducing Link Failure and Topology Change Notification Times in IS-IS Networks

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing IS-IS on Cisco IOS XR Software | | Controlling LSP Flooding for IS-IS

- Flooding Delays > Mesh groups does help prevent excess flooding, but in densely meshed networks the frequency of flooding might still be a problem. > If the flooding in terval is delayed, e.g., for a link flapping every 5 seconds, the amount of flooding will be reduced. > This is achieved by delaying the generation new LSP unti l the network is stable. > Configured with "lsp-gen-in terva l" using these options:

>> Lsp-Ini tial-Wai t - Is the normal tim e the router wai ts before generating an LSP (def = 50 msec). >> Lsp-Second-Wait - Is the delay between the fi rst and second generation of an LSP (def = 5000 msec on IOS, 200 msec on IOS-XR).

- This is doubled between every LSP generation until the flapping stops or once the ls p-max-wai t is reached. - I.e . the second LSP wi ll be delayed by 5 sec, the thi rd LSP wil l be delayed m y 10 sec, etc.

>> Lsp-Max-Wai t - Is the longest delay allowed between LSP generations to (def = 5 sec).

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Routing: ISIS Configuration Guide, Cisco IOS Release 12.2SR | | Reducing Alternate-Path Calculation Times in IS-IS Networks | | Configuring Incremental SPF

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing IS-IS on Cisco IOS XR Software | | Setting SPF Interval for a Single-Topology IPv4 and IPv6 Configuration

- iSPF (Incremental SPF)

> iSPF helps l imi ting the scope of SPF calculations. > If a change affects only a limi ted part of the topology, iSPF confines the SPF recalculation to that portion of the topology. > Even with iSPF is configured, there are s till some cases where a fu ll SPF is executed:

>> Periodic SPF. >> A calculation change for the routing calculation (such as a change in metric, is-type, and so on). >> The configuration of the "clear ip route" or "clear isis" commands. >> Adjacency changes.


TOC 34

> Configured with "ispf".

- PRC (Partial Route Calculation) > Received LSPs are examined and i f there are no topological changes requiring an SPF calcu lation, no SPF calculation is run. > Configured with "prc-in terval ".

- Fast Flooding > If an ini tial delay, less than 40 msec are used, the SPF m ay s tart before the LSPs that triggered SPF, is flooded to all neighbors. > The LSP that triggered SPF should always be flooded before the router runs the SPF computation. > Enabling the fast-flooding of LSPs before the router runs the SPF com putation, ensures faster convergence. > I t is recommended that the defaul t values for the "isis re transmi t-in terva l " and "isis re transmi t-throttle-in terva l " commands is kept when the fast-flood command is

configured > Configured with "fas t-flood", which replaces the old command "ip fas t-convergence".

- High-Priori ty > IS-IS tra ffic could be tagged when entering an in terface, for faster processing and ins talla tion in the global routing table , ul timate ly to achieve fas ter convergence. > VoIP is a typ ical candidate that uses IS-IS high-priori ty tagging. > Tagging on the in terface is configured with the command "isis tag {tag}". > Tagged tra ffic is given a higher priori ty with the command "ip route priori ty high tag {tag}".

IOS-COMMANDS

#router isis [tag] - Enters the IS-IS configuration mode #spf-interval [level-1|level-2] {max-wait} [initial-wait second-wait]

- Customizes IS-IS throttling of SPF calculations - Defaults are 10, 5.5, and 5.5 sec respectively

#lsp-gen-interval [level-1|level-2] {max-wait} [initial-wait second-wait]

- Customize IS-IS throttling of LSP generation - Defaults are 5000, 50, and 5000 msec respectively

#ispf {level-1|level-2|level-1-2} [seconds] - Enables iSPF for the specified level

#prc-interval {max-wait} [initial-wait second-wait] - Customizes IS-IS throttling of PRC (Partial Route Calculations) - Defaults are 5, 2, and 5 sec respectively

#fast-flood [lsp-number] - Specifies the number of LSP to be flooded before SPF is started (def = 5)

#ip route priority high tag {tag} - Assigns a high priority to IS-IS IP routes with a specific route tag

#interface {int}

#isis lsp-interval {ms} - Changes the default delay between transmissions of LSPs (def = 33 msec) #isis retransmit-interval {ms} - Increases the time to wait for an ACK before retransmitting (def = 5 sec) #isis retransmit-throttle-interval {ms} - Increases the time between each retransmitted LSP, if the wait time expired #isis tag {tag} - Tags traffic on the interface


TOC 35

XR-COMMANDS

#router isis {pid} - Enters the IS-IS configuration mode #lsp-gen-interval [level-1|level-2] {max-wait} [initial-wait second-wait]

- Customize IS-IS throttling of LSP generation - Defaults are 5000, 50, and 200 msec respectively

#address-family ipv4 unicast - Enters the IS-IS global IPv4 address-family #spf-interval [level-1|level-2] {max-wait} [initial-wait second-wait]

- Customizes IS-IS throttling of SPF calculations - Defaults are 5000, 50, and 200 sec respectively

#ispf {level-1|level-2|level-1-2} [seconds] - Enables iSPF for the specified level #spf prefix-priority {critical|high|med|low} {tag|acl}

- Changes the IS-IS prefix priority matching a tag or an ACL. #interface {int} - Enters the IS-IS interface configuration mode

#lsp-interval {ms} - Changes the default delay between transmissions of LSPs (def = 33 msec) #retransmit-interval {ms} - Increases the time to wait for an ACK before retransmitting (def = 5 sec) #retransmit-throttle-interval {ms} - Increases the time between each retransmitted LSP, if the wait time expired #lsp fast-flood threshold {no} [level1|level2] - Specifies the number of LSP to be flooded before SPF is started (def = 10) #tag {tag} - Tags traffic on the interface

Route Summarization

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Routing: ISIS Configuration Guide, Cisco IOS Release 12.2SR | | Customizing IS-IS for Your Network Design | | Summarizing Address Ranges in the IS-IS Routing Table

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing IS-IS on Cisco IOS XR Software | | Customizing Routes for IS-IS

- Summarization is another mechanism that reduces the need to flood LSPs. - Summarization generally hide instabili ties with in areas i f interfaces flap. - L1/L2 routers can summarize routes within the ir area. - Summarization mus t be configured identically for all L1/L2 routers in an area. - L1 routes cannot be s ummarized with in an area. - Any m ore-speci fic destination address that fall within the summarization range will be suppressed. - The metric of the summary route is the smallest metric of all the more-speci fic addresses.

IOS-COMMANDS

#router isis [tag] - Enters the IS-IS configuration mode #summary-address {address}{mask} {level-1 | level-1-2 | level-2} [tag tag-number] [metric metric-value]

- Creates aggregate addresses for IS-IS


TOC 36

XR-COMMANDS

#router isis {pid} - Enters the IS-IS configuration mode #address-family ipv4 unicast - Enters the IS-IS global IPv4 address-family

#summary-prefix {address/mask} {level-1|level-2} [tag] - Creates aggregate addresses for IS-IS

Default Routing

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Routing: ISIS Configuration Guide, Cisco IOS Release 12.2SR | | Customizing IS-IS for Your Network Design | | Enhancing Your IS-IS Network Design at the Router Level

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing IS-IS on Cisco IOS XR Software | | Default Routes

- The advertisement of a defaul t route (0 .0.0.0/0) with IS-IS is condi tional . - IS-IS wi ll originate an advertisement for 0.0.0.0/0, i f a router is configured with the "defaul t-in formation originate" command and has a default route present in the routing

tab le . - Without a route map, the default route is advertised only in L2 LSPs. - L1 routers use the ATT bi t to find the closest L1/L2 routers out the area. - A route map (IOS) or RPL (IOS-XR) can be used for two purposes:

> Force the router generate a defaul t route in i ts L1 LSPs. > Advertise a default route conditionally to the presence of other routes being present in the routing tab le .

>> Configured using 'm atch ip address' option within the route-m ap.

IOS-COMMANDS

#ip route 0.0.0.0 0.0.0.0 null0 - Creates a static default route in the local routing table


#default-information originate [route-map] - Advertises a default route into an IS-IS routing domain

XR-COMMANDS

#router static - Enters the static route configuration mode #0.0.0.0/0 null0 - Creates a static default route in the local routing table

#router isis {pid} - Enters the IS-IS configuration mode #address-family ipv4 unicast - Enters the IS-IS global IPv4 address-family

#default-information originate [route-policy] - Advertises a default route into an IS-IS routing domain


TOC 37

Authentication

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Routing: ISIS Configuration Guide, Cisco IOS Release 12.2SR | | Enhancing Security in an IS-IS Network

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing IS-IS on Cisco IOS XR Software | | Configuring Authentication for IS-IS

- IS-IS supports clear-text and MD5 authentication. - IS-IS authentication can be applied on three levels: between routers, area-wide(level-1), and domain-wide (leve l-2). - When authenticating between routers , the same password mus t be configured on the connecting in terfaces. - Authentication may be configured separately for L1 and L2 adjacencies. - When performing area-wide authentication, every router in the area m us t use the same authentication mode and mus t have a common key-s tring. - When performing domain-wide authentication, every L2 and L1/L2 router in the IS-IS domain m ust use the same authentication mode and m us t have a common key-s tring. - If no leve l is specified when configuring authentication, the authentication is applied to both L1 and L2. - Authentication applied to an in terface, authenticates the Hello PDUs. - Authentication applied to the IS-IS instance, authenticates LSPs, CSNPs, and PSNPs. - To disable SNP password checking, the 'snp send-only' keywords mus t be specified in the "lsp-password" command on IOS-XR.

- Two authentication methods on IOS: > Simple Text Authentication - Also known as the "old m ethod". > Key-Chains - See below.

- Three authentication methods on IO-XR: > In terface authentication - Text or MD5. > Dom ain Authentication - Text or MD5. > Key-Chains - Applied at ei ther interface or domain level .

- Key-Chains > Method used to configure reusable passwords for both clear-text and MD5 authentication. > When doing changes to the key-chain, i t is always best to fi rs t remove the key-chain from the in terface. > Steps involved:

1- Create the key chain with a name. 2- Define the key or keys on the key-chain. 3- Specify the password re ferred to as 'key-s tring '. 4- Specify whether the interfaces will use clear text or MD5. 5- Enable authentication on an in terface or for the IS-IS instance at level -1 or level -2 and specify the chain to be used.

IOS-COMMANDS

# sh key chain - Shows the configured key-chains

#key chain {name} - Creates the key-chain

#key {no} - Specifies the key on the chain #key-string {password} - Specifies the password to use


TOC 38

#interface {int} #isis password {password} [level-1|level-2] - Configures simple authentication using a text password (def = both levels)

#interface {int}

#isis auth mode {text|md5} [level-1|level-2] - Specifies the authentication type on the interface (def = both levels) #isis auth key-chain {name} [level-1|level-2] - Enables IS-IS authentication by using a key-chain (def = both levels)

#interface {int}

#isis auth send-only [level-1|level-2] - Used in production to avoid disruption when configuring authentication - Applied before configuring but remove once configured

#router isis #area-password {password} - Configures an old method plain text password for the IS-IS area instance #area-password {password [auth snp {validate|send-only}]

- Configures the text password to be inserted into SNPs - [validate] Adds a password on sent packets and validates received packets - [send-only] Adds a password on sent packets, doesn't validate received

packets #domain-password {password} - Configures an old method plain text password for the IS-IS domain instance

#authentication mode {text|md5} [level-1|level-2] - Specifies the authentication type on the interface (def = both levels)

#authentication key-chain {name} [level-1|level-2] - Enables IS-IS authentication by using a key-chain (def = both levels) - [level-1] will enable area-wide authentication - [level-2] will enable domain-wide authentication

XR-COMMANDS

#router isis {pid} - Enters the IS-IS configuration mode #lsp-password {md5|text} {clear|encrypt} {pwd} [level1|level2] [send-only] [snp send-only]

- Configures a domain password - [send-only] Adds a password on sent LSPs & SNPs, doesn't validate received

packets - [snp send-only] Disable SNP password checking

#lsp-password {keychain} {name} [level1|level2] [send-only] [snp send-only] - Configures a domain wide keychain

#interface {int} - Enters the IS-IS interface configuration mode #hello-password {md5|text} {clear|encrypt} {pwd} [level1|level2] [send-only]

- Authenticates the establishment of adjacencies on the interface #hello-password {keychain} {name} [level1|level2] [send-only] [snp send-only]

- Configures a keychain on the interface


TOC 39

Bibliography


ISO DP 10589 ISO DP 10589 http ://s tandards.iso.org/i ttf/PubliclyAvailableStandards /c030932_ISO_IEC_10589_2002(E).zip

RFC-1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Envi ronments http ://www.ie tf.org/rfc/rfc1195.txt

RFC-2966 Domain-wide Prefix Dis tribution with Two-Level IS-IS http ://www.ie tf.org/rfc/rfc2966.txt


TOC 40



TOC 41

Chapter 4

CORE IGP: OSPF


TOC 42

OSPF Overview

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Routing: OSPF Configuration Guide, Cisco IOS Release 12.2SR | | Configuring OSPF

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing OSPF on Cisco IOS XR Software

- OSPFv2 id defined in RFC-2328. - OSPF uses i ts own transport protocol number 89. - OSPF s upports equal-cost load balancing for m ore efficient use. This is not an OSPF l imi ta tion, instead i t is a dependency of the hardware platform. For mos t IOS versions

this limi t is ei ther six or eight paths . - OSPF s upports the use of route tagging for the tracking of external routes . - OSPF packets are exchanged only between neighbors on a network. They are never routed beyond the network on which they originated. - OSPF m ulticas t packets use a TTL of 1. - OSPF sees secondary networks as s tub networks . This means no adjacencies will be established using secondary networks . - If the network s tatement matches the IP address of the prim ary in terface, the primary in terface and the IP-unnumbered in terface will have OSPF enabled.

IOS-COMMANDS

# sh ip protocols - Shows brief protocol overview, filter-lists, interfaces, etc. # sh ip ospf - Shows information about OSPF timers, areas, etc.

XR-COMMANDS

# sh protocols ospf - Shows brief protocol overview, filter-lists, interfaces, etc. # sh ospf [summary] - Shows information about OSPF routing-process, timers, areas, etc. # sh running router ospf {pid} - Shows the OSPF configuration portion

Hello Protocol

- The hello protocol serves several purposes > I t is a means by which neighbors are discovered. > I t advertises several parameters on which two routers m ust agree before they can become neighbors . > Hello packets also act as keepalives between neighbors . > I t ensures bidi rectional communication between neighbors once a neighbor sees i ts own router ID in a received hello. > I t elects DRs (Designated Routers) and BDRs (Backup Designated Routers) on Broadcast and NBMA networks .

- Each hello packet contains the following in formation. > Router ID of the orig inating router. > Area ID of the originating router in terface. > Address mask of the originating in terface. > Authentication type and in formation of the originating in terface. > Hello -in terval of the originating in terface. > Router dead-interval of the orig inating interface.


TOC 43

> Router priori ty. > DR and BDR. > Five flag bi ts signi fying optional capabili ties. > Router IDs of the orig inating router's neighbors .

- To establish adjacencies the fol lowing values mus t match the values configured on the receiving interface > Area ID. > Authentication. > Network mask (point-to-point links are the exception). > Hello -in terval and dead-in terva l . > MTU. > Options.

- Hello-In terval > OSPF-speaking routers periodical ly send a hello packet out of each OSPF-enabled interface. > Uses a defaul t hello -interval of 10 seconds for broadcast and 30 seconds for non-broadcast networks . > Configured on a per in terface basis with "ip ospf hel lo -in terva l ".

- Router Dead-Interva l > Is the period of tim e after which a router will declare a neighbor down, i f i t does not receive a hello from that neighbor. > The defaul t is four times the hello -in terval but can be changed with the command "ip ospf dead-in terval " below.

- By changing the hello in terva l manually, the dead-in terval is adjusted accordingly to 4x the new hello value.

- Fast-Hello Packets > Provides a way to configure the sending of hello packets in in tervals less than 1 sec. > This is achieved using the "ip ospf dead-in terval minimal" command by s etting the dead in terval to 1 sec. > The 'he llo -mul tipl ier' value is set to the number of hello packets that m ust be sent during that 1 sec. > The fas t-hel los feature is not supported on IOS-XR. The equivalent functionali ty is provided with BFD (Bidi rectional Forwarding Detection). > E xample:

#ip ospf dead-in terval m in hello -mul tip lier 5 - Five hellos are sent every second i .e . at an in terval of 200ms.

IOS-COMMANDS

# sh ip ospf neighbor - Shows all OSPF speaking neighbors, their state, timer, interfaces # sh ip ospf interface - Shows OSPF-related interface information, DR, BDR, etc. # sh ip ospf interface brief - Shows brief summary of interfaces and their OSPF areas

#interface {int}

#ip ospf hello-interval {sec} - Specifies how often hellos are sent (10 sec/broadcast and 30 sec/non- broadcast). Range is (1-65535)

#ip ospf dead-interval {sec | minimal} - How long to wait before declaring a neighbor dead (default = 4x hello- interval). Range is (1-65535)

#ip ospf dead-interval min hello-multiplier {no} - Configures OSPF fast hello #ip ospf mtu-ignore - Disables the MTU check. Used when a switch uses a different system MTU

- The MTU size in a hello must be the same on between neighbors


TOC 44

XR-COMMANDS

# sh ospf neighbor - Shows the OSPF speaking neighbors, neighbor state, timers, interfaces # sh ospf interface - Shows OSPF-related interface information, DR, BDR, etc. # sh ospf interface brief - Shows brief summary of interfaces and their OSPF areas

#router ospf {pid} - Enters the OSPF configuration mode

#area {aid} - Enters the OSPF area configuration mode #interface {int} - Enters the OSPF interface configuration mode #hello-interval {sec} - Specifies how often hellos are sent (10 sec/broadcast and 30 sec/non-

broadcast). Range is (1-65535) #dead-interval {sec} - How long to wait before declaring a neighbor dead. Range is (1-65535) #mtu-ignore - Disables OSPF from checking if a neighbors MTU matches the

- The MTU size in a hello must be the same on between neighbors

Advertising Routes

- There are three ways to advertise routes with OSPF on IOS: > Network area process command. > In terface command. > Redis tribution.

- Network Area Command > Defines the interfaces on which OSPF runs . > Defines the area m embership of the in terface. > Configured with "network {ip-address } {wildcard} area {aid}" under the OSPF process. > The IP address and wi ldcard arguments together allow you to define one or multiple interfaces to be associated with a specific OSPF area using a single command. > The matched interfaces' IP-address/subnet-mask is advertised by OSPF, NOT the IP address/wi ldcard-mask of the "network" command.

- In terface Command > Accomplishes the same as the network area command. > Switches do not support th is command. > Configured with "ip ospf {pid} area {aid}" under the interface.

- With IOS-XR routes are advertised when an in terface is defined under the OSPF area configuration mode or through red istribution.


TOC 45

CONFIG-SET: OSPF- Different methods to enable OSPF on interfaces in IOS

| interface se0 | ip address 10.10.1.1 255.255.255.252 | ip ospf 1 area 3 - Enables OSPF on serial 0 in area-3 | ! | interface se1 | ip address 10.10.1.5 255.255.255.252 | ! | interface se2 | ip address 10.5.2.2 255.255.255.192 | ! | interface se3 | ip address 10.5.2.130 255.255.255.192 | ! | router ospf 1 | network 10.10.1.5 0.0.0.0 area 1 - Matches interface 1 only | - Enables OSPF on serial 1 in area-1 | network 10.5.2.0 0.0.0.255 area 2 - Matches interface 2 and 3 | - Enables OSPF on serial 2/3 in area-2 |

IOS-COMMANDS

# sh ip ospf interface [brief] - Shows OSPF enabled interfaces, DR, BDR, timers, type, etc.

#router ospf {pid}

#router-id {ip} - Specifies the OSPF router identifier #network {ip} {wildcard} area {aid} - Network command syntax that enables OSPF on an interface #network 0.0.0.0 0.0.0.0 area {aid} - Enables OSPF and advertise any interface in an UP state

#interface {int}

#ip ospf {pid} area {aid} [second none] - Interface command syntax that enables OSPF on an interface - [second none] Prevents advertising secondary IP addresses

XR-COMMANDS

# sh ospf interface [brief] - Shows OSPF enabled interfaces, DR, BDR, timers, type, etc.


#router-id {rip} - Specifies the OSPF router identifier #area {aid} - Enters the OSPF area configuration mode #interface {int} - Enables OSPF on the interface and advertise its IP range


TOC 46

Network Types

- An OSPF router maintains a data s tructure for each OSPF-enabled in terface. - If the network type is changed, the hello and dead tim ers will be adjus ted accordingly.

- OSPF Network Types > Broadcast Network

>> The defaul t network type on Ethernet interfaces. >> Will elect a DR and a BDR. >> Uses the multicast addresses 224.0.0.5 (0100.5E00.0005) for All-SPF-routers and 224.0.0.6 (0100.5E00.0006) for All-DR-routers. >> The next-hop IP is not changed and remains the IP address of the originating router. >> Layer3 to layer2 resolution is requi red. >> Broadcast networks may not have unicas t neighbors configured. >> 10/40second hello /dead-in terva l .

> Non-Broadcast Network >> Can connect m ore than two routers but has no native broadcast capabili ty. >> Non-broadcas t is the default network type on multipo int frame-relay interfaces, e.g. a physical m ain in terface. >> OSPF routers on NBMA networks elect a DR and BDR, but all OSPF packets are unicast between each manually specified neighbor with the "neighbor" command. >> The next-hop IP is not changed and remains the IP address of the originating router. >> The defaul t priori ty is 1 and should be disabled (=0) on ALL spoke routers to prevent a spoke route from becoming a blackhole DR/BDR. >> 30/120second hel lo /dead-in terval .

> Point-to-Point Network >> Defaul t on T1, DS-3, SONET links and on point-to-point frame-re lay sub-in terfaces. >> There is no DR/BDR election, OSPF configured is as per normal . >> Uses the multicast addresses 224.0.0.5 for All-SPF-routers , except for re transmi tted LSAs, which are unicast. >> The next-hop IP is that of the advertising router. >> OSPF ignores subnet mask mismatch on point-to-point l inks . >> 10/40second hello /dead-in terva l .

> Point-to-Mul tipoin t Network >> Cisco proprie tary and not a defaul t option but arguably the best choice for NBMA networks . >> Special configuration of NBMA networks in which the networks are treated as a collection of point-to-point links. >> There is no DR/BDR election and uses the multicas t addresses 224.0.0.5 for each known neighbor. >> The next-hop IP is that of the advertising neighbor. >> Layer3 to layer2 resolution is ONLY needed for the directly-connected neighbors. >> Non-di rect neighbors use recursive layer3 IP routing to reach each other. >> In addi tion, the endpoints of point-to-mul tipoint networks are advertised as host routes (/32). >> 30/120second hel lo /dead-in terval .

> Point-to-Mul tipoin t Non-Broadcast Network >> Cisco proprie tary. It is the same as point-to-m ul tipoint, but configured with the addi tional 'non-broadcast' keyword. >> There is no DR/BDR election, th is type uses unicast instead of multicast to each manually specified neighbor. >> Directly connected neighbor mus t be manually defined with the "neighbor" command. It is only required on one side, but i t is best to do i t on both sides. >> The next-hop IP is that of the advertising neighbor. >> IP routing will be used to establish reachabili ty between devices that are non-adjacent at layer2. >> This network was created to allow for the assignment of the cost per neighbor instead of using the interface's cost.


TOC 47

>> The cost of an interface is the 'incoming ' cost of an in terface. >> 30/120second hel lo /dead-in terval .

> Virtual Links >> Used to l ink an area to the backbone over a non-backbone area (also known as a transi t area). >> Also used to connect two parts of a parti tioned backbone through a non-backbone area. >> Must be configured between two ABRs of which one m ust be connected to area 0. >> The trans i t area may not be a s tub area and mus t have fu l l routing in formation. >> The vi rtual link will transi tion to the fully functional point-to-point in terface s tate when a route to the neighboring ABR is found in the route tab le . >> OSPF ignores subnet mask mismatch on point-to-point l inks . >> A vi rtua l link is seen as an in terface in area 0. >> All area 0 attributes are inheri ted by routers attached to the virtual link, including s ummarization and authentication. >> The cost of the virtual link is the cost of the route to the neighbor ABR interface via the transi t area. >> The m aximum path cost in the transi t area m ay not exceed 65535, else the virtual link will not come up. >> To see the cost of using the transi t area use "show ip ospf vi rtua l -link" and re fer to 'cost of using '. >> Virtual-links are only used for control tra ffic, i .e . flooding Type-1, Type-2, Type-3 and Type-4 LSAs. No data tra ffic is sent over a vi rtua l-links .

-OSPF over GRE > OSPF vi rtua l links m ay not transi t stub areas. > If a vi rtual l ink over a s tub area is required, the only s olution is to use a GRE tunnel . > The tunnel in terface m ust have an IP address with a matching network s tatement in area 0.

-Stub/Loopback Network > Defaul t for loopback in terfaces. > Assumes only a single attached router. OSPF advertises s tub networks as host routes(/32). > Don't confuse this with s tub areas!

IOS-COMMANDS

# sh ip ospf neighbors - Shows the OSPF neighbors, state, interface, etc. # sh ip ospf interface [brief] - Shows OSPF related interface information, DR, BDR, timers, type, etc. # sh ip ospf virtual-link - Shows the link state, the cost of transit area, transit interfaces

#interface {int}

#ip ospf {pid} area {aid} - Same as OSPF network command. Places the interface in a specified area #ip ospf network broadcast - Changes the network type to broadcast. Timers: 10/40 #ip ospf network non-broadcast - Changes the network type to NBMA. Timers: 30/120. Require manual neighbors #ip ospf network point-to-point - Changes the network type to point-to-point. Timers: 10/40 #ip ospf network point-to-multipoint - Changes the network type to point-to-multipoint. Timers: 30/120 #ip ospf network point-to-multi non-broadcast - Changes to network type to point-to-multipoint non-broadcast. Timers: 30/120 #ip ospf priority {number} - Highest priority elects the DR (Default = 1, Ineligible = 0)

#router ospf {pid} #network {ip} {mask} area {aid} - Defines an interface on which OSPF runs and its area ID #area {transit-area} virtual-link {abr-rid} - Configures the remote area border router ID of the virtual link #neighbor {ip} [priority {pri}] [cost {cost}] - Manually specifies a neighbor

- Optionally define priority or cost for the neighbor


TOC 48

XR-COMMANDS

# sh ospf neighbors - Shows the OSPF neighbors, state, interface, etc. # sh ospf interface [brief] - Shows OSPF related interface information, DR, BDR, timers, type, etc. # sh ospf virtual-links - Shows the link state, the cost of transit area, transit interfaces


#area {aid} - Enters the OSPF area configuration mode #interface {int} - Enters the OSPF interface configuration mode #network broadcast - Changes the network type to broadcast. Timers: 10/40 #network non-broadcast - Changes the network type to NBMA. Timers: 30/120. Require manual neighbors #network point-to-point - Changes the network type to point-to-point. Timers: 10/40 #network point-to-multipoint - Changes the network type to point-to-multipoint. Timers: 30/120 #network point-to-multi non-broadcast - Changes to network type to point-to-multipoint non-broadcast. Timers: 30/120 #priority {no} - Highest priority elects the DR (Default = 1, Ineligible = 0) #neighbor {ip} priority {no} - Define the priority of a neighbor #virtual-link {abr-rid} - Configures the remote area border router ID of the virtual link

DR and BDR

- Will be elected on broadcast and NMBA networks . - Addressing

> All non DR routers send updates to the des tination multicast address AllDRouters (224.0.0.6) (0100.5E00.0006). > The DR/BDR send updates to the des tination multicast address AllSPFRouters (224.0.0.5) (0100.5E00.0005).

- The concept behind the DR is that the broadcast l ink i tsel f is considered a 'pseudonode'. - The cost from an attached router to the pseudonode is the outgoing cost of that router's interface to the broadcast l ink. - The cost from the pseudonode to any attached router is zero. - The DR is a property of a router's in terface, not the enti re router. - On broadcas t segments traffic doesn't flow through the DR, only updates are sent to the DR and BDR. - The DR/BDR m us t have layer2 connectivi ty to all neighbors .

- Router In terface Priori ty: > In fluences the election process between DR and BDR, but will not override an active DR or BDR. > OSPF elections do not support pre-emption. > Highest priori ty value wins. The defaul t priori ty is 1. > Routers with a priori ty of 0 are ineligible to become the DR or BDR. > The priori ty can be changed on a per-mul ti -access-in terface basis with the command "ip ospf priori ty".

- Router ID > Used as a tie-breaker when router priori ties are equal. > Is the highes t loopback IP in an 'UP' s tate. If no loopbacks are configured, i t is the highest in terface IP in an 'UP' state. > Can be s tatica lly set.


TOC 49

IOS-COMMANDS

#router ospf {pid} - Enters the OSPF configuration mode #router-id {rid} - Manually assigns an OSPF router ID, should be configure before any other OSPF

config #interface {int} #ip ospf priority {priority} - Highest priority elects the DR (default = 1, ineligible = 0)

XR-COMMANDS

#router ospf {pid} - Enters the OSPF configuration mode #router-id {rid} - Manually assigns an OSPF router ID, should be configure before any other OSPF

config #area {aid} - Enters the OSPF area configuration mode #interface {int} - Enters the OSPF interface configuration mode #priority {no} - Highest priority elects the DR (default = 1, ineligible = 0)

OSPF Operation

- OSPF Fini te State Machine > Down

>> In i tial s tate, no hellos received since last router dead-in terva l . > At tempt

>> Applies to NBMA networks , with manual ly configured neighbors . > In i t

>> State when the firs t hello packet is received. > 2Way

>> Two-way communication s tate when the local router sees i ts own router ID the received hello packets. >> On multi-access networks , routers in the 2way s tate or higher may be elected as the DR or BDR.

> E xStart >> Two neighbors establish a m aster/slave rela tionship in preparation to exchange DDP (Data Descriptor Packets).

> Exchange >> Two neighbors exchange DDPs sharing thei r link s tate databases.

> Loading >> Used by a neighbor to request more LSAs that have not yet been received.

> Full >> State when neighbors are fu lly adjacent. The new adjacency s tarts appearing in router LSAs and network LSAs.

- OSPF packet types > DDP - Database Descrip tion Packets (type 2) carry summaries of LSAs > LSR - Link State Request packets (type 3) > LSU - Link State Update packets (type 4) > LSAck - Link State Acknowledgement packets (type 5)

- Do not confuse LSA (Link State Advertisement) with LSAck (L ink State Acknowledgement).


TOC 50

Router Types

-In ternal > A router with all interfaces in the one(non-backbone) area. These routers have a single l ink state database.

-Backbone > A router with all interfaces in the backbone area.

-ABR (Area Border Router) > A router with at least one in terface in the backbone area. Other interfaces in other areas. > The ABR m ainta ins separate l ink s tate databases for each of i ts connected areas. > The ABR act as a gateway for in ter-area tra ffic.

-ASBR (Autonomous Sys tem Boundary Router) > A gateway to an external network. > I t injects routes in to the OSPF domain that were redis tributed from another IGP/network.

LSAs (Link State Advertisements)

- A LSA is the OSPF data structure used to describe topology in formation. - LSAs are aged as they reside in the link s tate database. - MaxAge (defaul t = 1 hour) is the time, i f reached, when LSAs are flushed from the OSPF dom ain. - LSRefreshTime (defaul t = 30 m in) is the time in frequency when the router that originated a LSA floods a new copy of the LSA updating i t (wi th incremented sequence

number and an age of zero. - LSA Types

1 - Router LSAs >> Are produced b y every router for all i ts own connected in terfaces . >> Lists all the routers interfaces, the state and outgoing cost of each l ink and any known OSPF neighbors on that l ink. >> Has in tra -area flooding scope. >> Describes the in tra-area routes (displayed as 'O' routes in the RIB). >> Can be seen with "show ip ospf database router".

2- Network LSAs >> Are produced b y the DR on every multi-access network. >> Lists all attached routers including the DR i tsel f. >> Has in tra -area flooding scope. >> Describes the designated routers on a segment. >> Can be seen with "show ip ospf database network".

3- Network Summary LSAs >> Are originated by ABRs. >> Are sent in to a single area to advertise destinations outside that area, but s til l in ternal to the OSPF autonomous s ys tem . >> Defaul t routes external to the area, but in ternal to the OSPF autonomous s ys tem are also advertised by LSA type 3. >> Has in ter-area flooding scope. >> Describes the in ter-area routes (displayed as 'O* IA' routes in the RIB). >> Can be seen with "show ip ospf database s ummary".

4- ASBR Summary LSAs >> Are originated by ABRs. >> Are identical to network summary LSAs, except that the destination they advertise is an ASBR, not a network. >> Has in ter-area flooding scope. >> Describes which router is doing the redistribution.


TOC 51

>> Can be seen with "show ip ospf database asbr-summary". 5- AS External LSAs

>> Are originated by ASBRs. >> They advertise ei ther a destination external to the OSPF autonomous s ys tem , or a defaul t route external to the OSPF autonomous s ystem. >> AS external LSAs are the only LSA type that are not associated with a particular area. >> An OSPF external route cannot use another OSPF external route as i ts next hop. >> Autonomous s ys tem-wide flooding scope. >> Describes what routes were redis tributed (displayed as 'O*E1' or 'O*E2' routes in the RIB). >> Can be seen with "show ip ospf database external".

6- MOSPF >> Cisco routers do not support LSA Type 6 (MOSPF) and generate syslog messages i f such packets are received. >> It m ight be necessary to configure a router to ignore these packets and thus prevent a large number of syslog messages >> Configured with "ignore lsa mospf".

7- NSSA External LSAs >> Are originated by ASBRs within NSSAs (Not-So-Stubby Areas). >> Simi lar to an AS External LSA, except NSSA External LSAs are flooded only within the NSSA in which each was originated. >> Describes redis tributed routes with in a NSSA area (d isplayed as 'O*N1' or 'O*N2' routes in the RIB). >> Can be seen with "show ip ospf database nssa-external ".

10- Opaque LSAs >> Used to add extensions to OSPF, such as tra ffic engineering parameters for MPLS networks .

- OSPF Link-State Database Overload Protection > Allows number of non-sel f-generated LSAs for a given OSPF process to be lim i ted. > Used to prevent excessive LSAs generated by other routers in the OSPF domain from substantially drain ing the CPU and m em ory resources of a router. > Configured with "max-lsa".

- OSPF LSA Throttling > Provides a dynamic mechanism to slow down LSA updates in OSPF during times of network ins tabi li ty. > Also allows fas ter OSPF convergence by providing LSA ra te l imi ting in milliseconds. > Configured with "timers throttle lsa all ".

IOS-COMMANDS

# sh ip ospf traffic - Shows OSPF traffic statistics # sh ip ospf statistics [detail] - Shows the SPF calculation details, including time, reason and type

- Reason field descriptors: (R) A change in a router LSA (type-1) occurred (N) A change in a network LSA (type-2) occurred (SN) A change in a summary network LSA (type-3) occurred (SA) A change in a summary ASBR LSA (type-4) occurred (X) A change in an external (type-7) LSA occurred

# sh ip ospf database database-summary - Shows the number of LSAs in a link-state database by area and by LSA type

# sh ip ospf database [router|netw|sum|asbr-sum|ext|nssa-ext] - Shows a list of the different LSAs in a link-state database

#router ospf {pid} >>> LSA Timers and Pacing <<<


TOC 52

#timers pacing lsa-group {sec} - Allows more LSAs to be grouped together before being flooded (def = 240 sec) #timers pacing flood {ms} - Control the rate at which LSA updates occur (def = 33 ms) #timers throttle spf {delay} {holdtime} - Changes the delay time between receiving a topology change and SPF

calculation #timers throttle lsa all {start} {hold} {max} - Sets the rate-limiting intervals (in milliseconds) for LSA generation

- {start-interval}: (def = 0 ms) - {hold-interval}: (def = 5000 ms) - {max-interval}: (def = 5000 ms)

#max-lsa {max-no} [threshold-%] [warning-only] [ignore-time] [ignore-count] [reset-time]

- Limits the number of non self-generated LSAs in the OSPF LSDB - {max number}: Number of non-self-generated LSAs - [threshold]: Percentage at which a warning message is logged (def = 75%) - [warning-only]: OSPF process never enters ignore state (def = disabled) - [ignore-time]: Time to ignore neighbors after the limit exceeded (def = 5min) - [ignore-count]: Number of times consecutively to enter ignore state (def = 5) - [reset-time]: Time before ignore count gets reset (def = 10 min)

#ignore lsa mospf - Ignores MOSPF LSA packets and stops generating syslog messages

#neighbor {ip} database-filter all out - Blocks the flooding of OSPF LSA packets only to a specific neighbor

#interface {int}

#ip ospf database-filter all out - Blocks the flooding of OSPF LSA packets out an interface

XR-COMMANDS

# sh ospf statistics interface [int|summary] - Shows OSPF traffic statistics per interface # sh ospf database database-summary - Shows the number of LSAs in a link-state database by area and by LSA type # sh ospf database [router|netw|sum|asbr-sum|ext|nssa-ext]

- Shows a list of the different LSAs in a link-state database


#timers lsa refresh {sec} - Changes the self-originated LSA refresh interface (default = 1800 sec) #timers lsa group-pacing {sec} - Allows more LSAs to be grouped together before being flooded (def = 240 sec) #timers throttle spf {delay} {holdtime} - Changes the delay time between receiving a topology change and SPF

calculation #timers throttle lsa all {start} {hold} {max} - Sets the rate-limiting intervals (in milliseconds) for LSA generation

#max-lsa {max-no} [threshold-%] [warning-only] [ignore-time] [ignore-count] [reset-time]

- Limits the number of non self-generated LSAs in the OSPF LSDB #ignore lsa mospf - Ignores MOSPF LSA packets and stops generating syslog messages

#area {aid} - Enters the OSPF area configuration mode

#interface {int} - Enters the OSPF interface configuration mode #database-filter all out - Filters all outgoing LSAs out the interface


TOC 53

#neighbor {ip} database-filter all out - Filters all outgoing LSAs to a neighbor

Area Types

- LSA fi l tering can be done in two ways : > Area Types. > LSA type 3 (Network Summary) fil tering see fi ltering below.

- When only a single area network is used, i t does not have to be area 0. - The ru le is that all areas mus t connect to the backbone; therefore, a backbone area is needed only i f there are more than one area.

- Stub Areas > Type 4 ASBR Summary LSAs and 5 AS External LSAs are not flooded in to stub areas. > Sti ll receive t ype 3 (Network Summary) LSAs. > ABRs at the edge of a s tub area use type 3 LSAs to advertise a single defaul t route (0 /0) in to the area for destinations external to the AS. > The ABR wil l advertise this defaul t route with a cost of 1. > This defaul t cost can be changed with the "area defaul t-cos t". > Is configured on ALL routers in the stub area with "area s tub". > Stub area res trictions :

>> All routers in a s tub area mus t have identical l ink-state databases, and agree to be s tubs. >> To ensure th is condition, all s tub routers wil l set a flag (the E-bi t) in the ir hello packets to 0.They wil l not accept hellos with E=1 (i f the E-bi t = Evi l -bi t, then Stub-

Area = Holy-Area). >> Virtual links cannot be configured with in , nor transi t, a s tub area. >> No router within a s tub area can be an ASBR or perform any type of redis tribution, including s tatic and connect.

- Totally Stubby Areas > Use a defaul t route to reach not only destinations external to the autonomous s ystem but also all destinations outs ide the area. > The ABR of a to tally s tubby area will block all t ype 3 LSAs with the exception of a single type 3 LSA advertising a defaul t route (0 /0). > Configured with "area stub no-summary", which is necessary only at the ABR/s; the in ternal routers use the s tandard s tub area configuration.

- NSSA (Not-So-Stubby Areas) > Area that allow redis tribution while re taining the characteristics of a s tub area to the res t of the AS. > Type 4 and 5 LSAs are not allowed, but redistributed AS-external routes are allowed. > The ASBR in an NSSA will orig inate type 7 LSAs to advertise these external des tinations. > These NSSA external LSAs are flooded throughout the NSSA but are blocked at the NSSA ABR. > The NSSA ASBR has the option of setting or clearing the P-bit. > If the NSSA's ABR receives a type 7 LSA with the P-bi t set to 1, the type 7 LSA translates in to a type 5 LSA before being flooded to other areas. > If the P-bi t is set to 0, no translation will take place and the destination in the type 7 LSA wi ll not be advertised outside of the NSSA. > If an NSSA has m ultiple ABRs, the ABR with the highest router ID will do the LSA 7 to 5 conversion. > Configured on ALL routers in the NSSA area with "area nssa". > Biggest difference to a s tub area is that redistribution is allowed and no defaul t route is sent in to the area. > With NSSA, the ABR does not automatically originate a defaul t route. > To originate a default route (0 /0) in to a NSSA area use the command "area nssa defaul t-originate".

- Totally NSSA > Is the same as an NSSA area but addi tionally blocks type 3 s ummary LSAs > Type 3, 4 and 5 LSAs are not allowed, but redis tributed AS-external routes are allowed.


TOC 54

> The ASBR in an NSSA will orig inate type 7 LSAs to advertise these external des tinations. > An ABR defines an NSSA as to ta lly s tubby and originates a defaul t as 'O* IA'. > Configured with "area nssa no-summary", which is only necessary at the ABR; the in ternal routers use the standard NSSA area configuration.

- All routers in a STUB or NSSA m us t agree on the STUB or NSSA flag. - I t is the ABR(s) of the stub or NSSA area that determines i f the area is to ta lly-s tubby or totally-NSSA. - The keyword 'no-summary' following the command "stub/nssa" defines the area type.

- An ABR is responsible for generating type 4 LSAs, but i f the area is configured as a s tub the behavior is in teresting. > ABR fi l ters the type 5 LSAs(generated by the ASBR) and does not generate a type 4 LSA. > So, technica lly, an OSPF s tub configuration expl ici tly fil ters type 5 LSAs, but since there is no need for the ABR to generate type 4 LSAs, i t impl ici tly fil ters type 4 LSAs.

- When an ABR is also an ASBR and is connected to a NSSA, the defaul t behavior is to advertise the red istributed routes in to the NSSA. > This red istribution can be turned off by adding the 'no-redis tribution ' keyword to the "area nssa" command.

- Suppress OSPF Forwarding Address in Translated Type-5 LSAs > This is used when an NSSA ABR translates type 7 LSAs to type 5 LSAs. > 0.0.0.0 mus t be used as the forwarding address instead of the address specified in the type 7 LSA. > Routers which are configured not to advertise forwarding addresses in to the backbone wil l di rectly forward traffic to the translating NSSA ASBRs.

IOS-COMMANDS

#router ospf {pid} #area 1 default-cost {cost} - Changes the cost of the default route advertised by the ABR(default = 1) #area 1 stub - Configures area 1 to be a stub area

- Configured on all area routers - Shows the default route in the routing table as 'O*IA 0.0.0.0/0'

#area 2 stub no-summary - Configures area 2 to be a totally stubby area

- Configured only on ABRs - Shows the default route in the routing table as 'O*IA 0.0.0.0/0'

#area 3 nssa - Configures area 3 to be a NSSA (not so stubby area)

- Configured on all area routers - NO default route is automatically generated

#area 4 nssa default-information-originate - Configures area 4 to be a NSSA

- Configured only on ABRs that generate the default route - Shows the default route in the routing table as 'O*N2 0.0.0.0/0'

#area 5 nssa no-summary - Configures area 5 to totally-NSSA

- Configured only on ABRs - Shows the default route in the routing table as 'O*IA 0.0.0.0/0'

#area 6 nssa no-redistribution no-summary - Configures area 6 to totally-NSSA with default redistribution disabled

- Shows the type 3 default route in the routing table as 'O*IA 0.0.0.0/0'


TOC 55

#area 7 nssa no-redistribution default-information-originate - Configures a NSSA, allowing type 3, blocking type 4, 5 and 7 - Shows the type 7 default route in the routing table as 'O*N2 0.0.0.0/0'

#area 8 nssa translate type7 suppress-fa - Suppresses the inclusion of a forwarding address when translated into type 5

LSAs

##area type options explained### >>[stub] blocks type 4 and type 5 LSAs

>>[no-summary] blocks type 3 LSAs except the default route type 3 LSA >>[nssa] blocks type 4 and type 5 LSAs, but allows type 7 redistribution >>[no-redistribution] blocks type 7 LSAs

XR-COMMANDS

#router ospf {pid} - Enters the OSPF configuration mode #area 1 #stub - Configures area 1 to be a stub area

- Configured on all area routers #default-cost {cost} - Changes the cost of the default route advertised by the ABR (default = 1)

#area 2

#stub no-summary - Configures area 2 to be a totally stubby area - Configured only on ABRs

#area 3 #nssa - Configures area 3 to be a NSSA (not so stubby area)

- Configured on all area routers #area 4 #nssa default-information-originate - Configures area 4 to be a NSSA

- Configured only on ABRs that generate the default route #area 5 #nssa no-summary - Configures area 5 to be a totally-NSSA

- Configured only on ABRs #area 6 #nssa no-redistribution no-summary - Configures area 6 to totally-NSSA with default redistribution disabled

#area 7

#nssa no-redistribution default-information-origin - Configures a NSSA, allowing type 3, blocking type 4, 5 and 7

Filtering

- Fil tering m ay only occur between areas by RFC s tandard: 'All routers within an area m us t have the same l ink-s tate database'. - Different ways to fi l ter OSPF tra ffic:

> With the "fi l ter-lis t" command. > With the "dis tribute -lis t" command referencing an ACL/prefix-l ist/route -map.


TOC 56

> With the "distance" command. > With the "area range" command (re fer to the next section below). > With the "summary-address " command for external prefix fil tering (re fer to the next section below).

- Fil ter-Lis ts > The ABRs can fi l ter network addresses being advertised by type 3 LSAs ei ther in to or out of an area.

>> In-l ists - Fil ter LSAs before they are sent in to an area. >> Out-lis ts - Fil ter LSAs leaving an area to prevent those LSAs from entering any other areas attached to that router.

- Distribute -Lis t > Note that distribute-lists ONLY block routes from entering the LOCAL RIB, they do not s top LSA propagation. > Using a dis tribute-lis t out has NO effect with in an OSPF area since all routers in an area m ust have the same database. > Using a route-map the following 'match route-type ' cri teria can used with OSPF:

>> External - OSPF external route types E1 and E2. >> In ternal - OSPF in ternal routes (includes OSPF in tra /in ter-area). >> Local - OSPF routes locally generated on the router. >> NSSA-external - OSPF NSSA-external route type N1 and N2.

- Prefix-Suppression > Prevents OSPF from advertising all IP prefixes except prefixes that are associated with loopbacks, secondary IP addresses and passive in terfaces. > Another way to improve OSPF network convergence by l imi ting the number of IP prefixes carried in LSAs. > Enabled globally with "prefix-suppression". > Excluding IP prefixes on an in terface basis is enabled with "ip ospf prefix-suppression"

CONFIG-SET: OSPF-Route Filtering Examples

| ip prefix LIST1 seq 10 deny 10.5.1.0/24 - Matches 10.5.1.0/24 to be denied | ip prefix LIST1 seq 20 permit 0.0.0.0/0 le 32 - Permits everything else | | router ospf 1 | area 0 filter-list prefix LIST1 out - Filters traffic leaving from area 0, matching the prefix-list | - This will apply to all areas that the local router is connected to | area 25 filter-list prefix LIST1 in - Filters traffic sent into area 25, i.e. don't send 10.5.1.0 | - Does the same as the out list, but only for area 25 | distribute-list prefix LIST1 in - This stops 10.5.1.0 from entering the RIB, but the LSA still advertised | distance 255 10.5.1.5 0.0.0.0 - Assigns admin distance of 255 for the OSPF route 10.5.1.0 |

IOS-COMMANDS

#router ospf {pid} #area {aid} filter-list prefix {name} {in|out} - Filters routes in LSA type 3 between OSPF areas #distribute-list {acl|prefix|route-map} in - Filters routes installed in the local RIB, no impact on LSAs advertised #distance ospf {ext|inter-area|intra-area} {no} - Changes the admin distance of OSPF route types #distance {weight} {ip} {wildcard} [acl] - Changes the admin distance of the matched prefix #prefix-suppression - Prevents OSPF from advertising all IP prefixes, except loopback, secondary's

and passive interfaces #interface {int}


TOC 57

#ip ospf prefix-suppression - Prevents OSPF from advertising IP prefixes belonging to the interface (excludes secondary networks)

XR-COMMANDS

#router ospf {pid} - Enters the OSPF configuration mode #area {aid} - Enters the OSPF area configuration mode #route-policy {name} {in|out} - Filters routes in LSA type 3 between OSPF areas #distribute-list {acl} in - Filters routes installed in the local RIB, no impact on LSAs advertised #distance {weight} {ip} {wildcard} [acl] - Changes the admin distance of the matched prefix

Summarization

- Best practice dictates that a non-backbone area's addresses should be summarized in to the backbone by the area's own ABR.

- Two t ypes of address summarization are supported by OSPF. > In ter-Area Summarization

>> Used for summarization of in ternal OSPF area routes at ABRs. It does not apply to external routes injected in to OSPF. >> A route to Null0 for the summary prefix will be entered in to the routing table automatica lly, but can be disabled with "no dis card-route". >> The "area range" command specifies the area to which the summary address belongs. >> The defaul t behavior of the "area range" command is to only advertise the specified summary and suppress the more specifics, but th is can be suppressed with the

'no-advertise ' keyword. >> Summarizes type 3 LSAs.

> External Route Summarization >> Allows a set of external addresses to be redis tributed in to an OSPF domain as a s ummary address at the ASBRs. >> Configured with "summary-address" command on the ASBRs. >> Speci fics of the specified s ummary address wil l be suppressed. >> Summarizes type 5 and 7 LSAs.

IOS-COMMANDS

#router ospf {pid} - Enters the OSPF configuration mode #no discard-route - Disables creation of the Null route when using the area range command #area {aid} range {ip} {mask} [advertise] [not-advertise] [cost]

- Specifies the area to which the summary address belongs - [advertise] Advertises the summary route (default) - [not-advertise] Does not advertise the summary - [cost] User specified metric for this range

#summary-address {range} {mask} [not-advertise] - Summarizes type 5 and type 7 LSAs - More-specifics which are within the range will be suppressed

XR-COMMANDS

#router ospf {pid} - Enters the OSPF configuration mode #area {aid} - Enters the OSPF area configuration mode #range {ip} {mask} [advertise] [not-advertise] - Specifies the area to which the summary address belongs


TOC 58

- [advertise] Advertises the summary route (default) - [not-advertise] Does not advertise the summary

#summary-prefix {range} {mask} [not-advertise][tag] - Summarizes type 5 and type 7 LSAs - More-specifics which are within the range will be suppressed

Stub Router Advertisement

- Defined in RFC-3623 as Graceful OSPF Res tart. - Do not confuse this with STUB AREAS. - A s tub router advertisement is an update sent with a m aximum metric set. - Two m ain benefits of OSPF stub router advertisements

> Allow a new router to be brought in to the OSPF domain without immediate ly routing tra ffic through i t. > Allow a router to be reloaded gracefully by having the res t of the OSPF domain route around the router that is being reloaded.

- Advertises a m aximum m etric for all routes that the particu lar router does not originate. - Also the feature can be used to allow the router to advertise a m aximum metric until the BGP routing table converges. - A t yp ical scenario for the use of stub router advertisement is when there are m ultiple links between two areas, and one l ink should only be used as a last resort.

- Three di fferent configuration sets: 1- To configure an OSPF router to advertise a maximum metric during s tartup. 2- To configure an OSPF router to advertise a maximum metric until BGP routing tables converge. 3- To configure an OSPF router to advertise a maximum metric for a graceful s hutdown or removal from the network.

CONFIG-SET 1: Configuring Max-Metric advertisements on startup

| router ospf 1 | max-metric router-lsa on-startup {sec} - Advertises a maximum metric during startup for announce-time = sec | - There is no-default, (value = 5-86400 sec) |

CONFIG-SET 2: Configuring Max-Metric advertisements until routing tables converge

| router ospf 1 | max-metric router-lsa on-startup {sec} wait-for-bgp | - {sec} Time that router-LSAs are originated with max-metrics | - [bgp] Lets BGP decide when to originate router-LSA with normal metric | - (def = 600 sec) |

CONFIG-SET 3: Configuring Max-Metric advertisements for a graceful shutdown

| router ospf 1 | max-metric router-lsa - Configures OSPF to advertise a max-metric, allowing neighbors to | select an alternate path before the router is shutdown

IOS-COMMANDS #router ospf {pid} - Enters the OSPF configuration mode


TOC 59

#max-metric router-lsa [summary-lsa | include-stub | external-lsa | on-startup] - Sets a maximum metric for self-originated router-LSAs - [summary-lsa] Overrides summary-lsa metric with max-metric value - [include-stub] Sets maximum metric for stub links in router-LSAs - [external-lsa] Overrides external-lsa metric with max-metric value - [on-startup] Sets maximum metric temporarily after reboot

XR-COMMANDS

#router ospf {pid} - Enters the OSPF configuration mode #max-metric router-lsa [summary-lsa | include-stub | external-lsa | on-startup]

- Sets a maximum metric for self-originated router-LSAs

Passive-Interface

- The passive-in terface with OSPF wi ll prevent hello packets from exi ting an interface and prevent the device from form ing and adjacencies out of the specified in terface. - This works di fferently to distance vector protocols like RIP, where routes wil l sti ll be received, but not sent. - To get the same 'passive-in terface ' effect as distance vector protocols in OSPF,(i .e. receive routes but don't send routes) use:

"ip ospf database-fil ter all out" under the in terface.

IOS-COMMANDS

# sh ip ospf interface - Passive-interfaces indicated by 'No Hellos' in output

#router ospf {pid}

#passive-interface {int} - Prevents hello sent out an interface - Prevents forming of adjacencies on that interface

#interface {int} #ip ospf database-filter all out - Block the flooding of OSPF LSA packets out the interface

- Filtering the outbound updates breaks RFC standards

XR-COMMANDS

#router ospf {pid} - Enters the OSPF configuration mode #area {aid} - Enters the OSPF area configuration mode #interface {int} - Enters the OSPF interface configuration mode #passive - Prevents forming of adjacencies on the interface #database-filter all out - Filters all outgoing LSAs out the interface #neighbor {ip} database-filter all out - Filters all outgoing LSAs to a neighbor

Originating a Default Route

- A defaul t route is announced as an IP prefix 0.0.0.0/0 in OSPF. - Contrary to many other routing protocols, the defaul t route cannot be redis tributed in to OSPF. It m us t be configured manually.


TOC 60

- A defaul t route can be inserted into OSPF only as an external or in ter-area (s ummary) route, not as an in tra-area route.

- There are di fferent methods to originate a defaul t route with in OSPF: > Uncondi tional defaul t route. > Condi tional default route. > Condi tional default route with a route-map. > OSPF s tub areas. > OSPF NSSA defaul t routes.

- Unconditional OSPF Default Route > This advertises a defaul t route in to the OSPF domain, regardless of whether the local router can reach areas outside the OSPF dom ains, or not. > With no addi tional configuration options, the defaul t route is advertised as an External Type 2 (E2) route with metric 1. > Configured with "defaul t-in formation originate always" under the OSPF process.

- Condi tional OSPF Defaul t Route > Configured with "defaul t-in formation originate" but without the 'always ' keyword. > This advertises a defaul t route in to the OSPF domain, but only i f the advertising router has a non-OSPF defaul t route in i ts routing tab le . > The non-OSPF defaul t route could be any of the following:

>> A s tatic defaul t route with the next-hop pointing outside the OSPF domain. >> A s tatic defaul t route based on IP SLA measurements (exam ple: http ://wp.m e/p inca -9I). >> Or a BGP advertised defaul t route.

> The "defaul t-in formation originate" command without the always option is functionally equivalent to redistributing a defaul t route in to OSPF. > With no addi tional configuration options, the defaul t route is advertised as an E2 route with a m etric of 1. > The 'm etric' keyword could be used to change the defaul t route 's defaul t metric of 1.

CONFIG-SET: Conditional OSPF Default Route with a Non-Default Cost

| ip route 0.0.0.0 0.0.0.0 serial0/1 - Route via the interface connecting to a upstream ISP | ! | router ospf 1 | default-information originate metric 10 - Originates a default route provided the above static is in | the routing-table. If interface serial0/1 goes down | OSPF will stop advertising the default route | - Default route is also advertised with a cost of 10

- Condi tional OSPF Defaul t Route with a Route-Map

> The advertisement of a defaul t route in to OSPF could also be subject to specific routing in formation in the routing table . > For th is function a route-map is used. Thus whenever a route in the IP routing table matches the conditions specified in the route-map, the defaul t route wi ll be

advertised in to OSPF. > Because the specified route-map checks the entries in the IP routing table , i t may ONLY match on IP prefixes , next-hops and m etrics . BGP attributes may not be used. > Configured with "defaul t-in formation originate route-m ap {nam e}".


TOC 61

CONFIG-SET: Conditional OSPF Default Route with a Route-Map

| ip prefix-list UPLINKS permit 10.5.1.0/24 - Matches uplink 1 | ip prefix-list UPLINKS permit 10.5.2.0/24 - Matches uplink 2 | ! | route-map CONDITION | match ip address prefix UPLINKS - References either uplink to be present in the routing table | ! | router ospf 1 | default-information originate route-map CONDITION - Advertises a default route provided one of the two uplinks are | present in the routing table

- OSPF Stub Area's Defaul t Route > Refer to area section for more deta il . > To ensure end-to-end connectivi ty between routes in s tub areas and external destinations, the area ABRs by defaul t originates a defaul t route in to s tub areas. These

routes are advertised as in ter-area (summ ary) routes. > Unless configures otherwise, the defaul t routes are advertised in to the s tub area with OSPF m etric of 1. > When m ultip le exi t points out of a s tub area exis t, the routers wi ll select the nearest ABR to reach external destinations . > If desired, the in ter-area defaul t route metric can be changed with the area defaul t-cos t router configuration command.

CONFIG-SET: OSPF Stub Area's Default Route using a Non-Default Cost

| router ospf 1 | area 1 stub - Configures area 1 as a stub, and advertises a default route | area 1 default-cost 300 - Changes the cost of the stub default route to 300 |

- OSPF NSSA's Defaul t Routing > Cisco routers don't advertise external defaul t routes in to an NSSA area, even when configured with "defaul t- in formation orig inate always ". > The ABRs can be configured to advertise the OSPF defaul t route using one of the following options:

>> Manually advertise a type-7 (NSSA external ) defaul t route in to the NSSA area. >>> Configured with "area nssa defaul t- in formation-orig inate".

>> Configure an NSSA as a to tally NSSA and generate an in ter-area (type 3) summary route. >>> Configured with "area nssa no-summary".

IOS-COMMANDS

#router ospf {pid} - Enters the OSPF configuration mode #default metric {value} - Set the metric for all redistributed routes #default-information originate [always] [metric-type] [metric] [route-policy]

- Generates a default external route - [always] Advertises regardless of a default route in the RIB - [metric-type] Specifies the external route type (def = type 2) - [metric] Specifies the default route metric (def = 10)

XR-COMMANDS



TOC 62

#default metric {value} - Set the metric for all redistributed routes #default-information originate [always] [metric-type] [metric] [route-policy]

- Generates a default external route - [always] Advertises regardless of a default route in the RIB - [metric-type] Specifies the external route type (def = type 2) - [metric] Specifies the default route metric (def = 10)

Path Selection

- Each OSPF route entry is classified according to a destination type. The destination type wil l be ei ther network or router. > Network entries are the addresses of networks to which packets can be routed. These are destinations which are candidates for insertion in to the routing tab le .

>> Seen with "show ip route ospf". > Router entries are routes to ABRs and ASBRs. This in formation is kept in a separate in ternal OSPF router table .

>> Seen with "show ip ospf border-routers ".

- OSPF Route Selection Cri teria 1- Longest match 2- Most to least preferred path type:

>> O - In tra-area paths are to destinations with in one of the router's attached areas. >> O IA - In ter-area paths are to destinations to other areas but within the OSPF AS. >> E1 (N1) - Paths to external destinations.

- External cost + in ternal cost to the LSA forwarding address else the originating ASBR i f the forwarding address is 0.0.0.0. >> E2 (N2) - Paths to external destinations.

- Only the external cost to the des tination is used. !!DEFAULT-TYPE!! 3- Use lowest cost metric unless equal-cost paths exist.

- OSPF external routes are classified as E2 routes by defaul t. - E1 and N1 are cumulative metrics , combining the ASBR's advertised cost and in ternal OSPF cost to the ASBR. - E1 and N1 are often re ferred to as 'metrics that increase hop-by-hop '. - E2 and N2 are s tatic metrics as advertised by ASBR. - Use E1 metrics when packets should exi t the network at the closest exi t point. - Use E2 metrics when packets should exi t the network at the closest point to the external des tination. - If m ultip le E2 routes have the same external cost, the in ternal cost is used as a tie breaker.

- Cost is the OSPF m etric expressed as a 16-b i t in teger in the range of 1 to 65535. - Cisco uses a defaul t cost of 10

8/BW expressed in whole numbers, i.e . 100MB in terface gets a metric of 1, 10Mb = 1 0, etc. BW is the configured bandwidth of the interfaces

and 108 is the reference bandwidth.

- The re ference bandwidth of 108 (100MB) creates a problem for some m odern media with bandwidths higher than 100M.

- To remedy th is, the command "auto-cost re ference-bandwidth" may be used to change the defaul t reference. - Defaul t Cost = Reference-BW/Interface-BW.

- The OSPF cost can be modi fied with: > In terface "bandwidth". > In terface "ip ospf cos t". > Process "auto-cos t reference-bandwidth". > Process "neighbor x.x. x. x cos t" on point-to-mul tipo int non-broadcast areas.


TOC 63

- iSPF (OSPF Incremental SPF) > Incrementa l SPF is more efficient than the full SPF algori thm allowing slightly fas ter convergence. > Incrementa l SPF allows the s ystem to recalculate only the affected part of the SPF tree.

IOS-COMMANDS

# sh ip ospf border-routers - Shows the internal OSPF table, entries are routes to ABRs and ASBRs

#interface {int}

#bandwidth {kbps} - Changes the default interface bandwidth numerical integer #ip ospf cost {value} - Changes the outgoing interface cost for packets

#router ospf {pid}

#auto-cost reference-bandwidth {mbps} - Remedies the Cisco default reference bandwidth problem (def = 100 mbps) #neighbor {ip} [priority {pri}] [cost {cost}] - Changes the cost for routes received from the specified neighbor #ispf - Enables iSPF

XR-COMMANDS

# sh ospf border-routers - Shows the internal OSPF table. Entries are routes to ABRs and ASBRs


#auto-cost reference-bandwidth {mbps} - Remedies the Cisco default reference bandwidth problem (def = 100 mbps) #area {aid} - Enters the OSPF area configuration mode #interface {int} - Enters the OSPF interface configuration mode #cost {value} - Changes the outgoing interface cost for packets

Authentication

- If area authentication is configured, i t mus t be configured for the enti re area. - Don't forget about vi rtua l-links . Virtua l-link always have one in terface in Area 0. - In terface passwords do not have to match throughout the area, but m us t be the same between neighbors. - By defaul t OSPF uses NULL authentication. - OSPF s upports the following authentication types :

>(t ype 0) Null authentication >(t ype 1) Clear-text passwords >(t ype 2) MD5 cryptographic checksums

- Authentication keys are locally significant to an in terface and therefore m ay di ffer on a per in terface basis. - When doing changes to the keychain, i t is recommended to fi rs t remove the config of the in terface.

- Virtual -link authentication can be enabled in the following two ways : #area {id} authentication [m essage-diges t] #area {id} vi rtual -link router-id authentication [message-diges t | null ]


TOC 64

IOS-COMMANDS

# sh ip ospf interface {int} - Shows if message-digest is configured # sh ip ospf | i Area - To see if authentication is enabled for the area (with capital 'A')

#router ospf {pid}

#area 10 authentication - Enables type 1 authentication for area 10 #area 20 authentication {message-digest} - Enables type 2 MD5 authentication for area 20 #area 30 virtual-link 1.1.1.1 auth {key} - Enables type 1 authentication for the virtual-link #area 40 virtual-link 2.2.2.2 message-digest-key {key-id} md5 {key}

- Enables type 2 MD5 authentication on a virtual-link #interface {int1} #ip ospf authentication null - Enables type 0 authentication. Thus no authentication needed on the interface

#interface {int2}

#ip ospf authentication - Enables type 1 interface authentication #ip ospf authentication-key {key} - Specifies the type 1 key string

#interface {int3}

#ip ospf authentication message-digest - Enables type 2 MD5 interface authentication #ip ospf message-digest-key {id} md5 {key} - Specifies the type 2 MD5 key string

XR-COMMANDS

# sh ospf interface {int} - Shows if message-digest is configured # sh key chain - Shows the key chains configured


#area {aid} - Enters the OSPF area configuration mode #authentication [message-digest|null] - Enables plain text authentication, optionally md5 or null authentication #interface {int1} - Enters the OSPF interface configuration mode #authentication-key {key} - Configures the key used with the authentication mode

#key chain {name} - Configures a keychain

#key {no} #key-string clear {pwd} - Configures the keychain password


#area {area-id} - Enters the OSPF area configuration mode #interface {int} - Enters the OSPF interface configuration mode #authentication message-digest keychain {key} - Configures authentication using a keychain


TOC 65

OSPF Demand Circuit

- Demand circui t suppresses the hello and LSA re fresh functions. Historically used with dial -up links that did not stay connected continuously. - OSPF brings up a demand circui t to perform an ini tial database synchronization. - Afterwards only the LSAs in which changes have occurred are flooded. - These LSA changes include:

> A change in the LSA options fie ld . > A new instance of an exis ting LSA is received in which the age is MaxAge. > A change in the length fie ld of the LSA header. > A change in the contents of the LSA, excluding the 20-octet header, the checksum, or the sequence number.

- Because no periodic hellos are exchanged, OSPF makes a presumption about reachabi li ty. - OSPF demand circui t sets the "do not age" flag on all learned LSAs and will only send updates when there is a change in the OSPF topology. - The command should be configured on point-to-point links and is required only on one side. - If the router is part of a point-to-mul tipoin t topology, only the multipoint end m ust be configured with this command. - Configured with "ip ospf demand-circu i t". - Copy subtly owned by James Gibson. - Changes to the in terface and neighbor state machines and to the flooding procedure:

> MaxAge = DoNotAge. > A flag known as the DC-bi t (Demand Circui t) bi t is added to all LSAs the demand circui t originates . > The DoNotAge bi t is set on LSAs advertised out, therefore the in terface and the LSAs are not refreshed unless they change.

IOS-COMMANDS

#interface {int} - Enters the OSPF configuration mode #ip ospf demand-circuit - Configures the connected interface to the demand-circuit #ip ospf flood-reduction - The DoNotAge bit is set on LSAs advertised out of the interface

XR-COMMANDS

#router ospf {pid} - Enters the OSPF configuration mode #demand-circuit - Configures the connected interface to the demand-circuit #area {area-id} - Enters the OSPF area configuration mode #interface {int} - Enters the OSPF interface configuration mode #flood-reduction - The DoNotAge bit is set on LSAs advertised out of the interface


TOC 66

Troubleshooting OSPF

- When examining an ind ividual router's configuration, consider the following: > Are the necessary in terfaces in a UP/UP s tate (not admin shut)? # sh ip in t brie f > Do all the interfaces have the correct addresses and masks? # sh in t | i In ter|l ine > Do the network area s tatements and in terface IP addresses correlate? # sh in t | i In ter|l ine|network > Do the network area s tatements have the correct inverse masks? # sh ip ospf in t brie f > Are the network area s tatements putting the interfaces in to the correct areas? # sh ip ospf in t brie f > Are any interfaces wrongly in passive m ode, due to "passive-in terface defaul t" # sh ip ospf in t | i line|Hello > Does each router have the correct router ID? Any dupl icates on the network? # sh ip ospf | i ID > If address summarization is configured, is i t applied to the correct areas? # sh run | i area range|summary-add

- When examining an area-wide problem, consider the fo llowing by looking at the design: > Is the backbone area (area 0) one contiguous domain? - Not segregated? > Are all areas connected to area 0? - Directly or in-di rectly > Are all routers in an area configured as the same area type? - Normal, Stub, or NSSA > Are all ABRs configured correctly with the correct role? - Tota lly-s tub, or totally-NSSA

Remember with multiple NSSA ABRs, only the router with the highest RID does the conversion! > Is there a vi rtua l link that transi ts or is configured with in a s tub area? - If so, configure GRE tunnel instead > Is a defaul t summary LSA present allowing exi t out of an area for unknown subnets/ASs? - A NSSA needs a manual defaul t route > Does an external LSA exis t to leave the OSPF domain? # sh ip ospf data external > Is the forward ing address known as an in ternal OSPF route? I t m us t be. # sh ip route {fa -ip } > Is the forward ing address reachable? # ping {fa -i p}

- When examining adjacencies (or the lack thereof), consider the fo llowing: > I t could be helpful to log the neighbor adjacency changes. #os pf log-adjacency-changes > Is there layer2 connectivi ty and layer3 reachabili ty? # ping {neighbor-ip} > Are hellos being sent from both neighbors and received by both? # debug ip ospf hello

>> I f not check the network statements and interfaces addresses. # sh ip ospf in t brie f >> Any in terfaces wrongly configured as "passive-in terface"? # sh run | i passive

> If di fferent network types , are they compatible? # sh ip ospf in t | i line |Type > Are the hello /dead timers the same between neighbors? # sh ip ospf in t | i line |Dead > Are the optional capabili ty value the same between neighbors? # sh ip ospf neighbor detail | i Option > Are the interfaces configured on the same subnet (this excludes point-to-point links)? # sh ip ospf in t brie f > Is a router attempting to form an adjacency with another's secondary address? # sh run | i netw|area > Are any access-lists blocking OSPF protocol 89? # sh ip in terface | i line |lis t > If the neighbor is a swi tch, are the MTU values are the same? # debug ip ospf adj > If suspecting that the adjacencies are unstable or as a last resort, use. # debug ip ospf adj

- When using frame-relay, consider the fol lowing: > Do m ultipo int NBMA in terfaces have s tatic layer3-to-layer2 mappings? # sh run | i fram e.*map > Is frame-relay broadcast repl ication enabled where necessary? # sh run | i frame.*broadcas t > In a hub-spoke scenario are any of the spokes blackhole DRs (spoke = 0 priori ty)? # sh ip ospf in terface {int} | i ID


TOC 67

- When troubleshooting authentication issues, consider the fo llowing: > Are all routers with in an area configured to use authentication? # sh ip ospf | i Area > Is the authentication type the same between neighbor interfaces? # sh ip ospf in t {int} | i auth|line > With clear-text auth are the passwords the same between neighbor interfaces? # sh run | i auth.*key > With MD5 authentication, are the diges t-keys the same between neighbor interfaces? # sh run | i digest-key > Do all the vi rtual links also have authentication configured? # sh run | i vi rtual -l ink > If Area 0 has authentication configured, then vi rtua l links requi re authentication too. > To see the cause of authentication failures, us e: # debug ip ospf adj

- Link-s tate database problems. (All databases mus t be the same for each area) > Is the local router generating the expected LSAs? # sh ip ospf database sel f-originate > Is the local router receiving the expected LSAs from a neighbor? # sh ip ospf database adv-router {ip} > Are any fi l ters configured to deny LSAs being sent in to an area? # sh run | i fi l ter-lis t > Are any dis tribute lists configured to deny entry in the local RIB? # sh run | i distribute -l ist > Is summarization the cause of LSAs not being seen? # sh run | i area range|summary-add > Do all the routers in an area have the same number of LSAs? # sh ip ospf database database-summary

>> I f not, are any interfaces fi l tering LSAs from being sent out? # sh run | i database-fil ter > Do the checksums for every LSA in the databases match between routers? # sh ip ospf database > Do any LSAs have a higher than others sequence number (look at Seq#)? # sh ip ospf database

>> This could point to an unstable l ink, caused by frequent LSA advertising. # sh in t {int} | i error|drops >> Multiple LSAs with high sequence numbers could indicate a neighbor issue. # sh ip ospf neighbor detail | i Neighbor

> Have there been many SPF calculations? What triggered these events? # sh ip ospf statistics > Have you checked the memory-and CPU-util ization on the routers? # sh process cpu his tory

# sh process mem ory sorted - When doing redistribution, consider the fol lowing:

> Is the 'subnets ' keyword used in the s tatement? # sh run | i redis tribute.*s ubnets > For BGP redis tribution,

>> I f needed, was the 'external ' keyword specified? - Not done by defaul t


TOC 68

Bibliography


RFC-2328 OSPF Version 2 http ://www.ie tf.org/rfc/rfc2328.txt

RFC-3623 Graceful OSPF Restart http ://www.ie tf.org/rfc/rfc3623.txt


TOC 69

Chapter 5

BGP


TOC 70

The BGP Process

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: BGP Configuration Guide, Cisco IOS Release 12.4T | | Cisco BGP Overview

- Defined b y RFC-1771. - BGP (Border Gateway Protocol) is a path vector protocol that uses TCP port 179 for reliable transport. - BGP uses triggered updates when needed:

> Every 5 sec for in ternal peers. > Every 30 sec for external peers.

- Periodic keepalives are used to veri fy TCP connectivi ty: > By defaul t every 60 sec.

- Holdtime in terval is the time after which a noti fication is sent i f no keepalives have been received (defaul t = 180 sec). - Only the holdtime is sent in updates . Two peers agree on the lowes t holdtime value between them and then calculate the keepalive value from the holdtime value.

IOS-COMMANDS

# sh ip protocols - Shows brief protocol overview, filters, interfaces, etc. # sh ip bgp - Shows the entries in the BGP table

#router bgp {asn} - Enters the BGP configuration mode/Starts the BGP process

#bgp router-id {ip} - Configures the RID for BGP Process #bgp scan-time {scanner-interval} - Changes the default value of the BGP scanner process (max/default = 60 sec)

- BGP scanner walks the BGP table and confirms the reachability of next-hops - The BGP scanner process is also responsible for conditional advertisement

checks and performing route dampening #timers bgp {keepalive} {holdtime} - Changes the default BGP timer values (default = 60sec, 180sec)

- Only the holdtime value is communicated in the BGP open message - Smallest configured holdtime value between BGP peers are used by both peers

and used to determine the keepalive #neighbor {ip|peer-group} advertisement-interval {sec}

- Changes the default time interval of sending BGP routing updates - Lowered value can improve convergence but can consume considerable resources

in a jittery network if value is too low. (Range 0 to 600 seconds) - Default values: 30 sec for eBGP neighbors, 5 sec for iBGP neighbors

#neighbor {ip|peer-group} timers {keepalive} {holdtime} - Changes the default values of BGP timers per specific neighbor or peer group - Per neighbor timer overwrites the process timers

#bgp update-delay {sec} - Sets a delay period before a BGP device sends its first updates

XR-COMMANDS

# sh protocols - Shows brief protocol overview, filters, interfaces, etc. # sh bgp - Shows the entries in the BGP table


TOC 71

#router bgp {asn} - Enters the BGP configuration mode #bgp router-id {ip} - Configures the RID for BGP Process #address-family {ipv4|ipv6|vpnv4} {unicast} - Activates the BGP capabilities #bgp scan-time {scanner-interval} - Changes the default value of the BGP scanner process (max/default = 60 sec) #timers bgp {keepalive} {holdtime} - Changes the default BGP timer values (default = 60sec, 180sec) #bgp update-delay {sec} - Sets a delay period before a BGP device sends its first updates #neighbor {ip} - Enters the BGP neighbor configuration mode #advertisement-interval {sec} - Changes the default time interval of sending BGP routing updates #timers {keepalive} {holdtime} - Changes the default values of BGP timers per specific neighbor or peer group

Establishing Peerings

- The command "neighbor 1.2.3.4 remote-as 100" explained: > The local router listens for the address 1.2.3.4 starting a TCP session to DST (des tination) port 179. > The local router could ini tia te a TCP session to 1.2.3.4 on DST port 179. > By defaul t the SRC (source) IP is the IP configured on the outgoing in terface. > This is called the BGP update source and can be manually configured with the "neighbor update-source" command. > Recursive lookups are used to determine the outgoing in terface to the des tination. > Unexpected BGP sessions wil l be refused. > The SRC/DST IP addresses, DST port, AS-number and authentication mus t match between neighbors. > If the AS-numbers match between peers, then the session is iBGP according to Cisco IOS, otherwise i t is eBGP.

- The BGP States > Id le - Indicates the router is currently not attempting any connection es tablishments. > Connect - Indicates the router is wai ting for the TCP connection to be completed. If successful an OPEN message is sent. > Active - Indicates the router didn 't receive agreement on parameters of establishment and is trying to ini tia te TCP. > OpenSent - After the TCP session is setup, the router wai ts for an OPEN message to confirm all parameters .

- If no errors a BGP keepalive message is sent. > OpenConfi rm - Indicates the router is wai ting for a keepalive or noti fication message.

- If a keepal ive is received the s tate changes to Established, else changes to Idle > Established - Indicates peering to a neighbor is established; routing begins.

- The BGP Open Message contains the following fields : > BGP version number - Must m atch between neighbors. > Local AS num ber - Must m atch between neighbors. > Holdtime - Routers agree on lowest suggested value between neighbors. > BGP RID (Router Identi fier). > Optional parameters .

- Test a connection between peers to confi rm connectivi ty, by using "telnet {peer-ip} 179 /source {int}" .

IOS-COMMANDS

# telnet {peer ip} 179 /source {interface} - Useful to test connectivity between peers


TOC 72

# sh tcp brief - Lists the TCP sessions, the TCB values, the IPs, ports and their states - Established BGP peers should be in an 'ESTAB' state

# clear tcp tcb {number} - Clears a particular tcp session

# debug ip packet detail [acl] - Good for seeing the TCP session being build, with SRC and DST IPs and ports

# debug ip tcp transactions - Shows all TCP transactions (start of session, session errors, etc.) # debug ip bgp events - Shows the BGP state transitions # debug ip bgp keepalives - Debugs BGP keepalive packets # debug ip bgp updates[acl] - Shows all incoming or outgoing BGP updates (!!USE WITH CAUTION!!) # debug ip bgp [ip] updates [acl] - Shows all BGP updates received from or sent to a BGP neighbor

- [acl] Optionally matches an IP access-list (recommended)

#router bgp {asn} - Enters the BGP configuration mode

#neighbor {ip|peer-group} remote-as {asn} - Defines an external/internal neighbor #neighbor {ip|peer-group} description {text} - Assigns a description to an external neighbor (up to 80 characters) #neighbor {ip|peer-group} shutdown - Disables communication with the BGP neighbor

- Recommended while doing extensive modification to routing policies #neighbor {ip|peer-group} update-source {int} - Specifies the source interface for the TCP session that carries BGP traffic

XR-COMMANDS

# sh tcp {brief|packet-trace} - Lists the TCP sessions, the IPs, ports and their states # clear tcp tcb {number} - Clears a particular tcp session


#neighbor {ip} - Enters the BGP neighbor configuration mode #remote-as {asn} - Defines an external/internal neighbor ASN #description {text} - Assigns a description to an external neighbor, (up to 80 characters) #shutdown - Disables communication with the BGP neighbor

- Recommended while doing extensive modification to routing policies #update-source {int} - Specifies the source interface for the TCP session that carries BGP traffic

Authentication

- BGP supports only MD5 authentication on a per neighbor basis. - On IOS-XR authentication can be applied using a keychain.

IOS-COMMANDS

#router bgp {asn} - Enters the BGP configuration mode #neighbor {ip|peer-group} password {pwd} - Enables MD5 authentication for a neighbor

- {pwd}: Must match on both sides - CaSe-SenSiTive, the first character may not be a number


TOC 73

XR-COMMANDS

#router bgp {asn} - Enters the BGP configuration mode #neighbor {ip} - Enters the BGP neighbor configuration mode #password {pwd} - Enables MD5 authentication for a neighbor #keychain {name} - Enables keychain authentication for a neighbor

eBGP Sessions

- The Cisco AD (Admin istra tive Distance) for eBGP peers is 20. - By defaul t the TTL (time-to-l ive) is set to 1 for eBGP sessions. - If an eBGP session is configured between two non-di rectly connected peers , the TTL mus t be increased with "ebgp multihop". - This also applies when a loopback in terface is used, as tra ffic to the loopback counts as one extra hop.

- eBGP loop prevention > A router wi ll not accept a prefix i f the locally-configured ASN is listed in the received as-path lis t. > This defaul t behavior can be changed with the "ne ighbor allowas -in" command.

- BGP Backdoor > When a router learns a prefix via two paths , one via eBGP and the other via IGP, the eBGP route based on the AD(20) will be chosen as the best. > This might not always be the requi red best route. > The AD of that one route could be changed or the BGP backdoor feature could be used, which m akes the IGP route the preferred route.

- BGP Maximum-Paths > Used to control the maxim um number of parallel in ternal /external BGP routes that can be installed in the routing table . > Two required condi tions :

>> All attributes mus t be the same, i .e. weight, loca l-pref, as-path, orig in and med/IGP distance. >> The next-hop router for each m ultipath mus t be di fferent.

IOS-COMMANDS

#router bgp {asn} #neighbor {ip} ebgp-multihop [ttl] - By default, eBGP neighbors expect to be directly connected (TTL=1)

- eBGP-multihop allows a peer to be several hops away - Often used when eBGP is setup between loopbacks interfaces - If no TTL is entered a command default of 255 is used

#neighbor {ip} ttl-security hops {hop-count} - Max number of hops that can separate the eBGP peer from the local router

- A lightweight security mechanism to protect eBGP sessions from CPU-based attacks

#neighbor {ip} allowas-in {no} - Disables the default eBGP loop-prevention for the specified amount of entries

- Thereby allowing the local ASN to be listed in a received as-path list - {no} The number of times the local ASN may be listed, only on the LEFT - If no number is supplied, the default value of 3 is used


TOC 74

#neighbor {ip} as-override - Allows a PE router to override the ASN of a site with the ASN of a provider - The "as-override" could be used as an alternative to "allowas-in"

#distance bgp {ext-ad} {int-ad} {local} - Sets the AD for eBGP, iBGP, and local routes (default: eBGP=20 and

local/iBGP=200) - {local}: Locally originated routes via the "network", "aggregate" or

"redistribution" command

#network {prefix} backdoor - Makes the IGP route more preferred than the eBGP route for the destination

#maximum-paths eibgp {max-number} - Control the max number of parallel routes allowed to be installed (def=1)

XR-COMMANDS

#router bgp {asn} - Enters the BGP configuration mode #neighbor {ip} - Enters the BGP neighbor configuration mode #ebgp-multihop [ttl] - By default, eBGP neighbors must be directly connected (TTL=1) #ttl-security hops {hop-count} - Max number of hops that can separate the eBGP peer from the local router #address-family ipv4 unicast - Enters the BGP IPv4 unicast configuration mode #allowas-in {no} - Disables the default eBGP loop-prevention for the specified amount of entries #as-override - Allows a PE router to override the ASN of a site with the ASN of a provider #distance bgp {ext-ad} {int-ad} {local} - Sets the AD for eBGP, iBGP, and local routes (defaults= 20,200,200) #network {prefix} backdoor - Makes the IGP route more preferred than the eBGP route for the destination #maximum-paths {ebgp|ibgp|eibgp} {max-number} - Control the max number of parallel routes allowed to be installed (def=1)

Next-Hop Processing

- When a packet is passed between iBGP peers, NO next-hop processing is done, unless confederations are used. - When a packet is passed between eBGP peers, the next-hop field is modi fied to the IP address of the sending eBGP router's in terface - If the receiving BGP router is in the same subnet as the current next-hop address, the next-hop field remains unchanged to optimize packet forward ing (typically seen on

multi-access networks). - Be careful with next-hop processing on NBMA networks . The next-hop mus t be reachable. Rather use a sub-interface in terface on a di fferent subnet or al ternatively change

the next-hop processing. - Next-hop processing could be changed in one of two ways :

> As mentioned above with the "neighbor next-hop-sel f" command. > Or with a route-map by setting the "ip next-hop".

IOS-COMMANDS

#route-map {name} #set ip next-hop {ip} - Changes the next-hop to the IP specified

#router bgp {asn}

#neighbor {ip} route-map {name} {in|out} - Applies the route-map to change next-hop processing

#neighbor {ip} next-hop-self - Instructs iBGP to use this router as the next-hop for routes advertised Copyright © 2013 Routing-Bits.com

TOC 75

XR-COMMANDS

#router bgp {asn} - Enters the BGP configuration mode #neighbor {ip} - Enters the BGP neighbor configuration mode #address-family ipv4 unicast - Enters the BGP IPv4 unicast configuration mode #route-policy {name} {in|out} - Applies the route-policy to change next-hop processing #next-hop-self - Instructs iBGP to use this router as the next-hop for routes advertised #next-hop-unchanged disable - Disables overwriting the BGP next-hop before advertising an eBGP route

iBGP Sessions

- Cisco AD (Adm in istra tive Distance) for iBGP peers are 200. - There is no BGP next-hop modi fication by defaul t between iBGP neighbors. Thus a full mesh between iBGP neighbors are requi red for full reachabili ty. - Because iBGP sessions are usually log ical , i t is recommended to setup iBGP sessions using loopback in terfaces - iBGP loop prevention is done via route suppression/BGP spli t horizon:

> I.e . iBGP learned routes wil l not be advertised onto other iBGP neighbors . > This rule implies that the fo llowing is in place:

>> Fully meshed iBGP peerings (n( n- 1)

/2) OR >> Route-reflection OR >> Confederations

- RRs (Route-Reflectors) > Modifies the iBGP spli t-horizon rule . > With RRs the actual tra ffic does not need to pass through the RR, only the updates should. > RRs have di fferent client behavior:

>> eBGP neighbors >>> Normal eBGP neighbors . >>> Received updates will be advertised to other eBGP neighbors, RR clients and non-clients .

>> RR Clients >>> Configured on the RR with "neighbor route-reflector-client". >>> Received updates will be advertised to eBGP neighbors , all other RR clients and non-clients .

>> Non-Client peers >>> Normal iBGP neighbors (non RR clients ). >>> Received updates will be advertised to eBGP neighbors and all RR clients.

> Route re flector configuration is done only on RRs. RR clients use normal BGP configuration to the RRs. > I t is recommended to configure a clus ter-ID on RRs when they part of a redundant clus ter. > The defaul t value of the clus ter-ID i f not configured is the BGP router-ID of the RR. > The originator-ID attribute is added to the reflected updates i f i t is not already set. > RRs reflects only the routes that considered as the bes t.

- Confederations > Autonomous s ys tem can be broken up in to smaller sub autonomous s ys tems called confederations. > Even though confed-peers use eBGP sessions, they exchange routing in formation as i f they were iBGP peers. > More speci fica lly, the next-hop, MED attribute, and local preference in formation are preserved. > I t is generally good practice to use private ASNs (64512-65535) for confederations. > Neighbors inside a confederation AS m us t still be fully-meshed or route-reflectors mus t be used.


TOC 76

> To configure: >> Configure the BGP process with the sub-AS num ber. >> Then specify a rea l AS num ber. >> Lastly l is t the connected sub-AS numbers in the confederation.

CONFIG-SET: BGP Confederations Example

| router bgp 65001 - Member-AS number | bgp confederation identifier 123 - Real AS-number | bgp confederation peers 65002 65003 - Confederation peer AS-numbers | ! | neighbor 10.1.1.4 remote-as 65001 - iBGP neighbor | ! | neighbor 10.1.1.2 remote-as 65002 - eBGP with intra-confederation AS | neighbor 10.1.1.3 remote-as 65003 - eBGP with intra-confederation AS | ! | neighbor 145.1.1.2 remote-as 102 - Real eBGP session |

IOS-COMMANDS

#router bgp {asn} >>> Route-Reflector Configuration <<< #neighbor {ip-address} route-reflector-client - Configures an iBGP neighbor to be a client of this RR #bgp cluster-id {cluster-id} - Optionally assigns a cluster-ID to the RR

- Cluster-ID is a 4-byte value - Required only for clusters with redundant RRs - Cluster-ID cannot be changed after the first client is configured

>>> Confederation Configuration <<<

#router bgp {sub-as-number} - Configures BGP process with member-AS number #bgp confederation-id {external-as-number} - Configures real external AS-wide number #bgp confederation-peers {list-intra-confed-as} - Defines the connected confederation ASs

XR-COMMANDS

#router bgp {asn} >>> Route-Reflector Configuration <<< #bgp cluster-id {cluster-id} - Optionally assigns a cluster-ID to the RR #neighbor {ip} - Enters the BGP neighbor configuration mode #address-family ipv4 unicast - Enters the BGP IPv4 unicast configuration mode #route-reflector-client - Configures an iBGP neighbor to be a client of this RR

>>> Confederation Configuration <<<

#router bgp {sub-as-number} - Configures BGP process with member-AS number #bgp confederation-id {external-as-number} - Configures real external AS-wide number #bgp confederation-peers {list-intra-confed-as} - Defines the connected confederation ASs #neighbor {ip} - Configures the BGP neighbor #address-family ipv4 unicast - Activates the BGP IPv4 unicast configuration mode


TOC 77

iBGP Synchronization

- BGP Synchronization Rule: > If an autonomous s ystem is a transi t autonomous s ys tem and synchronization is enabled, BGP will not advertise a route until that router has learned that external route

via i ts IGP. - This rule was designed to prevent routing blackholes that can arise when non-BGP routers are in the BGP transi t path and don't have knowledge about the external next-

hop destinations . That resul ted in traffic being dropped. - This is a legacy ru le and is disabled by defaul t as from IOS 12.2(8)T+. - Al ternatives to using s ynchronization:

> Run BGP on every router in the transi t path. > Redistribute BGP in to IGP (genera lly not a good idea in production networks). > Tunnel BGP using a tunnel technique l i ke GRE, etc.

IOS-COMMANDS

#[no] synchronization - Disables synchronization between BGP and an IGP (default = disabled)

BGP Path Attributes

- The BGP Path Attributes are categorized as follow > Wel l -known attributes (m us t be recognized by every BGP implementation)

>> Mandatory mus t be present in all updates. >>> Next-Hop (see below) >>> AS-Path (see below) >>> Origin (see below)

>> Discretionary could be present in an update, but not requi red. >>> Local Preference (see below) >>> Atomic Aggregate - Is used to signal that original in formation may have been lost when the updates were summarized in to a single entry.

> Optional attributes- (not expected to be recognized by al l BGP implementations ) >> Transitive wi ll be propagated i f not recognized, but the partia l bi t will be set to indicate that the attribute was not recognized.

>>> Aggregator - Identi fies the AS and router with in that AS which created the route aggregate. >>> Communi ty - Is used for route tagging (see below).

>> Non-Transi tive wi ll be discarded i f not recognized. >>> MED (see below).

- Only the best routes (ind icated by a '>') are considered candidates for advertising and candidates to be placed in the RIB. - An outbound routing policy affects how tra ffic is re turned. - An inbound routing policy affects how tra ffic leaves an AS. - Prerequisi tes:

> A prefix m ust have IGP next-hop reachabili ty for BGP to consider that route. > The s ynchronization ru le mus t be m et or disabled.


TOC 78

- BGP Bestpath Selection Process 1- Prefer the highes t Cisco weight (local to router). 2- Prefer the highes t local preference (loca l to AS). 3- Prefer the routes that the router originated locally. 4- Prefer the shortes t AS paths (only the length is compared). 5- Prefer the lowest origin code (IGP-i before EGP-e before Incom plete-?). 6- Prefer the lowest MED. 7- Prefer external (eBGP) paths over internal (iBGP) paths :

>> For eBGP paths , prefer the oldest (mos t s table) path. >> For iBGP paths , prefer the path through the closest IGP neighbor (lowes t IGP m etric).

8- If route re flectors are configured: >> With multip le iBGP routes, non-reflected routes are preferred above re flected routes. >> Then re flected routes with a shorter clus ter-l ist are preferred above routes with a longer cluster-lis t.

9- Prefer the path from the router with the lowest BGP router-ID. 10- Prefer the path from the lowest neighbor interface address.

- Cisco Weight Attribute > Used for OUTBOUND routing decisions when ONE router has MULTIPLE links to a provider/providers . > I t is locally signi ficant within a router as i t is never sent out in updates. > BGP weights can be specified per neighbor with the "ne ighbor weight" command or with in a "route-map". > Weight is applied to new incoming updates to affect OUTBOUND routing decisions. > To enforce newly-set weight values, re-establish BGP sessions with the neighbors (re fer to the Clearing BGP Session). > If no weight value is specified, the default value of 0 is applied to received routes . > Routes that the router originates locally have a defaul t value of 32768. > Routes can be matched in any combination of prefix-l ists , AS-path fil ters, or other BGP attributes . > Routes not matched by the route-map will be discarded.

- Local Preference Attribute > Used for OUTBOUND routing decisions when SINGLE/MULTIPLE routers have SINGLE/MULTIPLE links to a provider/providers. > A BGP router can set local preference when processing incoming route updates when doing redistribution, or when sending outgoing route updates . > The defaul t value is 100. A higher value is always preferred.

- AS-Path Attribute > Used for INBOUND routing decisions to decide which re turn path to use when MULTIPLE paths exist. > AS-path prepending is useful in two scenarios:

>> Manipulating the outgoing AS-path length to effect proper re turn path selection for primary/backup links. >> Dis tributing the re turn tra ffic load for multi -homed scenarios.

> To enforce newly-set AS-path lengths , re-send BGP updates outbound to the neighbors (re fer to Clearing BGP Session). > AS-path prepending should be performed on outgoing eBGP updates over the non-desi red re turn path, or the path where the tra ffic load should be reduced.

!!NOTE!! AS-path prepending cannot be moni tored or debugged on the sending router. It can only be observed on the receiving router.

- MED (Mul ti Exit Discriminator) Attribute > Used for INBOUND routing decisions when MULTIPLE re turn paths from the SAME AS to ONE/MORE routers exis t. > There is by defaul t no MED attribute attached to a route, except i f the router orig inated the route. > The Cisco defaul t MED value of received updates is then assumed to be 0. > A received MED value is not propagated outside of the receiving AS.


TOC 79

> A lower MED value is m ore preferred. > By defaul t, the MED is considered only during selection of routes from the same AS and does not include in tra-confederation autonomous s ystems. > Defaul t MED behavior is di fferent with redis tribution. With the "network" or "redis tribution" command the metric in the routing table will be used as the MED.

- Communi ty Attribute > The communi ty attribute is an optional transi tive attribute. > BGP communi ties are a means of tagging routes to ensure consistent fi l tering or route selection policy in incoming/outgoing routing updates , or with red istribution. > By defaul t, communi ties are s tripped in outgoing BGP updates. Sending them m ust be manually enabled. > Routers that do not support communi ties wi ll pass them along unchanged. > There are two types of communi ty attributes :

>> Standard Communi ty >>> Is an extension used by BGP to pass addi tional in formation between BGP peers. >>> Typically used to aid policy administra tion and reduce the complexi ty of route management. >>> Is a 32-bi t value.

>> Extended Communi ty >>> Is an extension used by BGP to provide a mechanism for labeling in formation carried by BGP. >>> Is a 64-bi t value.

> BGP communi ty formats >> Decimal

>>> The communi ty value is expressed as "set communi ty 1966100". >>> By defaul t, IOS uses the older decimal format.

>> Hexadecimal >>> The communi ty value is expressed as "set communi ty 0x1E0014".

>> ASN:NN >>> A new communi ty form at is expressed as "set communi ty 30:20" >>> The high-order 16-bi ts contain the ASN of the autonomous s ys tem which defines the communi ty m eaning. >>> The low-order 16-b i ts have local significance to the orig inating AS. >>> Enabled with the command "ip bgp-communi ty new-format".

> RFC-1997 defined several wel l-known s tandard communi ties : >> no-advertise - Do not advertise routes to any BGP peer (local to a router). >> no-export - Do not advertise routes to REAL eBGP peers (local to an AS). >> loca l-as - Do not advertise routes to any eBGP peers (local to a confed-AS). >> in ternet - Used to m atch all communi ties . (Not RFC s tandard, but Cisco implementation).

> Communi ty values specified with the "set" command in a route-map will overwri te existing communi ty values unless the 'addi tive ' keyword is specified. > Communi ty-lis ts are simi lar to access-lists and are evaluated sequential ly, line by line. > All the values l isted in one line mus t match for the line to match and perm i t or deny a route.


TOC 80

CONFIG-SET: Setting BGP Communities in a Route-Map

| route-map SET-COMM | match ip address 123 | set community 100:12 100:212 additive - Attaches the communities to the matching routes | ! - [additive] Preserves the original communities and append new ones | router bgp 100 | neighbor 10.5.0.5 route-map SET-COMM out | neighbor 10.5.0.5 send-community standard - By default, communities are not sent in outgoing updates |

> Standard communi ty-lis ts

>> The keyword 'in ternet' can be used to match any communi ty value. >> Permi t action = match. >> Deny action = don't m atch.

> Expanded communi ty-l ists >> Simi lar to simple communi ty-lis ts but allow matching based on regular expressions. >> The regular expression '.* ' can be used to match any communi ty value.

> Named communi ty-lis ts >> Allow the use of meaningful names. >> Can be configured with regular expressions or with numbered communi ty values.

> Cost communi ty >> Allows the BGP bes t-path selection process to be customized for a local AS or confederation. >> In fluences the BGP best-path selection process at the POI (Point of In teres t). >> Appl ied ONLY to in ternal routes by configuring the fo llowing:

#s et extcommuni ty cost [igp] {com m uni ty-id} {cos t-va lue}

> BGP dm zlink bandwidth extended communi ty >> Used to enable m ultipath load balancing for external link with unequal bandwidth capaci ty. >> This is done by advertising the bandwidth of a l ink used to exi t the AS. >> Supports iBGP and eBGP multipath load balancing. >> Ind icates the preference of an AS exi t l ink in terms of bandwidth.

IOS-COMMANDS

#route-map {name} >>> Cisco Weight <<< #set weight {value} - Changes the weight in a route-map

#router bgp {asn} #neighbor {ip} weight {weight} - Sets the weight for all routes received from the neighbor

- Weight value (1-65535) #neighbor {ip} route-map {map-name} in - Sets the weight for the matching routes from the neighbor

#route-map {name} >>> Local-Preference <<< #set local-pref {value} - Changes the local preference in a route-map

#router bgp {asn}


TOC 81

#bgp default local-preference {pref} - Changes the default local preference in all updates received from a neighbor #neighbor {ip} route-map {map-name} in - The route-map sets the local-preference to incoming updates from neighbors #neighbor {ip} route-map {map-name} out - Used to change the local-preference advertised to a iBGP neighbor

#route-map {name} >>> AS-Path Prepending <<<

#set as-path prepend as-number [as-number] - Prepends an ASN to the AS path #router bgp {asn} #neighbor {ip} route-map {map-name} out - Applies the prepended AS-path to all routes matching #bgp bestpath as-path ignore - Ignores the AS-path length in its decision process

- Cisco IOS takes the length of the AS-path attribute into consideration but RFC 1771 does not include this step

#route-map {name} >>> MED <<<

#set metric {value} - Changes the MED in a route-map #router bgp {asn} #neighbor {ip} route-map {map-name} in|out - Applies the new MED value set in the route-map #default-metric {number} - This changes the default MED value #bgp always-compare-med - Used to consider MED for routes coming from a different ASs #bgp bestpath med missing-med-worst - Causes a missing MED to be interpreted as infinity (worst)

- If a MED is not attached to a BGP route, Cisco assumes as value 0 #bgp bestpath med confederation - Allows routers to compare MEDs learned from confederation peers #bgp deterministic-med - Ensures the comparison of MEDs from different neighbors in the same AS

- By default routes from the same autonomous system are grouped, and only the best entries of each group is then compared

>>> Communities <<<

#ip community-list {1-99} {permit|deny} value [value] - Defines a standard community-list #ip community-list {100-199} {permit|deny} {regex} - Defines an expanded community-list #ip community-list {std|exp} {name} {permt|deny} {value | regex}

- Defines a names community-list #route-map {name} #match community {value/list} - Reference a community value or list #set community {value} - Sets a static or well-known community #set comm-list {list} - Applies the BGP community list #set extcommunity cost [igp] {community-id} {value} - Sets the cost community value

#router bgp {asn}

#neighbor {ip} route-map {map-name} in|out - Applies/matches the community values set in the route-map #neighbor {ip} send-community [std|ext|both] - Enables the sending of communities in outgoing updates

- [both] Is the default option if none specified

#bgp {ip} dmzlink-bw - Distributes traffic proportionally over external links,

with unequal bandwidth when multipath is enabled #neighbor {ip} dmzlink-bw - Enables the link bandwidth attribute for routes learned to be included

for the specified neighbor


TOC 82

XR-COMMANDS

#router bgp {asn} - Enters the BGP configuration mode #bgp default local-preference {pref} - Changes the default local preference in all updates received from a neighbor #bgp bestpath compare-routeid - Compares RIDs and selects the lowest router-id #bgp bestpath as-path ignore - Ignores the AS-path length in its decision process #bgp bestpath med compare always - Used to consider MED for routes coming from a different ASs #bgp bestpath med missing-as-worst - Causes a missing MED to be interpreted as infinity (worst)

- If a MED is not attached to a BGP route, Cisco assumes as value 0 #bgp bestpath med confed - Allows routers to compare MEDs learned from confederation peers #bgp deterministic-med - Ensures the comparison of MEDs from different neighbors in the same AS #neighbor {ip} - Enters the BGP neighbor configuration mode #address-family ipv4 unicast - Enters the BGP IPv4 unicast configuration mode #weight {weight} - Sets the weight for all routes received from the neighbor

#dmz-link-bandwidth - Advertises the bandwidth of the links exiting the ASN

Originating Prefixes

- Routes can be originated in to BGP in the fol lowing ways : > Using the "network" s tatement. > By doing red istribution from another protocol . > By originating a defaul t route. > By using the "aggregate-address" command. > By using BGP condi tional route injection.

- Network Statement > If no m ask option is specified a classful s ubnet will be assumed. > If Auto-Summary is ENABLED, at least one subnet of the major network is required in the RIB for a route to be originated in BGP. > If Auto-Summary is DISABLED, an exact route match is required in the RIB before the route is originated in BGP. > BGP routes orig inated through the "network" s tatem ent have an origin code of 'i ' for IGP. > Optional ly a route-map can be referenced, which allows route parameters to be modi fied before the route is entered in to the BGP table . > A defaul t route could also be orig inated using "network 0.0.0.0 0.0.0.0" with same requirements as above.

- Redistribution > Can be used to orig inate routes in to BGP that were learned using another routing protocol . > Routes redis tributed into BGP wil l have an orig in code of '?' sign i fying incomplete, since BGP does not know exactly where the route was created.

- Defaul t In formation Originate > The "defaul t-in formation originate" command is used to configure a BGP routing process to advertise a defaul t route (0 /0). > A red istribution s tatement mus t also be configured to complete this configuration or the defaul t route wi ll not be advertised. > The "defaul t-in formation originate" command, however, requires explici t redis tribution of the route 0.0.0.0.

- Neighbor Default Originate > When enabled BGP advertises an uncondi tional defaul t route to the specified neighbor. > This advertises the defaul t route to a BGP neighbor even i f a defaul t route is not present in the BGP tab le .


TOC 83

> The advertisement can be made conditional by using a route-map. > The neighbor default route is not passed through the outbound BGP fi l ters (prefix-lis t, fil ter-l ist, or route-map).

- Aggregation > This is BGP terminology for summarizing routes in the BGP table . > The aggregate will be announced ONLY i f at least one of the routes in the specified range is in the BGP tab le (not the IGP tab le). > The defaul t behavior is to advertise the aggregate and the more specific routes . This can be disabled with 'summary-only' keyword. > BGP routes orig inated through the "aggregate-address" command have an origin code of 'i ' for IGP. > Optional ly, a route-map can be used to suppress only certain routes of the aggregate, using the "suppress-map". > Additionally, certain suppressed routes can be unsuppressed on a per-neighbor basis, using the "unsuppress-map".

- See Condi tional-Route-Injection and Conditional -Route-Advertisement below for addi tional methods.

CONFIG-SET: Originating prefixes with BGP

| ip prefix-list DEF seq 5 permit 0.0.0.0/0 - Matches the default route | ! | route-map DEFAULT permit 10 | match ip address prefix-list DEF - Reference the prefix-list | ! | route-map COMM | set community 100:12 - Attaches the communities to the matching routes | ! | router bgp 100 | no auto-summary - Automatic summarization to the classful boundary is disabled | network 10.22.22.0 mask 255.255.255.0 - The exact prefix 10.22.22.0/24 must be present in the RIB | ! table to be originated this into the BGP table | network 10.1.1.0 mask 255.255.255.0 route-map COMM - Community 100:12 will be attached to this route when originated | ! | aggregate-add10.22.0.0 mask 255.255.0.0 summary-only | ! - The summary 10.22.0.0/16 will only be originated if a more | ! specific route of the summary is present in the BGP table | neighbor 10.1.34.4 remote-as 65000 | neighbor 10.1.34.4 default-orig route-map DEFAULT - Because of the route-map, a default route will only be sent to | ! 10.1.34.4 if a default route exists in the BGP table | neighbor 10.1.13.1 remote-as 65001 | neighbor 10.1.13.1 default-originate - A default route will be sent to 10.1.13.1 regardless | ! whether a default exists in the BGP table |

IOS-COMMANDS

#router bgp {asn} #network {network} [mask] [route-map] - Originates a network into BGP with an origin code of IGP (i) #redistribute {igp} [pid] [metric] [route-map] - Originates redistributed routes with an origin code of '?-incomplete' #redistribute {static|conn} [route-map] [metric] - Originates static or connected routes into BGP


TOC 84

#default-information originate - Originates a redistributed default route #neighbor {ip} default-originate [route-map] - Advertises an unconditional default route to the neighbor

- [route-map] Allows the advertisement to be conditional #default-metric {metric} - Sets the metric of redistributed routes if not specified in another way #aggregate-address {aggregate} [mask] [summary-only]

- Originates a BGP summary/aggregate address - [summary-only] Advertises only the aggregate and not the individual routes

#aggregate-address {aggregate} {mask} suppress-map {route-map}

- Specifies only a subset of routes to be suppressed - The routes within the aggregate permitted/matched by the route-map will be

suppressed from being advertised to neighbors

#neighbor {ip} unsuppress-map {route-map} - Specifies what aggregate routes to unsuppress on a per neighbor basis

XR-COMMANDS

# sh bgp policy [summary] - Shows BGP advertisements with regards to route-policies


#default-information originate - Allows a redistributed default route to be originated #default-metric {metric} - Sets the metric of redistributed routes if not specified in another way #address-family ipv4 unicast - Enters the BGP IPv4 unicast configuration mode #network {network/mask}[route-policy] - Originates a network into BGP with an origin code of IGP (i) #redistribute isis [tag] [level 1|2|inter][metric] - Redistributed IS-IS routes with an origin code of '?-incomplete' #redistribute ospf [pid] - Redistributed OSPF routes with an origin code of '?-incomplete' #redistribute {static|conn} [route-pol] [metric] - Originates static or connected routes into BGP #aggregate-address {aggregate} [mask] [summary-only]

- Originates a BGP summary/aggregate address - [summary-only] Advertises only the aggregate and not the individual routes

#aggregate-address {aggregate} {mask} suppress-map {route-policy} - Specifies only a subset of routes to be suppressed - The routes within the aggregate permitted/matched by the route-policy will be

suppressed from being advertised to neighbors #neighbor {ip} - Enters the BGP neighbor configuration mode #address-family ipv4 unicast - Enters the BGP neighbors IPv4 unicast configuration mode #default-originate [route-policy] - Advertises an unconditional default route to the neighbor

BGP Route-Maps on IOS

- Defaul t s tatement is "perm i t". - Defaul t sequence number is 10 and the defaul t increment is 5. - If route is not matched by any s tatements i t is dropped. - 'Permi t al l' is achieved by speci fying a "perm i t" without a "match" clause. - Match conditions in one s tatement are AND'd together.


TOC 85

CONFIG-SET: BGP Route-Map Example Filtering Routes

| route-map RMAP permit 45 | match ip address prefix-list LIST - Allows only matched routes | ! | router bgp 1 | neighbor 10.1.1.1 route-map RMAP in - Prefixes not permitted by the route-map are discarded |

- MATCH Cri teria :

> Network num ber and subnet matched with an IP-prefix lis t > Route originator > BGP next-hop address > BGP origin > Tag attached to IGP route > AS-path > BGP communi ty attached to BGP route > IGP route type (in ternal /external )

- SET Options: > Origin > BGP communi ty > BGP next-hop > Local preference > Weight > MED

- Route-Map Policy-List > Adds the capabil ity for a network engineer to group route-map match clauses in to named lists called policy-lis ts. > Policy lists with groups of match clauses can be pre-configured and then referenced within di fferent route maps . > Eliminates the need to manually reconfigure each recurring group of match clauses that occur in di fferent route-maps.

- Route-Map Continue Feature > In troduces the 'continue ' clause to BGP route-map configuration, providing m ore programmable policy configuration and route fil tering. > Configures a route-map to go to another route-map entry with a higher sequence number. > The 'continue ' clause will be executed in the route-map instance i f a m atch occurred..


TOC 86

CONFIG-SET: Route-Map Continue Feature

| route-map RMAP permit 10 | match ip address 1 - Matches ACL-1 routes | set as-path prepend 2001 - Prepends 2001 to the ASN | continue 30 - Traffic matching sequence-10 will continue to sequence-30 | ! | route-map RMAP permit 20 | match next-hop 10.1.2.3 | set local pref 150 | ! | route-map RMAP permit 30 | set as-path prepend 2001 - Prepends 2001 again to the ASN

IOS-COMMANDS

# sh route-map [name] - Shows the configured route-map/s # sh ip bgp route-map {name} - Executes the route-map against the BGP routing table entries # sh ip policy-list {name22} - Shows the policy list/s

#ip policy-list {name22} {permit | deny} - Creates a policy list

#route-map {name} [permit|deny] {seq_no} - Configures the route-map #match policy-list {name22} - Matches a specific criteria like a policy-list #set {parameter} - Executes various set functions #continue {seq} - Moves on to the specified sequence number

Route Filtering on IOS

- The aggregate command could be used to fil ter the advertisement of BGP routes (re fer to previous Section).

- AS-Path Filters > Can be used to selectively fi l ter routes based on the AS-path lis t. > Incom ing routes - Permitted routes are entered in to the local BGP table , denied routes are silently dropped. > Outgoing routes - Permitted routes are transmi tted to the neighbor, denied routes are never sent to the neighbor. > Refer to the Regular Expression Section below to unders tand REGEX better.

- Distribute -Lis ts > Allow BGP routes to be fil tered per neighbor using an ACL. > Standard ACLs have an inherent problem - they cannot m atch the length of a network mask exactly, thus allowing more than the in tended length. The fol lowing example

ACL will permi t the /19 aggregate as well as the more specific /24 networks. #access-list 1 permit 10.10.0.0 0.0.31.255

> Extended ACLs can be used to match the network mask exactly. The following ACL line achieves the required match of 10.10.0.0/19:

#access-list 101 permit ip 10.10.0.0 0.0.0.0 255.255.224.0 0.0.0.0

>> The source is 10.10.0.0 and the source-wildcard of 0.0.0.0 is configured for an exact m atch of source.


TOC 87

>> A m ask of 255.255.224.0, and a m ask-wildcard of 0.0.0.0 is configured for an exact m atch of source m ask.

> For m ore in formation on this use of ACLs re fer to the Securi ty Chapter. > General ly, when fi l tering BGP networks , prefix-lis ts would be used. Occasionally when odd and even networks should be fi l tered while controll ing the mask length, a

distribute -l ist with an extended ACL could still be used.

CONFIG-SET: BGP Distribute-List Example

| access-list 101 permit ip 10.10.0.0 0.0.0.0 255.255.224.0 0.0.0.0 | access-list 123 permit ip 10.20.0.0 0.0.254.0 255.255.255.0 0.0.0.255 | ! | router bgp 100 | neighbor 172.16.1.2 remote-as 200 | neighbor 172.16.1.2 distribute-list 101 in - Filters 10.10.0.0/19 from 172.17.1.2 | neighbor 172.20.1.1 remote-as 200 | neighbor 172.20.1.1 distribute-list 123 in - Filters routes between /24 and /32 with an even number | in the 3rd octet

- Prefix-Fil ter > A prefix-lis t fil ter can be used as an al ternative to ACLs to fi l ter BGP routes . > Prefix lis ts are a m ore accurate way to m atch and fil ter networks in BGP.

CONFIG-SET: BGP Prefix-List Examples

| ip prefix-list A permit 0.0.0.0/0 ge 32 - Matches all hosts routes | ip prefix-list B permit 0.0.0.0/1 ge 8 - Any subnets in Class A address space (/1: 1st bit(0) can't change) | ip prefix-list C permit 128.0.0.0/2 ge 16 - Any subnets in Class B address space (/2: 1st 2 bits(10) can't change) | ip prefix-list D permit 192.0.0.0/3 ge 24 - Any subnets in Class C address space (/3: 1st 3 bits(110) can't change) | ip prefix-list E permit 0.0.0.0/0 le 32 - Matches any/all routes | ip prefix-list F permit 0.0.0.0/0 - Matches just the default route | ip prefix-list G permit 0.0.0.0/1 le 24 - Matches any prefix in Class A address space with more than 256 addresses | ip prefix-list H permit 10.0.0.0/8 - Matches only a 10.0.0.0/8 route (no more, no less) | ip prefix-list I permit 10.0.0.0/8 le 32 - Matches any route in the RFC-1918 pvt 10/8 range (including 10.1.2.0/24) | ip prefix-list J permit 172.16.0.0/12 le 32 - Matches any route in the RFC-1918 pvt 172.16/12 range | ip prefix-list K permit 192.168.0.0/16 le 32 - Matches any route in the RFC-1918 pvt 192.168.0.0/16 range

IOS-COMMANDS

# sh ip as-path-access-list [filter-list] - Shows the configured filter lists # sh ip bgp filter-list {access-list-number} - Shows all routes permitted by the specified AS-path access-list # sh ip bgp regexp {expression} - Shows all routes matching regular-expression in one or all filter-lists # sh ip prefix-list {list}[det|sum][longer] - Shows the prefix-list and the sequence numbers # sh ip bgp prefix-list {list-name} - Shows all routes in the BGP table matching prefix-list

#ip as-path access-list {1-199} [permit/deny] {regex}

- Configures an AS-path filter list #ip prefix-list {name} [seq] [permit|deny] {prefix} [ge] [le]


TOC 88

- Configures a prefix-list, prefix matched exactly without [ge|le] - [ge] Means greater than AND equals to - [le] Means less than AND equals to

#router bgp {asn} #neighbor {ip} filter-list {as-path} [in|out] - Applies an AS-path filter list to the neighbor #neighbor {ip} prefix-list {list} [in|out] - Applies a prefix-list filter to the neighbor #neighbor {ip} distribute-list {acl} [in|out] - Applies a ACL distribute-list to the neighbor #distribute-list {acl} {in|out} [interface] - Filters redistributed routes using an ACL #distribute-list prefix-list {name} {in|out} [int] - Filters redistributed routes using a prefix list

RPL (Routing Policy Language) on IOS-XR

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing Routing Policy on Cisco IOS XR Software

- RPL is a new IOS-XR m echanism used to define routing policy much in the same way as route-maps, prefix-lis t and as -path fil ter lists does on IOS.

- RPL consists of two objects : > Policies > Sets

- Policies

> Route policy defin itions create named sequences of s tatements. > The s yntax s tructure of a route policy comprise of a series of s tatements and expressions that s tarts with a "route-policy" name and ends with "end-policy". > Each line of a policy configuration is a logical sub-uni t. > One policy m ay re fer to another policy by using the 'app ly' s tatement keyword. > The high-level s yntax is as fo llow:

route-policy {NAME} {STATEMENT}

end-policy > The simplest form of a s tatement involves a single action li ke 'pass' or 'se t', which is used to change basic route metrics /attr ibutes . > But a s tatement can be build using a hierarchy of conditional expressions that decides what action is applied when. > The expressions available are:

>> I f … (then) >> Else >> Elseif >> Endi f

> Some of the actions that can be applied are: >> Set >> Delete >> Pass >> Drop >> Prepend >> Apply

> S yntax example of a hierarchical route policy (m any di fferent layouts are possible).


TOC 89

route-policy {NAME} if {SET-TYPE} {CONDITION} {ELEMENTS|NAMED-SET} then

set {ATTRIBUTE} else

set {ATTRIBUTE} endif

end-policy

- Sets > Are s imply conta iners hold similar data, used in conditional expressions. > There are five di fferent types of sets:

>> As-Path-sets >> Communi ty-sets >> Extcommuni ty-sets >> Prefix-sets >> Rd-sets

> The elements of a set are separated by commas ','. > Em pty sets are not allowed and wil l be rejected. > There are two di fferent implementations of sets (both accomplishing the same outcome):

>> In l ine Sets >>> Refers to the elements being matched di rectly in the policy. >>> The s yntax format is a comma-separated l ist surrounded by parentheses:

(ELEMENT1, ELEMENT2, ..., ELEMENT5) >> Named Sets

>>> Refers to elements being grouped and called in a policy by nam e. >>> The s yntax format is

SET-TYPE {NAME} ELEMENT1, ELEMENT2, ...

ELEMENT5

- AS-Path-Set > Used for matching against the BGP AS-path attribute. > Uses IOS regex for expressions, indicated by the s yntax keyword 'ios-regex'


TOC 90

CONFIG-SET: RPL-Named Set: Matching Specific AS-Paths

| as-path-set ASP1 - Creates an AS-Path-Set | ios-regex '_100_', - Match an ASN that contains AS-100 | ios-regex '_200_' - Match an ASN that contains AS-200 | end-set | ! | route-policy MATCH-AS | if community matches-any ASP1 then - Function of 'OR' meaning either an ASN with | pass AS-100 or AS-200 will be matched | endif | end-policy

- Communi ty-Set > Used for matching against the s tandard BGP communi ty attribute. > The s tandard communi ty s tructure is two (16-b i t) decimal in tegers separated by a colon, e.g., 1234:789. > A wildcard (*) can be used to match any value for the portion i t is used in . > Wel l -known communi ties value names can also be used:

>> no-advertise - Do not advertise routes to any BGP peer (local to a router). >> no-export - Do not advertise routes to external eBGP peers (local to an AS). >> loca l-as - Do not advertise routes to any eBGP peers (local to a confed-AS). >> in ternet - Used to m atch all communi ties .

CONFIG-SET: RPL-Named Set: Matching Specific BGP Communities

| community-set CS-1 - Creates a Community-Set | 100:10, - Matches the community of 100:10 | 100:20 | end-set | ! | route-policy MATCH-COMM | if community matches-every CS-1 then - Function of 'AND' meaning both community values must be present | set local-preference 110 | endif | end-policy

CONFIG-SET: RPL-Inline Set: Matching Specific BGP Communities

| route-policy MATCH-COMM - Achieves exactly the same result as previous Config-Set | if community matches-every (100:10, 100:20) then | set local-preference 110 | endif | end-policy |


TOC 91

- Extcommuni ty-Set > Used for matching against the extended BGP communi ty attribute. > The extended communi ty s tructure is two (32-bi t) values separated by a colon, e.g., 100:10.5.0.10 > A wildcard (*) can be used to match any value for the portion i t is used in . > Wel l -known extended communi ty names can also be used:

>> SoO - Si te of Orig in >> RT - Route-Target

CONFIG-SET: RPL-Named Set: Matching Specific BGP Ext-Communities

| extcommunity-set CE-1 - Creates the extcommunity-set | RT:100:10.5.0.1, - Matches R1 (10.5.0.1) from AS-100 | RT:100:10.5.0.2, - Matches R2 (10.5.0.2) from AS-100 | RT:100:10.5.0.3 - Matches R2 (10.5.0.3) from AS-100 | end-set | | route-policy MATCH-EXT | if extcommunity rt matches-any CE-1 then - If the route matches any of the above values it will be forwarded | pass | endif | end-policy |

CONFIG-SET: RPL-Inline Set: Matching Specific BGP Ext-Communities

| route-policy MATCH-RT - Achieves exactly the same result as previous Config-Set | if extcommunity rt matches-any (RT:1234:10.5.0.1, RT:1234:10.5.0.2, RT:1234:10.5.0.3) then | pass | endif | end-policy |

- Prefix-Set

> Used for matching against the IPv4 or IPv6 prefixes . > S yntax s tructure is similar to prefix-lis ts on IOS: dotted-decimal -IP/mas k and optionally 'LE' or 'GE' operands. > The s yntax s tructure also supports om itting the mask, which is then assumed to be /32 for IPv4 or /128 for IPv6.


TOC 92

CONFIG-SET: RPL-Named Set: Matching Specific BGP Prefixes

| prefix-set PREFIX-1 | 10.5.0.0/8, - Matches only one possible value 10.5.0.0/8 | 172.16.5.1, - Matches either 172.16.5.1 or 172.16.5.1/32 | 192.168.0.0/16 le 32 - Matches any route in the RFC-1918 private 192.168.0.0/16 range | end-set | ! | route-policy MATCH-PREFIX | if rd in matches-any PREFIX-1 then - If the route matches any of the above values it will be forwarded | pass | endif | end-policy |

- RD-Set > Used for matching against RD (Route Distinguisher) elements . > An RD is a unique 64-bi t value used with MPLS VPN that is prepended to a non-unique 32-bi t IPv4 address to create a unique 96-b i t VPNv4 address. > A wildcard (*) can be used to match any value for the portion i t is used in .

CONFIG-SET: RPL-Named Set: Matching Specific RD values

| rd-set VRF-RD-1 | 100:10.5.0.1, | 100:10.5.0.2, | 200:* | end-set | ! | route-policy MATCH-RD | if rd in matches-any VRF-RD-1 then | pass | endif | end-policy |

Route Filtering on IOS-XR

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing BGP on Cisco IOS XR Software | | Routing Policy Enforcement - IOS-XR has addi tional securi ty enabled by defaul t for eBGP neighbors. - eBGP neighbors mus t have an inbound and outbound route-policy configured. - If no policy is configured, no routes are accepted from the eBGP neighbor, nor are any routes advertised to i t. - iBGP neighbors are exem pt from this , i .e ., IBGP wi ll accept and advertise routes i f no route policy is defined.


TOC 93

CONFIG-SET: RPL Example Filtering eBGP routes

| prefix-set DEFAULT - Creates a prefix-set matching a default route | 0.0.0.0/0 | end-set | prefix-set ALLOW - Creates a prefix-set to match all other routes | 0.0.0.0/0 le 32 | end-set | ! | route-policy PERMIT - Creates a route policy to permit all routes | pass - Sets default action to pass | end-policy | ! | route-policy LIMITED - Creates a route policy to allow all except a default route | if destination in DEFAULT then - Matches a received default route to be discarded | drop | elseif destination in ALLOW then | apply PERMIT - Allow all other routes received from the neighbors | else | drop | endif | end-policy | ! | router bgp 100 | address-family ipv4 unicast - Enables the IPv4 address globally for BGP | neighbor 150.0.0.2 - Specifies the eBGP neighbor | remote-as 300 | address-family ipv4 unicast - Enables the neighbor for IPv4 | route-policy LIMITED in - Accept all routes received from 150.0.0.2 | route-policy PERMIT out - Permit all routes advertised to 150.0.0.2 | neighbor 150.0.0.3 - Specifies the iBGP neighbor | remote-as 100 - No route-policies necessary | address-family ipv4 unicast - Enables the neighbor for IPv4 |

XR-COMMANDS

# sh rpl - Shows the global RPL configuration


#neighbor {ip} - Enters the BGP neighbor configuration mode #address-family ipv4 unicast - Enters the BGP IPv4 unicast configuration mode #route-policy {name} {in|out} - Applies the route-policy


TOC 94

Regular Expressions

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | Cisco IOS Terminal Services Configuration Guide, Release 12.4T | | Appendixes | | Regular Expressions

- A regular expression is a pattern used to match against an input s tring. - When a regular expression is parsed, the input mus t match the string specified.

- A regular expression comprises of: > A Range, which is a sequence of characters:

[] (Square Brackets) - Represents a range of characters.

> An Atom , which is single characters: | (Vertical Bar) - Represents 'OR' s tatements. \ (Backslash) - Matches an exact character. Removes any special meaning. () (Parenthesis) - Represents 'and ' operations . Used to group things together. . (Dot) - Matches any single character. ^ (Carrot) - Matches beginning of an input s tring. $ (Dollar) - Matches the end of an input string. _ (Underscore) - Matches any delimi ter (beginning, end, space, tab, comma).

> A Piece, which is a single character that applies repetition to the Atom /Character that immediately precedes i t: * (As terisk) - Matches ZERO or MORE Atoms. ? (Question Mark) - Matches ZERO or ONE Atoms. + (Plus) - Matches ONE or more Atoms.

> A Branch, which is 0 or more concatenated pieces.

- Examples using simple regular expressions: 123|456 - Matches a line with 123 or 456. [1-4 ] - Matches a line that contains a num ber between 1 and 4. [67] - Matches a line that contains a 6 or 7. [1-4] . [67] - Matches a line with 1/2/3/4, followed by any character, followed by 6/7, e.g., '136 ' or '417 '. ^21 - Matches a line only when i t s tart with 21. $31 - Matches a line only when i t ends with 31. _41_ - Matches a line that contains 41 in the beginning, middle or end. (123|456)_78 - Matches a line with 123 or 46 followed b y a del imi ter, followed by 78*, e.g., '123 789' or '123 78'. _23(_78)*_45_ - Matches a line that contains "23 45" or "23 78 45" or "23 78 78 78 78 45" etc. _23(_78)?_45_ - Matches a line that contains "23 45" or "23 78 45" only. _23(_78)+_45_ - Matches a line that contains "23 78 45" or "23 78 78 78 78 78 78 45" etc. ^ \(213_ - Matches a line that contains (213 at the beginning of line.

- In the case of BGP, the s tring specified consists of path in formation that an input mus t match. - Examples using regular expression to match BGP AS-paths:

_100_ - Passes/passed through AS 100. ^100$ - Directly connected to AS 100 (begins and ends in AS 100). _100$ - Originated in AS 100.


TOC 95

^100_ - Matches networks behind AS 100. ^[0-9]+$ - Matches any AS path that is one AS long. ^([0-9]+)(_\1)*$ - Networks originating in neighboring AS, with possible prependings. ^$ - Networks originating in LOCAL AS. .* - Matches everyth ing.

BGP Conditional Route Advertisement

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: BGP Configuration Guide, Cisco IOS Release 12.4T | | Configuring a Basic BGP Network | | Aggregating Route Prefixes Using BGP

- Assume the following topology: Figure 5-1 : BGP Conditional Route Advertisement

- AS-300 wants ALL traffic to prefix-A to enter from AS-200 only, but in the event of l ink failure betweenAS-200 and AS-300, tra ffic should be allowed to enter from AS-100. - AS-100 has a weight set, preferring i ts direct l ink to AS-300 for all prefixes. - Assuming AS-100 is not co-operating in removing the weight value set, what can be done to meet the criteria?

- BGP conditional route advertisement offers an al ternative way to affect how tra ffic enters an AS. - By condi tional ly not advertising prefix-A to AS-100, AS-100 is forced to route via AS-200. - Then, in the event of a link fa ilure, conditional advertisement will advertise prefix-A to AS-100.

- By controlling which prefixes get advertised to which neighbors , traffic can be forced to enter on the appropria te links . - BGP conditional route advertisement consists of two parts :

> The prefix/s to watch (L INK-300-200). > The prefix/s to advertise (PREFIX-A).

!!NOTE!! Confi rm the above prefixes are in the BGP table before configuring conditional route advertisement.

- Once the prefix (L INK-300-200) leaves the BGP table, the prefix (PREFIX-A) wi ll be advertised to AS-100 (100.1.1.1)


TOC 96

CONFIG-SET: BGP Conditional Route Advertisement

| ip prefix-list PREFIX-A permit 30.0.0.0/24 - Matches the advertised prefix | ip prefix-list LINK-300-200 permit 30.20.1.0/30 - Matches the watched prefix | ! | route-map ADV permit | match ip address prefix-list PREFIX-A - References the advertised prefix | ! | route-map WATCH permit | match ip address prefix-list LINK-300-200 - References the watched prefix | ! | router bgp 300 | neighbor 100.1.1.1 remote-as 100 | neighbor 100.1.1.1 advertise-map ADV non-exist-map WATCH | - Applies conditional route advertisement for AS-100 | > # sh ip bgp neighbors 100.1.1.1 | i Condition - A positive, the WATCH route is DOWN > Condition-map WATCH, Advertise-map ADV, status: Advertise > - Prefix is advertised > > # sh ip bgp neighbors 100.1.1.1 | i Condition - A negative, the WATCH route is UP > Condition-map WATCH, Advertise-map ADV, status: Withdraw > - Prefix is not advertised >

IOS-COMMANDS

# sh ip bgp neighbors {ip}| i Condition - Shows the condition status of the advertised route

#router bgp {asn}

#neighbor {ip} advertise-map {route-map} non-exist-map {route-map} - Conditionally advertises a route to neighbors based on the existence of

another - {adv-map}: This is the route to be advertised based on - {non-exist-map}: Routes that will be tracked

BGP Conditional Route Injection

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: BGP Configuration Guide, Cisco IOS Release 12.4T | | Configuring a Basic BGP Network | | Originating BGP Routes

- Provides a method to orig inate a prefix in to the BGP routing tab le without the corresponding m atch in the IGP table. - Only prefixes that are equal to or m ore specific than the original prefix may be injected. - This is used to improve the accuracy of route aggregation, by condi tionally injecting or replacing less specific prefixes with more specific prefixes.


TOC 97

CONFIG-SET: BGP Conditional Route Injection

| ip prefix-list ROUTE permit 10.1.1.0/24 - The route to be monitored | ! | ip prefix-list ROUTE_SOURCE permit 10.2.1.1/32 - The advertising source | ! | ip prefix-list ORIGINATE_ROUTES permit 10.1.1.0/25 - The more specific routes to be injected | ip prefix-list ORIGINATE_ROUTES permit 10.1.1.128/25- The more specific routes to be injected | ! | route-map LEARNED_PATH permit 10 | match ip address prefix-list ROUTE - Watches the monitored prefix in the RIB | match ip route-source prefix-list ROUTE_SOURCE - Matches the prefix learned from a specific source | ! | route-map ORIGINATE permit 10 | set ip address prefix-list ORIGINATE_ROUTES - Identifies the specifics to inject | set community 14616:555 additive - Sets optional parameters | ! | router bgp 3741 | bgp inject-map ORIGINATE exist-map LEARNED_PATH - Applies conditional route injection |

IOS-COMMANDS

#router bgp {asn} #bgp inject-map {map} exist-map {map} [copy-attr] - inject-map: Defines the prefixes that will be created and installed into the

local BGP table - exist-map: Specifies the prefix which the BGP speaker will track - copy-attr: Config the injected route to inherit the attributes from the

tracked route

Clearing BGP Sessions

- The Cisco IOS software command s ummary lists the following circumstances when a BGP connection should be reset: > Addi tions or changes to BGP-related access lis ts. > Changes to BGP-related weights /attributes. > Changes to BGP-related dis tribution-lis ts. > Changes to BGP-related timers . > Changes to the BGP administra tive distance. > Changes to BGP-related route-maps.

- Hard Reset of BGP Sessions > Com pletely tears down the BGP session and rebuilds the sessions (in terruptive in production). > A new session should be re-established with in 30-60 sec depending on the am ount of routes. > If dampening is enabled a hard reset wil l resul t in a penal ty. > Processing the full In ternet table after a hard reset can take a long time, so be careful with this in production.


TOC 98

- Soft Reconfiguration > Outbound soft reconfiguration resends the complete BGP tab le . It is not configurable and is always enabled. > Inbound soft reconfiguration stores a complete copy of the BGP table from a neighbor in router mem ory (possibly resource dem anding). > Inbound soft reconfiguration m ust be enabled i f needed.

- Route Refresh (Soft Reset) > Used to request a neighbor to resend routing in fo . Useful after config changes to update the BGP table . > Route-refresh-capabili ty is negotia ted upon BGP peer session establishment. > Is also used with ORF when inbound prefix-l ist route re fresh is required (see ORF Section).

- BGP Dynamic Update Peer-Group Feature > Used to recalculate all BGP update-group member sessions.

IOS-COMMANDS

>>> Hard-Reset <<< # clear ip bgp {*|ip|peer-group name} - Tears the BGP session down completely and re-establishes it again

#router bgp {asn} >>> Soft Reconfiguration <<<

#neighbor {ip} soft-reconfig [inbound] - Enables inbound soft reconfiguration on the router, so that all the routes are stored in memory before filters are applied.

# clear ip bgp {ip} soft in - This takes all the routes in memory, reapplies the filters, before

implementing the passed routes into BGP table. # clear ip bgp {ip} soft out - This will resend the BGP table to a neighbor, for that neighbor to re-apply

all his configured inbound filters

>>> Route Refresh <<<

# clear ip bgp {*|ip|peer-group name} in - Requests a neighbor to resend routing information without terminating the session

# clear ip bgp update-group [index-group][peer] - Used to recalculate all BGP update-group member sessions

XR-COMMANDS

# clear bgp {ip|all} - Hard-reset the BGP session down completely and re-establishes it again # clear bgp {ipv4|vpnv4} unicast {ip|*} - Hard-reset the BGP session for the address-family # clear bgp {ipv4|vpnv4} unicast {ip} soft [in|out] - Soft-reset the BGP neighbor session for the address-family

# clear bgp {ipv4|vpnv4} unicast self-originated - Resends locally originated routes.


TOC 99

ORF (Outbound Route Filtering)

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: BGP Configuration Guide, Cisco IOS Release 12.4T | | Connecting to a Service Provider Using External BGP | | Influencing Outbound Path Selection

- The purpose of outbound route fil tering is to reduce the amount of BGP tra ffic and CPU use needed to process routing updates. - With ORF routers exchange inbound fi l ter configurations , which are then used as outbound fil ters on neighboring routers . - ORF entries are part of the route refresh message. - Negotia tion of prefix-lis t ORF capabili ty is done during the BGP session setup.

> The side that has the prefix-lis t uses the 'send' option, and is configured with the prefix-l ist inbound. > The side that sends the routes uses the 'receive' option. > ORF requi res the session to be reset after configuration.

- Inbound route re fresh is requi red, and only the inbound prefix-lis t fil ter is pushed to the neighbor and used by that neighbor the outbound di rection. - An ORF-capable BGP speaker will instal l ORFs per neighbor.

CONFIG-SET: ORF Example on IOS-XR

| route-policy ORF | if orf prefix in (150.5.0.0/22 le 24) then - Matches 150.5.0.0 prefixes with prefix lengths between 22 and 24 | pass | endif | end-policy | ! | router bgp 100 | neighbor 150.1.1.2 - Neighbor in AS-500 | remote-as 500 | address-family ipv4 unicast | route-policy PASS-ALL out - Recall eBGP peer routes must be explicitly allowed | capability orf prefix both - Enables ORF capability negotiation in both directions | orf route-policy ORF - Specifies the prefixes send to the ORF neighbor |

IOS-COMMANDS

# sh ip bgp neighbor - Useful to verify neighbor capabilities # clear ip bgp {ip} in [prefix-filter] - Triggers a route refresh from ORF receivers

- [prefix-filter] Refreshes the remote filter

#router bgp {asn}

#neighbor {ip} capability orf prefix-list {send|receive|both} - Enables negotiation of prefix-list ORF capability

#neighbor {ip} prefix-list {name} in - Specifies the prefix that will be send to the ORF capable neighbor


TOC 100

XR-COMMANDS

#router bgp {asn} - Enters the BGP configuration mode #neighbor {ip} - Enters the BGP neighbor configuration mode #address-family ipv4 unicast - Enters the BGP IPv4 unicast configuration mode #capability orf prefix {send|receive|both} - Enables negotiation of prefix-list ORF capability #orf route-policy {NAME}

BGP Network Migration

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: BGP Configuration Guide, Cisco IOS Release 12.4T | | Configuring Advanced BGP Features

- The "loca l-as " command is useful in manipulating the BGP AS-Path when one AS should to appear be using a di fferent ASN to a neighboring AS. - The best case s tudy for this when two AS's should m erge with least am ount of impact while al lowing for the migration.

IOS-COMMANDS

#router bgp {asn} #neighbor {ip} local-as {asn} [no-prepend [replace-as] [dual-as]]]

- Hide local-AS feature is necessary to connecting to different ISPs with more than one ASN number

- [no-prepend] Does not prepend the "local" ASN to any routes received - [replace-as] Prepends only the "local" ASN in the AS-path. The configured ASN

from the BGP process is not prepended - [dual-as] Configures the eBGP neighbor to establish peering session with

either real ASN or both #neighbor {ip} remove-private-as - Private AS numbers are only removed from the tail-end (left-side) of the AS-

path before the update is sent - Private AS numbers followed by a public AS numbers are not removed

XR-COMMANDS

#router bgp {asn} - Enters the BGP configuration mode #neighbor {ip} - Enters the BGP neighbor configuration mode #local-as {asn} [no-prepend[replace-as][dual-as]]] - Hide local-AS feature is necessary to connecting to different ISPs with more

than one ASN number - [no-prepend] Does not prepend the "local" ASN to any routes received - [replace-as] Prepends only the "local" ASN in the AS-path. The configured ASN

from the BGP process is not prepended - [dual-as] Configures the eBGP neighbor to establish peering session with

either real ASN or both #address-family ipv4 unicast - Enters the BGP IPv4 unicast configuration mode #remove-private-as - Private AS numbers are only removed from the tail-end (left-side) of the AS-

path before the update is sent Copyright © 2013 Routing-Bits.com

TOC 101

BGP Route-Dampening

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: BGP Configuration Guide, Cisco IOS Release 12.4T | | Configuring Advanced BGP Features | | Configuring BGP Route Dampening

- Designed to reduce router-processing load caused by uns table routes.

- Each tim e an eBGP route flaps, i t gets 1000 penal ty points (th is cannot be configured or changed). - iBGP routes are not dampened. - The penal ty placed on a route decays according to the exponential decay algori thm . - When the penal ty exceeds the suppress lim i t, the route is dampened (no longer used or propagated to other neighbors). - A dampened route is propagated again when the penal ty drops below the reuse l imi t. - A route is never dampened for more time than the maximum suppress limi t. - An unreachable route with a flap his tory is put in the history s tate. It stays in the BGP tab le but only to maintain the flap his tory (marked with 'h' in the BGP table). - A penal ty is applied on the individual path in the BGP table , not on the IP prefix. - Using "clear ip bgp *" is regarded as a flap to neighbors, which could cause that path to be suppressed i f executed multiple times . - Using "clear ip bgp * [s oft] in" is NOT regarded as a flap to neighbors .

IOS-COMMANDS

# sh ip bgp dampened-paths - Shows the dampened routes # sh ip bgp flap-stat [regexp|filter-list|ip] - Shows flap statistics for all routes with dampening history

# clear ip bgp {ip} flap-stat [regexp|filter-list|prefix]

- Clears the flap statistics but does not release dampened routes # clear ip bgp dampening [prefix] - Releases all the dampened routes or just the specified network

- Flap statistics also cleared when the BGP session with the neighbor is lost # debug ip bgp dampening - Shows the BGP dampening events

#route-map name - Route-map to configure dampening for specifics routes only

#match ip address {acl} #set dampening [half-life][reuse][suppress][max-suppress-time]

#router bgp {asn}

#bgp dampening [half-life][reuse][suppress][max-suppress-time] [route-map name] - [half-life] Decay time in which the penalty is halved (Def = 15min) - [suppress] The value at which a route is dampened (Def = 2000) - [reuse] The value when the dampened route is reused (Def = 750) - [max-suppress-time] Maximum time to suppress the route (Def = 60Min) - [route-map] Using route-map to dampen specific routes - Specified without a route-map applies to all routes

XR-COMMANDS

# sh bgp dampened-paths - Shows the dampened routes Copyright © 2013 Routing-Bits.com

TOC 102

# sh bgp flap-stat [regexp|ip] - Shows flap statistics for all routes with dampening history # clear bgp flap-statistics[regexp|ip] - Clears the flap statistics but does not release dampened routes # clear bgp dampening [prefix] - Releases all the dampened routes or just the specified network

- Flap statistics also cleared when the BGP session with the neighbor is lost


#address-family ipv4 unicast - Enters the BGP IPv4 unicast configuration mode #bgp dampening [half-life][reuse][suppress][max-suppress-time] [route-policy]

- [half-life] Decay time in which the penalty is halved (Def = 15min) - [suppress] The value at which a route is dampened (Def = 2000) - [reuse] The value when the dampened route is reused (Def = 750) - [max-suppress-time] Maximum time to suppress the route (Def = 60Min) - [route-policy] Using route-map to dampen specific routes - Specified without a route-map applies to all routes

Peer-Groups on IOS

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: BGP Configuration Guide, Cisco IOS Release 12.4T | | Configuring a Basic BGP Network | | BGP Peer Groups

- Benefits of using Peer-Groups

> Reduce the amount of s ys tem resources (CPU and mem ory) necessary in the update generation. > Mostly used to simpli fy large repeating BGP configurations .

- Individual parameters specified in a peer group can be overridden or removed on a neighbor-by-neighbor basis. - Configurable parameters include the fol lowing:

> Communi ty propagation. > Source in terface for TCP session. > eBGP m ultihop sessions. > MD5 password. > Neighbor weight. > Fi l ter-lis ts and dis tribute -l ists . > Route-maps.

IOS-COMMANDS

# sh ip bgp replication - Shows the replication statistics of BGP update-groups # sh ip bgp update-group [group|summary] - Shows the specific neighbors in an update-group # sh ip bgp peer-group [peer-group-name] - Shows the specified peer group or all peer groups # sh ip bgp peer-group [peer-group-name] summary - Shows summary status of all neighbors in the peer group # clear ip bgp [peer-group-name] [[soft] in|out] - Clears BGP session with all peer group members # debug ip bgp groups [index-group] [peer-ip] - Shows info about peer-group update-group calculation, the additions and the

removals of members peer-policy, and peer-session templates


TOC 103

#router bgp {asn} #neighbor {group-name} peer-group - Creates a BGP peer group

- Peer group names are case-sensitive #neighbor {group-name} {any-bgp-parameter} - Specifies any BGP parameter for the peer group #neighbor {ip} peer-group {group-name} - Assigns a BGP neighbor to a peer group, inheriting the peer-group parameters #neighbor {ip} {any-bgp-parameter} - Overrides the BGP parameter specified for the peer group #no neighbor {ip} {any-bgp-parameter} - Removes the BGP parameter specified for the peer group

BGP Update Groups on IOS-XR

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing BGP on Cisco IOS XR Software | | Update Groups

- Peer-groups are not available on IOS-XR.

- Ins tead the functionali ty was replaced with BGP update groups on IOS-XR. - Update group dynamical ly calculates BGP update group membership based on common outbound routing policies. - Update groups do not require any configuration. It is enabled defaul t. - When a change to the configuration occurs, the router automatically recalculates update group memberships and applies the changes.

XR-COMMANDS

# sh bgp update-group [index|neighbor|standby] - Shows the specific neighbors in an update-group

Fast External Fallover

- Fast external fallover for external peers is triggered by a session flap, based upon the receipt of an in terface change noti fication. - By defaul t, when a local BGP interfaces goes down, the BGP neighbors on that in terface are shutdown as soon as an interface reset is detected, instead of wai ting for the

holddown tim er (defaul t = 180 sec) to expi re. - If BGP fas t external fal lover is disabled BGP will wai t for the holddown tim er to expi re before s hutting down the neighbor sessions.

IOS-COMMANDS

#router bgp {asn} >>> Global Configuration <<< #no bgp fast-external-fallover - Disables fast external fallover globally. Will wait for hold-time to expire

#interface {int} >>> Interface Configuration <<<

#ip bgp fast-external-fallover permit - Allows per-interface fast external fallover #ip bgp fast-external-fallover deny - Prevents per-interface fast external fallover #no ip bgp fast-external-fallover - ONLY removes previously interface config, doesn't disable fall-over

XR-COMMANDS #router bgp {asn} - Enters the BGP configuration mode


TOC 104

#bgp fast-external-fallover disable - Disables fast external fallover globally. Will wait for hold-time to expire

BGP Fast Peering Session Deactivation

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: BGP Configuration Guide, Cisco IOS Release 12.4T | | Configuring BGP Neighbor Session Options | | BGP Fast Peering Session Deactivation

- Fast peering enables BGP to moni tor the peering session of a specified neighbor for adjacency changes to deactivate that peering session. - BGP fas t peering session deactivation is event driven and is configured on a per-neighbor basis. - Adjacency changes are detected and terminated peering sessions are deactivated in between the BGP scanning in tervals . - A route-map can be used to deactivate the peering session based a specific prefix. - Only the "match ip address" and "match source-protocol " commands are s upported in fas t peering route-maps .

CONFIG-SET: BGP fast peering session fall-over

| ip prefix-list FILTER28 seq 5 permit 0.0.0.0/0 ge 28 | ! - Matches any route with a prefix of /28 or more specific prefixes | route-map CHECK-NBR permit 10 | match ip address prefix-list FILTER28 - References the filter | ! | router bgp 100 | neighbor 10.5.123.1 remote-as 200 | neighbor 10.5.123.1 fall-over route-map CHECK-NBR - Resets the session if a /28 or more specific prefix disappears

IOS-COMMANDS

#router bgp {asn} #neighbor {ip} fall-over [bfd | route-map] - Enables BGP fast peering session fall-over

Support for Next-Hop Address Tracking

- This is enabled by defaul t when a supporting Cisco IOS software image is installed. - BGP prefixes are automatically tracked as peering sessions are established. - Next-hop changes are rap idly reported to the BGP routing process as they are updated in the Routing In formation Base (RIB). - This optimization improves overall BGP convergence by reducing the response time to next-hop changes for routes installed in the RIB. When a bes t-path calculation is run

in between BGP scanner cycles, only next-hop changes are tracked and processed.

IOS-COMMANDS

#router bgp {asn} #no bgp nexthop trigger enable - Disables next-hop tracking (enabled by default)


TOC 105

Maximum-Prefix

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: BGP Configuration Guide, Cisco IOS Release 12.4T | | Configuring BGP Neighbor Session Options | | BGP Neighbor Session Restart After the Max-Prefix Limit Is Reached

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing BGP on Cisco IOS XR Software | | BGP Default Limits

- This feature configures a m axim um num ber of prefixes that a BGP router is allowed to receive from a neighbor.

- With options specified, when the number of received prefixes exceeds the maxim um number configured, the peering session is terminated. - This behavior can be changed by including the 'warn ing-only' keyword.

IOS-COMMANDS

#router bgp {asn} - Enters the BGP configuration mode #neighbor {ip} maximum-prefix {max no} [threshold] [warning-only] [restart {interval}]

- Controls how many prefixes can be received from a neighbor - [Threshold] The percentage when message is logged (default is 75%) - [Warning-only]Generates a log message when exceeded, does not drop session - [Restart] Re-establish the session after the specified interval in minutes

XR-COMMANDS

#router bgp {asn} - Enters the BGP configuration mode #neighbor {ip} - Enters the BGP neighbor configuration mode #address-family ipv4 unicast - Enters the BGP IPV4 unicast configuration mode #maximum-prefix {max no} [threshold] [warning-only] [restart {interval}]

- Controls how many prefixes can be received from a neighbor - [Threshold] The percentage when message is logged (default is 75%) - [Warning-only] Generates a log message when exceeded, does not drop session - [Restart] Re-establish the session after the specified interval in minutes

Suppress BGP Advertisements for Inactive Routes

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: BGP Configuration Guide, Cisco IOS Release 12.4T | | Configuring a Basic BGP Network | | Aggregating Route Prefixes Using BGP

- Suppresses BGP advertising of inactive routes. Defaul t is to advertise the inactive routes . - Inactive routes are BGP routes not inserted in to the RIB due to another protocol's route with a lower AD being chosen. - Inactive routes are seen in the BGP table marked with 'rib -fa ilure '.


TOC 106

IOS-COMMANDS

# sh ip bgp rib-failure - Shows the BGP routes not installed into the RIB

#router bgp {asn}

#address-family ipv4 unicast #bgp suppress-inactive - Suppresses BGP advertising of inactive routes


TOC 107

Troubleshooting BGP

BGP Session Start-Up Problems - Are you seeing the expected neighbor in a NON 'idle ' or 'active ' state? # sh ip bgp summary - Is a sourced te lnet to the neighbor address working? # te lnet {peer-ip} 179 /source {s rc-in t-ip} - Confirm i f the config is correct and matching the neighbor's configuration? # sh run | b router bgp

- If eBGP, is the neighbor di rectly connected (Should be one hop in the trace)? # trace {peer-ip} source {s rc-in t-ip} > If not di rectly connected is multi -hop configured? # sh run | i {peer-ip}.*ebgp-mul tihop

- Is there IP reachabili ty to the neighbor? # ping {peer-ip} source {s rc-in t-ip} - Is the underlying routing in place between neighbors? # sh ip route {peer-ip}

- If the obvious checks don't help, enable debugging to analyze the session setup # debug ip tcp transactions or # sh tcp brie f > If the TCP-SYN packet is not answered with a SYN-ACK packet and times out?

>> Look for ACLs blocking port TCP-179. # sh ip in terface | i line |lis t

> If the TCP-SYN packet is answered with a RST packet, i t veri fies reachabili ty, but the neighbor is not willing to grant the connection attem pt. >> Does the neighbor have BGP configured or BGP "neighbor shutdown"? # sh run | i {peer-ip}.*s hutdown >> Does the outgoing interface IP m atch the peer's "neighbor" s tatement? # sh run | i neighbor.* {peer-ip} >> I f not, is the correct source in terface specified? # sh run | i {peer-ip}.*update-s ource

> If the 3-way TCP handshake completes but the router drops the session shortly after causing the neighbor to oscillate between idle and active, check the BGP parameters .

>> Confirm that the AS numbers between the neighbors are correct. # sh run | i router bgp|remote-as >> I f using confederations, double check the AS numbers . # sh run | i router bgp|remote-as >> Is MD5 password authentication configured correctly? # sh run | i neighbor.*password

> Are any TCP session s tuck in the TCP handshake? # sh tcp brie f >> Clear the TCP session. # clear tcp tcb {num ber}

Route Selection Issues - Are locally originated routes appearing in the BGP table? # sh ip bgp

> If auto-summary is enabled, is at least one subnet of the major network # sh run | i router bgp|summary present in the RIB? # sh ip route {prefi x} longer-prefixes

> If auto-summary is disabled, is there an exact prefix match in the RIB? # sh ip route | i {prefi x} /{m as k} > Is a dis tribute-lis t configured blocking the prefixes? # sh run | i distribute -l ist

- Is an aggregate is configured but not advertised? # sh run | i aggregate > Is there a more specific prefix of the aggregate in the BGP table? # sh ip bgp {prefi x}/ {m as k} longer-prefixes

- Is a prefix in the BGP table not getting advertised to a iBGP neighbor? # sh ip bgp {prefi x} (YIELDS NO RESULT) > Was the prefix learned via iBGP? BGP spli t horizon (Look for 'i ' routes)? # sh ip bgp {prefi x} | i _i |>i

- Are you receiving any prefixes from the neighbor (look at 'PfxRcd')? # sh ip bgp summary | i {peer-ip} > Is the neighbor sending any routes (this done on neighbor)? # sh ip bgp neighbor {peer-ip} advertised-route


TOC 108

> Are the prefixes showing BEFORE any fil ters are applied (need "soft-reconfig")? # sh ip bgp neighbor {peer-ip} received-routes > Are the prefixes showing AFTER the fil ters were applied? # sh ip bgp neighbor {peer-ip} routes

>> I f not, are any prefix-fi l ters configured denying the prefixes? # sh run | i {peer-ip}.*prefix-l is t >> I f not, are any AS-path fil ters configured denying the prefixes? # sh run | i {peer-ip}.* fi l ter- lis t >> I f a route-map is configured: # sh run | i {peer-ip}.* route -m ap

>>> The routes mus t be explici tly permi tted to be accepted/used. # sh route-map {name} >>> Are the prefixes explici tly denied? # sh route-map {name}

> Was the BGP session cleared after changes to fil ters and route-maps? # clear ip bgp * in (DO ON BOTH SIDES) > A useful debug to see routes entered and removed from the BGP table is : # debug ip bgp updates

- The prefix is in the BGP tab le , but not in the RIB # sh ip bgp | i {prefi x} > Is the BGP next-hop reachable? # sh ip route {bgp-next-hop} > Is the prefix selected as the best route (indicated with '>')? # sh ip bgp | i {prefi x}

>> I f not, veri fy the BGP attributes are correct. # sh ip bgp {prefi x}

> If a prefix is selected as best, but not entered in to RIB? >> Could be caused by a synchronization issue! # sh run | i ^no s ynch

> If the prefix is l isted in the BGP with the options : >> 'r ' means a lower admin distance route is used and entered in the RIB. # sh ip bgp | i ^r.*{prefix} >>'s ' means specific routes suppressed by aggregation are not advertised. # sh ip bgp | i ^s .* { pre fi x} >>'S ' means stale routes marked during a graceful res tart is not advertised. # sh ip bgp | i ^S .*{ pre fi x} >> 'd ' means the route is dampened, due to flapping viola tions. # sh ip bgp | i ^d.*{prefix}

- Are any communi ties attached to the prefix causing problems? # sh ip bgp {prefi x} | i entry|Communi ty - Are the expected communi ties being received? Sending communi ties enabled? # sh run | i neighbor.*s end-communi ty

IOS BGP Errors %BGP-3-NOTIFICATION: received from neighbor 150.1.1.1 2/2 (peer in wrong AS) 2 bytes 0064

>> Local router is expecting neighbor 150.1.1.1 to come from a di fferent AS to the configured AS-100 >> 2 bytes 0064: The 0064 is the received ASN in HEX, i .e . 0x0064 = 100 decimal

%BGP-4-MAXPFX: No. of unicast prefix received from ... - Approaching the max-prefix l imi t %BGP-3-MAXPFXEXCEED: No. of unicast prefix received from ... - When the max-prefix limi t for a neighbor is reached %TCP-6-BADAUTH: Inva l id MD5 diges t from ... - MD5 password m ismatch, check for whi te spaces


TOC 109

Bibliography


RFC-4271 A Border Gateway Protocol 4 (BGP-4) http ://www.ie tf.org/rfc/rfc4271.txt

RFC-6286 Autonomous-Sys tem-Wide Unique BGP Identi fier for BGP-4 http ://www.ie tf.org/rfc/rfc6286.txt

RFC-1997 BGP Communi ties Attribute http ://www.ie tf.org/rfc/rfc1997.txt

RFC-2858 Multiprotocol Extensions for BGP-4 http ://www.ie tf.org/rfc/rfc2858.txt

RFC-3107 Carrying Label In formation in BGP-4 http ://www.ie tf.org/rfc/rfc2858.txt


TOC 110



TOC 111

Chapter 6

MPLS


TOC 112

MPLS Overview

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | Multiprotocol Label Switching Configuration Guide, Cisco IOS Release 12.4T | | MPLS: Basic MPLS Configuration Guide, Cisco IOS Release 12.4T | | Multiprotocol Label Switching Overview

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | MPLS Configuration Guide | | Implementing MPLS Label Distribution Protocol

- MPLS was defined in RFC-3031. - Conventional IP routing forwards packets based on the destination IP address. - MPLS (Mul tiprotocol Label Switching) is a highly scalable, protocol agnostic, data-carrying mechanism where data packets are assigned labels. - Packet-forward ing decisions are made solely on the contents of these labels, without the need to examine the packet i tsel f. - CEF m us t be enabled on all MPLS routers and all MPLS interfaces.

- MPLS Terminology > LSR- Label Switch Router, is a router that forwards packets based on labels. > Edge-LSR - LSR located on the edge of a MPLS network, processes both labeled and unlabeled packets. > Ingress E-LSR - Router that receives an unlabeled packet and inserts one or more labels before the IP header. > Egress E-LSR - Router that receives a labeled packet, removes all the labels and forwards i t unlabeled. > CE Router - Customer Edge Router, a non-MPLS cl ient/si te router connected to the MPLS domain. > Label - A 4-byte identi fier used by MPLS to make forwarding decisions. > Label Binding - The mapping of a label to an FEC. > FEC - A group of packets forwarded in the same manner, over the same path or with the same forward ing treatm ent. > LSP - Label Switch Path, a series of LSRs that forward labeled packets to the ir destinations based on the FEC. > PHP - Penul timate-Hop-Popping is the act of popping/removing a label one hop before the Egress LSR/PE router.

- MPLS Components > CP (Control Plane)

>> Describes a part of a router's archi tecture that is responsible for collecting and propagating the in formation that is used to forward tra ffic. >> Uses the configured routing protocols to build a routing table called the RIB. >> Uses a label exchange protocol to maintain all labels in a table called the LIB. >> Provides specific in formation from the RIB and LIB tables to the Forwarding Plane. >> That in formation is used to bui ld the FIB and the LFIB tables .

> FP (Forward ing Plane) >> Describes a part of the router's archi tecture that is used to decide how a packet wi ll be forwarded once received on an inbound in terface. >> Consists of two tables. >> The FIB and LFIB tables are responsible for forwarding incoming packets based on ei ther the IP address (unlabeled) or the top label of the packet. >> The label functions (impose/push/insert, swap or dispose/pop/remove) happens in the FP.

> RIB (Routing In formation Base) >> Another name for the tradi tional IP routing table . >> Seen with "show ip route". >> Table s tructure is: PROTOCOL, PREFIX, NEXT-HOP.


TOC 113

> LIB (Label In formation Base) >> A label exchange protocol binds locally signi ficant labels to routes in the RIB. >> A label exchange protocol also exchange these label bindings among neighboring LSRs. >> A label exchange protocol stores local and received label bindings in the LIB tab le . >> The label exchange protocols are LDP, TDP, MP-BGP and RSVP. >> LDP and TDP are very similar protocols. LDP provides some addi tional features and is m ore widely used today. >> LDP/TDP labels are ONLY assigned to non-BGP routes in the RIB tab le . >> MP-BGP is used to dis tribute the label bindings for BGP routes in the RIB. >> RSVP is used to distribute the label bindings for TE (Traffic Engineering). >> The LIB tab le is seen with "show mpls ldp binding" or "show mpls ip bindings". >> The LIB tab le s tructure is : PREFIX, LSR/LOCAL, LABEL.

> FIB (Forwarding In formation Base) >> A CEF buil t table sourced from the in formation in the RIB table and then used to forward incoming IP packets. >> An arriving IP packet is forwarded unlabeled (as an IP packet) i f no label for the destination route exists. >> An arriving IP packet is forwarded labeled i f a next-hop label is available for the des tination route. >> The FIB table is seen with "show ip cef detail ". >> The FIB table s tructure is : PREFIX, NEXT-HOP, LABEL.

> LFIB (Label Forward ing In formation Base) >> A CEF buil t label table sourced from the in formation in the LIB. >> The LFIB table ONLY stores the labels used to forward packets , unlike the LIB table that stores ALL label bindings. >> The 'incoming label' is the 'local label ' that is advertised to adjacent LSRs. >> The 'outgoing label' is the received 'local label' from the next-hop LSR to a des tination. >> The LFIB table is seen with "show mpls forward ing table". >> The LFIB table structure is : INLABEL, OUTLABEL, NEXT-HOP.

IOS-COMMANDS

# sh ip route - Shows the RIB table # sh ip cef [detail] - Shows the FIB table # sh mpls ldp bindings - Shows the LIB table # sh mpls ip bindings - Shows the LIB table # sh mpls forwarding-table - Shows the LFIB table

#ip cef - Enables CEF which is a pre-requisite (default=enabled on most IOS versions)

#mpls label protocol [ldp|tdp|both] - Selects a label distribution protocol to be used globally #mpls ldp router-id {int} [force] - Configures the LDP router-ID (interface must be up state to be used)

- [force]: Forcibly changes the router-ID before a reload #interface {int} #mpls ip - Enables LDP on the interface

XR-COMMANDS

# sh route - Shows the RIB table # sh cef [detail] - Shows the FIB table # sh mpls ldp bindings - Shows the LIB table # sh mpls forwarding-table - Shows the LFIB table


TOC 114

#mpls ldp - Enters the MPLS configuration mode #router-id {int} - Specifies the MPLS router identifier #interface {int} - Activate MPLS LDP on the interface

MPLS Operations

- Layer2 frames have an NLPID (Network Layer Protocol Identi fier) field to indicate what the layer3 payload is. - An MPLS label, often called a SHIM header, is inserted between the layer2 and layer3 headers. - As a resul t, a router mus t change the layer2 NLPID or Ethertype to indicate that the packet is an MPLS-labeled packet and not a usual layer3 packet.

- MPLS Label Structure > Labels are 4-byte identi fiers used for forwarding decisions. > Each MPLS label is 4-bytes /32-b i ts and has the fol lowing structure:

Figure 6-1: MPLS Label Format

> 20-b i t label - Actual label value (labels 0 to 15 are reserved). > 3-b i t experimental field - Used to define a class of service. RFC-5462 renamed th is to TC (Traffic Class). > 1-b i t bottom-of-s tack - Indicates the last label in the label-s tack (1=true, 0=fa lse). > 8-b i t TTL - MPLS label TTL is used to prevent loops.

- Label TTL

> By default, on MPLS label imposi tion, the IP TTL is decremented and propagated/copied to the label TTL for loop prevention. > At every hop in the MPLS network, only the top label's TTL is decremented. > The underlying labels and the IP packet's TTL are le ft unchanged. > If the top label is swapped, the TTL from the arriving top label is decremented before copied to the swapped label. > If the top label in a label stack is popped, the TTL from the top label is propagated/copied to the next exposed label. > If an additional label is imposed, the TTL from the arriving top label is decremented and copied to the swapped label's TTL as wel l as the newly-added top label's TTL. > At MPLS label disposition the top label's TTL is copied to the IP TTL, but ONLY i f the label TTL < IP TTL.

- TTL Propagation > Disabling TTL propagation can be used to hide core LSRs in an MPLS backbone. > TTL propagation is enabled by defaul t. > If disabled, the ingress label TTL is set to 255 on MPLS label imposi tion. > If fu l ly disabled, the core LSRs wi ll not show up in a traceroute done from a edge-LSR or a client CE router. > If disabled only for forwarded tra ffic:

>> A traceroute done from the edge-LSR wi ll show the core LSRs. >> A traceroute done from the client CE routers will not show the core LSRs.


TOC 115

- PHP (Penul timate-Hop-Popping) > An egress LSR advertises a label value of 3 (IMP-NULL) to an ups tream (penul timate) LSR, instructing that LSR to pop the top label, before forwarding the packet onto

the egress LSR. > PHP rem oves the requirement for a double lookup to be performed on an egress LSR. > The LIB table will display a value of imp-nul l .

- Labels define the destination and services for a packet and identi fy the FEC (Forwarding Equivalence Class). - Labels have local signi ficance, because each LSR independently maps a label to an FEC in a label binding. - Label bindings are usually exchanged only between adjacent LSRs.

- FEC (Forwarding Equivalence Class) > Is a flow of packets that are forwarded along the same path or that share the same forward ing treatm ent. > All packets belonging to the same FEC have the same label. > The ingress LSR classifies and assigns packets to a specific FEC using a label . > By defaul t no further packet classification is done in a MPLS network. > Different types of FECs

>> MPLS unicast IP FEC - Corresponds to the des tination network stored in the RIB. >> MPLS multicas t IP FEC - Corresponds to the des tination multicas t address. >> MPLS VPN FEC - Corresponds to the VPN routing table on the BGP next-hop. >> MPLS QOS FEC - Corresponds to the combination of a destination network and the EXP value.

> The remainder of this section will focus on the MPLS unicast IP FEC where a label = prefix. > The MPLS VPN Section wi ll cover MPLS VPN FEC where the BGP next-hop is the FEC.

- LSRs can perform the fo llowing label operations: > Insert/impose/push a label. > Swap a label. > Rem ove/d ispose/pop a label.

- Label Stack > Refers to the labels inserted between the layer2 and layer3 headers. > The fi rs t label in the stack is called the top (outer) label and the last label is called the bottom (inner) label. > Label forward ing decisions are based ONLY on the top label in a s tack. > With basic MPLS the label stack only consists of one label. MPLS VPNs, TEs and ATOMs use multip le labels.

- LSP (Label Switch Path) > The label path via a series of LSRs that forward labeled packets based on the FEC. > LSPs are unidi rectional ; i .e ., re turn traffic will fo llow a different LSP.

- Local Bindings > A LSR assigns one locally signi ficant label per route in the RIB table . > The local binding is one route and i ts associated label. The local bindings are s tored in the LIB table. > The LIB table refers to this label as a 'local' label and the LFIB re fers to i t as a 'IN ' label. > Every LSR wil l advertise i ts local bindings to i ts adjacent LSRs using TDP/LDP. > The local bindings that a LSR advertises, tel l other LSRs what label values i t expects tra ffic to arrive with. > A LSR wil l only accepts labeled packets i f the top label in the label stack matches the local labels i t previously advertised. > If an LSR receives a labeled packet with a top label, that is not one of i ts own local labels, i t will drop the packet.


TOC 116

- Remote Bindings > A received binding advertised by an adjacent TDP/LDP LSR. > A TDP/LDP LSR may receive m ultip le label bindings for each route, usually one per TDP/LDP neighbor. > All these received bindings (rem ote bindings) are s tored in the LIB. > Only one LSR can be the downs tream LSR for a particular route, unless load balancing is configured. > The downs tream LSR is the next-hop for a particu lar route in the RIB. > Only the remote binding received from the next-hop LSR is used to populate the OUT label in the LFIB.

- Downs tream is always towards the des tination as indicated by the RIB. - Upstream is always towards the source as indicated by the RIB.

- MPLS Label Propagation > The configured IGP converges as normal and advertises all the routes to all the neighbors. > The routes are populated in the RIB and FIB tab les. > Each LSR assigns a label (loca l /IN) to each non-BGP route in i ts RIB table and stores i t in the LIB and LFIB tables. > Each allocated local binding is independently advertised to all neighbor LSRs, regardless of whether the neighbors are ups tream or downs tream for a particular

destination. > Upon receiving the label advertisements, each LSR stores all the remote bindings and details of the LSRs that advertised each one in the i r LIB tables . > After label convergence, each LSR processes i ts RIB table to find the next-hop/downs tream LSR for each des tination. > The label (next-hop/OUT) received from the next-hop/downstream LSR for each destination is taken from the LIB and placed in to the FIB and the LFIB. > Once the LFIB is ful ly populated LDP is considered converged. > For each route, the LSR always has a single local binding (IN label ) and one remote binding per LDP peer (OUT labels). > To s ummarize locally-assigned labels that were previously advertised to upstream neighbors, are mapped to next-hop labels, previously received from downstream

neighbors.

- MPLS Packet Forwarding > If a LSR receives an IP packet, the FIB is used to make the forwarding decision:

>> I f the next-hop IP has an OUT label associated, the packet is labeled and forwarded to the next-hop LSR. >> I f the next-hop IP does not have an OUT label associated, the packet is forwarded unlabeled to the next hop. >> I f there is no next-hop available for the des tination, the packet is dropped.

> If a LSR receives a labeled packet, the LFIB is used to make the forward ing decision. >> I f the top label matches an IN label , the corresponding OUT label determines i f:

>>> The top label is swapped before the packet is forwarded. >>> The top label is swapped and another label imposed before the packet is forwarded. >>> The top label is popped and the packet is forwarded:

>>>> Labeled i f any labels remain in the label stack (bottom -of-s tack bi t = 0) or >>>> Unlabeled i f the last label in the stack was removed (bottom-of-stack bi t = 1).

>> I f the top label does not match any of the IN labels, the packet is dropped. >>> This is the case regardless i f the FIB has the des tination IP listed.

- Aggregation/Summarization > An aggregating LSR will advertise the labels for the routes i t is summarizing. > The outgoing labels in the LFIB wil l show 'aggregate '. > If an LSR receives a labeled packet for routes i t is aggregating, i t will remove the label s tack. > The LSR will then do an IP lookup for the more specific route and find the new outgoing label. > The IP packet wil l then be labeled before being forwarded on. > Aggregation in MPLS networks breaks end-to-end LSPs and often causes tra ffic to be dropped.


TOC 117

> For th is reason LSR loopback addresses should never be summarized.

- MTU (Maxim um Transmission Uni t) > Ind icates the maximum size of a packet on an in terface without the need to fragment the packet. > IP MTU is the maxim um size of a layer3 IP packet on an in terface can be without requi ring fragmentation. > MPLS MTU is the maximum size a labeled packet (IP packet + label /s ) can be without requiring fragmentation. > By defaul t, the MPLS MTU value is derived from the IP MTU value. This is usually a problem on Ethernet links . > How does the fragmentation in MPLS work?

>> I f a labeled packet is received b y a LSR that notices the outgoing MTU is not big enough for the packet, the LSR strips off the label s tack, fragments the IP packet, puts the label stack onto all the fragments and forwards the fragments .

>> The only exception is when the DF (Don't Fragment) bi t is set in the IP header, which will generate an ICMP type 3,code 4 message instead.

> The typ ical MTU size on an Ethernet in terface is 1500-bytes . > Since each label is 4-bytes, a packet's size increases with 4-bytes for every label added. > If one label is added to an already m axim um sized IP packet of 1500-bytes the packet wi ll be fragmented. > To prevent this typical fragmentation problem , ei ther increase the MPLS MTU i f possible or decrease the IP MTU. > Another al ternative is to enable PMTU to auto discover the maximum allowed unfragmented IP MTU to the endpoint. > The MPLS MTU value is configured with "mpls m tu" under the in terface. > The configured in terface values can be seen with "show in t | i MTU" and "s how mpls in t detail | i MTU".

- MPLS MRU (Maximum Receive Uni t) > The m axim um size a received labeled packet m ay be without the need to be fragmented when forwarded out of the egress in terface. > This value is derived from the MPLS MTU on the egress interfaces . > Scenario :

>> Assume the MPLS MTU is set to 1504-bytes on all interfaces. This allows a single label on packets leaving the LSR. >> I f a received packet's label operation is 'pop ', the MRU for the route on that router would be 1508-bytes . >> This is because when the packet is sent out, i t can be no bigger than 1504-bytes . >> But since the operation is POP, the packet m ay be received with 2 labels (1508-bytes ) >> One label will be popped and the sent packet size of 1504-bytes would be allowed.

> The MRU value takes in to account the amount of labels pushed, swapped, or popped on the local router. > This value is calculated per FEC and not per in terface. > The MRU value can be seen in the LFIB with "show mpls forward ing-tab le detail | i MRU".

IOS-COMMANDS

# sh mpls interface {int} [detail] - Shows the MPLS enabled interfaces, their status and MTU settings # sh mpls label range - Shows the range of local labels available # sh int {int} | i MTU - Shows the MTU per interface # sh mpls interfaces [int] detail | i MTU - Shows the MPLS MTU per interface # sh mpls forwarding {route} detail | i MRU - Shows the MRU for the specified route # sh mpls forwarding labels {label} exact-path ipv4 {src-ip} {dst-ip}

- Shows the exact exit path a labeled packet takes based on the address pair # sh ip cef [vrf] exact-route {src-ip} {dst-ip} - Shows the exact exit link a packet takes based on the address pair

# sh ip cef table [vrf] - Shows information about the CEF tables and amount of routes

# sh ip cef switching statistics - Useful if CEF is dropping IP packets # sh adjacency - Shows the CEF adjacency table, including the NLPID


TOC 118

# clear cef table - Refreshes the CEF cache # clear adjacency - Clears the layer2 rewrite information

# debug ip cef drops [acl] - Shows if CEF is dropping IP packets on an ingress LSR

# debug mpls lfib - Debugs LFIB events: label creations, removals, rewrites # debug mpls packet [mpls-acl] [interface] - Debugs labeled packets switched by router

#no mpls ip propagate-ttl [forwarded|local] - Disables TTL propagation, useful to hide core LSRs (default = enabled) - Forwarded: Trace doesn't work for transit traffic labeled by the router - Local: Trace doesn't work from the router, but transit traffic does

#system jumbomtu {bytes} - Enables jumbo MTUs on 3560 switches

#interface {int} #mtu {bytes} - Specifies the maximum size of a layer3 frame on the interface, IOS excludes

layer2 overhead. - The interface MTU is automatically increased on WAN interfaces; IP MTU is

automatically decreased on LAN interfaces - Min MTU is 64 bytes, Max MTU depends on the interface type

#mpls mtu {bytes} - Max size a labeled packet can be without requiring fragmentation (default = IP MTU)

XR-COMMANDS

# sh mpls ldp interface {int|summary} [detail] - Shows the MPLS enabled interfaces, their status and MTU settings # sh mpls label range - Shows the range of local labels available (Min/Max: 16000/1048575) # sh int all brief - Shows summary of all interfaces, their states, MTUs and bandwidths # sh int {int} | i MTU - Shows the physical MTU per interface # sh mpls forwarding exact-route labels {label} ipv4|6 {src-ip} {dst-ip}

- Shows the exact exit path a labeled packet takes based on the address pair # sh cef [vrf] ipv4|6 exact-route {src-ip} {dst-ip} - Shows the exact exit link a packet takes based on the address pair # sh cef drops - Useful to see if CEF is dropping IP packets

#mpls ip propagate-ttl disable [forwarded|local] - Disables TTL propagation, useful to hide core LSRs (default = enabled)

- Forwarded: Trace doesn't work for transit traffic labeled by the router - Local: Trace doesn't work from the router, but transit traffic does

#interface {int} #mtu {bytes} - Specifies the maximum size of a layer2 frame on the interface, includes

layer2 overhead. IOS-XR MTU is different from IOS. On Ethernet difference is 14 bytes (2 bytes = Ethertype, 2x 6 bytes src|dst MAC addresses)

- Min MTU is 64 bytes, Max MTU depends on the interface type - IOS-XR MTU is different from IOS

#mpls - Enters interface MPLS configuration mode #mtu {bytes} - Specifies the max size a labeled packet can be without requiring

fragmentation (default = IP MTU)


TOC 119

Labels

- Label Values > Labels 0 through 15 are reserved labels which some special reserved labels:

>> 0 - IPv4 Explicit Null Label . >> 2 - IPv6 Explicit Null Label . >> 3 - Implici t Null Label.

- Implici t Null Label (3) > By defaul t, an LSR advertises a im plici t null label for directly connected and summarized prefixes to all neighboring LSRs. > An LSR receiving a binding with an implici t null label will pop the top label before forwarding packets to that LSR. > The use of the impl ici t nul l action at the end of an LSP is called PHP (Penul timate -Hop-Popping). > By removing the top label before forwarding a packet PHP removes the requi rement for a double label lookup on an egress LSR. > The LIB table will display a value of 'imp-nul l '.

- Explicit Null Labels (0 or 2) > The impl ici t null label optimizes lookups but i t also removes the EXP bi ts in those labels that might be needed in end-to-end QOS enforcement. > An egress LSR can signal the use of an IPv4/IPv6 explici t NULL label to the penul timate LSR instead of an implici t null label. > An LSR receiving a binding with an explici t nul l label wi ll swap the top label value with 0 or 2, before forwarding packets to that LSR. > An egress LSR will then receive labeled packets with the EXP bi ts in tact. > The top label (0 or 2) is removed and the next label (i f any) is used for forwarding. > Configured with "m pls ip encapsulate explici t-nul l" on an in terface.

- There are di fferent protocols that dis tribute labels: > TDP is used to distribute the bindings for non-BGP routes in the routing tab le . > LDP is used to dis tribute the bindings for non-BGP routes in the routing table . > MP-BGP is used to distribute the bindings for BGP routes in the routing table . > RSVP is used to dis tribute MPLS TE labels.

- The terms TDP and LDP are sometimes used s ynonymously, but there are differences.

- TDP (Tag Dis tribution Protocol) > Is a much older Cisco proprie tary protocol , not really used anym ore. > Refers to labels as tags . > Uses local broadcasts instead of multicast. > Uses UDP and TCP port 711. > Does not support MD5 authentication.

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | Multiprotocol Label Switching Configuration Guide Library, Cisco IOS Release 12.4T | | MPLS: LDP Configuration Guide, Cisco IOS Release 12.4T | | MPLS Label Distribution Protocol

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | MPLS Configuration Guide | | Implementing MPLS Label Distribution Protocol | | Overview of Label Distribution Protocol - LDP (Label Dis tribution Protocol)

> An IETF standards protocol .


TOC 120

> Uses the all -routers multicast address (224.0.0.2) for di rectly connected neighbor discovery. > Uses UDP port 646 for neighbor discovery and TCP port 646 for session establishment. > An LDP session is established from the LSR with the higher IP address. > Provides optional MD5 authentication. > The LDP hello in terva l is every 5 sec and the hold in terval is 15 sec. > If two LDP neighbors have di fferent values configured, the smaller of the two is used. > LDP sessions should be established using routable loopback addresses between adjacent LSRs.

- LDP-ID (Identi fier) > A 6-byte field used to identi fy a LSR (4-byte field) and to identi fy the label space of the sending LSR (2-byte fie ld). > The fi rs t 4-bytes called the LDP router-ID is functional ly equivalent to any other protocol router-ID. > Unless manual ly configured with the "mpls ldp router-id force" command, the address is taken from the highest loopback in terface i f available, else the highest

operational interface address. > The last two bytes indicate the label-space used. A value of 0 indicates fram e-m ode MPLS is used. > Im portant to remember the LDP router-ID mus t be routable else LDP sessions will not establish.

- Transport Address > By defaul t, a LDP session is setup using the LDP router-ID as the source for communication between two neighbors. > This is why the LDP router-ID mus t be routable, else session establishment will not happen. > Al ternatively the session may be s etup using an optional TLV called the transport address. > The transport address allows a LDP session between neighbors using an IP or in terface di fferent from the LDP router-ID. > Configured with the in terface command "mpls ldp discover transport-address". > If m ultip le links exis t between neighbors, the same transport address mus t be advertised on all links.

- Targeted LDP Session > Requi red for non-adjacent LDP neighbors. > UDP hellos are sent to the specified unicast IP address instead of the multicas t IP address. > When the neighbor is discovered, the mechanism to establish a session is the same. > Configured with "m pls ldp neighbor {ip} targeted". > In some cases li ke L2VPN xconnects automatically creates a targeted LDP session.

- LDP Authentication > To protect LDP sessions MD5 authentication can be configured between neighbors . > MD5 authentication adds a signature (the MD5 diges t) to the TCP s egments. The MD5 digest is calculated based on the password. > Only the MD5 diges t is transmi tted, the passwords are never transmi tted. > MD5 authentication is requi red on both sides of a link between two neighbors . > Configured with "m pls ldp neighbor {ip} password" (carefu l of whi te spaces at the end). > If one LSR has MD5 configured for LDP and the other not, the fo llowing message wi ll be logged:

%TCP-6-BADAUTH: No MD5 digest from 10.5.1.4(11092) to 10.5.1.3(646) > If both LDP neighbors have MD5 configured but the passwords don't match, the following message will be logged:

%TCP-6-BADAUTH: Invalid MD5 digest from 10.5.1.4(11093) to 10.5.1.3(646)

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | MPLS Configuration Guide | | Implementing MPLS Label Distribution Protocol | | Label Advertisement Control (Outbound Filtering)

- Condi tional Label Advertising

> Enables the selective advertisement of only the necessary labels to certain LDP neighbors. Copyright © 2013 Routing-Bits.com

TOC 121

> The 'FOR' keyword specifies which routes should have the i r labels advertised. > The optional 'TO' keyword specifies which LDP neighbor should receive the label advertisements. This mus t match the LDP router-ID. > More than one "mpls ldp advertise-labels " s tatement can be used on the same LSR.

CONFIG-SET: (IOS) Conditional Label Advertising for the Loopback IPs

| access-list 10 permit 10.5.1.0 0.0.0.255 - Matches all loopback addresses | ! | no mpls ldp advertise-labels - Disables the default behavior to advertise all local labels | mpls ldp advertise-labels for 10 - Labels matching ACL-10 are sent all neighbors

CONFIG-SET: (IOS-XR) Conditional Label Advertising for the Loopback IPs

| ipv4 access-list ACL-10 | 10 permit 10.5.1.0 0.0.0.255 - Matches all loopback addresses | ! | mpls ldp - Enters the MPLS configuration mode | label advertise | disable - Disables the default behavior to advertise all local labels | for ACL-10 - Labels matching ACL-10 are sent all neighbors

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | Multiprotocol Label Switching Configuration Guide Library, Cisco IOS Release 12.4T | | MPLS: LDP Configuration Guide, Cisco IOS Release 12.4T | | MPLS LDP Inbound Label Binding Filtering

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | MPLS Configuration Guide | | Implementing MPLS Label Distribution Protocol | | Label Acceptance Control (Inbound Filtering)

- LDP Inbound Label Binding Fil tering > Allows fi l tering received label bindings from a LDP neighbor. > This could be used to l imi t the number of label bindings s tored in the LIB.

CONFIG-SET: (IOS)-Filtering Inbound Label Bindings

| access-list 12 permit host 10.5.1.250 - Specifies the label bindings, which should be accepted | access-list 12 permit host 10.5.1.251 | ! | mpls ldp neighbor 10.5.1.250 labels accept 12 - Filters label bindings matching ACL-12 from neighbor 10.5.1.250 |


TOC 122

CONFIG-SET: (IOS-XR) Filtering Inbound Label Bindings

| ipv4 access-list ACL-12 | 10 permit 10.5.1.250 - Specifies the label bindings, which should be accepted | 20 permit 10.5.1.251 | ! | mpls ldp - Enters the MPLS configuration mode | label accept | for ACL-12 from 10.5.1.250 - Filters label bindings matching ACL-12 from neighbor 10.5.1.250

IOS-COMMANDS

# sh mpls ldp discovery - Verifies the status of LDP if operational # sh mpls ldp neighbor - Shows the status of LDP sessions # debug mpls ldp - Debugs LDP adjacencies, session establishments, label binding exchanges

#interface {int}

#mpls ip - Enables MPLS on the interface #mpls label protocol [ldp|tdp] - Specified the label distribution used on the interface

#mpls label protocol [ldp|tdp|both] - Specifies the label distribution protocol used globally

#mpls ldp router-id {int} [force] - Configures the LDP router-ID (interface must be up state to be used) - [force]: Forcibly changes the router-ID before a reload

#mpls label range [low high] - Changes the default label range (16-100000) #no mpls ldp advertise-labels - Disables the default behavior to advertise all labels to all neighbors #mpls ldp neighbor {ip} password {pwd} - Configures a MD5 password authentication for LDP #mpls ldp neighbor {ip} targeted - Establishes a targeted LDP session with a non-adjacent neighbor #mpls ldp neighbor {ip} labels accept {acl} - Configures filtering inbound LDP label bindings #mpls ldp adv-labels [for {prefix-acl}] [to {peer-acl}]

- Configures conditional label advertising - [for]: Specifies the destinations for which labels are generated - [to]: Specifies a recipient list of neighbors

#router ospf {pid} #mpls ldp autoconfig area {area} - Enables LDP on all OSPF enabled interfaces

#router isis [tag]

#mpls ldp autoconfig - Enables LDP on all IS-IS enabled interfaces

XR-COMMANDS

# sh mpls ldp discovery - Verifies the status of LDP if operational # sh mpls ldp neighbor - Shows the status of LDP sessions

#mpls label range [low high] - Changes the default label range (16000-1048575)

- Labels 16 through 15999 are reserved for L2VPN static pseudowires #mpls ldp - Enters the MPLS configuration mode


TOC 123

#router-id {int} - Configures the LDP router-ID #neighbor {ip} targeted - Establishes a targeted LDP session with a non-adjacent neighbor #neighbor {ip} password {pwd} - Configures a MD5 password authentication for LDP #label advertise - Enters outbound LDP label filtering configuration mode #disable - Disables the default behavior to advertise all labels to all neighbors #for {prefix-acl} [to {peer-acl}] - Configures conditional label advertising

- [for]: Specifies the destinations for which labels are generated - [to]: Specifies a recipient list of neighbors

#label accept - Enters inbound LDP label filtering configuration mode #for {prefix-acl} [to {peer-acl}] - Configures filtering inbound LDP label bindings

#router ospf {pid}

#mpls ldp auto-config - Enables LDP on all OSPF enabled interfaces

#router isis [tag]

#address-family ipv4 unicast #mpls ldp auto-config - Enables LDP on all IS-IS enabled interfaces


TOC 124

Troubleshooting MPLS LDP

- LDP Session Startup issues: > Do all the expected neighbors show up? # sh m pls ldp discovery > Is MPLS enable on all the necessary in terfaces? # sh m pls in terface > Are all the expected neighbors di rectly adjacent? (should be 1 hop) # traceroute {ne ighbor}

>> I f not was a directed LDP session configured? # sh run | i target >> Is the non-adjacent neighbor reachable? # ping {ip}

> Are all the neighbors using the same protocol : LDP/TDP? # sh m pls in terface detail > Any in terface access-lists dropping ports 711 or 646? # sh ip in terface | i line |lis t > Test connectivi ty between loopback in terfaces . # ping {ip} source {ip}

- Labels are not being allocated: > Are labels allocated to local routes? # sh m pls forwarding-table > Confi rm CEF is enabled globally and on interfaces . # sh cef in terface

- Labels are allocated, but not being dis tributed: > Does the adjacent LSR display the received labels? # sh m pls ldp bindings (on neighbor) > Is conditional label advertising configured? # sh run | i advert

- Problems with large packets > Does an extended ping with packet sizes close to 1500 fail? # ping {ip} size 1500 df > Are the correct MTUs set? # sh m pls interfaces detail | i MTU


TOC 125

Bibliography


RFC-3031 Multiprotocol Label Switching Archi tecture http ://www.ie tf.org/rfc/rfc3031.txt


TOC 126



TOC 127

Chapter 7

MPLS – L3VPNs


TOC 128

MPLS Layer3 VPNs

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | Multiprotocol Label Switching Configuration Guide Library, Cisco IOS Release 12.4T | | MPLS: Layer 3 VPNs Configuration Guide, Cisco IOS Release 12.4T | | Configuring MPLS Layer 3 VPNs

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR Software, Release 3.8 | | MPLS Configuration Guide | | Implementing MPLS Layer 3 VPNs on Cisco IOS XR Software

- Defined in RFC-4364.

- MPLS layer3 VPNs in terconnect customer sites over a service provider MPLS core.

- MPLS VPN Terminologies > Label - A 4-byte identi fier, used by MPLS to make forwarding decisions. > CE Router - Customer Edge Router, a non-MPLS cl ient/si te router connected to the MPLS network. > P Router - Provider Router, a LSR in MPLS VPN terminology. > PE Router - Provider Edge Router, an edge-LSR in MPLS VPN terminology. > LSP - Label Switch Path, a series of LSRs that forward labeled packets to the ir destinations (unidi rectional). > Ingress PE router - Is the edge-LSR an IP packet arrives at from a CE router before being labeled and forwarded to the egress PE router. > Egress PE Router - Is the edge-LSR where the des tination route is connected. Receives labeled packets, forwards IP packets.

- VRF (Vi rtual Routing and Forwarding) > Is a technology that allows multiple instances of tables to co-exis t on the same router. > Each instance operates independently and provides isolation between di fferent clients running the same address space. > Each VRF instance consists of a separate RIB, FIB and LFIB table . > A VRF is locally signi ficant to a router. > Traffic that enters on a VRF enabled in terface will belong to that VRF instance. > Each in terface can only be assigned to one VRF but a VRF can have m any interfaces assigned.

- RD (Route Dis tinguisher) > A VPN's routes are propagated across a MPLS VPN network by MP-BGP. MP-BGP requires that the transported routes be unique. > An RD is a 64-b i t (8-byte) value prepended to a client's non-unique 32-bi t IPv4 address to produce a unique 96-bit VPNv4 address. > An RD uniquely identi fies a route, i t does NOT identi fy a VPN. > An RD is locally signi ficant to a router but has global relevance.

- RT (Route-Target) > Is a 64-bi t (8-byte) extended BGP communi ty that is attached to a VPNv4 BGP route to indicate i ts VPN membership. > A certain number of RTs can be attached to a single route, up to the BGP Update packet size of 4096. > E xport RTs

>> Are attached to a route when i t is converted in to a VPNv4 route. >> Generally used to identi fy the VPN membership of routes .

> Im port RTs >> Are used to select VPNv4 routes for insertion in to matching VRF tables . >> On the receiving PE router, a route is imported in to a VRF only i f at least one RT attached to the route matches at least one im port RT configured in that VRF

(route-map conditions m ust be met, i f configured).


TOC 129

> An import or export map allows route control on a per-route basis. > RTs allow for more complex VPN designs li ke Hub-and-Spoke, Central Services, Extranet, Management VPNs, etc.

- RT/RD can be used in one of the following formats : > ASN:nn - Autonomous System Number; where 'nn ' can be any number. > IP-ADD:nn - 4-Octet Dotted Decimal format; where 'nn ' can be any num ber.

- Loopback In terfaces > With MPLS VPNs i t is always a requi rement to use loopback in terfaces on all P and PE routers . > These loopbacks mus t be advertised by the core IGP (e .g. OSPF or ISIS). > The MP-BGP sessions should be set up using these loopback addresses to avoid prem ature label popping in LSPs. > These loopback interfaces wi ll be used and re ferred to as the BGP next-hop address to carry MPLS VPN tra ffic. > A BGP next-hop address mus t be an IGP route.

- Protocols requi red for MPLS VPNs: Figure 7-1: MPLS VPN Protocols

> PROT - This is a VRF capable protocol used to advertise client routes in to the VRF routing table . - The VRF capable protocols used for PE-CE communication are s tatic routes , RIP, EIGRP, OSPF, eBGP.

> IGP - This is the core MPLS IGP. This is genera lly OSPF or IS-IS. > LDP - Ei ther TDP or LDP could be used as the label exchange protocol between the MPLS-enabled routers . > MP-BGP - For MPLS VPNs MP-BGP sessions are only required between PE routers (re fer to MP-iBGP Section below).

- With MPLS VPNs, two labels are used in the label s tack: > The outer/top label is used for swi tching the packet through the MPLS network (o ften called the LDP label ). > The top label points to the egress router and is propagated by LDP (the adjacent LSR's label for the next-hop 's IPv4 route). > The inner/bottom label is used to separate packets at egress points (o ften called the VPN label ). > The second label identi fies the outgoing interface on the egress router and is advertised by MP-BGP.

- MPLS VPN Label Operation > The configured IGP converges as normal , advertising the BGP next-hop IPs (loopbacks). > TDP/LDP converges as described in the previous section, advertising the TDP/LDP labels for the BGP next-hops. > Every egress PE router assigns a VPN label to every local VRF route. > MP-BGP on the PE routers converges by advertising all local VRF routes along with the VPN labels to ALL other PE routers in MP-BGP updates . > Once converged, all PE routers should have an OUT VPN label assigned to each non-local VRF route along with a LDP label for every BGP next-hop. > These two labels per route (VPN label, LDP label) are the two labels MPLS VPNs use in a label s tack.


TOC 130

- MPLS VPN Route Propagation > This scenario depicts how a route is advertised from CE2 to CE1 across a MPLS VPN network.

Figure 7-2: MPLS VPN Route Propagation

1- CE2 advertises an IPv4 route (10.5.1.0/24) to PE2, using the configured IGP or eBGP. 2- The received IPv4 route advertisement is inserted in to the VRF routing table associated with the PE2 in terface i t arrived on. 3- When the IPv4 route is red istributed in to MP-BGP, PE2 prepends the 64-b i t RD from the VRF to the non-unique 32-b i t IPv4 route, which results in a globally unique 96-

bi t VPNv4 packet. At the same time the export RTs from the VRF are attached. 4- The VPNv4 route (wi th VPN label and RTs) is advertised via MP-iBGP sessions to all other PE routers (PE1 in th is scenario). 5- PE1 receives the MP-BGP update but only processes the VPNv4 route i f i t is configured locally. If configured locally, implying the RTs attached to the route match an

im port RT in a local VPN, the VPNv4 route is imported in to the appropria te VPNv4 BGP table . 6- PE1 then s trips the RD off the VPNv4 route and installs the original IPv4 route (10.5.1.0/24) into the VRF table . 7- PE1 advertises the IPv4 route (10.5.1.0/24) via the configured IGP or eBGP to CE1

- MPLS VPN Packet Forwarding > This scenario depicts how a packet is routed from CE1 to CE2 after label and route convergence.

Figure 7-3: MPLS VPN Packet Forwarding

1- CE1 sends an IPv4 packet destined to 10.5.1.0/24, towards PE1. 2- The ingress PE router (PE1) receives the packet and looks up the next-hop for the destination in the VRF routing tab le associated with the ingress in terface the packet

arrived on. The egress PE router (PE2), which previously advertised th is route (and a VPN label ), wil l be used as the next-hop. 3- Since a label was received from the next-hop, the packet wil l be labeled:

- The bottom label is the VPN label, which will be used to indicate the correct CE next-hop on PE2. - The top label wil l be the LDP label used to get to PE2 loopback. On PE1 th is would be the LDP label received from P1.

4- The labeled packet is forwarded to P1. 5- P1 receives a labeled packet, checks the LFIB table and pops (PHP) the LDP label before forwarding the labeled packet to PE2. 6- PE2 receives a labeled packet, with the top label matching a VPN route pointing to the IP next-hop, CE2. 7- The remaining label stack is removed, before the original IPv4 packet is forwarded unlabeled towards CE2. 8- Return tra ffic wil l follow the same process but in reverse (remem ber a LSP is unidi rectional).

!!NOTE!!- Always make sure that the VPN label is only exposed on egress PE routers where the VRF is configured, otherwise PHP wil l occur premature ly and traffic will be dropped.


TOC 131

CONFIG-SET: MPLS-VPN - Layer3 VPN Between the Two Client Sites

|PE1# - IOS router | ip vrf BOB | rd 123:1 | route-target export 123:1 - Exports all VRF-RIB routes with a RT of 123:1 | route-target import 123:1 - Imports MP-BGP routes if the RT of 123:1 matches | ! | interface fa0/0 - The interface connected to CE1 | ip vrf forwarding BOB - Assigns the interface to VRF-BOB | |PE2# - IOS-XR router | vrf BOB | address-family ipv4 unicast - Enables the VRF for IPv4 unicast | import route-target 123:1 - Exports all VRF-RIB routes with a RT of 123:1 | export route-target 123:1 - Imports MP-BGP routes if the RT of 123:1 matches | ! | router bgp 100 | vrf BOB | rd 123:1 | address-family ipv4 unicast - Enables the BGP VRF instance for IPv4 unicast | | interface gi0/1/0/0 - The interface connected to CE2 | vrf BOB - Assigns the interface to VRF-BOB |

- Defaul t Route-Target Fil ter > LSRs by default only accept MP-BGP advertisements for VRFs that are locally configured (VRF im port s tatement). > The other advertisements are ignored and not entered in to any table . > This defaul t behavior of the RT fil ter check can be disabled with "no bgp defaul t route-target fil ter". > RRs (Route Reflectors) however will accept all VPNv4 routes . With RRs, the RT fil ter is implici tly disabled. > The command "no bgp defaul t route-target fil ter" is therefore not requi red on a RR.

- Another consideration to keep in mind is that RRs only re flect the best routes .

- VRF Im port Filtering > By using defaul t configuration all routes matching an import RT will be imported. > A VRF im port route-map allows more granulari ty by only im porting selected routes. > A route is only imported in to a VRF i f at least one RT attached to the route matches one RT configured in the VRF and the route is accepted (perm i tted) by the import

route-map. > The route-map can match routes using the fo llowing cri teria :

>> Access-lists. >> Prefix-lists . >> RTs.

> The route-map can be configured in addi tion to a RT import statement "route-target import {rt}". > If a VRF im port route-map is configured, routes m ust be explici tly allowed for import. If a route did not m atch any route-map instance i t will not be imported and fil tered

as a resul t.


TOC 132

CONFIG-SET: MPLS-VPN - VRF Import Filtering Example

| access-list 55 permit 10.5.1.0 0.0.0.255 - Matches a specific route | ! | ip extcommunity-list 10 permit rt 123:2 - Creates a community-list matching RT 123:2 | ! | route-map IMPORT permit 10 | match extcommunity 10 - Routes with a RT of 123:2 will be imported | ! | route-map IMPORT deny 20 | match ip address 55 - The route 10.5.1.0/24 will not be imported | ! | route-map IMPORT permit 30 - Allows all other routes matching 123:789 to be imported | ! | ip vrf CLIENT-A | rd 123:789 | import map IMPORT - Applies the import-map, importing any route with a RT 123:2 | or RT 123:789, except 10.5.1.0/24 | route-target import 123:789 - Imports all MP-BGP routes with a RT of 123:789 | route-target export 123:789 - Exports all VRF CLIENT-A RIB routes with a RT of 123:789 |

- Selective VRF Export > By defaul t all routes in the VRF RIB will be exported with the defaul t export RTs. > A VRF export route-map can be used to achieve any of the fo llowing:

>> Only export selective routes to the MP-BGP table for advertisement. >> Attach extra RTs in addi tion to the defaul t RTs (o ften used in extra-net designs).

> The impl ici t 'no-match ' at the end of a route-map DOES NOT prevent the route from being exported. If a route did not match any route-map instance i t will be exported using the defaul t route-target export.

> Copy subtly owned by James Gibson. > An explici t deny in an export-map will prevent a route from being exported. > An export-map with a "set extcommuni ty rt" command clears al ready added RTs. > But i f the 'addi tive ' keyword is specified that RT is added in addi tion to the al ready-set RTs. > Selective VRF export does NOT requi re a RT export s tatement i f "set extcommuni ty rt" is configured. > The fo llowing two config -sets accomplishes the same tas ks:

>> 20.1.20.0/24 is not exported. >> 10.5.1.0/24 is exported with two RTs. >> All other routes are exported with one RT.


TOC 133

CONFIG-SET: MPLS-VPN - Selective VRF Export Option-1

| access-list 55 permit 10.5.1.0 0.0.0.255 - Matches a route to be exported | access-list 66 permit 20.1.20.0 0.0.0.255 - Matches a no-export route | ! | route-map EX-MAP deny 10 | match ip address 66 - Explicitly prevents 20.1.20.0/24 from being exported | ! | route-map EX-MAP permit 20 | match ip address 55 - References ACL-55 for routes to be exported | set extcommunity rt 123:555 additive - Adds RT 123:55 additionally onto 10.5.1.0/24 | ! | ip vrf CLIENT-B | rd 123:789 | export map EX-MAP - Applies the export-map | route-target import 123:789 - Imports all MP-BGP routes with a RT of 123:789 | route-target export 123:789 - All VRF CLIENT-B RIB routes not matched by the EX-MAP are | exported with a RT of 123:789

CONFIG-SET: MPLS-VPN - Selective VRF Export Option-2

| access-list 55 permit 10.5.1.0 0.0.0.255 - Matches a global route | access-list 66 permit 20.1.20.0 0.0.0.255 - Matches a no-export route | ! | route-map EX-MAP deny 10 | match ip address 66 - Explicitly prevents 20.1.20.0/24 from being exported | ! | route-map EX-MAP permit 20 | match ip address 55 - References ACL-55 | set extcommunity rt 123:555 123:789 - Attaches RT 123:55 and RT 123:789 to 10.5.1.0/24 | ! | route-map EX-MAP permit 30 | set extcommunity rt 123:789 - All other routes have RT 123:789 attached | ! | ip vrf CLIENT-B | rd 123:789 | export map EX-MAP - Applies the export-map | route-target import 123:789 - Imports all MP-BGP routes with a RT of 123:789 |

- Hub-Spoke Scenario > A hub-spoke design could be used when fu ll connectivi ty between sites is prohibi ted, or i f there is a need, say s ecuri ty, for all branch-to-branch traffic to flow via the

head office s i te . > I t is unlikely that th is will be seen in production, but i t is good to know for the lab.


TOC 135

- VRF Route-Limi ting > The number of routes with in a VRF table can be lim i ted explicitly.

>> This applies to all routes on a router within the VRF, not jus t BGP routes . >> This applies to routes learned from CE routers and other PE routers . >> The defaul t behavior when the limi t is reached is that the router won't accept anym ore VRF routes. >> Log messages:

%IPRT-3-ROUTELIMITWARNING: IP routing table limi t warning.... %IPRT-3-ROUTELIMITEXCEEDED: IP routing table lim i t exceeded....

> The number of routes received from a BGP neighbor could be l imi ted. >> The defaul t behavior when the limi t is reached is to drop the neighbor re la tionship. >> Log messages:

%BGP-4-MAXPFX: No. of unicast prefix received from ... %BGP-3-MAXPFXEXCEED: No. of unicast prefix received from ...

- Multiprotocol VRFs > "ip vrf NAME" applies impl ici tly to the IPv4 address-family without the need to enable i t. > "ip vrf defini tion NAME" allows the requi red address-family, ei ther IPv4 or IPv6, to be selectively enabled. Use the command "address-family ipv4|ipv6" to enable. > Cisco IOS also has a m igration util i ty to upgrade the IPv4 VRF configuration to multiprotocol VRF configuration with "vrf upgrade-cl i multi -a f-m ode" command.

IOS-COMMANDS

# sh ip vrf - Shows the list of all VRFs configured in the router # sh ip vrf [detail] {name} - Shows the VRFs configured and associated interfaces

- [detail] Displays the import/export parameters per VRF # sh ip vrf interface - Shows the interfaces associated per VRF # sh ip protocols vrf {name} - Shows the routing protocols configured in a VRF # sh ip route vrf {name} [summary] - Shows the VRF routing table

- [Summary] Displays a summary of routes per VRF # sh mpls forwarding vrf {name} - Shows labels allocated for the specified VRF # sh ip cef vrf {name} - Shows per-VRF FIB table # sh ip cef vrf {name} {ip-prefix} {detail} - Shows details of an individual CEF entry, including label stack

#ip extcommunity-list {no} {permit|deny} rt {no} - Creates an extended community-list

#route-map {name} {permit|deny} [seq] #match .... - Matches the necessary #set extcommunity rt {value} [additive] - Attaches additional RTs in export-maps

- [additive] Will append this RT and not overwrite originals set

#vrf definition {name} - Multiprotocol equivalent of "ip vrf {name}"

#address-family {ipv4|ipv6} - Selectively enables the address-family #vrf upgrade-cli multi-af-mode {common|non-common} - Changes the existing VRF configuration to multiprotocol VRF configuration

#ip vrf {name} - Creates a new VRF or enters configuration of an existing VRF

- VRF names are case-sensitive - A VRF is not operational unless an RD is configured

#rd {route-distinguisher} - Assigns a route distinguisher to the VRF


TOC 136

- The format can be ASN:NN or A.B.C.D:NN #route-target export {rt} - Specifies an RT to be attached to routes exported from the VRF to MP-BGP #route-target import {rt} - Specifies what MP-BGP routes to import into a VRF instance #import map {route-map} - Configures VRF import filtering #export map {route-map} - Configures selective VRF export #vpn id {oui:vpn-index} - (o) Configures an additional VPN identifier for the VRF #maximum routes {limit} [warn-thres|warn-only] - Configures the maximum number of routes accepted into a VRF table

- [warn-threshold] Percentage value when a syslog message is logged - [warn-only] Creates a syslog error message when the maximum number of routes

exceeds the threshold #interface {int} #ip vrf forwarding {name} - This command associates an interface with a VRF

- This will remove the existing IP address if configured #router bgp {asn} #address-family ipv4 vrf {name} #neighbor {ip} maximum-prefix {limit} [threshold] [warning-only] [restart {interval}]

- Controls how many prefixes can be received from a neighbor - [Threshold] Percentage value when a syslog message is logged (default = 75%) - [Warning-only] Warning when exceeding appose to dropping the session - [Restart] Re-establish the dropped session after the time specified

XR-COMMANDS

# sh vrf {all|name} [detail] - Shows the list of all VRFs configured in the router # sh ipv4 vrf all interface brief - Shows a brief summary of all VRF interface (with IOS-XR interfaces belonging

to a VRF is not visible with "sh ip int brief" # sh route vrf {name} - Shows the VRF routing table # sh mpls forwarding vrf {name} - Shows labels allocated for the specified VRF # sh cef vrf {name} - Shows per-VRF FIB table # sh cef vrf {name} {ip-prefix} {detail} - Shows details of an per-VRF individual CEF entry, including label stack

#vrf {name} - Enters the VRF configuration mode

#address-family {ipv4 } unicast - Configures the address-family for the VRF #import route-target {rt} - Specifies what MP-BGP routes to import into a VRF instance #export route-target {rt} - Specifies an RT to be attached to routes exported from the VRF to MP-BGP #import route-policy {name} - Configures VRF import filtering #export route-policy {name} - Configures selective VRF export


#vrf {name} - Enters the BGP VRF configuration mode #rd {value|auto} - Assigns a route distinguisher to a VRF routes going into MP-BGP

- The format can be ASN:NN or A.B.C.D:NN #address-family {ipv4 } unicast - Enables the address-family for the VRF

#interface {int} - Enters interface configuration mode

#vrf {name} - Associates an interface with a VRF


TOC 137

PE to PE: MP-iBGP

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | Multiprotocol Label Switching Configuration Guide Library, Cisco IOS Release 12.4T | | MPLS: Layer 3 VPNs Configuration Guide| | Configuring MPLS Layer 3 VPNs | | Configuring the Core

Network

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR Software, Release 3.8 | | MPLS Configuration Guide | | Implementing MPLS Layer 3 VPNs on Cisco IOS XR Software | | Configuring the Core Network

- A protocol is required to carry VPNv4 routes between PE routers .

- RFC 2858 defines extensions to BGP, which enables i t to carry multiple network layer protocols . - The multi -protocol extensions are negotia ted between BGP peers using an optional capabilities parameter in the BGP Open message. - Multi -protocol extensions for BGP define two new BGP optional transitive attributes used to advertise or withdraw routes. - The attributes are MP_REACH_NLRI and MP_UNREACH_NLRI (Network Layer Reachabi lity In form ation). - The fi rs t two fields in these new attributes contain the AFI and the SAFI values. - The AFI (Address Family Identi fier) value identi fies the network layer protocol . - The SAFI (Subsequent Address Family Identi fier) value identi fies addi tional in formation about the type of NLRI carried. - When the BGP peers exchange the multiprotocol extension capabili ty, they also exchange AFI and SAFI numbers to identi fy what the other BGP peer is capable of.

- AFI Values > AFI 1 - IPv4 > AFI 2 - IPv6

- SAFI Values: > SAFI 1 - Unicast > SAFI 2 - Multicast > SAFI 3 - Unicast and Multicas t > SAFI 4 - MPLS > SAFI 128 - MPLS VPN

- Multiprotocol extensions within BGP are im plemented and configured as address-families (also known as contexts): >"address-family ipv4" - Enters the IPv4 BGP context. Configuration relates to BGP in the global table . >"address-family vpnv4" - Enters the VPNv4 MP-BGP context. Configuration relates to MP-BGP between PE routers . >"address-family ipv4 vrf name" - Enters the per VRF MP-BGP context. Configuration relates to per VRF BGP tables.

- MP-eBGP is also configured here, which is used for BGP communication between CE and PE routers .

- The exchange of routes with BGP neighbors are enabled by defaul t for the IPv4 address-family with IOS - If not required, this behavior can be disabled in two ways :

> For all IPv4 routes - "no bgp defaul t ipv4-unicas t". > For a specific neighbor - "no neighbor {ip} activate" (under the "address-family ipv4").

- The route exchange for all other address-families is disabled be defaul t. - If required the specified neighbors within an address-family can be enabled with "neighbor activate".


TOC 138

CONFIG-SET: MP-BGP- Limit the Route-Exchange for Neighbors to Specific Address-Families

| router bgp 65000 | neighbor 10.5.0.1 remote-as 65000 - Specifies the BGP neighbors | neighbor 10.5.0.5 remote-as 65000 | neighbor 10.5.0.9 remote-as 65000 | ! | no bgp default ipv4-unicast - Disables default IPv4 route exchange for all neighbors | address-family ipv4 - Enters the global BGP address-family | neighbor 10.5.0.1 activate - Manually enables IPv4 route exchange for these two neighbors | neighbor 10.5.0.5 activate | ! | address-family vpnv4 - Enter PE-PE MP-BGP configuration context | neighbor 10.5.0.5 activate - Manually enables VPNv4 route exchange for these two neighbors | neighbor 10.5.0.9 activate

IOS-COMMANDS

# sh ip bgp summary - Shows the global BGP neighbors and their session states # sh ip bgp neighbors [ip] - Shows the global BGP neighbors and their negotiated protocols # sh ip bgp vpnv4 all summary - Shows the VPNv4 BGP neighbors and their session states # sh ip bgp vpnv4 [all|rd|vrf{name}] labels - Shows the labels associated with VPNv4 routes # sh ip bgp vpnv4 vrf {name} - Shows the per-VRF VPNv4 BGP table # sh ip bgp vpnv4 all - Shows every VPNv4 BGP table # sh ip bgp vpnv4 rd {asn:nn} - Shows the VPNv4 routes matching the RD

#router bgp {asn}

#no bgp default ipv4-unicast - Disables the default exchange of IPv4 routes to all neighbors - Neighbors that need to receive IPv4 routes must then be activated manually

#neighbor {ip} remote-as {r-asn} - All BGP neighbors must be configured under global BGP config #neighbor {ip} update-source loopback0 - MP-iBGP sessions should run between loopback interfaces #address-family vpnv4 - Enters configuration of VPNv4 route exchanges for MP-iBGP sessions #neighbor {ip} activate - Enables the neighbor for VPNv4 route exchange #neighbor {ip} next-hop-self - Changes the next-hop IP to the local router's sending address #neighbor {ip} send-community [std|ext|both] - Extended communities are required for RT propagation

- It is enabled by default when neighbors are activated for VPNv4 #no neighbor {ip} activate - Disables route exchange on a per neighbor basis under the address-family

XR-COMMANDS

# sh bgp neighbors [ip] - Shows the global BGP neighbors and their negotiated protocols # sh bgp vpnv4 unicast neighbors [ip] - Shows the VPNv4 BGP neighbor statistics and information # sh bgp vpnv4 unicast summary - Shows the VPNv4 BGP neighbors and their session states # sh bgp vpnv4 unicast vrf {name} - Shows the per-VRF VPNv4 BGP table # sh bgp vpnv4 unicast[rd|vrf{name}] labels - Shows the labels associated with VPNv4 routes


TOC 139

#router bgp {asn} - Enters the BGP configuration mode #bgp router-id {ip} - Configures the RID for BGP Process #neighbor {ip} - Enters the BGP neighbor configuration mode #remote-as {asn} - Defines an external/internal neighbor #update-source {int} - Specifies the source interface for the TCP session that carries BGP traffic #address-family vpnv4 unicast - Enables the BGP VPNv4 unicast address-family for the neighbor #send-community-ebgp - Enables the sending of standard communities in outgoing EBGP updates #send-extended-community-ebgp - Enables the sending of extended communities in outgoing EBGP updates

(Enabled by default for iBGP sessions) #next-hop-self - Instructs iBGP to use this router as the next-hop for routes advertised

PE to CE: Connected & Static Routes

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 3.8 | | MPLS Configuration Guide | | Implementing MPLS Layer 3 VPNs on Cisco IOS XR Software | | Configuring Static Routes Between the PE and CE Routers

- The connected addresses, PE-to-CE address ranges, should be redis tributed in to MP-BGP to ensure end-to-end connectivi ty.

- If MP-BGP advertise static routes within an MPLS VPN, they m ust be redis tributed in to MP-BGP on the configured PE router. - With static routes a next-hop IP mus t be specified i f a non-point-to-point interface is used.

IOS-COMMANDS

#ip route vrf {name} {prefix} {mask} {[interface] [next-hop]} [global] [permanent] [tag {tag}] - Configures static route within a VRF - [global]: The next-hop will be in the non-VRF global routing table - [permanent]: Route stays in the RIB even if next-hop disappears

#router bgp {asn} #address-family ipv4 vrf {name} #redistribute static - Redistributes local VRF static routes into MP-BGP #redistribute connected - Redistributes connected VRF routes into MP-BGP

XR-COMMANDS

#router static #vrf {name} #address-family ipv4 unicast #{prefix/mask} {[interface] [next-hop]} [permanent] [tag {tag}]

- Configures static route within a VRF - [permanent]: Route stays in the RIB even if next-hop disappears


#vrf {name} - Enters the BGP VRF configuration mode #address-family ipv4 unicast - Enters the BGP VRF IPV4 unicast configuration mode


TOC 140

#redistribute static - Redistributes local VRF static routes into MP-BGP #redistribute connected - Redistributes connected VRF routes into MP-BGP

PE to CE: RIPv2

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | Multiprotocol Label Switching Configuration Guide Library, Cisco IOS Release 12.4T | | MPLS: Layer 3 VPNs Configuration Guide, Cisco IOS Release 12.4T | | Configuring MPLS Layer 3 VPNs |

| Configuring RIPv2 as the Routing Protocol Between the PE and CE Routers

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 3.8 | | MPLS Configuration Guide | | Implementing MPLS Layer 3 VPNs on Cisco IOS XR Software | | Configuring RIPv2 as the Routing Protocol Between the PE and

CE Routers

- Only RIPv2 is supported for PE-CE routing. - RIPv2 s upports the use of address-families within the RIP process. - The RIPv2 routes for a VRF should be redis tributed in to MP-BGP on the ingress PE router and back in to RIP on the egress PE router.

- For end-to-end RIP networks , the following applies : > On the ingress PE router, the RIP hop-count is copied in to the BGP MED by defaul t. > On the egress PE router, the RIP hop-count mus t be manually set for routes redis tributed back in to RIP, using the fol lowing methods :

>> Using a defaul t metric for all RIP redis tributed routes with "defaul t metric". >> Setting the hop-count in the "redis tribute" command (this overwri tes the defaul t metric). >> Using the 'metric transparent' option to copy the BGP MED in to the RIP hop-count (o ften used for a consistent end-to-end RIP hop-count).

IOS-COMMANDS

# sh ip route vrf {name} rip - Shows the RIP routes in the VRF-RIB table

#router rip

#version 2 - Version 2 must be used to support MPLS VPN #address-family ipv4 vrf {name} - Creates a VRF context within RIP routing process #default-metric {hop-count} - Configures the default metric for redistributed VRF routes #redistribute bgp {asn} metric 5 - Redistributes MP-BGP routes into RIP. Manually sets the RIP metric to 5 #redistribute bgp {asn} metric transparent - Redistributes MP-BGP routes. Copies the BGP MED into the RIP hop-count

#router bgp {asn}

#address-family ipv4 vrf {name} - Enters the MP-BGP VRF-context #redistribute rip - Redistributes RIP routes into MP-BGP. RIP hop-count is copied to BGP MED #no auto-summary - Disables auto-summarization

XR-COMMANDS

# sh route vrf {name} rip - Shows the RIP routes in the VRF-RIB table


TOC 141

#router rip #vrf {name} - Activate the VRF for RIP processing #default-metric {hop-count} - Configures the default metric for redistributed VRF routes #interface {int} - Activate RIP on the VRF interface #redistribute bgp {asn} [local|ext|int] [route-pol]- Redistributes MP-BGP routes into RIP, optionally based on route-type


#vrf {name} - Enters the BGP VRF configuration mode #address-family ipv4 unicast - Enters the BGP VRF IPV4 unicast configuration mode #redistribute rip [route-policy] - Redistributes RIP into MP-BGP

PE to CE: EIGRP


| Configuring EIGRP as the Routing Protocol Between the PE and CE Routers

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 3.8 | | MPLS Configuration Guide | | Implementing MPLS Layer 3 VPNs on Cisco IOS XR Software | | Configuring EIGRP as the Routing Protocol Between the PE and

CE Routers

- EIGRP supports the use of address-families within the EIGRP process. - The EIGRP routes for a VRF should be red istributed in to MP-BGP on the ingress PE router and back in to EIGRP on the egress PE router. - The EIGRP AS-number for each VRF mus t be specified within each EIGRP VRF context. - The metric of an EIGRP route is copied in to the BGP MED attribute when redis tributed in to MP-BGP at ingress. - When an MP-BGP route is redis tributed in to EIGRP, the BGP MED is NOT copied back to the EIGRP metric. - The EIGRP metric mus t be manually s et, otherwise the routes wi ll not be advertised to the CE router:

> Using a defaul t metric for all EIGRP red istributed routes . > Setting the metric in the "redis tribute" command (th is overwri tes the defaul t metric).

- If the same EIGRP AS-number is used between VPN CE si tes : > In ternal EIGRP routes from one VPN site will be learned as in ternal EIGRP routes in other VPN sites. > External EIGRP routes from one VPN site wi ll remain as external EIGRP routes .

- If the di fferent AS-numbers are used between VPN CE s i tes : > In ternal EIGRP routes from one VPN site will be learned as external EIGRP routes in other VPN sites. > External EIGRP routes from one VPN site wi ll remain as external EIGRP routes .

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: EIGRP Configuration Guide, Cisco IOS Release 12.4T | | EIGRP MPLS VPN PE-CE Site of Origin

- EIGRP SoO

> The SoO (Si te-of-Origin) BGP extended communi ty can be used to prevent loops in dual -homed scenarios or when a backdoor l ink is configured between di fferent VPN CE sites.


TOC 142

> A unique SoO value m us t be configured for each VPN CE si te . > When a router receives a route on an in terface with a si temap configured and the SOO of the route matches the configured SoO, the route is rejected. > This value should be used on the PE-CE in terface.

IOS-COMMANDS

# sh ip route vrf {name} eigrp - Shows the EIGRP routes in the VRF-RIB table

#router eigrp {asn}

#address-family ipv4 vrf {name} - Creates a VRF context within EIGRP routing process #autonomous-system {asn} - Configures the VRF AS-number #default-metric {b d l r m} - Configures the default metric for redistributed routes #redistribute bgp {asn} metric {b d l r m} - Redistributes MP-BGP routes and sets the EIGRP composite metric #no auto-summary - Same as normal EIGRP, recommended to turn this off

#router bgp {asn}

#address-family ipv4 vrf {name} - Enters the MP-BGP VRF-context #redistribute eigrp {asn} - Redistributes EIGRP into MP-BGP

#route-map {mapname} permit {seq} - Creates the site-map route-map

#set extcommunity soo {xx:yy} - Specifies the SOO extended community #interface {int} #ip vrf sitemap {mapname} - Applies the SOO extended community attribute to routing updates on the

interface

XR-COMMANDS

# sh route vrf {name} eigrp - Shows the EIGRP routes in the VRF-RIB table # sh eigrp vrf {name} ipv4 neighbor - Shows the per-VRF EIGRP neighbors # sh eigrp vrf {name} ipv4 interface - Shows the per-VRF EIGRP enabled interfaces

#router eigrp {asn} - Enters the EIGRP process configuration mode

#vrf {name} - Creates a VRF context within EIGRP routing process #address-family ipv4 #no auto-summary - Same as normal EIGRP, disabled auto-summarization at classful boundary #autonomous-system {asn} - Configures the VRF AS-number #default-metric {b d l r m} - Configures the default metric for redistributed routes #redistribute bgp {asn} [route-policy] - Redistributes MP-BGP routes and sets the EIGRP composite metric #interface {int} - Enables per-VRF processing on the interface #site-of-origin {value} - Configures SoO on the interface


#vrf {name} - Enters the BGP VRF configuration mode #address-family ipv4 unicast - Enters the BGP VRF IPV4 unicast configuration mode #redistribute eigrp {pid} [route-policy] - Redistributes EIGRP into MP-BGP

- The EIGRP composite metric is encoded in the EIGRP cost community for redistributed routes


TOC 143

PE to CE: OSPF


| Configuring OSPF as the Routing Protocol Between the PE and CE Routers

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 3.8 | | MPLS Configuration Guide | | Implementing MPLS Layer 3 VPNs on Cisco IOS XR Software | | Configuring OSPF as the Routing Protocol Between the PE and

CE Routers

- OSPF is not ful ly VPN-aware and does not support address-families. Ins tead OSPF requires a separate process per VPN. - The OSPF routes for a VRF should be redis tributed in to MP-BGP on the ingress PE router and back in to OSPF on the egress PE router. - The 'subnets ' keyword is s till a requi rement with OSPF to avoid the red istribution of only classful networks . - PE routers are seen as ABRs (Area Border Routers) and an MPLS VPN backbone is seen as a super Area 0. - Several extended BGP communi ties were defined to carry OSPF route types and area types across an MPLS VPN backbone. - The cost of an OSPF route is copied in to the BGP MED attribute when the route is redis tributed in to MP-BGP at ingress. - By defaul t, OSPF to MP-BGP at PE redistributes in tra-area and in ter-area routes only. It does not redis tribute external routes . - Redistributing external routes mus t be explicitly specified using the "match in ternal external" command

- When an MP-BGP route is redis tributed in to OSPF the value of the MED is used to set the cost of the redis tributed routes. - This defaul t behavior can be overwri tten by:

> Setting a defaul t metric for all OSPF redis tributed routes. > Setting the metric in the "redis tribute" command (th is overwri tes the defaul t metric).

- Routes redis tributed from BGP in to OSPF appear as in ter-area summary routes or as external routes based on thei r original LSA type. - Rules for MP-BGP routes redistributed in to OSPF:

> For original Type-1 or Type-2 LSAs, the redis tributed routes will appear as in ter-area s ummary LSA (Type-3). > For original Type-3 LSAs, the redis tributed routes will appear as in ter-area summary LSA (Type-3). > For Type-5 LSAs, the LSAs are re-originated as Type-5 LSAs with the egress PE as a ASBR. > For Type-7 LSAs, the LSAs are announced as Type-5 LSAs (since the route has al ready crossed area boundaries). > For non-original OSPF routes, normal BGP-OSPF redis tribution rules apply (defaul t LSA Type 5, route-type E2 and metric of 20).

- OSPF Domain-ID > Domain-ID is one of the new BGP extended communi ties used to recons truct an original OSPF route. > A domain-ID can be used to indicate that routers using di fferent process-IDs belong to the same OSPF domain. > By defaul t the domain-ID is set equal to the OSPF router process-ID. > If two PE routers use di fferent OSPF process-IDs for the same VPN, the domain-ID should be m anually set, otherwise all routes between the two VPN sites wil l appear as

Type-5 external .

- OSPF Down-Bi t > The down-b i t is set in the options field of Type-3 LSA headers by egress PE routers to prevent loops (PE1-to-CE-to-PE2). > PE routers will never redis tribute OSPF routes in to MP-BGP i f the down-b i t is set.

- OSPF Domain-Tag > The domain-tag is set in the options field of Type-5 LSA headers by egress PE routers to prevent loops (PE1-to-CE-to-PE2). > The domain-tag is set to the configured value or the BGP AS-number is encoded in to the domain-tag.


TOC 144

> If a PE router receives an external route with the route tag matching i ts domain-tag, i t will not redis tribute the route in to the MPLS VPN.

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: OSPF Configuration Guide, Cisco IOS Release 12.4T | | OSPF Sham-Link Support for MPLS VPN

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Routing Configuration Guide | | Implementing OSPF on Cisco IOS XR Software | | OSPFv2 Sham Link Support for MPLS VPN

- Sham-Link > Scenario when required

>> When two sites belonging to the same area are in terconnected via MPLS backbone and they have a backdoor l ink. >> The backdoor l ink will always be preferred, as OSPF prefers in tra-area routes to in ter-area routes .

> A s ham-l ink is a logical in tra-area l ink across the MPLS backbone. > A separate /32 address space is required on each PE router for the sham-link. > This /32 mus t be advertised by MP-iBGP, not OSPF and m us t belong to the VRF. > I t is not possible to route tra ffic from one sham -link over another. > Sham -links get a defaul t cost of 1 i f the cost was not explicitly specified.

CONFIG-SET: MPLS OSPF Sham-Link between Two PEs (R1 and R2)

|R1# interface loopback1 - Creates a new loopback to use as sham-link end-point | ip vrf forwarding VPN - Must be part of the client VRF | ip address 10.5.1.1 255.255.255.255 - Can be any /32 IP address | ! | router ospf 1 vrf VPN - Enters the per-VRF OSPF process | area 0 sham-link 10.5.1.1 10.5.1.2 cost 3 - Creates the sham-link from 10.5.1.1 to 10.5.1.2 | redistribute bgp 1 subnets - Usual MPLS OSPF config on a PE router | network 10.5.18.0 0.0.0.255 area 0 - Enables OSPF on the PE-to-CE interface | router bgp 1 | address-family ipv4 vrf VPN | redistribute connected route-map loopback1 - This advertises Loopback1 to R2 via MP-BGP | redistribute ospf 1 vrf VPN match internal extern - Usual MPLS OSPF config on a PE router | |R2# interface loopback1 | ip vrf forwarding VPN | ip address 10.5.1.2 255.255.255.255 | !


TOC 145

| router ospf 1 vrf VPN | area 0 sham-link 10.5.1.2 10.5.1.1 cost 3 - Creates the sham-link from 10.5.1.2 to 10.5.1.1 | redistribute bgp 1 subnets - Usual MPLS OSPF config on a PE router | network 10.1.26.0 0.0.0.255 area 0 - Enables OSPF on the PE-to-CE interface | router bgp 1 | address-family ipv4 vrf VPN | redistribute connected route-map loopback1 - This advertises Loopback1 to R1 via MP-BGP | redistribute ospf 1 vrf VPN match internal external > > %OSPF-5-ADJCHG: Process 1, Nbr 10.5.1.1 on OSPF_SL0 from LOADING to FULL, Loading Done > - Shows the sham-link coming up

IOS-COMMANDS

# sh ip route vrf {name} ospf - Shows the OSPF routes in the VRF-RIB table # sh ip bgp vpnv4 vrf {name} {ip} - Shows the MP-BGP OSPF routes # sh ip ospf sham-links - Shows the operational status and info of all sham-links

#router ospf {pid} vrf {name} - Starts a separate OSPF routing process for every VRF

#network {network} {wildcard} area {area} - Enables OSPF on the PE-CE link #domain-id ospf {domain-id} - Manually specifies the OSPF domain-ID instead of using the process-ID value #domain-tag {value} - Manually specifies the value used in the OSPF domain-tag #default-metric {cost} - Configures the default metric for redistributed routes #redistribute bgp {asn} subnets - Redistributes MP-BGP routes into OSPF

- The subnets keyword is needed to avoid classful routes being from redistributed

#area {id} sham-link {src-ip} {dst-ip} cost - Configures a sham-link

#router bgp {asn}

#address-family ipv4 vrf {name} - Enters the MP-BGP VRF-context #redistribute ospf {pid} [match [internal] [ex1] [ex2]]

- Without the OSPF match keyword specified, only internal OSPF routes are redistributed into OSPF

XR-COMMANDS

# sh route vrf {name} ospf - Shows the OSPF routes in the VRF-RIB table


#vrf {name} - Starts a separate OSPF routing process for the VRF #redistribute bgp {asn} [metric] [metric-type] - Redistributes MP-BGP routes into OSPF #area {aid} - Enters the OSPF area configuration mode #interface {int} - Enables OSPF on the PE-CE link #sham-link {src-ip} {dst-ip} - Configures a sham-link #cost - Configures the cost of the sham-link



TOC 146

#vrf {name} - Enters the BGP VRF configuration mode #address-family ipv4 unicast - Enters the BGP VRF IPV4 unicast configuration mode #redistribute ospf {pid} [match [internal] [ex1] [ex2]] [metric] [route-policy]

- Without the OSPF match keyword specified, only internal OSPF routes are redistributed into OSPF

PE to CE: eBGP


| Configuring BGP as the Routing Protocol Between the PE and CE Routers

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | MPLS Configuration Guide | | Implementing MPLS Layer 3 VPNs on Cisco IOS XR Software | | Configuring BGP as the Routing Protocol Between the PE and CE

Routers

- To configure eBGP as a PE-CE routing protocol , a CE router is configured as an eBGP neighbor under the IPv4 VRF address-family.

- The neighbor m ust be activated under the address-family.

- AS-Override > AS-override is typ ical ly required i f the same AS-number is used on di fferent CE-sites in terconnected by MP-BGP. > The command "as-override" circum vents the defaul t BGP loop prevention by overrid ing the client AS-number. > If the fi rs t AS-number in the AS-path is equal to the neighboring CE site's AS-number i t is replaced with the provider AS-number. > If the client AS-number was prepended m ultiple times, all AS-number occurrences are replaced with the provider AS-number.

- Allowas-in > By defaul t, a BGP router cannot accept a prefix if the loca lly-configured AS-number is listed in the received AS-path l ist. > The command "allowas-in" circum vents the defaul t BGP loop prevention by ignoring the local AS-number in the AS-path l ist.

- SOO (Si te -Of-Orig in) > An extended communi ty used to prevent PE-CE-PE and CE-PE-CE routing loops in multi -hom ed envi ronments. > A route inserted in to a VRF is not propagated to the CE router i f the SOO attached of that route is equal to the SOO attribute associated with the CE router.

IOS-COMMANDS

# sh ip route vrf {name} bgp - Shows the eBGP routes in a VRF-RIB table # sh ip bgp vpnv4 vrf {name} - Shows the eBGP routes in the VRF MP-BGP table # sh ip bgp vpnv4 vrf {name} summary - Shows the configured neighbor per VRF along with their status

#router bgp {asn}

#address-family ipv4 vrf {name} - Configures/enters the MP-BGP VRF context #neighbor {ip|peer-group} remote-as {asn} - Configures an eBGP neighbor in the VRF context, not in the global BGP config #neighbor {ip|peer-group} activate - eBGP neighbors must to be activated #neighbor {ip|peer-group} as-override - PE router overrides client AS-number with its own AS-number


TOC 147

#neighbor {ip|peer-group} allowas-in {no} - CE router allows its local AS-number to be listed in a received AS-path list - {no} The number of times the local ASN can be listed from the LEFT

#route-map {mapname} permit {seq} - Configures SOO route-map

#set extcommunity soo {xx:yy} - Specifies the SSO extended community

#router bgp {asn}

#address-family ipv4 vrf {name} #ip vrf sitemap {mapname} - Applies a route map that sets SOO extended community attribute to inbound

routing updates received

XR-COMMANDS

# sh route vrf {name} bgp - Shows the eBGP routes in a VRF-RIB table # sh bgp vpnv4 unicast vrf {name} - Shows the eBGP routes in the VRF MP-BGP table

#route-policy {name} - Creates a route-policy to accept PE-CE eBGP routes

#pass #end-policy

#route-policy {name} - Creates a route-policy

#if extcommunity soo matches-any ({value1 }) then - References an inline SOO extcommunity set #pass

#endif #end-policy

#router bgp {asn} - Enters the BGP configuration mode on the IOS-XR PE router

#vrf {name} - Enters the BGP VRF configuration mod #rd {rd} - Specified the per-VRF RD #address-family ipv4 unicast - Activates the BGP VRF for IPv4 unicast #neighbor {ip} - Configures an eBGP neighbor in the VRF context #remote-as {asn} - Specifies the CE routers ASN #address-family ipv4 unicast - Enters the PE-CE IPv4 address-family #route-policy {name} in - On IOS-XR without a policy no eBGP routes are accepted #route-policy {name} out - On IOS-XR without a policy no eBGP routes are sent #as-override - PE router overrides client AS-number with its own AS-number #allowas-in {no} - CE router allows its local AS-number to be listed in a received AS-path list

#router bgp {asn} - Enters the BGP configuration mode on the IOS-XR CE router

#address-family ipv4 unicast - Activates the BGP VRF for IPv4 unicast #neighbor {ip} - Configures an eBGP neighbor in the VRF context #remote-as {asn} - Specifies the CE routers ASN #address-family ipv4 unicast - Enters the PE-CE IPv4 address-family #route-policy {name} in - On IOS-XR without a policy no eBGP routes are accepted #route-policy {name} out - On IOS-XR without a policy no eBGP routes are sent #allowas-in {no} - CE router allows its local AS-number to be listed in a received AS-path list


TOC 148

VRF-Lite (Multi-VRF CE)

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Routing: OSPF Configuration Guide, Cisco IOS Release 12.4T | | OSPF Support for Multi-VRF on CE Routers

- VRF-li te allows the CE router the abili ty to maintain separate VRF tab les, with the purpose of extending the privacy and securi ty of an MPLS VPN down to the branch-office interfaces .

- The CE router separates traffic between client networks using VRF tables. - The received route advertisements are inserted in to the VRF routing table associated with the in terface i t arrived on. - There is no MPLS functionali ty (LDP) on the CE router. - Any routing protocol supported by normal VRF can be used in a multi-VRF CE im plementation.

- OSPF Capabili ty VRF-Lite > This feature disables the down-bi t and domain-tag checks in OSPF. > The MPLS VPN PE routers advertise VPN routes with the down-b i t set to CE routers. > Since a CE router acts as the PE router with VRF-li te, these checks should be disabled, because i f a VRF-lite CE router receive routes with down-bi t set i t wil l discard

them . > If a VRF-li te CE router connects to other OSPF routers , the "capabili ty vrf-l i te" should be configured under the OSPF process.

CONFIG-SET: VRF-lite CE Configuration Example

| ip vrf BOB | description friendly-traffic | ip vrf BRUCE | description unfriendly-traffic | ! | interface fa2/0.10 | encapsulation dot1Q 10 | ip vrf forwarding BOB - Places the interface into the BOB VRF | ip address 10.0.12.1 255.255.255.252 | interface fa2/0.20 | encapsulation dot1Q 20 | ip vrf forwarding BRUCE - Places the interface into the BRUCE VRF | ip address 192.168.12.1 255.255.255.252 | ! | router ospf 1 vrf BOB | router-id 0.0.1.1 | network 10.0.0.0 0.0.255.255 area 0 | capability vrf-lite - Disables the down-bit and domain-tag checks in OSPF | router ospf 2 vrf BRUCE | router-id 0.0.1.2 | network 192.168.0.0 0.0.255.255 area 0 | capability vrf-lite - Disables the down-bit and domain-tag checks in OSPF |


TOC 149

IOS-COMMANDS

#router ospf {pid} #capability vrf-lite - Applies the multi-VRF capability to the OSPF process on CE routers

#ip vrf {name} - Enters the VRF configuration mode #rd {rd} - Specified the RD, (IOS requires a RD to be specified for VRF-lite)

#interface {int} - Enters the interface configuration mode #ip vrf forwarding {name} - Assigns a VRF to an interface

XR-COMMANDS

#vrf {name} - Enters the VRF configuration mode #address-family ipv4 unicast - Activates the IPv4 address-family for the VRF

#interface {int} - Enters the interface configuration mode #vrf {name} - Assigns a VRF to an interface

#router ospf {pid} #vrf {name} - Enters the VRF configuration mode #disable-dn-bit-check - Applies the multi-VRF capability to the OSPF process on CE routers


TOC 150

Troubleshooting MPLS L3VPNs

Figure 7-4: Troubleshooting MPLS L3VPNs

- Veri fying proper routing in formation flow end-to-end (le ft-to-right): > Is CEF enabled on the ingress PE1 router interface and other interfaces? PE1# sh cef in terface > Are the CE routes received b y an ingress PE1 router? PE1# sh ip route vrf {NAME}

> Is there PE-to-PE connectivi ty? PE1# ping {pe2-lo0} source {lo0} > Are the MP-iBGP neighbor sessions established? PE1# sh ip bgp vpnv4 * s ummary > Are VPNv4 routes propagated to other PE routers? PE1# sh ip bgp vpnv4 all {prefix/length}

> Do the routes redis tributed in to MP-BGP have proper extended communi ties? PE1# sh ip bgp vpnv4 vrf {NAME} {pre fi x} > Have the PE routers exchanged the i r allocated VPN labels? PE1# sh ip bgp vpnv4 all labels > Has PE1 received a VPN label for the destination prefix from PE2? PE1# sh ip bgp vpnv4 all labels | begin {prefix} > On PE1 does the BGP next-hop prefix have LDP label received from P? PE1# sh mpls forward ing-table {bgp-nh} > Confi rm the CEF entry is correct in the LFIB, with VPN and LDP label ! PE1# sh ip cef vrf {NAME} {p refi x} detail > Is there an end-to-end (PE1-to-PE2) LSP? Veri fy labels on all LSRs: ALL# sh mpls forward ing-tab le | in {̂label}

> Is the BGP route selection process working correctly? PE2# sh ip bgp vpnv4 vrf {NAME} {pre fi x} > Are the expected best routes installed in to the VRF-RIB on PE2? PE2# sh ip route vrf {NAME} {p refi x}

> If there are multiple equal cost links (CE1-to-PE1): >> Is only one route installed in the VRF-RIB on PE2? PE2# sh ip route vrf {NAME} {p refi x} >> Is BGP multipath enabled? PE2# sh run | i maxim um-paths.*address-fa

> Are routes redis tributed from BGP in to the PE2-CE2 routing protocol? PE2# sh ip route vrf {NAME} {p refi x} > Are IPv4 routes propagated to CE2 routers? CE2# sh ip route {prefix}


TOC 151

Bibliography


RFC-4364 BGP/MPLS IP Virtual Private Networks (VPNs) http ://www.ie tf.org/rfc/rfc4364.txt

RFC-2858 Multiprotocol Extensions for BGP-4 http ://www.ie tf.org/rfc/rfc2858.txt

RFC-5462 MPLS Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field http ://www.ie tf.org/rfc/rfc5462.txt


TOC 152



TOC 153

Chapter 8

MPLS – TE


TOC 154

Basic Operation

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Guide Library | | MPLS TE: Path Calculation and Setup Configuration Guide | | MPLS Traffic Engineering and Enhancements

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | MPLS Configuration Guide | | Implementing MPLS Traffic Engineering

- Path selection with conventional IP routing is based on the lowest cumulative cost of all paths to a given des tination. - IP routing decisions are made hop-by-hop with no regard for link load or link congestion. - MPLS TE (Traffic Engineering) is a tunnel technology that:

> Allows customizing the forward ing path between two routers in a network. > Can take link congestion between two end-points in to account. > Offers better load sharing capabili ty to avoid under-/over-utilized links.

- MPLS TE Components > LSR - Any router enabled with MPLS TE and RSVP with the purpose to transport RSVP labeled tra ffic (LDP is not required). > Head-end LSR - The LSR where the TE tunnel in terface is configured. The head-end determines the path of the tunnel . > Tail -end LSR - The LSR where the TE tunnel is terminated/ends . > TE tunnel in terface - The logical in terface on the head-end LSR configured with the tunnel parameters. > TE transi t in terface - Any in terface enabled to carry MPLS TE tra ffic. > Signaling protocol - On Cisco platforms RSVP is used exclusively to signal the TE tunnels and exchange label in form ation. > Link-s tate protocol - OSPF or IS-IS are capable of presenting the topology in formation and advertising the MPLS TE l ink resources. > Resources/Attributes - Configurable characteristics used to setup/forward a TE tunnel across a particular path.

- MPLS TE Archi tecture Figure 8-1: MPLS TE Architecture

> In the above figure, certain traffic can be forwarded along the path R11-R2-R3-R12 using MPLS TE instead of using the IGP shortes t path R11-R1-R12. > MPLS TE will build a LSP (Label Switch Path) from the source router R11 (head-end LSR) to the destination router R12 (tai l-end LSR). > Once the LSP is signaled and the labels are received, can tra ffic be forwarded from R11 to R12 using label swapping along the desired path. > A MPLS TE tunnel is unidi rectional , meaning that i f tra ffic should be re turned on the same path another MPLS TE tunnel is needed in the opposite direction.

- RSVP Label Propagation > The In tServ (In tegrated Services) QOS framework origina lly used RSVP to signal bandwidth reservations for QOS.


TOC 155

> The origina l RSVP s tandard was extended to carry an MPLS label and TE in formation (as specified in RFC-3209). > RSVP is used with MPLS TE to signal a LSP for a TE tunnel whether the path is buil t dynamically or defined explici tly. > RSVP use DOD (Downs tream-on-Demand) label distribution, meaning a label is only advertised ups tream once a label from the downs tream LSR is received. > RSVP and LDP are di fferent label protocols. LDP can be le ft disabled i f only TE is requi red.

> The RSVP Path message: >> Is used for signaling a TE tunnel and request resources at each LSR along the TE path, as determined by the head-end LSR. >> Carries the ERO (Explici t Route Object), which is a lis t of LSRs and interfaces a PATH messages should use to reach the ta il -end LSR. >> Also carries the label reques t, reques ting a label from the tai l-end LSR in order to setup the LSP from the head-end LSR to the tail -end LSR.

> The RSVP Resv message: >> Is sent by the tail -end LSR in response to the Path message back to the head-end LSR. >> Will fo llow same route the Path message followed, but in the reverse direction. >> Each LSR along the route that receives the Resv message, records the present label, allocates a local label to the requested TE tunnel and forwards that label

upstream. >> When the Resv message reaches the head-end with a label a LSP is considered signaled.

> RSVP uses di fferent message types used to tear down TE LSPs ei ther due to errors or configuration changes. > An optional fie ld , the RRO (Record Route Object) carried in the Path and Resv messages, m ay be used to record the LSRs a packet traversed.

> By defaul t the tai l-end LSR advertises an explici t null label (label = 0) towards the penul timate LSR. > When a penul timate LSR receives an explici t null label i t in terprets i t as an implici t null label (label = 3) on Cisco routers. > With an implici t nul l outgoing label, the penul timate LSR wil l remove the label i f only one label is present or pop the top label i f multiple labels are present. > This process is called PHP (Penul timate Hop Popping) and is similar to that of LDP. > If required to preserve the QOS label in formation up to the tai l-end LSR, the penul timate LSR should use an explici t null label. > With an expl ici t null outgoing label, the penul timate LSR will swap the top label with an explici t null label to preserve the QOS markings. > To enable th is behavior the penul timate LSR should in terpret the received explicit null label as is. > Configured with "m pls traffic-eng signalling in terpret explici t-nul l verbatim ".

- RSVP Path Signaling Example Figure 8-2: RSVP Path Signaling Example

1- R11 calculates the MPLS TE path above as R11-R2-R3-R12, before sending a RSVP Path message downs tream to R12 and requesting a label from R2. 2- R2 receives the Path message with a LRO (Label Request Object), does the necessary res ervations i f feasible and looks up the next-hop (R3) in the ERO before

forward ing the Path message. 3- R3 receives the Path message and goes through the same process as R2. 4- R12 (tai l-end LSR) receives the Path message, allocates a label (0) to the LSP and advertises the label upstream to R3 in a Resv message. 5- R3 (PHP LSR) receives the Resv message with a label (0) and in terprets i t as label (3). The OUT label (3) is placed in to the LFIB table . R3 assigns a local label (301) to


TOC 156

the LSP, i .e ., the 'IN label' in the LFIB and advertises i t ups tream to R2. 6- R2 receives the Resv message from R3 with a label (301) places i t in to the LFIB table as the OUT label. R2 assigns a local label (201) to the LSP, i .e ., the 'IN label' in

the LFIB and advertises i t upstream. 7- R11 receives the Resv message from R2 with a label (201) places i t in to the LFIB tab le as the OUT label. At th is point the one-way LSP is considered signaled.

- MPLS TE Traffic Forwarding Example Figure 8-3: MPLS TE Traffic Forwarding Example

1- An IP packet destined to R22 arrives on R11 with the next-hop in terface in the LFIB being the TE tunnel in terface. A label of 201 is imposed on the IP packet before the labeled packet is forwarded down to R2.

2- R2 receives a labeled packet with the top label (201) which matches a local IN label (201) in the LFIB. R2 performs a label swap (201>301) before forwarding the labeled packet down to R3.

3- R3 receives a labeled packet with the top label (301) which matches a local IN label (301) in the LFIB. The associated OUT label (3) indicates the top label m ust be popped. The exposed IP packet is forwarded down to R12.

4- R12 receives an IP packet with a IP des tination of R22 and performs a normal IP lookup to determine the next-hop in terface.

- Basic MPLS TE Configuration Steps > Enable CEF i f previously disabled (defaul t = enabled). > Enable MPLS TE global ly on all LSRs (between and including the head-end LSR and tai l-end LSR). > Enable MPLS TE under the link state protocol (OSPF or IS-IS) on all LSRs.

>> Speci fy the MPLS TE router ID (mus t be a loopback IP address). > Enable MPLS TE and RSVP on all TE transi t interfaces and specify the TE transi t in terface attributes. > Create the logical TE tunnel in terface on the head-end LSR and specify the TE tunnel in terface attributes .

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Guide Library | | MPLS TE: Path Calculation and Setup Configuration Guide | | MPLS Traffic Engineering and Enhancements | | Configuring OSPF for MPLS Traffic Engineering

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 3.8 | | MPLS Configuration Guide | | Implementing MPLS Traffic Engineering | | Configuring an OSPF Area of MPLS-TE

- Using MPLS TE with OSPF as the IGP > OSPF was extended through the use of opaque LSAs (L ink State Advertisement) to carry the necessary MPLS TE information (defined in RFC-2370).


TOC 157

> LSA Type 10 is primarily used for in tra-area MPLS TE. > LSA Type 10 is not forwarded beyond OSPF ABRs (Area Border Routers). > OSPF wi ll flood LSAs out when the fo llowing events occur:

>> Configuration changes. >> Link s tate changes. >> TE resource changes. >> Periodic flooding.

>>> OSPF periodic LSA flooding (defaul t = 30 m in) can be changed with "timers pacing lsa-group". >>> TE periodic in formation flooding (defaul t = 3 min) can be changed with "mpls tra ffic-eng link timers period ic-flooding".

CONFIG-SET: (IOS) MPLS TE Basic Configuration using OSPF

|The following commands must be configured on every participating MPLS TE LSR. |The TE tunnel configuration on the head-end LSR is not shown here. | | ip cef - Enables CEF globally if not enabled | mpls traffic-eng tunnels - Enables MPLS TE globally | ! | interface loopback0 | ip address 150.0.0.1 255.255.255.255 | ! | interface s1/0/0 | ip address 150.5.12.1 255.255.255.0 | mpls traffic-eng tunnels - Enables MPLS TE on a TE transit interface | ip rsvp bandwidth - Enables TE reserved bandwidth using default values | ! | router ospf 0 | router-id loopback0 | network 150.0.0.1 0.0.0.0 area 0 | network 150.5.12.1 0.0.0.0 area 0 | mpls traffic-eng router-id loopback0 - Specifies loopback0 as the MPLS TE RID | mpls traffic-eng area 0 - Enables MPLS TE for the backbone area |


TOC 158

CONFIG-SET: (IOS-XR) MPLS TE Basic Configuration using OSPF

|The following commands must be configured on every participating MPLS TE LSR. |The TE tunnel configuration on the head-end LSR is not shown here. | | interface loopback 0 | ipv4 address 150.0.0.10/32 | ! | router ospf 1 | mpls traffic-eng router-id loopback0 - Specifies loopback0 as the MPLS TE RID | area 0 | mpls traffic-eng - Enables MPLS TE for the backbone area | ! | mpls traffic-eng - Enters the TE configuration mode | interface gi0/1/0/0 - Enables MPLS TE on a TE transit interfaces | ! | rsvp - Enters the TE configuration mode | interface gi0/1/0/0 - Enables RSVP on a TE transit interfaces

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Guide Library | | MPLS TE: Path Calculation and Setup Configuration Guide | | MPLS Traffic Engineering and Enhancements | | Configuring IS-IS for MPLS Traffic Engineering

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | MPLS Configuration Guide | | Implementing MPLS Traffic Engineering | | Configuring IS-IS to Flood MPLS-TE Link Information

- Using MPLS TE with IS-IS as the IGP > The origina l IS-IS implementation was standardized in ISO 10589 and is referred to in MPLS TE terminology as old-s tyle IS-IS. > In tegrated IS-IS was extended to support MPLS TE (defined in RFC-3784), which is re ferred to as new-s tyle IS-IS. > The extensions specified in RFC-3784 m odi fies IS-IS in the following ways :

>> Removes the 6-bi t limi ta tion on IS-IS metrics. >> Allows in ter-area IP routes. >> Enables carrying the addi tional in formation requi red for MPLS TE.

> IS-IS was extended using three new TLVs (Type, Length, Value) to carry the necessary MPLS TE in formation. >> TLV 22 (Extended IS Reachability) describes the IS-IS neighbors and various MPLS TE attributes. >> TLV 134 (TE Router-ID) carries the 32-bi t RID of the head-end LSR that originates a TE tunnel . >> TLV 135 (Extended IP Reachabili ty) carries the 32-bi t metric and up/down bi t used for loop prevention.

> The LSPDB (LSP Database) is calculated di fferently for old-s tyle and new-style IS-IS. This means the two implementations are not compatible . > To transi tion to new-style IS-IS, two options are available:

>> Co-existence; run both old and new implementations concurrently. >> Migrate; where all IOS s oftware mus t be upgraded, configuration and m etrics are changed.

> The IS-IS m etric options avai lable: >> "m etric-s tyle narrow" - Enables the LSR to generate and accept only old-s tyle TLVs. >> "m etric-s tyle transi tion" - Enables the LSR to generate and accept both old-style and new-s tyle TLVs. >> "m etric-s tyle wide" - Enables the LSR to generate and accept only new-s tyle TLVs.


TOC 159

> IS-IS will flood LSPs out when the following events occur: >> Configuration changes >> Link s tate changes >> TE resource changes >> Periodic flooding

>>> IS-IS period ic LSP flooding (defaul t = 15 m in) can be changed with "lsp-refresh-in terval ". >>> TE periodic in formation flooding (defaul t = 3 min) can be changed with "mpls tra ffic-eng link timers period ic-flooding".

CONFIG-SET: (IOS) MPLS TE Basic Configuration Using IS-IS

|The following commands must be configured on every participating MPLS TE LSR. |The TE tunnel configuration on the head-end LSR is not shown here. | | ip cef - Enables CEF globally if not enabled | mpls traffic-eng tunnels - Enables MPLS TE globally | ! | interface loopback 0 | ip address 150.0.0.1 255.255.255.255 | ip router isis | ! | interface s1/0/0 | ip address 150.5.12.1 255.255.255.0 | ip router isis | mpls traffic-eng tunnels - Enables MPLS TE on the TE transit interface | ip rsvp bandwidth - Specifies the TE reserved bandwidth using default values | ! | router isis | network 47.0000.0000.0001.00 - Specifies the NET address | is-type level-2-only | metric-style wide - Enables new-style IS-IS metrics | mpls traffic-eng router-id loopback0 - Specifies loopback0 as the MPLS TE RID | mpls traffic-eng level-1 - Enables MPLS TE for level-1 |


TOC 160

CONFIG-SET: (IOS-XR) MPLS TE Basic Configuration Using IS-IS

|The following commands must be configured on every participating MPLS TE LSR. |The TE tunnel configuration on the head-end LSR is not shown here. | | interface loopback 0 | ipv4 address 150.0.0.10/32 | ! | router isis | address-family ipv4 unicast - Enters the IPv4 address-family configuration mode | metric-style wide - Enables new-style IS-IS metrics, "metric style transition" could also | mpls traffic-eng level-1-only be used if some none TE router are using narrow metrics | mpls traffic-eng router-id loopback0 - Specifies loopback0 as the MPLS TE RID | ! | mpls traffic-eng - Enters the TE configuration mode | interface gi0/1/0/0 - Enables MPLS TE on a TE transit interfaces | ! | rsvp - Enters the TE configuration mode | interface gi0/1/0/0 - Enables RSVP on a TE transit interfaces |

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Guide Library | | MPLS TE: Path Calculation and Setup Configuration Guide | | MPLS TE LSP Attributes

- TE Transit In terface Attributes

> Reservable Bandwidth >> Is the maxim um amount of bandwidth available for all MPLS TE traffic on an in terface. >> Also known as global -pool bandwidth. >> Configured with "ip rs vp bandwidth [kbps ]" on IOS. >> On IOS i f no value is specified, a value of 75% of the configured "bandwidth", else 75% of in terface bandwidth is used.

> Reservable Sub-Pool Bandwidth >> Is the maxim um amount of bandwidth available for DiffServ TE tunnels .

> TE Metric >> By defaul t the TE metric of a TE Transit in terface is the IGP m etric of that l ink. >> The TE m etric command can be used to influence the TE cost of an in terface, which overwri tes the IGP derived value. >> Configured with "mpls tra ffic-eng admin istra tive-weight". >> Refer to the TE Metric section below for more in formation.

> Attribute Flag >> Is an optional 32-bi t value used to determine i f an in terface may carry a particu lar TE tunnel . >> The attribute flag is m atched against the affini ty flag and m as k bi ts to determine TE tunnel admission. >> Configured with "mpls tra ffic-eng attribute-flags 0x{hex-va lue}".

- TE Tunnel In terface Attributes > Tunnel Des tination

>> Is the MPLS TE router ID of the ta il -end LSR where the TE tunnel should terminate. > Tunnel Bandwidth


TOC 161

>> Is the amount of bandwidth the TE tunnel requires to successfully s etup a LSP. >> Two types of bandwidth can be speci fied; global and s ub-pool bandwidth. >> Global bandwidth specifies the bandwidth requi red for normal TE tunnels. >> Sub-pool bandwidth specifies the bandwidth required for di ffserv TE tunnels. >> Copy subtly owned by James Gibson. >> Refer to the TE Tunnel Bandwidth section below.

> Tunnel Priorities >> Are used to define the importance of one TE tunnel compared to the next. >> There are two priori ties ; setup priori ty and hold priori ty. >> The priori ty values are 0-7, with a lower value indicating greater importance. >> The defaul t setup priori ty values is 7 and the defaul t hold priori ty value is 7. >> Setup Priori ty

>>> Is used during the tunnel signaling to determine i f the TE tunnel can preempt other TE tunnels. >>> The setup priori ty of the TE tunnel is compared against the hold priori ty of another exis ting TE tunnel .

>> Hold Priori ty >>> The hold priori ty will determine i f a new TE tunnel can preempt th is TE tunnel .

>> Configured with "tunnel mpls tra ffic-eng priori ty". > Path-Options

>> Determines the path a TE tunnel uses. >> Multiple path-options can be configured provided each uses different preference. >> The lowest preference numbered path-option wil l be used to setup the TE tunnel . >> When the lowes t path-option is not available anym ore, the next lowes t path-options will be used. >> The options available are dynamic and explici t. >> Dynamic Path-Option

>>> With this option only the TE tunnel destination is specified. >>> The head-end LSR uses the MPLS TE database in formation derived from OSPF/IS-IS to calculate the best path available given the constrain ts and resources.

>> Explicit Include Path-Option >>> The "next-address" option specifies the exact path the TE tunnel wil l traverse by including the transi t LSRs and the tai l-end LSR. >>> The MPLS TE router IDs of LSRs along the preferred path should be specified in the "expl ici t-path". >>> Al ternatively interface IP addresses along the path could be specified, e.g., i f the tunnel should be tied to a specific l ink between two LSRs. >>> How s trict the include option is, by defaul t, is determined whether forward or receive in terface IP addresses are used. >>> Forward addresses are the egress in terface IP address on a LSR, whereas a receive address is the IP address on the far-side of the same l ink. >>> Using receive addresses wi ll tie down a TE tunnel m ore strictly to a specified link when multip le links between two nodes are availab le.

>> Explicit Include Loose Path-Option >>> Specifying the 'loose' keyword in the "next-address" command allows for the next-hop LSR specified to not be di rectly connected. >>> Allows the head-end the flexib ili ty of using a di fferent path between two specified next-addresses, i f the in tended path is not avai lable.

>> Explicit Exclude Path-Option >>> The "exclude-address" option within the "explici t-path" lis t allows control over which links/LSRs should be excluded from the LSP path calculation. >>> Excluding a TE transi t in terface IP address, will exclude the l ink from LSP path calculations . >>> Excluding a LSR (by specifying the MPLS TE router ID), will exclude the LSR and all i ts connected links from LSP path calculations. >>> An "expl ici t-path" l ist may not have a m ix of include and exclude addresses.

> Affin ity Flag and Mask >> Is an optional 32-bi t value and m ask used to control TE tunnel admission onto TE transi t interfaces with corresponding attribute flags. >> The binary bi ts (expressed in HEX) of the flag value and m ask has no official format/m eaning. Its purpose is decided at wil l . >> The m ask determines which bi ts of the affin i ty flag value m us t match which bi ts of the link attribute flag. >> I.e ., i f the nth bi t in mask is 1, the nth bi t of the affini ty flag m us t match the nth bi t of the link attribute flag for successful TE admission >> Configured with "mpls tra ffic-eng affini ty 0x{ va lue} m ask 0x{m as k}".


TOC 162

- MPLS TE Path-Options Example Figure 8-4: MPLS TE Path Options Example

> In the diagram a TE tunnel is bui l t from R11 to R12 with three di fferent path-options. > Path-option 1 is an explicit include path fo llowing the path R11-R1-R3-R12. > Path-option 2 is an explicit exclude path bypassing R1 and all i ts l inks . > Path-option 3 is a dynamic path, which wi ll be based on the least cost IGP path available at the time. > Path-option 1 being the lowes t preference wi ll be signaled firs t. If successful i t will be used. > If path-option 1 is unsuccessful, path-option 2 wi ll be signaled, otherwise path-option 3 wi ll be tried. > The label stack with MPLS TE over native IP consist of one label ; the TE label which is used to tunnel tra ffic hop-by-hop to the ta il-end LSR. > Refer to the Walk The LSP section below to see the CLI output.

CONFIG-SET: (IOS) MPLS TE Explicit Paths with Dynamic Path Backup

| ip explicit-path PATH13 - Creates an explicit path R11-R1-R3-R12 | next-address 150.0.0.1 - Loopback of R1 | next-address 150.0.0.3 - Loopback of R3 | next-address 150.0.0.12 - Loopback of R12 | ! | ip explicit-path PATH23 - Creates an explicit path avoiding R1 | exclude-address 150.0.0.1 - Loopback of R1 | ! | interface tunnel1 | ip unnumbered loopback 0 - Uses the local loopback 0 as the tunnel source | tunnel destination 150.0.0.12 - Specifies the tail-end LSR as R12 | tunnel mode mpls traffic-eng - Sets the tunnel mode to MPLS TE | tunnel mpls traffic-eng priority 1 1 - Sets the tunnel importance to the highest value | tunnel mpls traffic-eng autoroute announce | tunnel mpls traffic-eng path-option 1 explicit name PATH13 | - First path-option is an explicit include path | tunnel mpls traffic-eng path-option 2 explicit name PATH23 | - Second path-option is an explicit exclude path | tunnel mpls traffic-eng path-option 3 dynamic - Third path-option is dynamic


TOC 163

CONFIG-SET: (IOS-XR) MPLS TE Explicit Paths with Dynamic Path Backup

| explicit-path name PATH13 - Creates an explicit path R11-R1-R3-R12 | index 1 next-address ipv4 unicast 150.0.0.1 - Loopback of R1 | index 2 next-address ipv4 unicast 150.0.0.3 - Loopback of R3 | index 3 next-address ipv4 unicast 150.0.0.12 - Loopback of R12 | ! | explicit-path name PATH123 - Creates an explicit path avoiding R1 | index 1 exclude-address ipv4 unicast 150.0.0.1 - Loopback of R1 | ! | interface tunnel-te1 | ipv4 unnumbered Loopback0 - Uses the local loopback 0 as the tunnel source | autoroute announce | destination 150.0.0.12 - Specifies the tail-end LSR as R12 | priority 1 1 - Sets the tunnel importance to the highest compared to other tunnels | path-option 1 explicit name PATH13 - First path-option is an explicit include | path-option 2 explicit name PATH123 - Second path-option is an explicit exclude | path-option 3 dynamic - Third path-option is dynamic |

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Configuration Guides | | Part 3: MPLS TE Path Calculation and Setup | | Verbatim Path Support

- TE Verbatim Path > Allows an expl ici t include path-option to be setup using RSVP (wi th TE extensions) without the IGP topology in formation. > This supersedes the need for the IGP (OSPF or IS-IS) to support MPLS TE extension or be enabled for MPLS TE. > Verbatim LSPs are useful when in termediate LSRs do not support IGP extensions for MPLE TE. > Configured using the 'verbatim ' keyword in "tunnel mpls tra ffic-eng path-option explici t".

- TE Tunnel Reoptimization > Is the action of reevaluating the path a TE tunnel uses, to a more suitable path given the constrain ts and resources i f another path is available. > TE Tunnels can be reoptimized with one of the following:

>> Manually >>> TE tunnels can be forced to reoptimize using the "mpls tra ffic-eng reoptimize" command.

>> Link Recovery >>> If a l ink that a TE tunnel previously used, comes back up after a failure the TE tunnel wi ll not reoptimize to use i t. >>> This defaul t behavior can be changed with "mpls tra ffic-eng reoptimize events link-up".

>> Periodically >>> By defaul t TE tunnels are reoptimized every 60 minutes . >>> This timer could be changed globally for all TE tunnels using "m pls tra ffic-eng reoptimize timers frequency" commands . >>> A value of 0, disables periodic reoptimization globally for all TE tunnels. >>> To disable periodic reoptimization for a single TE tunnel , the 'lockdown' keyword should be specified with "path-option" command.

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Guide Library | | MPLS TE: Path Calculation and Setup Configuration Guide | | MPLS TE Configurable Path Calculation Metric for Tunnels


TOC 164

- TE Metrics > By defaul t the TE link metric value is derived from /equal to the IGP (OSPF or ISIS) metric. > This means each TE transi t in terface has two m etrics; the IGP metric and the TE link metric. > Changing the IGP cost of an in terface will change the derived TE l ink m etric value. Obviously th is wi ll affect IGP and MPLS TE calculations. > The TE l ink metric could be manually specified. Changing the TE link metric only affect the MPLS TE calculations to allow incongruent routing topologies. > The TE l ink metric is manually configured with "mpls traffic-end adminis tra tive -weight" under the TE transi t in terface. > By defaul t the cost of the TE tunnel in terface is the lowest IGP cost to the tail -end LSR, even i f the TE tunnel does not follow the least cost route. > The TE tunnel in terface can be configured to use ei ther the IGP link metrics or the TE l ink metrics with "tra ffic-eng path-selection metric".

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Configuration Guides | | Part 3: MPLS TE Path Calculation and Setup | | LSP Attributes | | Path-Option Selection for MPLS TE Tunnel LSPs

- TE Tunnel Bandwidth

> Is the amount of bandwidth a TE tunnel requires to be setup. > If the bandwidth amount is not available using the fi rs t path-option, the second path-option will be tr ied, and so on. > Configured on the TE tunnel in terface with "tunnel mpls tra ffic-eng bandwidth" for IOS and "s ignalled-bandwidth" for IOS-XR. > Path-Option Bandwidth Override

>> A path-option could have i ts own bandwidth amount specified which wi ll override the TE tunnel in terface bandwidth amount. >> This allows a second or thi rd path-option to requi re less bandwidth than the original amount in tended on the TE tunnel in terface. >> By defaul t i f bandwidth override is configured, the LSR will attempt to reoptimize the TE tunnel to the preferred path every 30 seconds. >> This feature was designed as a temporary reduction in bandwidth constrain ts . >> This reoptimization can be disabled using the 'lockdown' keyword after the 'bandwidth' keyword is specified. >> Bandwidth override being enabled can be veri fied with "show mpls tra ffic-eng tunnels ".

CONFIG-SET: TE Tunnel Bandwidth with Path-Option Bandwidth Override

| interface tunnel1 | ip unnumbered loopback 0 - Uses the local loopback 0 as the source | tunnel destination 150.0.0.12 - Specifies the TE end-point as R12 TE RID | tunnel mode mpls traffic-eng - Sets the tunnel mode to MPLS TE | tunnel mpls traffic-eng bandwidth 2000 - Specifies the TE tunnel bandwidth required in kbps | tunnel mpls traffic-eng path-option 1 explicit name PATH1 | - Path-option 1 will need 2000 kbps to be signaled | tunnel mpls traffic-eng path-option 2 dynamic bandwidth 1000 | - Path-option 2 will need 1000 kbps if option1 is unavailable

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Configuration Guides | | Part 3: MPLS TE Path Calculation and Setup | | Automatic Bandwidth Adjustment for TE Tunnels

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | MPLS Configuration Guide | | Implementing MPLS Traffic Engineering | | MPLS-TE Automatic Bandwidth Overview


TOC 165

- TE Auto-Bandwidth > The bandwidth allocated to TE tunnels can be auto adjusted based on largest sample of tra ffic flow between adjus tment in tervals . > This adjustm ent happens by defaul t once every 24 hours, but the adjus tment and s ampling intervals can be changed. > Configured with "tunnel mpls tra ffic-eng auto-bw" on IOS, or "auto-bw" on IOS-XR.

IOS-COMMANDS

# mpls traffic-eng reoptimize - Forces the recalculation the LSP a TE tunnel uses # sh ip ospf interface [brief] - Shows the OSPF information on the enabled interfaces # sh ip ospf neighbors - Shows the OSPF neighbor information # sh ip ospf database [opaque-area] - Shows the bandwidth amounts # sh isis database [verbose] - Shows the MPLS link resources, bandwidth amounts # sh isis mpls traffic-eng advertisements - Shows the MPLS link resources # sh mpls ldp discovery - Shows the LDP targeted sessions # sh mpls traffic-eng topology - Shows TE and IGP metrics for each link # sh mpls traffic-eng tunnels [tunnel-int] [brief] - Shows information about the configured TE tunnels # sh ip explicit-paths [name|detail] - Shows the configured explicit paths

#debug mpls packets - Shows the label information in MPLS packets

#debug ip rsvp dump-messages - Shows the negotiated parameters

>>> MPLS TE Global Configuration Commands <<<

#mpls traffic-eng tunnels - Enables MPLS TE globally #mpls traffic-eng link timers periodic-flooding {sec}- Changes the TE flooding interval (default = 3 min) #mpls traffic-eng reoptimize timers delay {install} - Sets the delay on new LSPs after reoptimization #mpls traffic-eng reoptimize events link-up - Enables reoptimization on link recovery #mpls traffic-eng reoptimize timers frequency {sec} - Changes the default 60 min periodic reoptimization timer #mpls traffic-eng auto-bw [frequency {sec}] - Enables automatic bandwidth adjustment for the LSR #mpls traffic-eng signalling advertise implicit-null {acl}

- Sets a tail-end LSR to advertise a implicit null label in accordance to RFC #mpls traffic-eng signalling interpret explicit-null verbatim

- Sets a PHP LSR to interpret a received explicit null label as-is

#router ospf {pid} >>> Configuring OSPF for MPLS TE <<<

#mpls traffic-eng area {area} - Enables MPLS TE for the indicated OSPF area #mpls traffic-eng router-id {interface} - Specifies the TE RID (router-id) #timers pacing lsa-group {sec} - Changes the OSPF LSA flooding interval (default = 30 min)

#router isis [pid] >>> Configuring IS-IS for MPLS TE <<<

#mpls traffic-eng {level-1|level-1-2|level-2-only} - Enables MPLS TE for IS-IS level specified #mpls traffic-eng router-id {interface} - Specifies the TE RID (router-ID) #metric-style wide - Generates and accept only new-style TLVs #lsp-refresh-interval {sec} - Changes the IS-IS LSP flooding interval (default = 15 min)

#ip explicit-path {name {name}|id} {enable|disable] >>> Configures an Explicit Include Path <<< #next-address [loose] {ip} - Specifies the next-hop address

- [loose] Allows additional hops between next-addresses


TOC 166

#ip explicit-path {name {name}|id} {enable|disable] >>> Configures an Explicit Exclude Path <<< #exclude-address {ip} - Excludes a specific link or an entire LSR and its links

#interface {interface} >>> Configuring the TE transit interface <<<

#mpls traffic-eng tunnels - Enables MPLS TE on a transit interface #ip rsvp bandwidth [kbps] [sub-pool {kbps}] - Sets the maximum reservable TE tunnel bandwidth on a transit interface

- (default = 75% of the configured "bandwidth" or interface bandwidth) #mpls traffic-eng attribute-flags 0x{value} - Sets the interface attribute value #mpls traffic-eng administrative-weight {te-metric} - Sets the TE link metric/administrative-weight

#interface tunnel{no} >>> Configuring the TE tunnel interface <<<

#ip unnumbered loopback {no} - Enables IP processing on the interface #tunnel destination {tail-end-te-rid} - Specifies the MPLS TE route-id of the tail-end LSR #tunnel mode mpls traffic-eng - Sets the tunnel mode to MPLS TE #tunnel mpls traffic-eng bandwidth {kbps} [sub-pool {kbps}]

- Sets the desired bandwidth of the TE tunnel #tunnel mpls traffic-eng auto-bw [frequency] [max-bw] [min-bw]

- Enables automatic bandwidth adjustment for the LSR #load-interval {seconds} - Changes the interval over which the auto-bw rates are averaged #tunnel mpls traffic-eng record-route - Enables recording the LSRs along the TE tunnel path #tunnel mpls traffic-eng priority {setup} [hold] - Sets the importance of the TE tunnel #tunnel mpls traffic-eng affinity 0x{value} mask 0x{mask}

- Sets the TE tunnel affinity flag and mask values #tunnel mpls traffic-eng path-option {priority} {dynamic|explicit} [lockdown] [verbatim]

- Configures the TE tunnel path-option as dynamic or explicit - {dynamic} Specifies a dynamic LSP to be calculated - {explicit} Specifies the path of the LSP is an IP explicit path - [lockdown] Disables LSP re-optimization - [verbatim] Bypasses IGP topology database information, used only with

explicit paths #traffic-eng path-selection metric {igp|te} - Specifies the metric type used on the TE tunnel

XR-COMMANDS

# mpls traffic-eng reoptimize - Forces the recalculation the LSP a TE tunnel uses # sh ospf interface [brief] - Shows the OSPF information on the enabled interfaces # sh ospf neighbors - Shows the OSPF neighbor information # sh ospf database [opaque-area] [ip] - Shows the TE database attributes, bandwidth amounts # sh isis database [verbose] - Shows the MPLS link resources, bandwidth amounts # sh isis mpls traffic-eng advertisements - Shows the TE database attributes, bandwidth amounts # sh mpls ldp discovery - Shows the LDP targeted sessions # sh mpls traffic-eng topology - Shows the TE and IGP metrics for each link


TOC 167

# sh mpls traffic-eng tunnels [tunnel-int] [brief] - Shows information about the configured TE tunnels # sh explicit-paths [name|id] - Shows the configured explicit paths

>>> MPLS TE Global Configuration Commands <<<

#mpls traffic-eng - Enters the MPLE TE configuration mode #link-management timers periodic-flooding{sec} - Changes the TE flooding interval (default = 3 min) #reoptimize timers delay {install} {sec} - Sets the delay on new LSPs after reoptimization #reoptimize {sec} - Changes the default 60 min periodic reoptimization timer #auto-bw - Enables automatic bandwidth adjustment for the LSR #bw-limit min {amount} [max {amount}] - Sets the minimum and maximum bandwidth for a tunnel #collect-bw-only - Gathers data without adjusting bandwidth automatically #signalling interpret explicit-null verbatim - Sets a PHP LSR to interpret a received explicit null label as-is

#router ospf {pid} >>> Configuring OSPF for MPLS TE <<<

#mpls traffic-eng router-id {int} - Specifies the TE RID (router-ID) #area [aid}] - Enters the OSPF area configuration mode #mpls traffic-eng - Enables MPLS TE for the indicated OSPF area

#router isis >>> Configuring IS-IS for MPLS TE <<<

#address-family ipv4 unicast - Enters the IS-IS address-family configuration mode #metric-style wide - Generates and accept only new-style TLVs #mpls traffic-eng {level-1|level-1-2|level-2-only} - Enables MPLS TE for IS-IS level(s) specified #mpls traffic-eng router-id {int} - Specifies the TE RID (router-id)

#explicit-path name {name} >>> Configures an Explicit Include Path <<<

#index {no} next-address [loose|strict] ipv4 unicast {ip} - Specifies the next-hop address - [loose] Allows additional hops between next-addresses - [strict] Specifies the required next-hop (default)

#explicit-path name {name} >>> Configures an Explicit Exclude Path <<<

#index {no} exclude-address ipv4 unicast {ip} - Excludes a specific link or an entire LSR and its links

#mpls traffic-eng >>> Configuring the MPLS TE transit interfaces <<<

#interface {int} - Enables MPLS TE on a TE transit interface #attribute-flags 0x{value} - Sets the interface TE attribute value #admin-weight {te-metric} - Sets the TE link metric/administrative-weight

#rsvp >>> Configuring the RSVP Interfaces <<<

#interface {int} - Enables RSVP on a TE transit interface #bandwidth [kpbs] [sub-pool {kpbs}] - Sets the maximum reservable TE tunnel bandwidth on a transit interface

#interface tunnel-te{no} >>> Configuring the TE tunnel interface <<<

#ipv4 unnumbered {int} - Specifies the tunnel source interface #destination {ip} - Specifies the tail-end LSR #record-route - Enables recording the LSRs along the TE tunnel path


TOC 168

#priority {setup} [hold] - Sets the importance of the TE tunnel #signalled-bandwidth {kbps} - Sets the desired bandwidth of the TE tunnel #affinity 0x{value} mask 0x{mask} - Sets the TE tunnel affinity flag and mask values #path-selection metric {igp|te} - Specifies the metric type used on the TE tunnel #path-option {priority} {dynamic|explicit} [lockdown] [verbatim]

- Configures the TE tunnel path-option as dynamic or explicit - {dynamic} Specifies a dynamic LSP to be calculated - {explicit} Specifies the path of the LSP is an IP explicit path - [lockdown] Disables LSP re-optimization - [verbatim] Bypasses IGP topology database information, used only with

explicit paths

TE Tunnel Selection

- Traffic can be routed via the TE tunnel in di fferent ways once a TE tunnel is signaled. This section will cover those options.

- Using Static Routes > The use of static routing is stra ight forward; the tunnel in terface is simply specified as the next hop. > Configured with "ip route x.x. x. x y. y. y. y {tunnel -in t} " on IOS and "router s tatic; x. x. x. x/ yy { tunnel -in t}" on IOS-XR.

- Using PBR (Policy-Based Routing) > PBR also allows non-des tination classifications of tra ffic to be m apped to specific MPLS TE tunnels using a route-map. > Mapping tra ffic onto a tunnel is configured with in the policy route-map using "set in terface {tunnel -in t}".

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Guide Library | | MPLS TE: Path Calculation and Setup Configuration Guide | | MPLS Traffic Engineering and Enhancements

- Using Autoroute Announce > With autoroute announce IP prefixes downs tream from the tail -end LSR are inserted in to the RIB on the head-end LSR with the TE tunnel as the next-hop. > From the head-end LSR the TE tunnel wil l always be used for prefixes that are di rectly connected to the tai l-end LSR, even i f there is an IP path with a lower cost. > But for prefixes (a t least one hop) behind the ta il-end LSR (not directly connected) both TE and IP paths will be considered and be load-shared i f equal. > With autoroute the cost of IP prefixes where the TE tunnel is the next hop, is the lowest IGP cost calculated from the head-end to the ta il -end LSR. > By defaul t, th is cost is derived using the lowest IGP cost and not the IGP cost of the path the TE tunnel fo llows . > This is seen under 'Shortest Unconstrained Path In fo ' with the command "show mpls tra ffic-eng tunnels tunnel". > Configured on the TE tunnel in terface with "tunnel mpls tra ffic-eng autoroute announce". > The cost could be changed using "tunnel mpls tra ffic-eng autoroute {m etric}". > Autoroute avoids any risk of routing loops.

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Guide Library | | MPLS TE: Path Calculation and Setup Configuration Guide | | MPLS TE Forwarding Adjacency - Using Forwarding Adjacencies

> Forwarding adjacency requires a TE tunnel from the head-end to the tail -end and another TE tunnel from the tail -end to head-end. > With forwarding adjacency a set of bidi rectional TE LSPs are advertised by the OSPF or IS-IS as one logical link. > The logical l ink with its metric is used for normal IGP tra ffic routing.


TOC 169

> Configured on the TE tunnel in terface with "tunnel mpls tra ffic-eng forward ing-adjacency".

- Using Pseudowire Tunnel Selection > AToM/pseudowire tunnel support is covered in detail in the MPLS - L2VPN chapter.

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Guide Library | | MPLS TE: Path Calculation and Setup Configuration Guide | | MPLS TE Class-based Tunnel Selection

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | MPLS Configuration Guide | | Implementing MPLS Traffic Engineering | | Policy-Based Tunnel Selection

- Using CBTS (Class-Based Tunnel Selection)

> With CBTS tra ffic is forwarded onto di fferent TE tunnels between the same head-end and tail -end LSR based on COS (Class Of Service) values. > The EXP bi ts imposed by the head-end LSR is used, but only referenced after the QOS operation on a LSR to allow input COS values to be changed fi rs t. > One COS value cannot be load-balanced across multip le TE tunnels. > CBTS relies on autoroute announce to select the TE tunnels used (a .k.a . as a tunnel bundle). > CBTS tunnels are configured with the specific EXP values i t m us t carry or specified with the 'defau l t' keyword. > The 'defaul t' keyword option on a TE tunnel acts as a catch all EXP tunnel for unmatched EXP values.

Figure 8-5: MPLS TE Class-Based Tunnel Selection

> Here two TE tunnels are created to carry two di fferent sets of EXP classifications. > TE tunnel 1 will use the least cost dynamic path, whereas TE tunnel 2 will use an explici t path (R11-R2-R3-R12). > TE tunnel 1 will be used to carry all voice tra ffic marked with EXP 5 and all contro l tra ffic marked with EXP 6 and 7. > TE tunnel 2 will be used to carry all data traffic marked with EXP 1-4 along with the defaul t class. > The configuration below is shown for one di rection only (PE1 to PE2). The opposite di rection 's configuration is similar.


TOC 170

CONFIG-SET: MPLS TE using Class-Based Tunnel Selection

| interface tunnel 1 - Creates the EXP member TE tunnel | ip numbered loopback 0 | mpls traffic-eng tunnels | tunnel destination 150.0.0.11 - Specifies the tail-end LSR as PE2 | tunnel mode mpls traffic-eng | tunnel mpls traffic-eng bandwidth 20000 - Specifies the tunnel bandwidth amount | tunnel mpls traffic-eng exp 5 6 7 - Allocates EXP 5-7 marked packets to tunnel1 | tunnel mpls traffic-eng path-option 1 dynamic | ! | interface tunnel 2 - Creates the EXP member TE tunnel | ip numbered loopback 0 | mpls traffic-eng tunnels | tunnel destination 150.0.0.11 - Specifies the tail-end LSR as PE2 | tunnel mode mpls traffic-eng | tunnel mpls traffic-eng bandwidth 10000 - Specifies the tunnel bandwidth amount | tunnel mpls traffic-eng exp 1 2 3 4 default - Allocates all other EXP marked packets to tunnel2 | tunnel mpls traffic-eng path-option 1 explicit name R2R3 | ! | interface tunnel 10 - Creates the EXP master tunnel | ip unnumbered Loopback0 | mpls traffic-eng tunnels | tunnel destination 150.0.0.11 | tunnel mode mpls traffic-eng | tunnel mpls traffic-eng autoroute announce - Enables auto routing via the master TE tunnel | tunnel mpls traffic-eng exp-bundle master - Specifies TE tunnel 10 as the EXP master | tunnel mpls traffic-eng exp-bundle member tunnel1 - Specifies TE tunnel 1 as the EXP bundle member | tunnel mpls traffic-eng exp-bundle member tunnel2 - Specifies TE tunnel 2 as the EXP bundle member |

IOS-COMMANDS

# sh mpls traffic-eng autoroute - Shows the TE tunnels announces to the IGP # sh mpls traffic-eng forwarding-adjacency - Shows MPLS TE forwarding adjacency information # sh mpls traffic-eng topology [isis|ospf] - Shows the MPLS TE global topology information # sh mpls traffic-eng tunnels {tunnel} [brief] - Shows the information about the TE tunnels # sh mpls traffic-eng exp - Shows the configured vs. actual EXP values # sh mpls forwarding-table {prefix} detail - Shows the EXP tunnel selection for a prefix # sh ip ospf database - Shows the OSPF LSAs and database information # sh isis database - Shows the IS-IS LSPs and database information # sh ip cef [detail] - Shows the CEF prefix table

# debug mpls traffic-eng forwarding-adjacency - Shows messages for TE forwarding-adjacency events

#interface tunnel{no} - Enters the TE tunnel interface configuration mode


TOC 171

#ip unnumbered loopback {no} - Enable IP processing on the interface #tunnel destination {tail-end-te-rid} - Specifies the MPLS TE router id of the tail-end LSR #ip ospf cost {metric} - Associates an OSPF cost with the tunnel seen by OSPF #isis metric {metric|max} [level-1|level-2} - Associates an OSPF cost with the tunnel seen by OSPF #tunnel mpls traffic-eng forwarding-adjacency [hold] - Advertises a TE tunnel as a link in an IGP network #tunnel mpls traffic-eng autoroute announce - Installs downstream tail-end IP prefix into the RIB #tunnel mpls traffic-eng autoroute {metric} [absolute | relative]

- Sets the TE metric used by IGP for path calculation #tunnel mpls traffic-eng bandwidth {kbps} [sub-pool | global]

- Sets the required TE tunnel bandwidth #tunnel mpls traffic-eng exp {exp-values} [default] - Sets the EXP bits to be carried over the TE tunnel #tunnel mpls traffic-eng exp-bundle {master|member} - Sets the TE tunnel membership to the EXP bundle

XR-COMMANDS

# sh mpls traffic-eng autoroute - Shows the TE tunnels announces to the IGP # sh mpls traffic-eng forwarding-adjacency - Shows MPLS TE forwarding adjacency information # sh mpls traffic-eng topology [isis|ospf|brief] - Shows the MPLS TE global topology information # sh mpls traffic-eng tunnels {tunnel} [brief] - Shows the information about the TE tunnels # sh mpls forwarding {prefix} detail - Shows the EXP tunnel selection for a prefix # sh ospf database - Shows the OSPF LSAs and database information # sh isis database - Shows the IS-IS LSPs and database information # sh cef [detail] - Shows the CEF prefix table

#interface tunnel-te{no} - Enters the TE tunnel interface configuration mode

#ipv4 unnumbered loopback {no} - Enable IP processing on the interface #destination {ip} - Specifies the tail-end LSR #forwarding-adjacency [hold] - Advertises a TE tunnel as a link in an IGP network #autoroute announce - Installs downstream tail-end IP prefix into the RIB #autoroute {metric} [absolute | relative] - Sets the TE metric used by IGP for path calculation

MPLS TE FRR - Link and Node Protection

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Configuration Guides | | Part 5: Traffic Engineering: Path, Link and Node Protection | | MPLS TE - Link and Node Protection

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | MPLS Configuration Guide | | Implementing MPLS Traffic Engineering | | Fast Reroute

- FRR (Fast Reroute) > Is a MPLS technology that offers fas t recovery (as low as 50ms is possible).


TOC 172

> FRR protects MPLS TE LSPs/tunnels when a link or a node in the path fails. > FRR is defined in RFC-4090.

- FRR Terminologies > Protected LSP - A TE tunnel /LSP that has a backup tunnel associated, protecting i t along the path taken. > Protected l ink - A l ink carrying LSPs that has a backup tunnel bypassing i t. > Protected node - A LSR in the transi t path for LSPs that has a backup tunnel bypassing i t. > NHOP (Next-Hop) backup TE tunnel - A TE tunnel that can bypass a protected l ink. > NNHOP (Next-Next-Hop) backup TE tunnel - A TE tunnel that can bypass a protected node . > PLR (Point of Local Repair) - The head-end LSR of a backup TE tunnel . > MP (Merge Point) - The ta il -end LSR of a backup TE tunnel .

- FRR Link Protection > With link protection a backup tunnel is bui l t to the LSR on the far side of the protected l ink using a different path. > This backup TE tunnel is called a NHOP tunnel , since the backup tunnel is bui l t to the next-hop. > Protected LSPs wil l be minimally affected when the protected link goes down. > Routing should not be enabled across backup tunnels. > The s tatus of the backup TE can be verified with "show mpls tra ffic-eng fas t-reroute database s tate" on the PLR. > A s tatus of 'ready' means the backup TE tunnel is signaled correctly and ready to be used. > A s tatus of 'active' means the backup TE tunnel is in use and carrying tunnel tra ffic.

Figure 8-6: MPLS TE Link Protection using FRR


TOC 173

CONFIG-SET: MPLS TE Link Protection using Fast Reroute

|R2# | ip explicit-path name BCK23 enable - Creates the explicit path via R1 | next-address 150.0.0.1 | next-address 150.0.0.3 | ! | interface tunnel23 - Creates a backup tunnel via R1 to the MP | ip unnumbered loopback0 | tunnel mode mpls traffic-eng - No autoroute is used since this is a backup TE tunnel | tunnel destination 150.0.0.3 - The MP or tail-end LSR is R3 | tunnel mpls traffic-eng path-option 1 explicit name BCK23 | ! | interface serial2/1 | description link-to-R3 | ip address 150.2.3.2 255.255.255.0 | mpls traffic-eng backup-path tunnel23 - Enables TE tunnel 23 as the NHOP tunnel for R2-R3 link | |R11# | interface tunnel1 - A normal tunnel that might use the back path | ip unnumbered loopback0 | tunnel mode mpls traffic-eng | tunnel destination 150.0.0.12 | tunnel mpls traffic-eng autoroute announce | tunnel mpls traffic-eng path-option 1 explicit name PATH23 | tunnel mpls traffic-eng fast-reroute - Enables FFR with a NHOP backup path |

- FRR Node Protection > With node protection a backup tunnel is bui l t to a LSR one hop behind the protected LSR using a di fferent path. > This backup TE tunnel is called a NNHOP tunnel . > Protected LSPs wil l be minimally affected when the protected node goes down. > Routing should not be enabled across backup tunnels. > The s tatus of the backup TE can be verified with "show mpls tra ffic-eng fas t-reroute database s tate" on the PLR. > A s tatus of 'ready' means the backup TE tunnel is signaled correctly and ready to be used. > A s tatus of 'active' means the backup TE tunnel is in use and carrying tunnel tra ffic.


TOC 174

Figure 8-7: MPLS TE Node Protection using FRR

CONFIG-SET: MPLS TE Node Protection using Fast Reroute

|R2# | ip explicit-path name PROTECT-R3 enable - Creates a explicit path excluding R3 | exclude-address 150.0.0.3 | ! | interface tunnel212 - Creates a backup tunnel via R1 to the MP | ip unnumbered loopback0 | tunnel mode mpls traffic-eng - No autoroute is used since this is a backup TE tunnel | tunnel destination 150.0.0.12 - The MP or tail-end of the backup TE tunnel is R12 | tunnel mpls traffic-eng path-option 1 explicit name PROTECT-R3 | ! | interface serial2/1 | description link-to-r3 | ip address 150.2.3.2 255.255.255.0 | mpls traffic-eng backup-path tunnel212 - Enables TE tunnel 212 as the NNHOP tunnel | |R11# | interface tunnel1 | ip unnumbered loopback0 | tunnel mode mpls traffic-eng | tunnel destination 150.0.0.22 | tunnel mpls traffic-eng autoroute announce | tunnel mpls traffic-eng priority 1 1 | tunnel mpls traffic-eng path-option 1 explicit name PATH2321 | tunnel mpls traffic-eng fast-reroute node-protect - Enables FRR with a NNHOP backup path |

- Bandwidth Protection > NHOP and NNHOP backup tunnels can be used to guarantee specific am ounts of bandwidth. > By enabling bandwidth protection a backup path is only used when enough bandwidth is available for a protected LSP.

IOS-COMMANDS

# sh mpls traffic-eng tunnels brief - Shows a summary of TE tunnels # sh mpls traffic-eng tunnels backup - Shows information about the backup tunnels


TOC 175

# sh mpls traffic-eng tunnels {tunnel} protection - Shows the fast reroute protection on a primary LSPs # sh mpls traffic-eng fast-reroute database[detail] - Shows the status of the backup TE tunnel on the PLR # sh ip rsvp fast-reroute [detail] - Shows info, status and type of backup TE tunnel (NHOP or NNHP) # sh ip rsvp sender [detail] - Shows LSPs protected by backup tunnels. # sh ip rsvp reservation - Shows the FRR status at each hop this LSP traverses

#interface {int} >>> Configured on the PLR <<<

#mpls traffic-eng backup-path tunnel{no} - Assigns LSPs for the interface to use the backup TE tunnel

#interface tunnel{no} >>> Configured on the head-end of primary LSPs <<<

#tunnel mpls traffic-eng fast-reroute [node-protect] [bw-protect] - Enabled FRR to use link or node protection - [bw-protect] Enables bandwidth protection

XR-COMMANDS

# sh mpls traffic-eng tunnels backup - Shows information about the backup tunnels # sh mpls traffic-eng tunnels protection frr - Shows the fast reroute protection on a primary LSPs # sh mpls traffic-eng fast-reroute database [det] - Shows the status of the backup TE tunnel on the PLR # sh rsvp fast-reroute [detail] - Shows info, status and type of backup TE tunnel # sh rsvp sender [detail] - Shows LSPs protected by backup tunnels. # sh rsvp reservation - Shows the FRR status at each hop this LSP traverses

#mpls traffic-eng

#interface {int} >>> Configured on the PLR <<< #backup-path tunnel{te-no} - Assigns LSPs for the interface to use the backup TE tunnel

#interface tunnel-te{no} >>> Configured on the head-end of primary LSPs <<<

#fast-reroute - Enabled FRR to use link protection

Inter-Area MPLS TE

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Configuration Guides | | Part 3: Path Calculation and Setup | | Interarea Tunnels

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | MPLS Configuration Guide | | Implementing MPLS Traffic Engineering | | MPLS Traffic Engineering Interarea Tunneling

- In ter-area tunnels allow the MPLS TE head-end LSR and the tai l-end LSR to be in di fferent OSPF or IS-IS areas.

- In ter-area TE tunnels is buil t using an expl ici t loose path-option by specifying the MPLS TE router-IDs of the LSRs along the path. - Each LSR is responsible for calculating the path to the next-hop LSR in the ERO. - The autoroute destination feature (simi lar to autoroute announce) allows tra ffic to be automatical ly routed through a TE tunnel . - Restrictions of in ter-area TE tunnels


TOC 176

> Autoroute announce is not supported. > Dynamic path-option is not supported. > Affin ity flag and m ask values are not s upported for in ter-area TE tunnels .

IOS-COMMANDS

# sh mpls traffic-eng tunnels brief - Shows a summary of TE tunnels

#router ospf {pid}

#mpls traffic-eng router-id {int} - Specifies the MPLS TE RID #mpls traffic-eng area {aid} - Enables MPLS TE for the area

#router isis

#mpls traffic-eng router-id {int} - Specifies the MPLS TE RID #mpls traffic-eng {level-1|level2} - Enables MPLS TE for IS-IS area

#ip explicit-path name {name} - Defines the explicit path for the LSP

#next-address loose {lsr-rid} - Specifies the LSRs in the path of the TE tunnel

#interface tunnel{no}

#ip unnumbered {int} - Enables IP processing on the interface #tunnel destination {ip} - Specifies the tail end LSR router-id #tunnel mpls traffic-eng autoroute destination - Automatically routes traffic through a TE tunnel #tunnel mpls traffic-eng path-option {no} explicit name {name}

- Sets the explicit loose path-option

XR-COMMANDS

# sh mpls traffic-eng tunnels brief - Shows a summary of TE tunnels

#router ospf {pid}

#router-id {int} - Specifies the OSPF TE RID #mpls traffic-eng router-id {int} - Specifies the MPLS TE RID #area {aid} #mpls traffic-eng - Enables MPLS TE for the area

#router isis

#address-family ipv4 unicast - Enters the IPv4 address-family configuration mode #mpls traffic-eng {level-1|level2} - Enables MPLS TE for IS-IS area #mpls traffic-eng router-id {int} - Specifies the MPLS TE RID

#explicit-path name {name} - Defines the explicit path for the LSP

#index {no} next-address loose ipv4 unicast {ip} - Specifies the LSRs in the path of the TE tunnel

#interface tunnel-te{no} - Configuring the TE tunnel interface

#ipv4 unnumbered {int} - Specifies the tunnel source interface #destination {ip} - Specifies the tail-end LSR


TOC 177

#autoroute announce - Installs prefixes downstream from the tail-end LSR into the local RIB #path-option {priority} {dynamic|explicit} [lockdown] [verbatim]

- Configures the TE tunnel path-option as dynamic or explicit

MPLS VPNs over MPLS TE

- Up to now in the MPLS TE chapter, the only label signaling protocol used was RSVP with TE extension. - Basic MPLS TE does not use LDP or TDP, but when used with MPLS L3VPNs LDP and RSVP could both be used. - There are three common implementations of MPLS L3VPNs over MPLS TE:

> TE tunnels between MPLS PE routers . > A TE tunnel ending on a MPLS P router. > Per-VRF MPLS-TE Tunnels.

- MPLS TE Tunnels between MPLS PE routers > MPLS VPNs require an end-to-end transport LSP to carry VPN tra ffic. > With MPLS VPNs the VPN label should only be exposed on the egress PE routers that advertised the label. > MPLS TE could be used as the transport protocol between MPLS PE routers . This means LDP is not used and might not be required. > MPLS TE and RSVP should be configured on all TE transi t interfaces along the path between the PE routers . > The MPLS TE tunnels and VPNv4 MP-BGP sessions should be setup between the MPLS PE loopback IP addresses. > MPLS TE tunnels should be configured bi -directionally between a set of PE routers. > VPN tra ffic is forward via the MPLS TE tunnels when the VPNv4 MP-BGP next-hop is the loopback IP of the ta il -end PE router. > In th is scenario the label stack consists of two labels :

>> The TE label swapped at every hop is used to reach the egress PE router. >> The VPN label is used to identi fy the exi t-in terface on the egress PE router.

Figure 8-8: MPLS VPNs over MPLS TE PE-to-PE

> VPNv4 MP-BGP is setup between PE1 and PE2 as usual. > VRF12 is configured with CE1 and CE2 members of VRF12. > LDP is not enabled on any l ink. > Steps above:

1- An IP packet arrives at PE1 on a VRF12 in terface. The VPN label (17) previously received from PE2 and the TE label (100) received from P1 is imposed on the packet before the labeled packet is forwarded to P1.

2- P1 receives a packet with a top label (100) matching a IN label (100) in the LFIB. The IN label is swapped with the OUT label (200) before forwarded. 3- P2 receives a packet with a top label (200) matching a IN label (200) in the LFIB. The IN label is swapped with the OUT label (300) before forwarded.


TOC 178

4- P3 receives a packet with a top label (300) matching a IN label (200) in the LFIB. The OUT label (3) indicates the top label is popped before the packet is forwarded. 5- PE2 receives a packet with a top label (17) matching a IN label (17) in the LFIB. The las t label (VPN label ) is popped before the packet is forwarded out towards CE2.

> Refer to the Walk The LSP section below to see the output commands.

CONFIG-SET: MPLS VPN over MPLS TE - PE to PE

|On every TE LSR | mpls traffic-eng tunnels - Enables MPLS TE globally | ! | router ospf 1 | mpls traffic-eng router-id loopback0 - Specifies the MPLS TE RID | mpls traffic-eng area 0 - Enables MPLS TE for the backbone are | |On every TE transit interface | interface {int} | mpls traffic-eng tunnels - Enables MPLS on every TE transit interface | ip rsvp bandwidth - Enables RSVP signalling on the TE transit interface | |PE1 TE tunnel interface - The same TE tunnel configuration is applied to PE2, | interface tunnel0 but with the destination being PE1 | ip unnumbered loopback0 | tunnel mode mpls traffic-eng | tunnel destination 150.0.0.12 - Specifies the remote PE router loopback | tunnel mpls traffic-eng autoroute announce | tunnel mpls traffic-eng path-option 1 dynamic |

- A MPLS TE Tunnel Ending on a P Router > MPLS VPNs require an end-to-end transport LSP to carry VPN tra ffic. > With MPLS VPNs the VPN label should only be exposed on the egress PE routers that advertised the label. > A MPLS TE tunnel that terminates on a P router (tai l -end LSR) instead of a PE router, creates a problem since TE does not provide an end-to-end LSP anymore. > As a result of the PHP operation, packets wil l arrive on the tail -end P router with VPN label exposed. > The ta i l-end P router not having issued the VPN label will drop the packets or forward the packets onto the wrong LSP. > The correct behavior is for the tail -end P router to receive packets with a top label i t advertised to the ingress PE. > This problem is corrected b y having a label (for the onwards l ink) advertised using a targeted LDP session between the head-end and tail -end LSRs. > There are two ways to create the targeted LDP LSP between the head-end and tai l-end LSRs:

>> Active Targeted LDP Session >>> Requires the TE tunnel from the head-end LSR to the tail -end LSR enabled with "mpls ip". >>> A second TE tunnel from the ta il -end LSR to the head-end LSR with "mpls ip" m ust be configured. >>> The command "mpls ip" on the TE tunnel interfaces enables LDP hellos to establish a targeted LDP session over the TE tunnel .

>> Passive Targeted LDP Session >>> Requires the TE tunnel from the head-end LSR to the tail -end LSR enabled with "mpls ip". >>> Requires the tail -end LSR to accept and respond to the LDP hellos with "mpls ldp discovery targeted-hello accept".

> The targeted LDP sessions can be seen with "show mpls ldp discovery". > A targeted LDP session only addresses hal f of the problem . What about the link(s) between the ta il -end LSR and the egress PE. > An end-to-end transport LSP is s till required to carry the VPN tra ffic to the egress PE. > There are two ways to complete the end-to-end transport LSP:


TOC 179

>> Creating another MPLS TE tunnel from the tail -end LSR to the egress PE router. >> Or enable LDP on the l ink(s ) between the tai l-end LSR to the egress PE router.

> In th is scenario the label stack consists of three labels : >> The TE label swapped at every hop, used to reach the tail -end P router. >> The LDP label is used to protect the VPN label from the PHP process and help carry data to the egress PE router. >> The VPN label is used to identi fy the in terface on the egress PE router.

Figure 8-9: MPLS VPNs over MPLS TE PE-to-P

> VPNv4 MP-BGP is setup between PE1 and PE2 as usual. > VRF12 is configured with CE1 and CE2 members of VRF12. > A TE tunnel is setup to P3 using the path PE1-P1-P2-P3. > Steps above:

1- A passive targeted LDP session is setup between PE1 and P3. 2- LDP is enabled only on the P3-to-PE2 l ink. 3- An IP packet arrives at PE1 on a VRF12 in terface. The VPN label (16) received from PE2, the LDP label (303) received from P3 and the TE label (102) received from

P1 is imposed on the packet before the labeled packet is forwarded to P1. 4- P1 receives a packet with a top label (102) matching a IN label (102) in the LFIB. The IN label is swapped with the OUT label (201) before forwarded. 5- P2 receives a packet with a top label (201) matching a IN label (201) in the LFIB. The top label is popped before t he labeled packet is forwarded. 6- P3 receives a packet with a top label (303) matching a IN label (303) in the LFIB. The top label is popped before t he labeled packet is forwarded. 7- PE2 receives a packet with a top label (16) matching a IN label (16) in the LFIB. The las t label (VPN label ) is popped before the IP packet is forwarded out towards

CE2. > Refer to the Walk The LSP section below to see the output commands.

CONFIG-SET: MPLS VPN over MPLS TE - PE to P (Passive option)

|On every TE LSR | mpls traffic-eng tunnels - Enables MPLS TE globally | ! | router ospf 1 | mpls traffic-eng router-id Loopback0 - Specifies the MPLS TE RID | mpls traffic-eng area 0 - Enables MPLS TE for the backbone area |


TOC 180

|On every TE transit interface | interface {int} | mpls traffic-eng tunnels - Enables MPLS TE for the TE transit interface | ip rsvp bandwidth - Enables RSVP signalling | |PE1 TE tunnel interface - Configuration on the head-end PE router | interface tunnel0 | ip unnumbered loopback0 | tunnel mode mpls traffic-eng | tunnel destination 150.0.0.3 - Specify the destination as P3 | tunnel mpls traffic-eng autoroute announce | tunnel mpls traffic-eng path-option 1 dynamic | mpls ip - Enables transmitting targeted LDP hellos via TE tunnel | |On P3 - Configuration on the tail-end LSR | mpls ldp discovery targeted-hello accept - Enables responding to targeted LDP hellos | ! | interface s2/1 | mpls ip - Enables LDP on the P3-to-PE2 link | |On PE2 - Configuration on the egress PE router | interface s2/0 | mpls ip - Enables LDP on the P3-to-PE2 link |

- Per-VRF MPLS-TE Tunnels > I t could be useful to di rect some client VRFs on a cheaper path while directing higher paying cl ient VRFs onto a low latency path. > This solution allows routing traffic from a VRF onto a TE tunnel instead of fo llowing the defaul t path to the egress PE router. > The configuration is pretty s traight forward:

>> A TE tunnel is configured on the ingress PE to take a user defined path to the egress PE router and vice versa. >> A new loopback IP address is specified to be used for VPNv4 next-hop processing. >> The new BGP next-hop address must be routed via the TE tunnel . >> For the VRF(s) that wil l be routed via the TE tunnel , a di fferent BGP next-hop is specified with in VRF.

Figure 8-10: MPLS VPNs over MPLS TE – Per-VRF TE Example

> The least cost route for VRF tra ffic between the PE1 and PE2 is via P1.


TOC 181

> All VPN tra ffic will follow the route PE1-P1-PE2 by defaul t. > Let's assume traffic for VRF34 between CE3 and CE4 should take the path PE1-P2-P3-PE2. > TE tunnel 34 is buil t via P2 and P3 from PE1 to PE2 and from PE2 to PE1. > All VRF34 tra ffic is mapped onto TE tunnel 34. > The PE1 configuration shown below. PE2's configuration wi ll be identical with only the destination and loopback addresses being di fferent. > In th is scenario the label stack for VRF34 consists of two labels :

>> The TE label swapped at every hop and used to reach the egress PE router. >> The VPN label is used to identi fy the in terface on the egress PE router.

CONFIG-SET: MPLS VPN over MPLS TE - Per-VRF MPLS-TE

|PE1#interface loopback34 - Creates a new BGP next-hop | description VRF34-TE-loopback | ip add 150.34.34.11 255.255.255.255 | ! | ip vrf VRF34 | rd 10:34 | route-target both 10:34 | bgp next-hop loopback34 - Specifies loopback34 to be used as BGP next-hop for VRF34 traffic | ! | ip explicit-path name E-PATH34 enable - Creates an explicit path PE1-P2-P3-PE2 | next-address 150.0.0.2 | next-address 150.0.0.3 | next-address 150.0.0.12 | ! | interface tunnel34 - Creates a new TE tunnel for the VRF traffic | ip unnumbered loopback0 | tunnel mode mpls traffic-eng | tunnel destination 150.0.0.12 - Specifies the MPLS TE router-id of PE2 as the tail-end | tunnel mpls traffic-eng path-option 1 exp name E-PATH34 | ! | ip route 150.34.34.12 255.255.255.255 tunnel34 - Route the new BGP next-hop of PE2 via TE tunnel 34

IOS-COMMANDS

# sh mpls ldp discovery - Shows the LDP targeted sessions # sh mpls traffic-eng topology - Shows TE and IGP metrics for each link # sh mpls traffic-eng tunnels [tunnel-int] [brief] - Shows information about the configured TE tunnels # sh ip explicit-paths [name|detail] - Shows the configured explicit paths

#ip vrf {name} - Creates a VRF/enters the VRF configuration

#rd {xx:xx} - Sets the route distinguisher #route-target {both|import|export} {xx:xx} - Sets the route-target value and their action #bgp next-hop loopback {no} - Change the BGP next-hop used for this VRF

#ip explicit-path {name {name}|id} {enable|disable] - Creates an explicit include path/enters an existing path configuration


TOC 182

#next-address [loose] {ip-address} - Specifies the next-hop LSR address

#interface tunnel{no} - Enters the TE tunnel interface configuration mode

#ip unnumbered loopback {no} - Enable IP processing on the interface #tunnel destination {tail-end-te-rid} - Specifies the MPLS TE route-id of the tail-end LSR #tunnel mode mpls traffic-eng - Sets the tunnel mode to MPLS TE #tunnel mpls traffic-eng path-option {number} {dynamic|explicit {name | identifier}} [lockdown] [verbatim]


XR-COMMANDS

# sh mpls ldp discovery - Shows the LDP targeted sessions # sh mpls traffic-eng topology - Shows TE and IGP metrics for each link # sh mpls traffic-eng tunnels [tunnel-int] [brief] - Shows information about the configured TE tunnels

#explicit-path name {name} - Defines the explicit path for the LSP

#index {no} next-address [loose] ipv4 unicast {ip} - Specifies the LSRs in the path of the TE tunnel

#interface tunnel-te{no} - Enters the TE tunnel interface configuration mode

#ipv4 unnumbered {int} - Specifies the tunnel source by enabling IP processing #destination {tail-end-te-rid} - Specifies the MPLS TE route-id of the tail-end LSR #path-option {priority} {dynamic|explicit} [lockdown] [verbatim]



TOC 183

Walking the LSP

MPLS TE from a Head-End LSR to a Tail-End LSR

Figure 8-11: Walking the LSP from the head-end LSR to a tail-end LSR

R21#traceroute 150.12.22.22 - A traceroute from R21 to R22 shows a single label Tracing the route to 150.12.22.22 in the stack 1 150.11.21.11 56 msec 48 msec 48 msec - R21 to R11 link 2 150.1.11.1 [MPLS: Label 100 Exp 0] 44 msec 56 msec 36 msec - R11 to R1 link 3 150.1.3.3 [MPLS: Label 300 Exp 0] 40 msec 48 msec 48 msec - R1 to R3 link 4 150.3.12.12 40 msec 52 msec 68 msec - R3 to R22 link 5 150.12.22.22 44 msec * 32 msec - The * is default behavior of "ip icmp rate-limit unreachable"

R21#sh ip route 150.12.22.22 | i ago, - Let's look at the routing from the R21 * 150.11.21.11, from 150.0.0.12, 01:09:33 ago, via Serial2/0

R11#sh ip route 150.12.22.22 | i ago, - R11 is the head-end of TE tunnel * 150.0.0.12, from 150.0.0.12, 00:39:36 ago, via Tunnel1

R11#sh mpls traffic-eng tun desti 150.0.0.12 | i Out|Next - First, find the out-label used by Tunnel1 OutLabel : Serial2/1, 100 - R11 learned the out-label (100) from R1 Next Hop : 150.1.11.1 - R1 (receive address) is the first hop of path-option 1

R1#sh mpls traffic-eng tun desti 150.0.0.12 | i Out|InL|Next InLabel : Serial2/1, 100 - When R1 receives a packet with an in-label of 100 OutLabel : Serial2/3, 300 it will be swapped with the out-label of 300 that Next Hop : 150.1.3.3 was learned from R3

R3#sh mpls traffic-eng tun desti 150.0.0.12 | i Out|InL|Next InLabel : Serial2/3, 300 - When R3 receives a packet with an in-label of 300 being the OutLabel : Serial2/0, implicit-null penultimate LSR for the LSP, the only label is popped Next Hop : 150.3.12.12 - The packet is forwarded unlabeled towards the tail-end LSR

R12#sh ip route 150.12.22.22 | i via - Once the IP packet arrive on the tail-end LSR a normal IP * directly connected, via Serial2/1 lookup is performed to find the next-hop interface (s2/1)


TOC 184

MPLS TE Tunnels Between MPLS PE Routers

Figure 8-12: Walking the LSP with TE tunnels between MPLS PE routers

PE1#sh ip bgp vpnv4 vrf VRF12 labels | i 10.12.2.0 - First, find the VPN label (17) and the egress PE 10.12.2.0/24 150.0.0.12 nolabel/17 - The next-hop (egress PE) is 150.0.0.12 (PE2)

PE1#sh ip route 150.0.0.12 | i ago, - Find the exit interface for the BGP next-hop * 150.0.0.12, from 150.0.0.12, 00:58:54 ago, via Tunnel0 - The egress PE loopback was learned via tunnel0

PE1#sh mpls traffic-eng tun desti 150.0.0.12 | i Out|Next - Because the next-hop is a TE tunnel, the label used OutLabel : Serial2/1, 100 will be visible in the tunnel information Next Hop : 150.1.11.1 - Here TE label (100) was received from P1

P1#sh mpls traffic-eng tun desti 150.0.0.12 | i Out|InL|Next - From P1 lookup the label swap and next-hop InLabel : Serial2/1, 100 - An in-label (100) on P1 is swapped with the out-label (200) OutLabel : Serial2/0, 200 Next Hop : 150.1.2.2 - P2 advertised the out-label (200)

P2#sh mpls traffic-eng tun desti 150.0.0.12 | i Out|InL|Next - From P2 lookup the label swap and next-hop InLabel : Serial2/0, 200 - An in-label (200) on P1 is swapped with the out-label (300) OutLabel : Serial2/1, 300 Next Hop : 150.2.3.3 - P3 that advertised the out-label (300)

P3#sh mpls traffic-eng tun desti 150.0.0.12 | i Out|InL|Next - From P3 lookup the label swap and next-hop InLabel : Serial2/1, 300 - P3 is the PHP LSR OutLabel : Serial2/0, implicit-null - Implicit-null indicates the top label is popped Next Hop : 150.3.12.12

PE2#sh mpls forwarding-table | i ^17 - PE2 receives a packet with the VPN label (17) 17 No Label 10.12.2.0/24[V] 3760 Se2/1 point2point - PE2 pops the label and forwards the IP packet out se2/1 to CE2

- [V] shows the next hop interface in a VRF


TOC 185

MPLS TE Tunnel Ending on a MPLS P Router

Figure 8-13: Walking the LSP when a TE tunnel ends on a MPLS P pouter

PE1#sh mpls ldp discovery | b Int - Firstly lets confirm the targeted LDP session is Interfaces: established

Tunnel0 (ldp): Targeted -> 150.0.0.3 Targeted Hellos:

150.0.0.11 -> 150.0.0.3 (ldp): active/passive, xmit/recv - The 'recv' shows the response and two-way session LDP Id: 150.0.0.3:0

PE1#sh mpls forwarding-table vrf VRF12 10.12.2.2 detail - A label lookup for the CE prefix will indicate a Local Outgoing Prefix Bytes Label Outgoing Next Hop label stack of 3 labels: Label Label or Tunnel Id Switched interface > TE label (102) None 16 10.12.2.0/24[V] 0 Tu0 point2point > LDP label (303) MAC/Encaps=4/16, MRU=1492, Label Stack{102 303 16}, via Se2/1 > VPN label (16)

PE1#sh ip bgp vpnv4 vrf VRF12 labels | i 10.12.2.0 - Lets walk through the LSP 10.12.2.0/24 150.0.0.12 nolabel/16 - Firstly confirm the VPN label (16) and the egress PE

PE1#sh ip route 150.0.0.12 | i ago, - Find the exit interface for the egress PE * 150.0.0.3, from 150.0.0.12, 02:05:09 ago, via Tunnel0 - Egress PE loopback was learned via tunnel0 from P3

PE1#sh mpls forwarding-table 150.0.0.12 - Confirm the LDP tunnel label (303) Local Outgoing Prefix Bytes Label Outgoing Next Hop - This label would be received from PE2 Label Label or Tunnel Id Switched interface 1119 [T] 303 150.0.0.12/32 0 Tu0 point2point - [T] Indicates the label was received via the TE tunnel


TOC 186

PE1#sh mpls traffic-eng tun desti 150.0.0.3 | i Out|InL|Next - Because the next-hop is a TE tunnel, the label used InLabel : - will be visible in the tunnel information OutLabel : Serial2/1, 102 - The TE label (102) was received from P1 Next Hop : 150.1.11.1

P1#sh mpls traffic-eng tun desti 150.0.0.3 | i Out|InL|Next - From P1 lookup the label swap and next-hop InLabel : Serial2/1, 102 - An in-label (102) on P1 is swapped with the out-label (202) OutLabel : Serial2/0, 202 Next Hop : 150.1.2.2 - The next-hop is P2

P2#sh mpls traffic-eng tun desti 150.0.0.3 | i Out|InL|Next - From P2 lookup the label swap and next-hop InLabel : Serial2/0, 202 OutLabel : Serial2/1, implicit-null - P2 is the PHP LSR, implicit-null indicates the top Next Hop : 150.2.3.3 label is popped, before packet is forwarded to P3

P3#sh mpls forwarding-table | i ^303 - P3 receives a packet with LDP label (303) 303 Pop Label 150.0.0.12/32 16332 Se2/0 point2point - P3 pops the top label and forward the packet onto PE2

PE2#sh mpls for | i ^16 - PE2 receives a packet with the VPN label (16) 16 No Label 10.12.2.0/24[V] 3312 Se2/1 point2point - PE2 pops the last label and forwards the IP packet out se2/1 to

CE2


TOC 187

Bibliography


RFC-2370 The OSPF Opaque LSA Option http ://www.ie tf.org/rfc/rfc2370.txt

RFC-3784 IS-IS Extensions for Traffic Engineering (TE) http ://www.ie tf.org/rfc/rfc3784.txt

RFC-3209 RSVP-TE: Extensions to RSVP for LSP Tunnels http ://www.ie tf.org/rfc/rfc3209.txt

RFC-4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels http ://www.ie tf.org/rfc/rfc4090.txt

RFC-5085 Pseudowire Virtual Circuit Connectivi ty Veri fication (VCCV): A Contro l Channel for Pseudowires http ://www.ie tf.org/rfc/rfc5085.txt

RFC-4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks http ://www.ie tf.org/rfc/rfc4448.txt

RFC-3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3) http ://www.ie tf.org/rfc/rfc3931.txt

RFC-4216 MPLS In ter-Autonomous Sys tem (AS)- Traffic Engineering (TE) Requirements http ://www.ie tf.org/rfc/rfc3931.txt


TOC 188



TOC 189

Chapter 9

MPLS – L2VPNs


TOC 190

L2VPN Overview

- L2VPN (Layer2 VPNs) provides a transparent end-to-end layer2 connection to an enterprise over a SP's (Service Provider) MPLS or IP core. - Unlike L3VPNs where the SP take part in the client routing, with L2VPNs the SP has no invo lvement in the client IP routing. - Client layer2 tra ffic is tunneled through the IP/MPLS core network, such that the CE routers appear to be directly connected. - L2VPN can be implemented using two different technologies:

> AToM >> Requires a MPLS core using either LDP or MPLS TE. >> Supports point-to-point, point-to-mul tipoint and m ultipoint-to-mul tipo int pseudowires. >> Supports l ike-to-like protocols and in terworking.

> L2TPv3 >> Requires an IP core with IP reachabili ty between PE routers . >> Supports only point-to-point pseudowires. >> Supports l ike-to-like protocols and in terworking. >> Uses control messages to negotiate session-IDs.

- L2VPN Components > Control Plane - Handles the session management, signaling, error noti fication, etc. > Transport Network - Handles the delivery of the encapsulated packets, ei ther by IP header or MPLS label. > Tunnel Component - Uniquely identi fies each VC (Vi rtual Circui t) between PE routers . This will be ei ther a VC label or a VCID. > Transported Protocol - The layer2 frames received from a CE router that are to be sent across the SP network.

- A pseudowire is a logical connection between two PE routers which connects the physical links facing the client. - These PE-to-CE links are called ACs (Attachment Circui ts). - AToM and L2TPv3 are only supported on certa in routers/linecards . It is advisable to read through the res trictions on the DOC-CD.

- PW (Pseudowire) > Is the VC (Virtual Circui t) between two interfaces that emulates a point-to-point link, also known as a cross-connect/xconnect. > Pseudowires should be bui l t between PE router loopback IP addresses. > Configured with "xconnect" under the AC, except for Frame Relay DLCI-to-DLCI m ode. > Addi tional configuration can be applied using a pseudowire-class.

- Pseudowire-Class > Is a configuration profile used to configure addi tional settings for L2VPN technologies. > For AToM the encapsulation m us t be set to MPLS. > For dynamic L2TPv3 the encapsulation m ust be set to L2TPv3. > For m anual L2TPv3 the encapsulation m us t be set to Manual . > If the encapsulation m us t be changed, the pseudowire-class mus t be removed and re-added.

- VCID (Vi rtua l Circuit Identi fier) > Is a 32-bi t identi fier used to identi fy a pseudowire between to two PE routers. > The combination of the VCID and the loopback used of the egress PE router mus t be unique.

- VCCV (Vi rtual Circuit Connectivity Veri fication) > Is the protocol used to tes t and veri fy the forwarding path of pseudowires between PE routers . > Defined by PWE3 (Pseudowire Edge-to-Edge Em ulation) working group in RFC-5085. > VCCV messages are encapsulated using the PWE3 encapsulation to build a contro l channel between PE routers .


TOC 191

AToM

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Guide Library | | MPLS: Layer 2 VPNs, Configuration Guide | | Any Transport over MPLS

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS-XR > Cisco IOS XR Software | | | | Configuration Guides | | Release 3.9 | | Virtual Private Network Configuration Guide | | Implementing MPLS Layer 2 VPNs on Cisco IOS-XR Software

- AToM (Any Transport over MPLS) is a method used to tunnel layer2 packets over a MPLS backbone. - Layer2 packets from one site is transparently carried across a MPLS backbone to another site with the impression that the two sites are di rectly connected.

Figure 9-1: AToM Architecture

- AToM com ponents > Control Plane - Uses targeted MPLS sessions to exchange VC labels between the ingress and egress PE routers . > Transport Network - LSPs between the PE routers , consists of ei ther LDP or MPLS TE or a combination there of. > Tunnel Component - VC label received from the egress PE is used to label the L2-PDUs. > Transported Protocol - The supported AToM payloads on ACs (Attached Circui ts) are ATM, Ethernet, Frame Relay, PPP and HDLC.

Figure 9-2: AToM header

- AToM Header Overhead > Transport Label (4 bytes) - I t is the label associated with the egress PE router's loopback IP. > VC Label (4 bytes ) - I t is the label used to identi fy the AC (egress in terface) on the egress PE router. Must be unique between PE routers . > CW (4 bytes ) - Optional Control Word to carry addi tional layer2 PDU in formation. > L2-PDU (varies) - Client layer2 header/PDU (Protocol Data Uni t).


TOC 192

- CW (Control Word) > Is a 4 byte AToM header field used to carry header in formation about the transported layer2 protocol . > The CW is optional for Ethernet, PPP and HDLC, but required for Frame Relay and ATM. > By defaul t the CW is set to auto sense, but can manually be enabled with "control -word" with in the "pseudowire-class".

- MTU Guidelines > The MTU values on both sides of a pseudowire mus t match for the tunnel to come up. > MTU m ismatches are corrected by reducing the MTU of pseudowire side with the higher MTU value. > On IOS-XR the in terface command "MTU size" includes the layer2 overhead, unlike on IOS. > With the addi tional overhead added by AToM i t is important to determine the max size of packets supported on core interfaces . > AToM packets should only be fragmented by the ingress PE router forwarding the packets in to the pseudowire. > P routers with in the MPLS network will drop an AToM packet i f i t is la rger than i ts in terface MTU. > The fo llowing formula can be used to calculate the requi red in terface MTU of core in terfaces :

MTU >= (AC MTU + Transport header + CW + (label stack * 4 bytes )) > AC MTU is the MTU of the attached circui t interface. > Transport header sizes of the layer2 protocol carried:

>> HDLC - 4 bytes >> PPP - 4 bytes >> Frame Relay - 2 bytes (Cisco Encapsulation) >> Frame Relay - 8 bytes (IETF Encapsulation) >> Ethernet VLAN - 18 bytes >> Ethernet Port - 14 bytes

> The CW is 4 bytes but optional. > The size of the label stack depends on the connection between the PE routers .

>> I f the AToM PE routers are directly connected, the stack consists of 1 label (VC label ). >> I f LDP is used between the PE routers , the stack consist of 2 labels (LDP + VC label). >> I f MPLS TE is used between the PE routers , the stack consist is 2 labels (TE + VC label). >> I f LDP and MPLS TE is used between the PE routers , the stack consist of 3 labels (LDP + TE + VC label ).

> The above form ula can be adapted to calculate the largest IP MTU required on a CE router, looking at the core in terface MTUs: >> CE IP MTU = In terface MTU - (CW + (label stack * 4 bytes )).

> In terface MTUs can be configured with "m tu {mtu}"

- AToM Forwarding Plane Figure 9-3: AToM Traffic Forwarding Example

> The fo llowing example depicts the packet flow from le ft to right. > PE1 (ingress PE router) receives layer2 frames on the AC from CE1.


TOC 193

> PE1 encapsulates the frame, adds a VC-label (28), that was received from PE2 (egress PE router) during the pseudowire signal ing. > PE1 adds a second label, the transport (LDP) label (14), received from P1 before sending the labeled packet out. > P1 receives a labeled packet with a top label (14) and swaps the top label (in -label) with the out-label (17). > P2 receives a labeled packet with a top label (17) and performs PHP. > PE2 receives a labeled packet with a top label (28) corresponding to a in -label in the LFIB. This label is associated with the AC connected to CE2. > PE2 removes the label and forwards the origina l frame down to CE2.

- Ethernet over MPLS > Described in RFC-4448. > Ethernet over MPLS connects two local area networks in separate locations to form one broadcast network. > STP will work across the pseudowire, but i f the VLAN is changed on the egress PE router STP could cease to operate. > EoMPLS can be implemented in two modes : VLAN and Port m ode. > If di fferent VLANs are used on the ACs from one side to the other, the VLAN ID on egress wil l be changed automatically. > Port Mode (a .k.a . raw mode in the RFC)

>> Ethernet frames received on the AC are forwarded in i ts entire ty (wi thout the preamble or FCS), using PW type 0x0005 (a .k.a . VC type 5). >> I f a VLAN tag is present on arrival at the ingress PE route i t will be s tripped before sent in to the pseudowire. >> Configured using Ethernet physical in terfaces .

> VLAN Mode (a .k.a . tagged mode in the RFC) >> Dot1Q frames received on the AC are forwarded in to the pseudowire (wi thout the preamble or FCS), using PW type 0x0004 (a .k.a . VC type 4). >> Every arriving frame mus t have a VLAN ID matching the local in terface configuration, else i t will be discarded. >> Configured using Ethernet sub-in terfaces. >> Per-sub in terface MTU is supported on some platforms, but for EoMPLS only.

CONFIG-SET: ATOM- Ethernet Configuration Modes over MPLS on IOS

|Port Mode | int gi1/0 - Enters the physical interface | xconnect 10.5.0.1 551 encapsulation mpls - Binds the AC to the pseudowire VC | +- |VLAN Mode | int gi2/0.100 - Enters the sub-interface | encapsulation dot1q 100 | xconnect 10.5.0.1 552 encapsulation mpls - Binds the AC to the pseudowire VC | ! | int gi2/0.200 - Enters the sub-interface | encapsulation dot1q 200 | xconnect 10.5.0.1 553 encapsulation mpls - Binds the AC to the pseudowire VC

- HDLC over MPLS > With HDLC over MPLS, the whole HDLC packet (except the HDLC flags and FCS bi ts) is transported, using PW type 0x0006 (a .k.a . VC type 6).

- PPP over MPLS > With PPP over MPLS, the ingress PE router removes the flags, address, contro l field , and the FCS, using PW type 0x0007 (a .k.a . VC type 7). > MLP (Mul til ink PPP) is not supported with AToM.


TOC 194

- Frame-Relay over MPLS > Frame Relay over MPLS encapsulates Frame Relay frames in MPLS packets and forwards them across the MPLS network. > LMI is the protocol that communicates status in formation about the PVCs. > Support for LMI depends on the pseudowire connection m ode. > FRoMPLS can be implemented using ei ther DLCI or Port m ode. > DLCI Mode

>> One Frame Relay VC is carried over one pseudowire using PW type 0x0001 (a .k.a . VC type 1). >> The Frame Relay header is stripped of the frames, but the FECN, BECN, DE and CR bi ts are copied to the CW before labeling. >> LMI runs locally on the Frame Relay ports between the PE and CE routers . >> The local PE wil l send active s tatus to the CE, i f a pseudowire exists to the egress PE.

> Port Mode >> The PE routers do not participate in LMI as the PE interfaces use HDLC to transport the encapsulated frame-relay packets. >> Uses PW type 0x0006 (a .k.a . VC type 6). >> The contents of the Frame Relay packets are not used or changed, including BECN, FECN and DE bi ts . >> LMI thus operates only between the CE routers meaning the CE routers to be configured as DCE-DTE.

> ACs can be configured as : >> DTE - Enables the router to function as a DTE (router) device (defaul t CLI option). >> DCE - Enables the router to function as a Frame Relay swi tch. >> NNI - Enables the router to function as a Frame Relay swi tch connected to a Frame Relay switch.

> Only the DCE and NNI in terface types can report the LMI s tatus. > Configured with "frame-relay in tf-type [dce | dte | nni ]".

CONFIG-SET: ATOM- Frame-Relay over MPLS Configuration Modes

|DLCI mode | frame-relay switching - Enables frame-relay PVC switching on the PE | ! | interface se1/0 | encapsulation frame-relay - Sets the encapsulation to frame-relay | frame-relay intf-type dce - Sets the AC as DCE type | ! | connect FRAME se1/0 109 l2transport - Creates a switched PVC on the PE router for DLCI-109 | xconnect 10.5.0.1 554 encapsulation mpls - Binds the AC to the pseudowire VC | +--- |Port mode | interface se1/0 | encapsulation hdlc - Sets the encapsulation to HDLC | xconnect 10.5.0.1 555 encapsulation mpls - Binds the AC to the pseudowire VC

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Guide Library | | MPLS: Layer 2 VPNs, Configuration Guide | | Any Transport over MPLS | | Configuring Tunnel Selection

- AToM Tunnel Selection > By defaul t the IGP (leas t cost route) determines the path a pseudowire takes to reach the egress PE router.


TOC 195

> Tunnel selection allow the path taken by a pseudowire to be speci fied, by using ei ther a MPLS TE tunnel or destination IP. > Using a destination IP

>> The speci fied IP m us t be a loopback in terface IP on the egress PE router, with an address mask of /32. >> There m us t be an established LSP to des tination IP.

> Using MPLS TE >> The tunnel ta il -end IP m us t be a loopback interface IP on the egress PE router with an address mask of /32.

> Configured with "preferred-path" under the pseudowire-class. > By defaul t, if the preferred path is not available, the path selection falls back to the default IGP path to reach the egress PE router. > This fallback behavior can be disabled with the keyword 'disable-fallback'. > Tunnel selection is only supported when MPLS encapsulation is used within the pseudowire-class.

Figure 9-4: AToM Tunnel Selection using MPLS TE

CONFIG-SET: AToM Tunnel Selection using MPLS TE

|Assume AToM traffic from CE1 to CE2 has to follow the path PE1-P1-P2-PE2. |Below is the config on PE1 (ingress). Inverse config to be applied for return traffic on PE2. | | ip explicit-path name P1-P2 enable - Creates an explicit MPLS TE path | next-address 150.0.0.1 - Loopback of P1 | next-address 150.0.0.2 - Loopback of P2 | next-address 150.0.0.12 - Loopback of PE2 | ! | pseudowire-class P1-P2 | encapsulation mpls - Enable AToM encapsulation | preferred-path interface tunnel1 disable-fallback - Specifies the path the AToM must follow | ! - Fallback to IGP disabled | interface tunnel1 - Creates the TE tunnel interface | ip unnumbered loopback0 - Uses PE1 loopback0 as the source | mpls traffic-eng tunnels | tunnel destination 150.0.0.12 - Destination is PE2 loopback0 | tunnel mode mpls traffic-eng | tunnel mpls traffic-eng priority 1 1 | tunnel mpls traffic-eng path 1 explicit name P1-P2 - Specifies the explicit path | ! | interface fastethernet1/0.100 | encapsulation dot1Q 100 - Ethernet VLAN mode | xconnect 150.0.0.12 301 pw-class P1P2 - Specifies the pseudowire |


TOC 196

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Configuration Guide | | Part 6: MPLS: Layer 2 VPNs | | L2VPN Pseudowire Switching

- L2VPN Pseudowire Switching > In ter-connects pseudowires part of di fferent autonomous s ys tems to provides one logical layer2 end-to-end path > Joins two or more contiguous pseudowire segments to form an end-to-end multi -hop pseudowire. > Possible between two separate MPLS networks or across an in ter-AS boundary.

Figure 9-5: L2VPN Pseudowire Switching

CONFIG-SET: L2VPN Pseudowire Switching

|PE1 and PE4 would have normal AToM config to PE2 and PE3 respectively. PE2 config shown here (PE3 would be similar) | | pseudowire-class ATOM-SW | encapsulation mpls | ! | l2 vfi A2A point-to-point | neighbor 150.0.0.11 112 pw-class ATOM-SW - Configures the PE1 AToM as one part of the VC | neighbor 200.0.0.13 234 pw-class ATOM-SW - Sets PE3 AToM as the 2nd part of the VC | ! | interface loopback0 | ip address 150.0.0.12 255.255.255.255 - PE2 loopback IP |

IOS-COMMANDS

# sh mpls l2transport vc [detail] - Shows information about the AToM pseudowires # sh mpls l2transport binding - Shows local and remote MTU values # sh xconnect {all|int|peer} [detail] - Shows the pseudowire details

# xconnect backup force-switchover {int|peer} - Manually switch between pseudowires

# clear xconnect [all | interface | peer] - Removes pseudowire config

# debug mpls l2transport vc event - Useful with tunnel selection Copyright © 2013 Routing-Bits.com

TOC 197

#xconnect logging pseudowire status - Tracks the status of pseudowires #xconnect logging redundancy - Tracks the status of the xconnect redundancy groups #no pseudowire-class {name} - Removes a pseudowire-class #pseudowire-class {name} - Creates a pseudowire-class #encapsulation {mpls|l2tp3} - Sets the encapsulation to AToM or L2TPv3 #preferred-path {interface tunnel {no} | peer {ip} [disable-fallback]

- Enables AToM tunnel selection to MPLS TE or destination IP - [disable-fallback] Disables using default path as a backup

#control-word - Manually enables the CW #status - Enables sending pseudowire status messages via labels

#interface {int}

#encapsulation dot1q {vlan-id} - Sets the VLAN ID and encapsulation #xconnect {remote-pe} {vcid} encap mpls [pw-class {name}]

- Specifies the local AC to connect to remote PE/VCID - [pw-class] Specifies the PW class

#mtu {value} - Sets a per-VC MTU on Ethernet interfaces #backup peer {remote-pe} {vcid} [pw-class {name}] - Sets a redundant pseudowire VC for a peer #backup delay {sec} {disable-delay | never} - Specifies the delay between tunnel take over

#frame-relay switching - Enables frame-relay PVC switching on the PE

#interface {int} #encapsulation frame-relay [cisco|ietf] - Sets the encapsulation (default = cisco) #frame-relay intf-type [dce|dte|nni] - Sets the frame-relay interface role

- [dte] Interface function of router (default option) - [dce] Interface function of frame-relay switch

#connect {name} {interface} {dlci} l2transport - Defines local connect between frame-relay PVCs

#xconnect {remote-pe} {vcid} encapsulation mpls - Creates the pseudowire

XR-COMMANDS

# sh xconnect {all|int|peer} [detail] - Shows the pseudowire details

#interface {int}

#l2transport - Enables layer2 transport on the Ethernet interface

#interface {int}

#encapsulation frame-relay - Enables frame-relay encapsulation #frame-relay intf-type dce - Sets the frame-relay interface role

#interface {int}.{sub} #pvc 10 - Sets the frame-relay DLCI

#l2vpn - Enters L2VPN configuration mode to configure a TE tunnel selection


TOC 198

#pw-class {name} - Creates the pseudowire class #encapsulation mpls - Sets the encapsulation to MPLS #preferred-path {int|te} [fallback disable] - Sets the preferred tunnel path for the pseudowire

#xconnect group {name} - Creates the pseudowire group #p2p {name} - Creates the point-to-point pseudowire group #interface {int} - Specifies the interface #neighbor {remote-pe} pw-id {vcid} - Sets the pseudowire to the remote PE router #pw-class {name} - References a pseudowire class

L2TPv3

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | Wide-Area Networking Config Guide | | Layer 2 Tunneling Protocol Version 3

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS-XR > Cisco IOS XR Software | | | | Configuration Guides | | Release 3.9 | | Virtual Private Network Configuration Guide | | Implementing Layer 2 Tunnel Protocol Version 3

- L2TPv3 is a standards VPN technology based on the L2TP protocol . - Defined b y the IETF L2TPEXT working group and formalized in RFC-3931. - Layer2 packets from one site is transparently carried across an IP backbone to another site with the impression that the two sites are directly connected. - L2TPv3 on Cisco devices support data encapsulation only over IP using protocol number 115. - L2TPv3 in comparison to AToM:

> Does not require MPLS. > Does not support point-to-mul tipoin t pseudowires.

Figure 9-6: L2TPv3 Architecture

- L2TPv3 Components > Control Plane - PE routers emulate the function of LCCEs (L2TP Contro l Connection Endpoint) to provide an in-band control plane. > Transport Network - Normal IP reachabil i ty is requi red between the PE routers.


TOC 199

> Tunnel Component - Uses the session-ID and cookie to encapsulate the L2-PDUs for identi fication by the egress PE router. > Transported Protocol - The supported L2TPv3 payloads on ACs (Attached Circui ts) are ATM, Ethernet, Frame Relay, PPP and HDLC.

Figure 9-7: L2TPv3 Header Structure

- L2TPv3 Header Overhead > IP header (20 bytes) - I t is the IP addresses (Des tination and Source) used to reach the egress PE router. > Session-ID (4 bytes) - Used to uniquely identi fy the pseudowire/VC between two PE routers. > Cookie (0 ,4,8 bytes ) - Optional cookie is used to provide session in tegri ty and validation. > PW Ctrl (4 bytes ) - Optional pseudowire contro l carries layer2 header in formation to support L2-PDU sequencing and emulation. > L2-PDU (variab le) - Client layer2 payload/PDU (Protocol Data Uni t).

- MTU Guidelines > The MTU values on both sides of a pseudowire mus t match for a tunnel to come up. > Always configure the MTU values appropria te ly to cater for the addi tional overhead required by L2TPv3 pseudowires. > The defaul t behavior at the ingress PE is to fragment packets that are larger than the tunnel MTU. > Enabling "ip dfb i t set" within the pseudowire-class, changes the MTU behavior to drop packets that larger than tunnel MTU. > Enabling "ip pm tu" with in the pseudowire-class, enables PMTU (Path MTU) discovery between the CE routers via the contro l class. > The fo llowing formula can be used to calculate the requi red in terface MTU of core in terfaces:

MTU >= (AC MTU + Transport header + L2TPv3 IP Header + Session-ID + Cookie + PW-Ctrl) > AC MTU is the MTU of the attached circu i t. > Transport header sizes of the layer2 protocol carried:

>> HDLC - 4 bytes >> PPP - 4 bytes >> Frame Relay - 2 bytes (Cisco Encapsulation) >> Frame Relay - 8 bytes (IETF Encapsulation) >> Ethernet VLAN - 18 bytes >> Ethernet Port - 14 bytes

> The session-ID is 4 bytes. > The cookie and PW-Ctrl are optional . > This means the minim um MTU overhead is 24 bytes and the maxim um is 36 bytes. > The above form ula can be adapted to calculate the largest IP MTU required on a CE router, looking at the core in terface MTUs:

>> CE IP MTU = In terface MTU - (L2TPv3 IP header + Session-ID + Cookie + PW-Ctrl ). > In terface MTUs can be configured with "m tu {mtu}".

- L2TPv3 can be provisioned through: > Static Sessions


TOC 200

>> Session and L2TP contro l parameters are configured m anually (includes the session-IDs and cookies). >> No signaling is required for session es tablishment. >> Static configuration allows sessions to be established without dynamically negotia ting control connection parameters. >> Authentication and other contro l parameters can s till be configured.

> Dynamic Sessions >> Sessions are established through the exchange of control messages containing AV (Attribute -Value) pai rs. >> An AV pair contains in formation about the AC, e.g., payload t ype, VCID etc. >> Session IDs and cookies are dynamically generated and exchanged as part of a dynamic session setup.

- L2TP-Class > L2TPv3 uses an addi tional template known as "l2 tp-class" to classify control characteris tics and authentication. > If the L2TP class is not defined a defaul t class named "l2 tp_default_class" will be deployed.

- L2TPv3 s upports two types of control channel authentication or in tegri ty checking. > CHAP-style L2TP

>> Also known as old authentication s tyle . >> Utilizes challenge/chal lenge -response messages for peer authentication.

> Control Message Hashing >> Also known as new authentication style . >> Does per-message authentication and the hash is present in all L2TPv3 control messages. >> I f the "diges t" command is issued without the 'secret' keyword option, only L2TPv3 control channel in tegri ty checking is enabled.

- Ethernet over L2TPv3 > Port Mode

>> The enti re Ethernet frame received on an AC is encapsulated and forward in to the pseudowire. >> Configured using a physical in terface.

> VLAN Mode >> The VLAN Ethernet frames (tagged or untagged) are forwarded in the ir entire ty. >> The egress PE m ay rewri te the VLAN ID to another value before forwarding the traffic in to the AC. >> Configured using a sub-interface.

CONFIG-SET: L2TPv3 Dynamic Ethernet VLAN Mode with CHAP Authentication

| l2tp-class CHAP | authentication - Enables control channel authentication | password unicorns - Sets the password used with CHAP authentication | ! | pseudowire-class VLAN-MODE | encapsulation l2tpv3 | protocol l2tpv3 CHAP - Enables the signaling protocol to L2TPv3 using the L2TP class | ip local interface loopback0 - Specifies the source interface of the tunnel | ! | interface fa0/0.1 | encapsulation dot1Q 5 - VLAN mode | xconnect 10.5.0.1 551 pw-class VLAN-MODE - Creates the pseudowire to the remote PE router for VLAN-5 |


TOC 201

- HDLC over L2TPv3 > The entire HDLC frame received on an AC is encapsulated and forwarded in to the pseudowire.

- PPP over L2TPv3 > The entire PPP frame received on an AC is encapsulated and forwarded in to the pseudowire.

- Frame-Relay over L2TPv3 > Port Mode

>> All packets (including full layer2 header) are forward via the pseudowire unchanged to the remote side. >> The PE routers do not change the headers, or participate in LMI. >> The CE routers are LMI peers.

> DLCI Mode >> Ind ividual DLCIs are connected to create end-to-end PVCs. >> The PE routers participate in LMI, with the CE routers as LMI peers. >> Frame Relay header flags (FECN, BECN, C/R, DE) are preserved across the pseudowire.

CONFIG-SET: L2TPv3 Dynamic Frame Relay DLCI Mode with Digest Authentication

| l2tp-class DIGEST | digest secret bananas - Enables control channel digest authentication | | pseudowire-class DLCI | encapsulation l2tpv3 | protocol l2tpv3 DIGEST - Sets the signaling protocol to L2TPv3 using the L2TP class | ip local interface Loopback0 - Specifies the source interface of the tunnel | ! | interface se0/0 | encapsulation frame-relay | frame-relay intf-type dce | ! | connect FIRST se0/0 100 l2transport - Specifies the DLCI | xconnect 10.5.0.1 552 pw-class DLCI - Specifies the local AC and the remote peer | connect SECOND se0/0 200 l2transport - Specifies the DLCI | xconnect 10.5.0.1 553 pw-class DLCI - Specifies the local AC and the remote peer |

- L2TPv3 s upports in terworking, to di fferent layer2 protocol on di fferent sides of the pseudowire. Refer to the In terworking section. - In terworking is not allowed when L2TPv3 sequencing is enabled. - In addition to in terworking, L2TPv3 also supports local swi tching between two interfaces on the same PE router. Refer to the Local Switching section.


TOC 202

CONFIG-SET : Dynamic L2TPv3 Session alternative for Local HDLC Switching

|This example is an alternative to using local (connect) switching. | | interface loopback 1 | ip address 10.0.0.1 255.255.255.255 - Two loopbacks are defined to create two endpoints | interface loopback 2 - This is needed for the VCID to be unique | ip address 10.0.0.2 255.255.255.255 | ! | pseudowire-class LB1 | encapsulation l2tpv3 | ip local interface loopback1 - Specifies Loopback1 as the source | pseudowire-class LB2 | encapsulation l2tpv3 | ip local interface loopback2 - Specifies Loopback1 as the source | ! | interface s0/0 | encapsulation hdlc | xconnect 150.0.0.1 100 pw-class LB2 - Specifies the local AC and the peer as loopback2 | ! | interface s0/1 | encapsulation hdlc | xconnect 150.0.0.2 100 pw-class LB1 - Specifies the local AC and the peer as loopback1 |

IOS-COMMANDS

# sh l2tun session brief - Shows the summary of L2TPv3 sessions and their status # sh l2tun session [all|hostname] - Shows more information about the L2TPv3 sessions # sh l2tun tunnel [all|auth] - Shows the information of the L2TP control channels # sh l2tun counters tunnel l2tp - Shows global or per-tunnel control message statistics # sh xconnect {all|int} [detail] - Shows xconnect ACs and pseudowires

# clear l2tun counters [tunnel]... - Clears global/tunnel session counters for pseudowires

# clear l2tun [all|tunnel|remote|local] - Clears the specific L2TPv3 tunnel

# debug condition xconnect - Limits debug output to messages related to pseudowires

# debug vpdn - Useful to troubleshoot authentication failure messages

#xconnect logging pseudowire status - Enables syslog reporting of pseudowire status events

#l2tp-class {name} - Creates the L2TP class for old style authentication

#authentication - Enables control channel authentication #password {0|7} {pwd} - Sets the CHAP password #hostname {name} -(o) Specifies PE name, else default hostname is used #hello {seconds} -(o) Sets the hello exchange interval (default = 60 sec)


TOC 203

#l2tp-class {name} - Creates the L2TP class for new style authentication #digest {secret [0|7] pwd} [hash {md5|sha}] - {secret} Enabled control channel authentication

- [hash] Specifies the hash function, (default = md5) #no digest check -(o) Disables validation of digest messages.

- Possible only when 'secret' keyword was not used. #hello {seconds} -(o) Sets the hello exchange interval (default = 60 sec)

#pseudowire-class {name} - Creates the PW class

#encapsulation l2tpv3 - Sets the pseudowire encapsulation to L2TPv3 #ip local interface {int} - Sets the source interface of the tunnel #ip pmtu -(o) Enables Path MTU discovery for tunneled traffic #ip tos {value value | reflect} -(o) Sets the TOS value or copies it from inner IP header (default =0) #ip dfbit set -(o) Sets the DF bit in the outer IP header to prevent fragmentation #ip ttl {value} -(o) Sets the TTL in the outer IP header #protocol {l2tpv3 | none} [l2tp-class] -(o) Sets the L2TPv3 signaling protocol dynamic or manual #ip protocol {l2tp | uti | protocol-number} -(o) Changes the default (115) protocol number used #sequencing {transmit | receive | both} -(o) Enables sequencing in a direction, typically with manual configuration

#interface {int}

#xconnect {remote-pe} {vcid} [encap [l2tpv3|manual]] [pw-class {name}] - Specifies the local AC to connect to remote PE/VCID - [encap manual] Disables signaling for the L2TPv3 control channel [pw-class] Specifies the PW class

XR-COMMANDS

# sh l2tun session brief - Shows the summary of L2TPv3 sessions and their status # sh l2tun session [all|name] - Shows more information about the L2TPv3 sessions # sh l2tun tunnel [brief|detail] - Shows the information of the L2TP control channels # sh l2tun counters forwarding session - Shows the forwarding session counters

# clear l2tun counters control [tunnel|session] - Clears global/tunnel session counters for pseudowires

# clear l2tun tunnel [all|remote|local] - Clears the specific L2TPv3 tunnel

#l2tp-class {name} - Creates the L2TP class for new style authentication

#digest {secret {0|7} pwd} [hash {md5|sha1}] - {secret} Enabled control channel authentication - [hash] Specifies the hash function, (default = md5)

#digest check disable -(o) Disables validation of digest messages. #hello {seconds} -(o) Sets the hello exchange interval (default = 60 sec)

#l2vpn - Enters L2VPN mode

#pw-class {name} - Creates the pseudowire class #encapsulation l2tpv3 - Sets the encapsulation to L2TPv3 #sequencing {both} - Enables pseudowire class sequencing #protocol l2tpv3 class {name} - Sets dynamic pseudowire signaling #ipv4 source {ip} - Sets the local source IP address


TOC 204

#xconnect group {name} - Creates the pseudowire group #interworking ipv4 - Enables interworking #p2p {name} - Creates the point-to-point pseudowire group #interface {int} - Specifies the interface #neighbor {remote-pe} pw-id {vcid} - Sets the pseudowire to the remote PE router #pw-class {name} - References a pseudowire class

Interworking

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Configuration Guide | | Part 6: MPLS: Layer 2 VPNs | | L2VPN Interworking

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS-XR > Cisco IOS XR Software | | | | Configuration Guides | | Release 3.9 | | Virtual Private Network Configuration Guide | | Implementing MPLS Layer 2 VPNs | | IP Interworking

- Enables the translation between the di fferent layer2 encapsulations end-points , e.g., th is allows one side of an pseudowire to be Ethernet while the other side is PPP.

- There are m any res trictions (both code and hardware dependencies) for in terworking. Be sure to read the res triction sections of the DOC-CD. - In terworking is available in three modes ; Ethernet (bridged), Ethernet (VLAN) or IP (routed).

> Ethernet (Bridged) Mode >> In th is mode only Ethernet frames are accepted, extracted and forwarded in to the pseudowire. >> Non-Ethernet frames wil l be discarded. >> The header of dot1Q frames will be discarded, leaving the native Ethernet frame to be forwarded.

> Ethernet VLAN Mode >> In VLAN the dot1q header is included as part of the Ethernet frame transported across the pseudowire.

> IP Mode (Routed) Mode >> In th is mode the IP payload is extracted and forwarded in to the pseudowire. >> This uses VC type 11 (0x000B) on the pseudowire. >> Non-IP tra ffic will be discarded, as only IP NLPID packets will be accepted. >> Address resolution packets are dropped, thus layer3 to layer2 address resolution is requi red.

>>> For Ethernet ACs the PE router acts as a proxy-ARP device to requests from the CE router. >>> For PPP ACs the remote CE routers IP address m ust be specified for the IPCP negotia tion to complete. >>> For m ultipoint Frame Relay ACs manual rem ote IP to DLCI mappings are requi red as inverse ARP is dropped. >>> For point-to-point Frame Relay ACs nothing is required as inverse ARP is not needed.

- PPP Peer IP address is configured : > On the CE router with "peer defaul t ip address {ip}" with the IP address of the remote CE router. > On the PE router with "ppp ipcp address proxy {ip}" with the IP address of the remote CE router.

- When to use a particu lar mode wi ll depend on the type of application used end-to-end. - With in terworking also make sure that the routing protocols in terface type matches.

> E.g., OSPF running over Frame Relay to Ethernet in terworking would need the OSPF in terface types set to m atch.

- AToM In terworking Supported > Ethernet to /from VLAN (bridged or routed).


TOC 205

> Ethernet/VLAN to /from Frame Relay (bridged or routed). > Ethernet/VLAN to /from PPP (routed). > Frame-relay to PPP (routed).

- L2TPv3 In terworking Supported > Ethernet to /from VLAN (bridged or routed). > Ethernet/VLAN to /from Frame Relay (bridged or routed). > Frame-relay to PPP (routed).

- MTU Considerations > As with AToM and L2TPv3, the MTU values on both sides of a pseudowire m us t match for the tunnel to come up. > A pi tfal l that is created with in terworking, is the defaul t MTU values of di fferent interfaces. > The defaul t MTU values

>> POS - 4470 bytes . >> ATM - 4470 bytes . >> Serial - 1500 bytes . >> Ethernet - 1500 bytes .

> The di fferent in terwork modes have di fferent MTU challenges. > IP m ode MTU considerations:

>> In IP m ode only the IP payload is sent across the pseudowire and the layer2 transport header is discarded. >> This means the transport header overhead should be discounted from MTU calculations.

> For Ethernet modes the transport header overhead s till applies.

- Deta iled configuration examples are covered in detail on the DOC-CD.

IOS-COMMANDS

# sh l2tun session [all|brief] - Shows details about the L2TPv3 sessions # sh l2tun session interworking - Shows the interworking L2TPv3 information # sh arp - Shows the IP ARP table # sh connect [all|name|port] - Shows details and status of the local connects # sh mpls l2transport vc [detail] - Shows information about the AToM pseudowires

# debug mpls l2transport packet data - Useful to see the AToM pseudowire packet data

#pseudowire-class {name} - Creates the PW class

#encapsulation {mpls|l2tpv3 - Sets the pseudowire encapsulation #ip local interface {int} - Sets the source interface of the tunnel (only for L2TPv3) #interworking {{ethernet | i p} | vlan} - Sets the type of pseudowire and the type of traffic allowed

#connect {name} {int} {dlci} l2transport - Used for Frame Relay AToM/L2TPv3 pseudowires

#xconnect {remote-pe} {vcid} [encap [mpls|l2tpv3|manual]] [pw-class {name}] - Specifies the local AC to connect to remote PE/VCID - [pw-class] Specifies the PW-class

#interface{int}

#xconnect {remote-pe} {vcid} [encap [mpls|l2tpv3|manual]] [pw-class {name}]


TOC 206

- Specifies the local AC to connect to remote PE/VCID - [pw-class] Specifies the PW-class

#ppp ipcp address proxy {ip} - Allows a PE router to proxy IPCP traffic to the remote CE router

#interface{int} - PPP interface on the CE router

#peer default ip address {ip} - Manually specify the IPCP peer IP address

XR-COMMANDS

# sh l2tun session [detail|brief] - Shows details about the L2TPv3 sessions # sh l2tun session interworking - Shows the interworking L2TPv3 information

#hw-module slot {number} np mode feature - Enables L2TPv3 L2VPN interworking

#l2vpn - Enters L2VPN mode

#pw-class {name} - Creates the pseudowire class #encapsulation {mpls|l2tpv3} - Sets the encapsulation to AToM or L2TPv3 #sequencing {both} - Enables pseudowire class sequencing #protocol l2tpv3 class {name} - Sets dynamic pseudowire signaling #ipv4 source {ip} - Sets the local source IP address

#xconnect group {name} - Creates the pseudowire group

#interworking ipv4 - Enables interworking #p2p {name} - Creates the point-to-point pseudowire group #interface {int} - Specifies the interface #neighbor {remote-pe} pw-id {vcid} - Sets the pseudowire to the remote PE router #pw-class {name} - References a pseudowire class

Local Switching

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | Wide-Area Networking Config Guide | | Layer 2 Local Switching

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS-XR > Cisco IOS XR Software | | | | Configuration Guides | | Release 3.9 | | Virtual Private Network Configuration Guide | | Implementing Layer 2 Tunnel Protocol Version 3 | | Local Switching

- Local switching (local connections) allows s wi tch ing layer2 frames between two interfaces or circu its on the same router of: > The same data type (Ethernet-to-Ethernet, Frame-Relay-to-Frame-Relay, and DHLC-to-HDLC etc.) > Different data types (Ethernet-to VLAN, etc.)

- The "connect" command is used to configure local connects. - But the "connect" commands is also used with other technologies. This is indicated in the CLI context.


TOC 207

- Refer to the command section to see the options.

- The 'in terworking ' keyword mus t be defined when different data types are used on the two connect in terfaces. - Refer to the In terworking section for m ore detai ls.

CONFIG-SET : Local Connect - Frame Relay DLCI to DLCI Switching

| interface se1/0 | encapsulation frame-relay | frame-relay int-type nni - Specifies the interface as a Frame Relay NNI | ! | connect DLCI2DLCI se1/0 100 se1/0 200 - Creates a local connect between two DLCIs |

CONFIG-SET : (IOS) Local Connect - Ethernet Port to Ethernet VLAN Switching

| interface fa1/1 | ! | interface fa0/0.2 | encapsulation dot1q 2 - Enables dot1Q encapsulation | ! | connect ETH2VLAN fa1/1 fa0/0.2 interwork ethernet - Creates a local connect between the two different Ethernet interfaces |

CONFIG-SET : (IOS-XR) Local Connect - Ethernet Port to Ethernet VLAN Switching

| interface gi0/0/2/1 l2transport - Enables the interface to operate in L2VPN port mode | ! | interface gi0/0/2/2.2 l2transport - Enables the interface to operate in L2VPN VLAN mode | encapsulation dot1q 2 - Enables dot1Q encapsulation | rewrite ingress tag pop 1 symmetric - Enables the addition/removal of a VLAN tag | ! | l2vpn - Enters the L2VPN configuration mode | bridge group ETH2VLAN - Creates a bridge group to contain the bridge domains | bridge-domain RB - Create a bridge domain for the two Ethernet interfaces | interface gi0/0/2/1 - Creates a local connect between the two different Ethernet interfaces | interface gi0/0/2/2.2 |

IOS-COMMANDS

# sh connect [all|name|port] - Shows details and status of the local connects

#connect {name} {int} {dlci} l2transport - Used for Frame Relay AToM/L2TPv3 pseudowires

#connect {name} {fr-int} [dlci] {fr-int} [dlci] - Used for Frame Relay to Frame Relay switching #connect {name} {eth-int} {eth-int} - Used for Ethernet to Ethernet local switching #connect {name} {eth-int} {vlan-int} interworking ethernet

- Used for Ethernet to VLAN local switching Copyright © 2013 Routing-Bits.com

TOC 208

#connect {name} {eth-int} {fr-int} {dcli} interworking ip - Used for Ethernet to Frame Relay local switching

XR-COMMANDS

# sh l2vpn forwarding - Shows the L2VPN forwarding information # sh l2vpn session [brief] - Shows L2VPN sessions

#l2vpn - Enters the L2VPN configuration mode

#bridge group ETH2VLAN - Creates a bridge group to contain the bridge domains #bridge-domain R - Create a bridge domain for the two Ethernet interfaces #interface {int} - Specifies the AC interface

Pseudowire Redundancy

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | Wide-Area Networking Config Guide | | L2VPN Pseudowire Redundancy

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS-XR > Cisco IOS XR Software | | | | Configuration Guides | | Release 3.9 | | Virtual Private Network Configuration Guide | | Implementing Virtual Private LAN Services | | Pseudowire Redundancy for P2P AToM Cross-Connects

- A passive backup pseudowire can be configured to become active when a primary pseudowire fai ls. - When the failed primary pseudowire comes back up, i t will resume primary operational ro le . This could be disabled, i f deemed disruptive. - Pseudowire redundancy provides a solution to protect the following single points of failure:

> PE fa ilure. > CE fa ilure. > AC l ink fai lure. > Pseudowire path failure.

- Only one backup pseudowire per primary pseudowire is supported. - The backup pseudowire becomes active only after the primary pseudowire fails. - The primary and backup AToM pseudowires mus t run the same type of transport service. - Configured with the "backup peer" command on IOS under the in terface configuration for an AC. - Backup pseudowire can be applied to VPLS pseudowires as well .


TOC 209

CONFIG-SET: AToM Pseudowire Redundancy with HDLC

|The following example shows a High-Level Data Link Control (HDLC) attachment circuit xconnect with a backup pseudowire: | | pseudowire-class mplsbck | encapsulation mpls | ! | interface se1/0 | xconnect 150.5.0.1 555 pw-class mplsbck - Creates the primary pseudowire | backup peer 150.5.0.2 555 pw-class mplsbck - Creates the passive backup pseudowire |

IOS-COMMANDS

# sh connect [all|name|port] - Verifies connect details, status of the local connects

#connect {name} {interface} [dlci|pvc] {interface} [dlci|pvc] [interworking ip | ethernet]

- Creates a local layer2 connect #xconnect {remote-pe} {vcid} encapsulation mpls - Creates the pseudowire #backup peer {remote-pe} {vcid} [pw-class {name}] - Creates a backup pseudowire VC #monitor peer bfd local int {int} {remote-pr} - Enables fast-failure detection using BFD

#connect {name} {interface} {dlci} l2transport - Defines local connect between frame-relay PVCs

#xconnect {remote-pe} {vcid} encapsulation mpls - Creates the pseudowire #backup peer {remote-pe} {vcid} [pw-class {name}] - Creates a backup pseudowire VC

XR-COMMANDS

# sh l2vpn bridge-domain [detail] - Shows the pseudowire details

#l2vpn - Enters L2VPN configuration mode

#xconnect group {name} - Enters the name of the xconnect group #p2p {name} - Specifies the point-to-point xconnect #neighbor {remote-pe} pw-id {vcid} - Creates the primary pseudowire #backup neighbor {remote-pe} pw-id {vcid} - Creates the passive backup pseudowire

#pw-class {name} - Enters the pseudowire class #backup disable delay {sec} - Sets the delay before backup pseudowire becomes active

VPLS

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS-XR > Cisco IOS XR Software | | | | Configuration Guides | | Release 3.9 | | Virtual Private Network Configuration Guide | | Implementing Virtual Private LAN Services


TOC 210

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Configuration Guide | | Part 6: MPLS: Layer 2 VPNs | | VPLS Auto discovery: BGP Based

- VPLS (Vi rtua l Private LAN Service) is a point-to-mul tipo int and multipo int-to-m ul tipoint extension of AToM for transparent Ethernet based services.

- CE routers connect to VPLS PE routers using ACs which are jo ined using multip le pseudowires. - VPLS requires a fu ll mesh of pseudowires between VPLS PE routers belonging to the same bridged (VPLS) domain. - Multiple bridged domains can be setup for di fferent clients and di fferent requi rements . - VPLS is extremely dependent supported hardware, thus i t is possible that some portions below m ight not be seen in the CCIE SPv3 lab.

Figure 9-8: VPLS

- VPLS Components > Control Plane - Signaling of pseudowires use targeted LDP session to exchange label values and attributes . > Transport Network - LDP LSPs are used between VPLS PE routers. > Tunnel Component - The VC label received from the egress VPLS PE is used to label the L2-PDUs. > Transported Protocols - Ethernet and 802.1Q frames .

- Every VPLS enabled PE router emulates a vi rtua l switch with MAC forwarding tables to emulate the behavior of an Ethernet swi tch. - ACs connect to th is vi rtua l swi tch, while pseudowires connect the vi rtual switches on the VPLS PE routers over a MPLS network. - With EoMPLS the mapping between the AC and a pseudowire is a one-to-one rela tionship. - With VPLS the mapping between the AC and all the pseudowires are a many-to-many rela tionships. - A VFI (Vi rtua l Forwarding Ins tance) is a vi rtual swi tch in terface on a VPLS PE router that performs the following functions:

> Dynamic source-based MAC address learning (s til l forwarding plane). > Destination-based MAC addresses forwarding. > Flooding of broadcast/mul ticast and unknown unicast tra ffic. > Aging of MAC addresses in the forwarding tab le . > Withdrawal of MAC addresses from the forwarding table .

- MAC address learning takes place dynamically when packets arrive on a VPLS PE router, similar to a tradi tional switch. - If the source MAC address is unknown, an entry with an aging tim er is added to the forwarding table , with the pseudowire or VC the packet arrived on as the outgoing

in terface. - If the source MAC address is known, the aging timer of the existing entry in the forwarding table is updated. - Layer2 loop prevention is done using spli t horizon forward ing. - Spli t horizon is enabled by defaul t, meaning packets arriving from one pseudowire are not forwarded in to another pseudowire. - All VPLS PE routers part of the same VPLS domain should have the same unique VPN ID. - VPN IDs m ay not overlap with the VCIDs used with normal point-to-point pseudowires. - By defaul t layer2 contro l PDUs (VTP, STP, and CDP) are dropped at ingress VPLS PE routers .


TOC 211

- Layer2 protocol tunneling configured with "l2protocol -tunnel" allows VTP, STP or VTP to be sent across a pseudowire. - Enabling STP might be required in certain VPLS network designs to avoid downstream loops. - MAC Address Limiting

> The number of MAC address learned can be l imi ted through configuration at the bridge domain level and at an in terface level . > When the l imi t is reached, the following actions are avai lable:

>> Lim i t Flood - Stops learning new MAC addresses, when limi t is reached. >> Lim i t No-Flood - Stops learning new MAC addresses and stops flooding unknown unicast packets . >> Shutdown - Shuts down all bridge domain functions or the viola ting port. Can only be undone manually.

> When the viola tion occurs, noti fication can be generated or disabled via one of the following options : >> Syslog - Defaul t method of noti fication. >> SNMP trap - Send traps to the SNMP s erver. >> Both - Syslog events and traps. >> None - Disables all noti fications .

- VPLS Modes > Port Mode

>> All frames received on an AC (tagged, untagged, and BPDUs) are transparently forwarded over the bridge domain. >> Also known as TLS (Transparent LAN Services). TLS emulates the behavior of a hub. >> Flooding is di rected to all ACs belonging to the same bridge domain. >> Can't have dupl icates MAC address as the bridge domain in this mode is one big broadcast domain.

> VLAN Mode >> The VLAN ID in received packets on an AC is used to differentia te client VLANs from one another. >> BPDUs from CE routers are processed by the VPLS PE routers . >> Also known as EVCS (Ethernet Virtua l Connection Service). EVCS emulates the behavior of a swi tch. >> Each carried VLAN across a bridge domain has i ts own MAC address space and forms one broadcas t domain. >> Flooding is limi ted to the carried VLAN within a bridge domain.

- VPLS PE neighbors can be configured in the following ways : > Manually specifying each VPLS PE neighbor participating in the bridge domain. > Using BGP Autodiscovery

>> Each VPLS PE uses BGP to discover and keep track of other VPLS PE routers belonging to the same bridging domain. >> BGP only assists with the VPLS neighbor discovery; the pseudowire signaling s till happen via targeted LDP.

- VPLS Configuration Requirements > PE routers m ust have a routed loopback IP address with a /32 mask. > MPLS LSPs should exis t between these PE loopback IP addresses.

- VPLS Configuration Steps > Configure the ACs. > Configure the bridge-domain by specifying the VPN ID. > Speci fy the rem ote VPLS PE routers for pseudowires to be setup. > Create/Enter the VFI/SVI in terface. > Associate ACs to the VFI.


TOC 212

CONFIG-SET : (IOS-XR) VPLS PE Router Configuration Example

| interface gi0/1/0/1.100 | l2transport - Specifies the AC facing the LAN | dot1q vlan 100 - Specifies the VLAN | ! | l2vpn | bridge group VPLS | bridge-domain 100 | interface gi0/1/0/1.100 - Links the AC to the bridge-domain | ! | vfi 100 - Creates the logical bridge interface | neighbor 150.2.2.2 pw-id 100 - Specifies the VPLS PE neighbors | neighbor 150.3.3.3 pw-id 100 |

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | Configuration Guides | | MPLS Configuration Guide | | Part 6: MPLS: Layer 2 VPNs | | H-VPLS N-PE Redundancy for QinQ and MPLS Access

- HVPLS (Hierarchical VPLS) > In ter-AS VPLS and in ter-network VPLS is deployed using HVPLS m odels . > HVPLS models offer improved scalability for large scale deployments by reducing the number of pseudowires required. > HVPLS models typically consist of two tiers /autonomous s ystems. > A PE router in the top tier is called a NPE (Network-facing PE) and a PE router in the bottom called a UPE (User-facing PE).

Figure 9-9: HVPLS Architecture

> The two models for deployment are: 1- HVPLS with MPLS access network

>>> NPE-to-NPE routers should connect via fu ll mesh of VPLS pseudowires. >>> UPE-to-NPE routers should connect via with hub-spoke pseudowires, with a UPE connecting to one NPE. >>> Spl i t horizon should be enabled NPE-to-NPE and disabled for NPE-to-UPE pseudowires. >>> Packets arriving from pseudowires connected to NPEs are forwarded to UPEs only.


TOC 213

>>> Packets arriving from pseudowires connected to UPEs are forwarded in to other pseudowires. 2- HVPLS with QinQ access network

>>> NPE-to-NPE routers should connect via fu ll mesh of VPLS pseudowires. >>> UPE-to-NPE routers should connect via with Ethernet QinQ, with a UPE connecting to one NPE. >>> Spl i t horizon should be enabled NPE-to-NPE. >>> Copy subtly owned by James Gibson. >>> Packets arriving from pseudowires connected to NPEs are forwarded to UPEs only. >>> Packets arriving from UPEs QinQ tunnels are forwarded in to other pseudowires.

> A UPE can m ulti -hom e to NPEs for redundancy, but would require STP enabled on the UPE for i ts UPE-to-NPE links. > If STP is enabled, the NPE can be configured to ei ther re lay the BPDUs or participate in STP.

IOS-COMMANDS

# sh vfi [summary|name|detail|vcid] - Shows information related to VFIs # sh xconnect [all|int|peer] - Shows information about ACs and pseudowires # sh mpls l2transport vc [detail] - Shows information about the AToM pseudowires

#interface {int}

#switchport mode access - Sets the interface to single untagged VLAN interface #switchport access vlan {vlan-id} - Sets the access mode VLAN ID

#interface {int}

#switchport mode trunk - Sets the interface to trunking mode

#interface {int}

#switchport mode dot1q-tunnel - Sets the interface to 802.1Q tunnel mode #switchport access vlan {vlan-id} - Sets the access tunnel VLAN ID #l2protocol-tunnel {cdp|vtp|stp} - Enables protocol tunneling on an interface

#l2 vfi {name} autodiscovery - Enables VPLS autodiscovery

#vpn id {vpn id} - Specifies the VPN ID of the bridging domain

#l2 vfi {name} manual - Enables VPLS manual configuration mode

#vpn id {vpn id} - Specifies the VPN ID of the bridging domain #shutdown - Disables the bridge domain on the VPLS PE #neighbor {vpls-peer-ip} encap mpls [no-split-hori] - Specifies the remote VPLS peers

- [no-split-horizon] Required on hub of a hub-spoke design #interface vlan {vlan-id} #no ip address - Disables IP routing for the SVI #xconnect vfi {name} - Associates the VFI with the VLAN


TOC 214

XR-COMMANDS

# sh l2vpn bridge-domain [brief|summary|detail] - Shows information about the bridge domain, the ACs, PWs, MTU, etc. # sh l2vpn forward bridge mac [mac] loc {linecard} – Shows the MAC address table on the PE

- [linecard] Is the linecard that the AC is connected to

#l2vpn - Enters L2VPN configuration mode

#bridgegroup {g-name/number} - Creates a bridge group #bridge-domain {d-name/number} - Specifies the bridge domain #interface {int} - Adds the AC interface to the bridge domain for forwarding #static-mac-add {mac} - Associates a remote MAC address with the pseudowire

#vfi {vfi-name} - Creates VFI/Enters VFI configuration mode #shutdown - Disables the VFI #neighbor {remote-pe} pw-id {vcid} - Creates the primary pseudowire #pw-class {name} - Reference a pseudowire class #flooding disable - Disables flooding of traffic #flooding unknown-unicast disable - Blocks unknown unicast flooding #mtu {mtu} - Sets the MTU for the bridge domain #shutdown - Disables the bridge domain on a VPLS PE #mac - Enters MAC configuration mode #learning disable - Disables dynamic MAC learning #withdrawal - Enables the MAC address withdrawal #aging - Enters MAC aging configuration mode #time {sec} - Sets the maximum aging time #type {absolute|inactivity} - Sets the type of MAC aging

#limit - Enables/Enters MAC limiting configuration mode #action {flood|no-flood|shutdown} - Sets the MAC limiting violating action #notification {trap|none|both} - Sets the notifications used when MAC limits are exceeded


TOC 215

Bibliography


RFC-4664 Framework for Layer 2 Virtua l Private Networks (L2VPNs) http ://www.ie tf.org/rfc/rfc4664.txt

RFC-4447 Pseudowire Setup and Maintenance - Using the Label Distribution Protocol (LDP) http ://www.ie tf.org/rfc/rfc4447.txt

RFC-4385 Pseudowire Emulation Edge-to-Edge (PWE3) - Control Word for Use over an MPLS PSN http ://www.ie tf.org/rfc/rfc4385.txt

RFC-4906 Transport of Layer 2 Frames Over MPLS http ://www.ie tf.org/rfc/rfc4906.txt

RFC-6624 L2VPNs Using BGP for Auto-Discovery and Signaling http ://www.ie tf.org/rfc/rfc6624.txt

RFC-4762 Virtua l Private LAN Service (VPLS) Using Label Dis tribution Protocol (LDP) Signaling http ://www.ie tf.org/rfc/rfc4762.txt

RFC-4761 Virtua l Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling http ://www.ie tf.org/rfc/rfc4761.txt

RFC-2817 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 http ://www.ie tf.org/rfc/rfc2817.txt


TOC 216



TOC 217

Chapter 10

INTER-AS


TOC 218

Overview

- In ter-AS MPLS is generally used when one client has si te /s which are connected to di fferent MPLS providers . - There are di fferent In ter-AS MPLS connectivi ty/design options available:

> Option-1 - Back-to-Back VRFs > Option-2a - VPNv4 eBGP peering using Next-Hop-Sel f. > Option-2b - VPNv4 eBGP peering using Redistribute connected. > Option-2c - VPNv4 eBGP peering between loopbacks. > Option-3 - Multihop VPNv4 eBGP between RRs.

- Cisco's naming for these options vary, option 1 (a .k.a . 10A), option 2 (a .k.a . 10B) and option 3 (a .k.a . 10C) - I t is recommended to have a solid understanding of MPLS before continuing with th is chapter. - Let's s tart with a couple rules and reminders . - Always rem ember to consider the label stack depth to avoid MTU problems with In ter-AS designs. - The length of an LSP is determined by the point of label imposi tion unti l the next-hop is changed.

- Label Types > LDP labels - Transport labels for IPv4 IGP routes, distributed by TDP or LDP. > BGP labels - Transport labels for IPv4 BGP routes , dis tributed by IPv4 BGP (a .k.a . IPv4+Label ). > VPN labels - Labels for VPNv4 BGP routes, distributed by VPNv4 BGP.

- IPv4 BGP > Requires IP reachabili ty between the source IP addresses to bring the session up. > Requires the IP next-hops to be reachable using the RIB tab le to consider the routes .

- VPNv4 BGP session > Requires IP reachabili ty between the source IP addresses to bring the session up. > Requires an LSP to the IPv4 BGP next-hop to allow successful label swi tching.

- BGP Next-Hop Behavior > The BGP next-hop address affect what the transport-label is bound to . > By defaul t, a BGP next-hop value is only updated to the sending router when passed over an eBGP session. > If the next-hop is not reachable, the routes learned via that next-hop wi ll not be considered or used. > This can be recti fied by:

>> Changing the BGP next-hop to the router which is advertising those routes using the "next-hop-sel f" command. >> Originating the remote router's in terface in to the local IGP for reachabili ty.

- Defaul t Route-Target Fil ter > By defaul t a MPLS VPN router will ignore fi l ter VPNv4 routes , i f the RTs attached to those routes do not match a VRF configured locally with matching RT s tatements . > Routers mus t have knowledge of the VPNv4 routes to be able to advertise them to a neighboring AS. > The defaul t behavior of fi l tering VPNv4 routes can be changed by:

>> Configuring a VRF locally for each of the required RTs. >> Disabling the default route-target fil ter with "no bgp defaul t route-target fil ter". >> Configuring the router as a RR (Route-Reflector), since a RR accepts all VPNv4 routes by defaul t.


TOC 219

- Set MPLS-Label > Route m aps enables the following fil tering:

>> For a router dis tributing MPLS labels, you can specify which routes are dis tributed with an MPLS label. >> For a router receiving MPLS labels, you can specify which routes are accepted and ins talled in the BGP table .

> By defaul t i f a route-map is used to fil ter prefixes on a link used for MPLS propagation, all prefixes are sent unlabeled. > The command "set mpls-label " is requi red to allow the route to be distributed with a label i f the route-map action is permi t.

- Topology and lab deta ils used in this chapter

Figure 10-1: Inter-AS Chapter Topology

> There are two clients i l lustra ted in the topology: >> CLIENT1 - Has two sites presented by CE7 and CE8.

- Uses VRF-78 throughout both ASs. >> CLIENT2 - Has two sites presented by CEa and CEb.

- Uses VRF-AB throughout both ASs. > There are two SPs (Service Providers) in the topology in terconnecting CLIENT1's and CLIENT2's sites. > SP-A uses OSPF and SP-B uses ISIS as the ir core IGPs. > The config-sets used in this chapter was simpli fied to focus purely on relevant In ter-AS portions. > Consideration for MTU config , LDP router-IDs, fil tering of any kind, etc., were omitted (expect in Option-3). > P3 and P4 are setup as RRs (Route Reflectors). > Any PE-CE protocols m ay be used with In ter-AS. > The focus of th is chapter should be to unders tand what action is requi red under which circumstances, to be able to configure In ter-AS as requi red in production designs. > The Config-Sets in th is chapter focuses only on IOS, as th is chapter is accompanied with full dynamips configs. > The fu ll config for th is chapter is available at http ://db.tt/TjZITnRF.


TOC 220

Option-1: Back-to-back VRF

- The ASBRs treat each other as any regular CE router and the In ter-AS l ink as a normal PE-CE link, with no LSPs between the ASs.

Figure 10-2: Inter-AS Option-1: Back-to-back VRF

- Option-1 is simple, secure and a feasible option for real -world SPs (Service Providers).

- I t is also the mos t commonly deployed option. - The PE routers (PE1 and PE2) on the edge between two ASs (Autonomous Sys tems) act as ASBRs (Autonomous System Border Routers). - The ASBRs are connected using a single physical l ink with multip le logical sub-interfaces or m ultiple physical l inks. - Each link (logical or physical) is used to carry a single client VRF. - Each ASBR treats the other ASBR as any regular CE router and the In ter-AS link as a normal PE-CE l ink. - Al though any VRF s upporting protocol can be used to distribute the VPN routes between the ASs, eBGP is a popular choice by SPs. - With Option-1 there is no label dis tributions between the ASBRs and thus no LSPs between the ASs. - LSPs only exis t inside each AS, as -wi th normal MPLS communication. - In ter-AS communication relies purely on IP forwarding.


TOC 222

Option-2a: VPNv4 eBGP peering using Next-Hop-Self

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | MPLS Configuration Guide, Release 12.2SX | | Layer 3 VPNs: Inter-AS and CSC Configuration Guide | | MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Virtual Private Network Configuration Guide | | Implementing MPLS Layer 3 VPNs on Cisco IOS XR Software | | Inter-AS Support for L3VPN

- The adjacent ASBRs exchange VPNv4 routes for In ter-AS connectivi ty. - Option-2a illus tra tes the BGP "next-hop-se l f" approach.

Figure 10-3: Inter-AS Option-2a: VPNv4 eBGP peering using Next-Hop-Self

- The PE routers (PE1 and PE2) on the edge between two ASs act as ASBRs. - The ASBRs are connected using a single l ink. - A VPNv4 eBGP session is setup between the ASBRs using the local In ter-AS link. An IPv4 eBGP session is not required. - With Option-2a, each ASBR announces i tsel f as the next-hop for VPNv4 routes received from the neighbor ASBR, when advertising these routes inside i ts local AS. - Since the next-hop is the local ASBR:

> The fi rs t LSP extends from the ingress PE router to the local ASBR. > The second LSP extends from one ASBR to the neighbor ASBR. > The th i rd LSP extends from the remote ASBR to the egress PE router in the neighboring AS.

- With Option-2a, there should be three LSPs per direction. - LDP is not requi red on the In ter-AS link. - The VPNv4 eBGP session between the di rectly connected interfaces enable label forwarding since both ASBRs are aware of the VPN label. - When using IPv4 eBGP or VPNv4 eBGP for label exchange over a directly connected non-MPLS enabled in terface, the command "mpls bgp forwarding" will automatical ly be

added to the transi t interface on IOS devices.


TOC 223

CONFIG-SET: Option-2a: VPNv4 eBGP peering using Next-Hop-Self Configuration

| Full config omitted. The config between PE5/PE6 and their CEs are standard. The SPs LDP/BGP config are standard. | Only the left half of the relevant config is shown. | |PE1#no ip vrf 78 - Local VRF tables from Option-1 is not needed anymore | no ip vrf AB - Removes the VRF and ALL related configuration | no int FastEthernet0/0.78 - An interface per client is not needed | no int FastEthernet0/0.99 - Removes the per-client interfaces | ! | interface FastEthernet0/0.12 - Configures one interface between the ASBRs | ip address 12.1.12.1 255.255.255.0 | mpls bgp forwarding - Auto-command used to maintain MPLS forwarding for directly | ! connected BGP peers | router bgp 100 | no bgp default ipv4-unicast - (o) Disables default IPv4 routing behavior | no bgp default route-target filter - Needed to accept VPNv4 prefixes since not configured locally anymore | neighbor 12.1.12.2 remote-as 200 - BGP session to the neighbor ASBR (PE2) | neighbor 100.0.3.3 remote-as 100 - BGP session to the RR (P3) | neighbor 100.0.3.3 update-source Loopback0 | ! | address-family vpnv4 | neighbor 12.1.12.2 activate - Enables VPNv4 BGP to the neighbor ASBR (PE2) | neighbor 100.0.3.3 activate - Enables VPNv4 BGP to the local RR (R3) | neighbor 100.0.3.3 next-hop-self - ASBR announces itself as the next-hop for VPNv4 routes | |PE5#ip vrf 78 - Only one VRF is shown here, since the config is similar | rd 100:78 | route-target export 100:78 - Exports CLIENT1 routes with the SP1 RT value | route-target import 200:78 - Imports CLIENT1 routes from SP2 | |PE6#ip vrf 78 | rd 100:78 | route-target export 200:78 - Exports CLIENT1 routes with the SP2 RT value | route-target import 100:78 - Imports CLIENT1 routes from SP1 | |


TOC 224

Option-2b: VPNv4 eBGP peering using Redistribute Connected

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.2S Family > 12.2.SR | | MPLS Configuration Guide, Release 12.2SX | | Layer 3 VPNs: Inter-AS and CSC Configuration Guide | | MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses


- The adjacent ASBRs exchange VPNv4 routes for In ter-AS connectivi ty. - Option-2b is similar to Option-2a but offers a di fferent approach to the BGP "next-hop-sel f".

Figure 10-4: Inter-AS Option-2b: VPNv4 eBGP peering using Redistribute Connected

- The PE routers (PE1 and PE2) on the edge between two ASs act as ASBRs.

- The ASBRs are connected using a single l ink. - A VPNv4 eBGP session is setup between the ASBRs using the local In ter-AS link. An IPv4 eBGP session is not required. - With Option-2b, the remote IP of the In ter-AS l ink is redis tributed in to the IGPs of both SPs to provide reachabi li ty to the next-hop.

> Using an ACL with the redis tribution is advised for securi ty purposes in production networks . - Since the next-hop is the remote ASBR, for one di rection:

> The fi rs t LSP extends from the ingress PE router to the remote ASBR. > The second LSP extends from the remote ASBR to the egress PE router in the neighboring AS.

- With Option-2b, there should be two LSPs per di rection. - LDP is not requi red on the In ter-AS link. - The VPNv4 eBGP session between the di rectly connected interfaces enables label forwarding since both ASBRs are aware of the VPN label. - When using IPv4 eBGP or VPNv4 eBGP for label exchange over a non-MPLS enabled in terface, the command "mpls bgp forward ing" will automatical ly be added to the transi t

in terface.


TOC 225

CONFIG-SET: Option-2b: VPNv4 eBGP peering using Redistribute Connected Configuration

| Full config omitted. The config between PE5/PE6 and their CEs are standard. The SPs LDP/BGP config is standard. | Only the left half of the relevant config is shown. | |PE1#interface FastEthernet0/0.12 - Configures one interface between the ASBRs | ip address 12.1.12.1 255.255.255.0 | mpls bgp forwarding - Auto-command used to maintain MPLS forwarding for directly | ! connected BGP peers | access-list 69 permit 12.1.12.2 - Matches the neighbor ASBR's interface IP | route-map REDI permit 10 | match ip address 69 | ! | router ospf 1 | redistribute connected subnets route-map REDI - Allows only the remote ASBR IP to be redistributed | ! | router bgp 100 | no bgp default ipv4-unicast - (o) Disables default IPv4 routing behavior | no bgp default route-target filter - Needed to accept VPNv4 prefixes since not configured locally | neighbor 12.1.12.2 remote-as 200 - BGP session to the neighbor ASBR (PE2) | neighbor 100.0.3.3 remote-as 100 - BGP session to the RR (P3) | neighbor 100.0.3.3 update-source Loopback0 | ! | address-family vpnv4 | neighbor 12.1.12.2 activate - Enables VPNv4 BGP to the neighbor ASBR (PE2) | neighbor 100.0.3.3 activate - Enables VPNv4 BGP to the local RR (R3) | no neighbor 100.0.3.3 next-hop-self - Disables changing the BGP next-hop | |PE5#ip vrf 78 - Only one VRF is shown here, since the config is similar | rd 100:78 | route-target export 100:78 - Exports CLIENT1 routes with the SP1 RT value | route-target import 200:78 - Imports CLIENT1 routes from SP2 | |PE6#ip vrf 78 | rd 100:78 | route-target export 200:78 - Exports CLIENT1 routes with the SP2 RT value | route-target import 100:78 - Imports CLIENT1 routes from SP1 | |


TOC 226

Option-2c: VPNv4 eBGP peering between Loopbacks



- The adjacent ASBRs exchange VPNv4 routes using the i r loopback IPs ra ther than the di rectly connected interfaces.

Figure 10-5: Inter-AS Option-2c: VPNv4 eBGP peering between Loopbacks

- The PE routers (PE1 and PE2) on the edge between two ASs act as ASBRs. - The ASBRs are connected using a single or multiple links. - The VPNv4 eBGP session is setup between the ASBRs using the i r loopback IPs ra ther than the di rectly connected in terfaces.

> This implies that an IGP is needed to provide reachabili ty in formation about the neighbor ASBR's loopback. - A common reason to implement Option-2c is for load-balancing between the ASBRs when multiple links are availab le. - Since the next-hops are not di rectly connected, LDP is now requi red on the In ter-AS link between the ASBRs. - The auto command "mpls bgp forwarding" only applies to MPLS forwarding for di rectly connected BGP peers. - There are al ternatives to using LDP for Option-2c, but that is beyond the scope of the CCIE-SP. - The same BGP next-hop rules apply. The 'next-hop-sel f' method can be used here. - Since the next-hop is the local ASBR:

> The fi rs t LSP extends from the ingress PE router to the local ASBR. > The second LSP extends from one ASBR to the neighbor ASBR. > The th i rd LSP extends from the remote ASBR to the egress PE router in the neighboring AS.

- With Option-2c, there should be three LSPs per di rection.


TOC 227

CONFIG-SET: Option-2c: VPNv4 eBGP peering between Loopbacks Configuration

| Full config omitted. The config between PE5/PE6 and their CEs are standard. The SPs LDP/BGP config is standard. | Only the left half of the relevant config is shown. | |PE1#ip route 200.0.2.2 255.255.255.255 12.1.12.2 - Adds a route to PE2's loopback via the Inter-AS link | ! | interface FastEthernet0/0.12 - Configures one interface between the ASBRs | ip address 12.1.12.1 255.255.255.0 | mpls ip - Enables LDP on the Inter-AS link | ! | router bgp 100 | no bgp default ipv4-unicast - (o) Disables default IPv4 routing behavior | no bgp default route-target filter - Needed to accept VPNv4 prefixes if not configured locally | neighbor 100.0.3.3 remote-as 100 - BGP session to the RR (P3) | neighbor 100.0.3.3 update-source Loopback0 | neighbor 200.0.2.2 remote-as 200 - BGP session to the neighbor ASBR (PE2) loopback0 | neighbor 200.0.2.2 ebgp-multihop - Important to remember this is a eBGP multihop session | neighbor 200.0.2.2 update-source Loopback0 | ! | address-family vpnv4 | neighbor 100.0.3.3 activate - Enables VPNv4 BGP to the local RR (P3) | neighbor 100.0.3.3 next-hop-self - ASBR announces itself as the next-hop for VPNv4 routes | neighbor 200.0.2.2 activate - Enables VPNv4 BGP to the neighbor ASBR (PE2) | |PE5#ip vrf 78 - Only one VRF is shown here, since the config is similar | rd 100:78 | route-target export 100:78 - Exports CLIENT1 routes with the SP1 RT value | route-target import 200:78 - Imports CLIENT1 routes from SP2 | |PE6#ip vrf 78 | rd 100:78 | route-target export 200:78 - Exports CLIENT1 routes with the SP2 RT value | route-target import 100:78 - Imports CLIENT1 routes from SP1 | |


TOC 228

Option-3: Multihop VPNv4 eBGP between RRs



- One end-to-end LSP is established between the edge PE routers. - The VPNv4 peering with Option-3 is setup between the RRs in each AS.

Figure 10-6: Inter-AS Option-3: Multihop VPNv4 eBGP between RRs

- The PE routers (PE1 and PE2) on the edge between two ASs act as ASBRs.

- The ASBRs are connected using a single l ink. - With Option-3 one LSP is setup between the edge PEs (PE5 and PE6) in each AS using the i r loopback IPs. - The VPNv4 session for the edge PEs is advertised between the ASs using the RRs (P3 and P4).

> This implies that IP reachabi li ty is required for the VPNv4 neighbor's loopback IPs. > The IPv4 reachabili ty in formation could be provided by an IGP (originating/red istribution) or by BGP. > The m ultihop VPNv4 eBGP session (R3-to-R4) should not change the BGP next-hop in formation unless the RRs are in the forwarding path, with the command "neighbor

next-hop-unchanged". > The RRs in this config-set are not in the forwarding path.

- The ASBRs (PE1 and PE2) are responsible for exchanging the IPv4 next-hop addresses. - The ASBRs need to propagate label in formation for the next-hops to complete the end-to-end LSP between the edge PEs (PE5 and PE6).

> This could be accomplished using either an IGP (wi th LDP) or eBGP (IPv4+Label). > SPs usually prefer using eBGP with MPLS labels.


TOC 229

- Optional fi l tering was added here to Option-3, to illustra te when "set mpls-label" is required in a route-map. - Also for complexi ty purposes, to cover everyth ing possible needed:

> SP-A red istributes the remote AS next-hops in to OSPF to allow for LDP label distribution > SP-B uses IPv4 BGP between PE2-P4 and P4-PE6 for BGP label distribution.

CONFIG-SET: Option-3: Multihop VPNv4 eBGP between RRs Configuration

| Full config omitted. The config between PE5/PE6 and their CEs are standard. | Only the relevant config is shown. | |PE1#interface FastEthernet0/0.12 - Configures one interface between the ASBRs | ip address 12.1.12.1 255.255.255.0 | mpls bgp forwarding - Auto-command used to maintain MPLS forwarding for directly | ! connected BGP peers | ip prefix-list FILTER seq 5 permit 100.0.3.3/32 - (o) Matches the AS100 next-hop addresses | ip prefix-list FILTER seq 10 permit 100.0.5.5/32 - (o) Matches the AS100 next-hop addresses | ip prefix-list PE6 seq 5 permit 200.0.6.6/32 - (o) Matches the AS200 next-hop addresses | ip prefix-list R4 seq 5 permit 200.0.4.4/32 - (o) Matches the AS200 next-hop addresses | ! | route-map REDI permit 10 | match ip address prefix-list P4 - (o) Allows P4's loopback to be redistributed | route-map REDI permit 20 | match ip address prefix-list PE6 - (o) Allows PE6's loopback to be redistributed | ! | route-map FILTER permit 10 | match ip address prefix-list FILTER - (o) Filters the routes send to PE2 | set mpls-label - Permits sending MPLS labels, else they are filtered | ! | router ospf 1 | redistribute bgp 100 subnets route-map REDI - Redistributes AS200s routes | network 100.0.1.1 0.0.0.0 area 0 | network 100.1.135.1 0.0.0.0 area 0 | ! | router bgp 100 | no bgp default ipv4-unicast - (o) Disables default IPv4 routing behavior | no bgp default route-target filter - Needed to accept VPNv4 prefixes if not configured locally | neighbor 12.1.12.2 remote-as 200 - Enabled eBGP to neighboring ASBR (PE2) | address-family ipv4 | neighbor 12.1.12.2 activate - Activates neighboring ASBR (PE2) for IPv4 BGP | neighbor 12.1.12.2 send-label - Allows sending MPLS labels with BGP routes | neighbor 12.1.12.2 route-map FILTER out - (o) Filters what is sent to PE2 | network 100.0.3.3 mask 255.255.255.255 - Originates local next-hops (P3 and PE5) for reachability in AS200 | network 100.0.5.5 mask 255.255.255.255 |


TOC 230

|P3# router bgp 100 | no bgp default route-target filter - Needed to accept VPNv4 prefixes if not configured locally | neighbor 100.0.5.5 remote-as 100 - The iBGP peering to PE5 | neighbor 100.0.5.5 update-source Loopback0 | neighbor 200.0.4.4 remote-as 200 - The eBGP peering to P4 in AS200 | neighbor 200.0.4.4 ebgp-multihop - Important to remember this is an eBGP multihop session | neighbor 200.0.4.4 update-source Loopback0 | address-family vpnv4 | neighbor 100.0.5.5 activate - Actives PE5 for VPNv4 BGP | neighbor 200.0.4.4 activate - Actives P4 for VPNv4 BGP | neighbor 200.0.4.4 next-hop-unchanged - Leaves the next-hops unchanged when advertising routes to P4 | - With the next-hops being R5 and R6 an end-to-end LSP can be built |PE5#router bgp 100 | neighbor 100.0.3.3 remote-as 100 - Enables iBGP peering to P3 | neighbor 100.0.3.3 update-source Loopback0 | address-family vpnv4 | neighbor 100.0.3.3 activate - Actives P3 for VPNv4 BGP | ! | ip vrf 78 - Only one VRF is shown here, since the config is similar | rd 100:78 | route-target export 100:78 - Exports CLIENT1 routes with the SP1 RT value | route-target import 200:78 - Imports CLIENT1 routes from SP2 | > The config in AS#200 is the same for the most part, except for the IPv4 BGP transport label distribution which is shown here |PE2#router bgp 200 | neighbor 200.0.4.4 remote-as 200 - Enables iBGP to RR (P4) | neighbor 200.0.4.4 update-source Loopback0 | address-family ipv4 | neighbor 200.0.4.4 activate - Activates IPv4 iBGP to RR (P4) | neighbor 200.0.4.4 next-hop-self | neighbor 200.0.4.4 send-label - Advertises IPv4 BGP transport labels | |P4 #router bgp 200 | neighbor 200.0.2.2 remote-as 200 - Enables iBGP to ASBR (PE2) | neighbor 200.0.2.2 update-source Loopback0 | neighbor 200.0.6.6 remote-as 200 | neighbor 200.0.6.6 update-source Loopback0 - Enables iBGP to EDGE PE (PE6) | address-family ipv4 | neighbor 200.0.2.2 activate | neighbor 200.0.2.2 route-reflector-client | neighbor 200.0.2.2 send-label - Advertises IPv4 BGP transport labels | neighbor 200.0.6.6 activate | neighbor 200.0.6.6 route-reflector-client | neighbor 200.0.6.6 send-label - Advertises IPv4 BGP transport labels


TOC 231

IOS-COMMANDS

# sh ip cef [vrf name] [prefix] [detail] - Shows the FIB table entries # sh mpls forwarding-table - Shows the LFIB table entries # sh mpls interfaces [vrf name] - Shows the MPLS interfaces, enabled protocols # sh mpls ldp neighbor vrf {name} - Shows the status of LDP sessions # sh ip route [vrf] - Shows the global or a VRF RIB table # sh ip bgp labels - Shows the MPLS labels for the default BGP table # sh ip bgp vpnv4 [all|vrf|rd] labels - Shows the MPLS labels in the VRF tables # sh ip bgp summary - Shows the status of the global IPv4 BGP neighbors # sh ip bgp vpnv4 [all|vrf|rd] summary - Shows the status of the VPNv4 BGP neighbors # sh ip bgp [prefix] - Shows the global IPv4 BGP details for prefix # sh ip bgp vpnv4 {all|vrf|rd| [prefix] - Shows the VPNv4 BGP details for prefix

#mpls ldp router-id {int} [force] - Configures the LDP router-ID

#interface {int} #mpls ip - Enables LDP on the interface


#rd {route-distinguisher} - Assigns a route distinguisher to the VRF #route-target {both|import|export} {rt} - Specifies an RT actions for the VRF #import map {route-map} - Configures VRF import filtering #export map {route-map} - Configures selective VRF export

#interface {int}

#mpls bgp forwarding - Auto enabled to send MPLS labels for BGP routes between directly connected interfaces

#ip vrf forwarding {name} - This command associates an interface with a VRF - This will remove the existing IP address if configured

#router bgp {asn} #no bgp default ipv4-unicast - Disables the default exchange of IPv4 routes to all neighbors #no bgp default route-target filter - Needed to accept VPNv4 prefixes if not configured locally #neighbor {ip} remote-as {r-asn} - All BGP neighbors must be configured under global BGP config #neighbor {ip} update-source loopback0 - MP-iBGP sessions should run between loopback interfaces #address-family ipv4 vrf {name} - Enters configuration of IPv4 route exchanges #neighbor {ip} activate - Enables the neighbor for IPv4 route exchange #neighbor {ip} next-hop-self - Changes the next-hop IP to the local router's sending address #neighbor {ip} send-label - Enables sending labels with BGP routes #neighbor {ip} route-reflector-client - Enables the neighbor as a route-reflector client

#address-family vpnv4 - Enters configuration of VPNv4 route exchanges for MP-iBGP sessions #neighbor {ip} activate - Enables the neighbor for VPNv4 route exchange #neighbor {ip} next-hop-self - Changes the next-hop IP to the local router's sending address #neighbor {ip} next-hop-unchanged - Leaves the next-hop as-is for prefixes from the neighbor

#address-family ipv4 vrf {name} - Configures/enters the MP-BGP VRF context #neighbor {ip} remote-as {asn} - Configures an eBGP neighbor in the VRF context, not in the global BGP config #neighbor {ip} activate - eBGP neighbors must to be activated


TOC 232

XR-COMMANDS

# sh cef [vrf name] [prefix] [detail] - Shows the FIB table entries # sh mpls forwarding - Shows the LFIB table entries # sh mpls ldp interfaces [brief] - Shows the MPLS interfaces, enabled protocols # sh mpls ldp neighbor - Shows the status of LDP sessions # sh route [vrf] - Shows the global or a VRF RIB table # sh bgp ipv4 unicast labels - Shows the BGP labels for the default IPv4 BGP table # sh bgp vpnv4 unicast [vrf|rd] labels - Shows the BGP labels in the VRF tables # sh bgp ipv4 unicast summary - Shows the status of the global IPv4 BGP neighbors # sh bgp vpnv4 unicast [vrf|rd] summary - Shows the status of the VPNv4 BGP neighbors # sh bgp ipv4 unicast [prefix] - Shows the global IPv4 BGP details for prefix # sh bgp vpnv4 unicast [vrf|rd| [prefix] - Shows the VPNv4 BGP details for prefix


#address-family ipv4 unicast - Enables the IPv4 address-family for the VRF #import route-target {rt} - Specifies what MP-BGP routes to import into a VRF instance #export route-target {rt} - Specifies an RT to be attached to routes exported from the VRF to MP-BGP #import route-policy {name} - Configures VRF import filtering #export route-policy {name} - Configures selective VRF export




#pass #end-policy

#mpls ldp - Enters the MPLS configuration mode

#router-id {int} - Specifies the MPLS router identifier #interface {int} - Activate MPLS LDP on the interface


#bgp router-id {ip} - Configures the RID for BGP Process #address-family ipv4 unicast - Activates the BGP IPv4 unicast configuration mode #network {ip/mask} - Originates routes into BGP #allocate-label {route-policy|all} - Enables sending labels with BGP routes, same as "send-label" in IOS.

#address-family vpnv4 unicast - Activates the BGP VPNv4 unicast configuration mode #neighbor {ip} - Enters the BGP neighbor configuration mode #remote-as {asn} - Defines an external/internal neighbor #update-source {int} - Specifies the source interface for the TCP session that carries BGP traffic #ebgp-multihop {no} - Changes the TTL value for non-directly connected neighbors #address-family vpnv4 unicast - Enters the BGP VPNv4 unicast configuration mode #route-reflector-client - Enables the neighbor as a route-reflector client #next-hop-self - Changes the next-hop to the local router for all prefixes sent into AS #next-hop-unchanged - Leaves the next-hop as-is for prefixes from the neighbor


TOC 233

#neighbor {ip} - Enters the BGP neighbor configuration mode #remote-as {asn} - Defines an external/internal neighbor #update-source {int} - Specifies the source interface for the TCP session that carries BGP traffic #address-family ipv4 labeled-unicast - Enables IPv4 labeled-unicast address prefixes #route-policy {name} {in|out} - On IOS-XR a permit route-policy in required

#vrf {name} - Enters the BGP VRF configuration mode

#rd {value|auto} - Assigns a route distinguisher to a VRF routes going into MP-BGP #address-family ipv4 unicast - Activates the BGP VRF for IPv4 unicast #neighbor {ip} - Configures an eBGP neighbor in the VRF context #remote-as {asn} - Specifies the CE routers ASN #address-family ipv4 unicast - Enters the PE-CE IPv4 address-family #route-policy {name} in - On IOS-XR without a policy no eBGP routes are accepted #route-policy {name} out - On IOS-XR without a policy no eBGP routes are sent


TOC 234

Walking the LSP

- The end-to-end LSPs using Option-3 above is build using a mixture of LDP, BGP and VPN label distribution. - This is not a requi rement, but was purposefully done to show the in terworking of label operations . - Unders tanding the label stack and how to follow i t makes troubleshooting a li ttle easier.

Inter-AS: Walking the LSP (CE7-to-CE8) Figure 10-7: Inter-AS Option-3: Walking the LSP (CE7-to-CE8)

PE5#sh ip route vrf 78 172.16.8.8 | i via|ago|for - How was the destination learned? Routing entry for 172.16.8.8/32 - VRF learned route = VPN label is used Known via "bgp 100", distance 200, metric 0 * 200.0.6.6 (Default-IP-Routing-Table), from 100.0.3.3, 00:02:48 ago - Via the BGP next-hop (PE6)

PE5#sh ip bgp vpnv4 vrf 78 labels | i 172.16.8.8 - MPLS rule, if a label exists for the destination 172.16.8.8/32 200.0.6.6 nolabel/18 the packet will be sent labeled

- Label (18) was advertised by PE6 for 172.16.8.8/32

PE5#sh ip route 200.0.6.6 | i Known - How was the BGP next-hop learned? Known via "ospf 1", distance 110, metric 2, type intra area - IGP learned route = LDP label is used

PE5#sh mpls forwarding-table 200.0.6.6 - How is the BGP next-hop reached? Local Outgoing Prefix Bytes tag Outgoing Next Hop - The packet will be labeled as follow: tag tag or VC or Tunnel Id switched interface (21) = LDP transport label from PE1 23 21 200.0.6.6/32 0 Et0/0.135 100.1.135.1 (18) = VPN label from PE6

PE1#sh ip route 200.0.6.6 | i Known - How was the BGP next-hop learned? Known via "bgp 100", distance 20, metric 20 - BGP learned route = BGP label is used

PE1#sh ip bgp labels | i _21 - The LDP in-label (21) is swapped with out-label (17) 200.0.6.6/32 12.1.12.2 21/17 before packet is sent to PE2

PE1#sh mpls forwarding-table | i ^21 - The LFIB table confirms above, although BGP labels not always 21 17 200.0.6.6/32 4608 Fa0/0.12 12.1.12.2 shown in the LFIB, on some platforms


TOC 235

PE2#sh ip route 200.0.6.6 | i Known - How was the BGP next-hop learned? Known via "isis", distance 115, metric 20, type level-2 - IGP learned route = LDP label is used

PE2#sh mpls forwarding-table | i ^17 - The in-label (17) is disposed before packet 17 Pop Label 200.0.6.6/32 5696 Fa0/0.246 200.1.246.6 is sent to PE6

PE6#sh ip bgp vpnv4 all labels | i _18 - Packet arrives at the BGP next-hop with a top 172.16.8.8/32 172.16.68.8 18/nolabel label (18) which indicates the IP next-hop interface

PE6#sh ip vrf int | i 172.16.68. - The exit interface to the destination is e0/0.68 Et0/0.68 172.16.68.6 78 up


TOC 236

Inter-AS: Walking the LSP (CE8-to-CE7) Figure 10-8: Inter-AS Option-3: Walking the LSP (CE8-to-CE7)

PE6#sh ip route vrf 78 172.16.7.7 | i Known - How was the destination learned? Known via "bgp 200", distance 200, metric 0 - VRF learned route = VPN label is used

PE6#sh ip bgp vpnv4 vrf 78 label | i 172.16.7.7 - Label present, so packet is sent labeled 172.16.7.7/32 100.0.5.5 nolabel/18 - VPN label (18) was received from PE5 for 172.16.7.7/32


PE6#sh ip bgp labels | i 100.0.5.5 100.0.5.5/32 200.0.2.2 nolabel/22 - Transport label (22) was received from PE2 for BGP next-hop

PE6#sh ip cef vrf 78 172.16.7.7 detail - The FIB table confirms the double label imposition 172.16.7.7/32, version 28, epoch 0, cached adjacency 200.1.246.2 0 packets, 0 bytes tag information set

local tag: VPN-route-head - (22) = BGP transport label from PE2 fast tag rewrite with Et0/0.246, 200.1.246.2, tags imposed: {22 18} - (18) = VPN label from PE5


PE2#sh ip bgp labels | i _22 - The BGP transport in-label (22) is swapped with the 100.0.5.5/32 12.1.12.1 22/17 out-label(17) before the packet is sent to PE1

PE1#sh ip route 100.0.5.5 | i Known - How was the BGP next-hop learned? Known via "ospf 1", distance 110, metric 2, type intra area - IGP learned route = LDP label is used

PE1#sh mpls forwarding-table | i ^17 - The top label (17) is popped before packet 17 Pop Label 100.0.5.5/3 8720 Fa0/0.135 100.1.135.5 is sent to PE5


TOC 237

PE5#sh ip bgp vpnv4 all label | i _18 - Packet arrives at the BGP next-hop with a top label, 172.16.7.7/32 172.16.57.7 18/nolabel the VPN label (18) which indicates the IP next-hop

PE5#sh ip vrf int | i 172.16.57. - The exit interface to the destination is e0/0.57 Et0/0.57 172.16.57.5 78 up - '78' is the VRF


TOC 238



TOC 239

Chapter 11

CSC


TOC 240

CSC Overview

DOC-CD REFERENCE: | Products > Cisco IOS > Cisco IOS > 12.4 Family > 12.4T | | Configuration Guides | | MPLS Configuration Guide | | Part8: MPLS Layer 3 VPNs: Carrier Supporting Carrier

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Virtual Private Network Configuration Guide | | Implementing MPLS Layer 3 VPNs on Cisco IOS XR Software | | Carrier Supporting Carrier Support for L3VPN

- CSC is short for Carrier Supporting Carrier. - All carriers/SPs (Service Providers) aim extend thei r network footprin t. - Occasionally i t happens that a SP needs to extend to an area not attached to thei r current backbone, e.g., in a di fferent country or reg ion. - The connectivi ty to a dis tant POP is m ore often driven by a cl ient that has remote office, requi ring connectivi ty to thei r local network. - Expensive or lim i ted WAN connectivi ty to this remote POP (Point of Presence) could be a reason to use another SP's backbone for connectivi ty. - CSC allows a SP to in terconnect his remote POPs without operating his own WAN. - This could be achieved by buying an NNI (Network-to-Network In terconnect) service from another SP that has presence in the needed area. - The end res ul t is a hierarchy of SPs interconnecting the client sites of the one SP. - The simpl icity in understanding the CSC hierarchy, is to visualize how a normal SP connects different cl ient sites. - The fo llowing diagram shows a SP with two client si tes:

Figure 11-1: Basic MPLS Service Provider

- CSC is methods to in terconnect a provider's segregated backbone, by allowing transi t via another provider's backbone:

Figure 11-2: CSC MPLS Service Provider

- The terminology used in the section is di fferent to m ost other publications (reason, it's less confusing and m ore practical ): > CSC - Carrier Supporting Carrier, is the SP that offer interconnects the another SPs (CCs). > CC - Customer Carrier, is the SP that requires i ts client sites to be in terconnected via a CSC's backbone. > CSC-P - A core router with in the CSC network connecting the CSC-PE routers . > CSC-PE - An edge router within the CSC network where the CC-P routers connects to . > CC-P - A core router with in the CC network that also connects to the CSC-PE routers . > CC-PE - An edge router within the CC network that connects to the CC cl ient sites and CC P routers. > CE - Refers to a Customer Edge device in a customer site of the CC.


TOC 241

- I t is im portant to unders tand what labels are used when: > If the IP next-hop was learned via IGP, the label associated with the next-hop MUST have been received via LDP. > If the IP next-hop was learned via BGP, the label associated with the next-hop MUST have been received via BGP.

Figure 11-3: CSC Chapter Topology

- Topology and LAB details used in th is chapter: > The cl ient si te -1 and si te-2 belong to one SP-2, which uses SP-1 for WAN connectivi ty. > The lab s etup used in this section was simpli fied to focus purely on CSC. > Configuration for MTU config, LDP router-IDs , fil tering of any kind, etc. were omitted. > In production or in the lab, networks are almos t never segmented as simple as the lab setup used below. > I t is necessary to understand what is implemented in each m ethod, to be able to apply CSC in production designs. > The CSC models , covered below, are buil t on each other with only the relevant configs listed below. > The Config-Sets in th is chapter focuses only on IOS, as th is chapter is accompanied with full Dynamips configs available for download at http ://db.tt/h xrZOlB6 .

- A CSC is supported in several m odels : > CSC-1 - Native IP with s tatic routes . > CSC-2 - Native IP with LDP labels. > CSC-3 - MPLS with LDP labels. > CSC-4 - MPLS with BGP labels (IPv4+label ). > CSC-5 - MPLS VPN with LDP and BGP labels.


TOC 242

CSC-1 Native IP with Static Routes

- CSC-1 describes the method of implementing CSC when the CC is running a native IP core. - The CSC backbone runs MPLS VPN, but requires knowledge of the CE routes .

Figure 11-4: CSC-1 - Native IP with Static Routes Model

- The CE routers (R7 and R8) connects to the CC-PE routers using eBGP (R7-R5 and R6-R8). - The CC runs an IGP and iBGP with in i ts POPs. - The CC relies on IGP routing across a CSC VRF to enable the iBGP session between the CC-P routers (R3 and R4). - The CC-P routers are typ ica lly setup as route-reflectors with CSC-1. - The CCs in ternal routes are propagated to the CSC VRF using an IGP. This should not include client site routes . - The CSC backbone uses a VRF and MB-BGP to propagate the CC backbone routes across the CSC backbone. - The Native IP m odel requires s tatic routes to the client sites , in the CSC network to prevent transi t black-holes .


TOC 244

CSC-2 Native IP with LDP Labels

- CSC-2 describes the method of implementing CSC when the CC is running a native IP core. - The CSC backbone runs MPLS VPN and does not requi re knowledge of the client-sites since a LSP tunnels tra ffic between the CC POPs.

Figure 11-5: CSC-2 - Native IP with LDP Label Model

- The CE routers (R7 and R8) connects to the CC-PE routers using eBGP (R7-R5 and R6-R8). - The CC runs an IGP and iBGP with in i ts POPs. - The CC relies on IGP routing across a CSC VRF to enable the iBGP session between the CC-P routers (R3 and R4). - The CC-P routers are typ ical ly setup as route-reflectors with CSC-2. - The CSC backbone uses a VRF and MB-BGP to propagate the CC in ternal routes across i ts backbone. - LDP is enabled between the CC-P and CSC-PE routers (between R3-R1 and R2-R4). - This builds an end-to-end LSP between the CC-P routers (R3 and R4), which allows the CSC backbone to forward tra ffic based only on the BGP next-hops with in the CC

network. - The bigges t difference com pared to the native-IP, is that the CSC backbone does not need to know about the client site routes . - Note: The CSC-PE routers (in CSC 2,3,4 and 5) do not requi re a VRF loopback configured to set the LDP router-ID for the CC VRF. In production this is usually best practice.


TOC 246

CSC-3 MPLS with LDP Labels

- CSC-3 describes the method of implementing CSC when the CC is running a MPLS core. - The CSC backbone runs MPLS VPN and LDP is used to dis tribute labels between the CSC backbone and the CC POPs.

Figure 11-6: CSC-3 - MPLS with LDP Labels Model

- The CE routers (R7 and R8) connects to the CC-PE routers using eBGP (R7-R5, R6-R8). - The CC runs an IGP and iBGP with in i ts POPs. - The CC relies on IGP routing across a CSC VRF. - The CSC backbone uses a VRF and MB-BGP to propagate the CC in ternal routes across i ts backbone. - LDP is enabled within the CC network and within the CSC VRF to dis tribute labels between the CC backbone and the CSC backbone. - This allows the building of an end-to-end LDP LSP between the CC-PE routers (R5 and R6). - The CSC backbone should only be concerned with forward ing tra ffic based on these BGP next-hops within the CC network. - BGP is not required between the CC-P routers (R3 and R4) with CSC-3 and has been removed.


TOC 247

Figure 11-7: CSC-3 - MPLS with LDP - Label Flow

- CSC-3 label flow from le ft to right: > An IP packet arrives from si te-1 (R7) on the CC-PE router (R5).

>> The CC trans port label received from the adjacent LDP peer (R3) for the IP next-hop (R6) is imposed on the IP packet. > The transport label (LDP) is swapped at every router. > When the packet enters the CSC backbone, the CC transport label is swapped with a CSC VPN label before a CSC transport label is imposed.

>> The CSC VPN label identi fies the egress interface on the CSC-PE router (R2). >> The CSC transport label identifies the next-hop (R9) to reach to the egress CSC-PE router (R2).

> At the penul timate CSC-P router (R9) PHP occurs, and the CSC-LDP label is popped. > The CSC-VPN label is swapped with the CC-LDP label received from the CC-P router (R4). > At the penul timate CSC-P router (R9) PHP occurs and the CSC-LDP (top) label is popped, before forwarding an unlabeled packet to the CC-PE router (R6). > The CC-PE router (R6) receives a IP packet destined for s i te-2 (R8) and performs a IP looking to route the packet. > Refer to the Walk the LSP section below to see the end-to-end flow on CLI.


TOC 249

CSC-4 MPLS with BGP Labels (IPv4+label)

- CSC-4 describes the method of implementing CSC when the CC is running a MPLS core. - The CSC backbone runs MPLS VPN and eBGP is used to distribute labels between the CSC backbone and the CC POPs. - CSC-4 and CSC-3 is the same implementation, the only difference is method of label distribution between the CC and CSC.

Figure 11-8: CSC-4 - MPLS with BGP Labels (IPv4+label) Model

- The CE routers (R7 and R8) connects to the CC-PE routers using eBGP (R7-R5, R6-R8). - The CC runs an IGP and iBGP with in i ts POPs. - The CC relies on eBGP routing across a CSC VRF. - CSC backbone uses a VRF and MB-BGP to propagate the CC in ternal routes across i ts backbone. - LDP is enabled within the CC network. - BGP label advertising is enabled to allow the CC and the CSC backbone to distribute labels (aka IPv4+Labels ). - This s til l allows the building of an end-to-end LSP between the CC-PE routers (R5 and R6). - The CSC backbone should only be concerned with forward ing tra ffic based on these BGP next-hops with in the CC network. - IPv4+Label is configured using the "send-label " command within BGP. - When eBGP sessions come up (R3-R1 and R2-R4), BGP automatical ly generates the "mpls bgp forward ing" command on the in terface for IOS.


TOC 250

Figure 11-9: CSC-4 - MPLS with BGP - Label Flow

- CSC-4 labeled flow from le ft to right: > An IP packet arrives from si te-1 (R7) on the CC-PE router (R5).

>> The CC trans port label received from the adjacent LDP peer (R3) for the IP next-hop (R6) is imposed on the IP packet. > The transport label (whether BGP or LDP) is swapped at every router. > LDP labels are used between R5-R3, R1-R9-R2 and R4-R5. BGP labels are used between R3-R1 and R2-R4. > When the packet enters the CSC backbone, the CC transport label is swapped with a CSC VPN label before a CSC transport label is imposed.


> At the penul timate CSC-P router (R9), PHP occurs and the CSC-LDP (top) label is popped. > The CSC-VPN label is swapped with the CC-LDP labels received from the CC-P router (R4). > At the CC-P router (R4) PHP removes the CC-LDP label, before forward ing an unlabeled packet to the CC-PE router (R6). > The CC-PE router (R6) receives a IP packet destined for s i te-2 (R8) and performs a IP looking before routing the packet.


TOC 251

CONFIG-SET: CSC-4 - MPLS with BGP Labels (IPv4+label)

| Full config omitted. The eBGP configs are standard. The CSC MPLS VPN backbone uses standard config. | Only the left half of the relevant config is shown. | |R1# ip vrf CC - The CSC VRF used transport the CC routes | rd 10:20 | route-target both 10:20 | ! | interface FastEthernet0/0.13 - Interface between R3 and R1 (CC-P and CSC-PE) | encapsulation dot1Q 13 | ip vrf forwarding CC | ip address 100.10.13.1 255.255.255.0 - MPLS IP was removed | mpls bgp forwarding - Added to the interface when the BGP peering comes up | ! | no router ospf 22 vrf CC - OSPF as the CSC-CC IGP is replaced by eBGP | ! | router bgp 10 | address-family ipv4 vrf CC - Configures eBGP between R1 and R3 | neighbor 100.10.13.3 remote-as 20 | neighbor 100.10.13.3 activate | neighbor 100.10.13.3 as-override - Required since the ASN used is the same between POP1 and POP2 | neighbor 100.10.13.3 send-label - Enables sending MPLS labels with BGP routes | |R3# interface Ethernet0/0.13 - Interface between R3 and R1 | encapsulation dot1Q 13 | ip address 100.10.13.3 255.255.255.0 - "mpls ip" was removed, as BGP label distribution is now used | ! | router ospf 20 | redistribute bgp 20 subnets | ! | router bgp 20 | redistribute ospf 20 | neighbor 100.10.13.1 remote-as 10 - Configures eBGP between R3 and R1 | neighbor 100.10.13.1 send-label - Enables sending MPLS labels with BGP routes | |R5# (R5's config remains the same as the previous section) |


TOC 252

CSC-5 MPLS VPN with LDP and BGP Labels

- CSC-5 describes the method of implementing CSC when the CC is running a MPLS VPN core. - The CSC backbone runs MPLS VPN and eBGP/LDP is used to dis tribute labels between the CSC backbone and the CC POPs. - Apart from MPLS VPN used in the CC network, both label methods were included to show the full complexi ty of CSC.

Figure 11-10: CSC-5 - MPLS VPN with LDP and BGP Labels

- The CE routers (R7 and R8) connects to the CC-PE routers using eBGP (R7-R5 and R6-R8). - The CC runs an IGP and iBGP with in i ts POPs. - The CC relies on eBGP routing across a CSC VRF. - CSC backbone uses a VRF and MB-BGP to propagate the CC in ternal routes across i ts backbone. - LDP is enabled within the CC network. - In the Config-Set below BGP label dis tribution is enabled between R3-R1 and LDP label distribution between R2-R4. But any combination could be used. - This s til l allows the building of an end-to-end LSP between the CC-PE routers (R5 and R6). - The CSC backbone should only be concerned with forward ing tra ffic based on these BGP next-hops within the CC network. - When eBGP sessions come up (R3-R1), BGP automatically generates the "mpls bgp forwarding" command on the interface. - In the CSC-5 labeled packets passing via the CSC should have a label stack of 3 labels deep. - Refer to the Walk the LSP section to see the label action in further deta il .


TOC 253

Figure 11-11: CSC-5 - MPLS VPN with LDP and BGP - Label Flow

- CSC-5 labeled packet flow from le ft to right: > An IP packet arrives from si te-1 (R7) on the CC-PE router (R5) and has two labels imposed

>> The CC VPN label received from the egress CC-PE router (R6) indicating the egress interface to reach the destination (R8). >> The CC trans port label received from the adjacent LDP peer (R3) to reach the IP next-hop (R6).

> The transport label (LDP or BGP) is swapped at every router. > When the packet enters the CSC backbone, the CC transport label is swapped with a CSC VPN label before a CSC transport label is imposed.


> At the penul timate CSC-P router (R9), PHP occurs and the CSC-LDP (top) label is popped. > The CSC-VPN label is swapped with the CC-LDP labels received from the CC-P router (R4). > At the CC-P router (R4) PHP occurs and the CC-LDP label is removed. > The egress CC-PE router (R6) uses VPN label to determine the exi t in terface, before popping the VPN label and forward ing the IP packet to Si te-2 (R8). > Refer to the Walk The LSP section below to see the end-to-end flow on CLI.


TOC 255

| router bgp 20 | neighbor 10.1.5.6 remote-as 20 - Specifies the egress CC-PE router as a neighbor | neighbor 10.1.5.6 update-source Loopback0 | neighbor 10.1.5.6 next-hop-self | ! | address-family vpnv4 | neighbor 10.1.5.6 activate - Activate VPNv4 transport with the egress CC-PE router | ! | address-family ipv4 vrf CLIENT - Configures the VPN e-BGP session to site-1 | neighbor 100.20.57.7 remote-as 70 | neighbor 100.20.57.7 activate

IOS-COMMANDS

# sh ip cef [vrf name] [prefix] [detail] - Shows the FIB table entries # sh mpls forwarding-table - Shows the LFIB table entries # sh mpls interfaces [vrf name] - Shows the MPLS interfaces, enabled protocols # sh mpls ldp neighbor vrf {name} - Shows the status of LDP sessions # sh ip route [vrf] - Shows the global or a VRF RIB table # sh ip bgp labels - Shows the MPLS labels for the default BGP table # sh ip bgp vpnv4 [all|vrf|rd] labels - Shows the MPLS labels in the VRF tables # sh ip bgp summary - Shows the status of the global IPv4 BGP neighbors # sh ip bgp vpnv4 [all|vrf|rd] summary - Shows the status of the VPNv4 BGP neighbors # sh ip bgp [prefix] - Shows the global IPv4 BGP details for prefix # sh ip bgp vpnv4 {all|vrf|rd| [prefix] - Shows the VPNv4 BGP details for prefix

#mpls ldp router-id {int} [force] - Configures the LDP router-ID

#interface {int} #mpls ip - Enables LDP on the interface


#rd {route-distinguisher} - Assigns a route distinguisher to the VRF #route-target {both|import|export} {rt} - Specifies an RT actions for the VRF #import map {route-map} - Configures VRF import filtering #export map {route-map} - Configures selective VRF export

#interface {int}

#mpls bgp forwarding - Auto enabled to send MPLS labels for BGP routes between directly connected interfaces

#ip vrf forwarding {name} - This command associates an interface with a VRF - This will remove the existing IP address if configured

#router bgp {asn} #no bgp default ipv4-unicast - Disables the default exchange of IPv4 routes to all neighbors #no bgp default route-target filter - Needed to accept VPNv4 prefixes if not configured locally #neighbor {ip} remote-as {r-asn} - All BGP neighbors must be configured under global BGP config


TOC 256

#neighbor {ip} update-source loopback0 - MP-iBGP sessions should run between loopback interfaces #address-family ipv4 vrf {name} - Enters configuration of IPv4 route exchanges #neighbor {ip} activate - Enables the neighbor for IPv4 route exchange #neighbor {ip} next-hop-self - Changes the next-hop IP to the local router's sending address #neighbor {ip} send-label - Enables sending labels with BGP routes #neighbor {ip} route-reflector-client - Enables the neighbor as a route-reflector client

#address-family vpnv4 - Enters configuration of VPNv4 route exchanges for MP-iBGP sessions #neighbor {ip} activate - Enables the neighbor for VPNv4 route exchange #neighbor {ip} next-hop-self - Changes the next-hop IP to the local router's sending address

#address-family ipv4 vrf {name} - Configures/enters the MP-BGP VRF context #neighbor {ip} remote-as {asn} - Configures an eBGP neighbor in the VRF context, not in the global BGP config #neighbor {ip} activate - eBGP neighbors must to be activated

XR-COMMANDS

# sh cef [vrf name] [prefix] [detail] - Shows the FIB table entries # sh mpls forwarding - Shows the LFIB table entries # sh mpls ldp interfaces [brief] - Shows the MPLS interfaces, enabled protocols # sh mpls ldp neighbor - Shows the status of LDP sessions # sh route [vrf] - Shows the global or a VRF RIB table # sh bgp ipv4 unicast labels - Shows the BGP labels for the default IPv4 BGP table # sh bgp vpnv4 unicast [vrf|rd] labels - Shows the BGP labels in the VRF tables # sh bgp ipv4 unicast summary - Shows the status of the global IPv4 BGP neighbors # sh bgp vpnv4 unicast [vrf|rd] summary - Shows the status of the VPNv4 BGP neighbors # sh bgp ipv4 unicast [prefix] - Shows the global IPv4 BGP details for prefix # sh bgp vpnv4 unicast [vrf|rd| [prefix] - Shows the VPNv4 BGP details for prefix


#address-family ipv4 unicast - Enables the IPv4 address-family for the VRF #import route-target {rt} - Specifies what MP-BGP routes to import into a VRF instance #export route-target {rt} - Specifies an RT to be attached to routes exported from the VRF to MP-BGP #import route-policy {name} - Configures VRF import filtering #export route-policy {name} - Configures selective VRF export




#pass #end-policy

#mpls ldp - Enters the MPLS configuration mode

#router-id {int} - Specifies the MPLS router identifier #interface {int} - Activate MPLS LDP on the interface



TOC 257

#bgp router-id {ip} - Configures the RID for BGP Process #address-family ipv4 unicast - Activates the BGP IPv4 unicast configuration mode #network {ip/mask} - Originates routes into BGP #allocate-label {route-policy|all} - Enables sending labels with BGP routes, same as "send-label" in IOS.

#neighbor {ip} - Enters the BGP neighbor configuration mode #remote-as {asn} - Defines an external/internal neighbor #update-source {int} - Specifies the source interface for the TCP session that carries BGP traffic #ebgp-multihop {no} - Changes the TTL value for non-directly connected neighbors #address-family vpnv4 unicast - Enters the BGP VPNv4 unicast configuration mode #route-reflector-client - Enables the neighbor as a route-reflector client #next-hop-self - Changes the next-hop to the local router for all prefixes sent into AS

#neighbor {ip} - Enters the BGP neighbor configuration mode

#remote-as {asn} - Defines an external/internal neighbor #update-source {int} - Specifies the source interface for the TCP session that carries BGP traffic #address-family ipv4 labeled-unicast - Enables IPv4 labeled-unicast address prefixes #route-policy {name} {in|out} - On IOS-XR a permit route-policy in required

#vrf {name} - Enters the BGP VRF configuration mode

#rd {value|auto} - Assigns a route distinguisher to a VRF routes going into MP-BGP #address-family ipv4 unicast - Activates the BGP VRF for IPv4 unicast #neighbor {ip} - Configures an eBGP neighbor in the VRF context #remote-as {asn} - Specifies the CE routers ASN #address-family ipv4 unicast - Enters the PE-CE IPv4 address-family #route-policy {name} in - On IOS-XR without a policy no eBGP routes are accepted #route-policy {name} out - On IOS-XR without a policy no eBGP routes are sent


TOC 258

Walking the LSP

CSC-3 – MPLS with LDP

Figure 11-12: Walk the LSP - CSC-3 - MPLS with LDP Labels

- The end-to-end LSP using CSC-3 is bui l t using primari ly LDP label dis tribution with VPN label dis tribution in the CSC backbone. - Troubleshooting one primary label dis tribution is easy, since as mos t labels are learned using the same m ethod. - This output section below i l lustra tes simple steps in troubleshooting the end-to-end flow with CSC-3.

R5#sh ip route 190.8.8.8 - How was the destination learned? Routing entry for 190.8.8.8/32 Known via "bgp 20", distance 200, metric 0 - Learned via MP-iBGP Tag 80, type internal Last update from 10.1.5.6 00:07:07 ago Routing Descriptor Blocks: * 10.1.5.6, from 10.1.5.6, 00:07:07 ago

Route metric is 0, traffic share count is 1 - Via the IP next-hop of R6 AS Hops 1 Route tag 80

- MPLS rule, if a label exists for the destination the packet R5#sh mpls forwarding-table 10.1.5.6 will be sent labeled Local Outgoing Prefix Bytes tag Outgoing Next Hop - The LFIB table shows an out-label used to reach the tag tag or VC or Tunnel Id switched interface destination R6 19 18 10.1.5.6/32 0 Et0/0.35 100.20.35.3 - Shows the CC-LDP transport label(18) received from R3

R3#sh mpls forwarding-table | i ^18 18 24 10.1.5.6/32 9262 Et0/0.13 100.10.13.1 - The transport in-label (18)is swapped with the out-label(24)

R1#sh mpls forwarding-table det | b ^24 - The transport in-label will be swapped and another label will 24 20 10.1.5.6/32[V] 10264 AT4/0.1 point2point be imposed

MAC/Encaps=12/20, MRU=4466, Label Stack{17 20} - 20 (swapped) = VPN label from R2 - 17 (imposed) = LDP label from R9


TOC 259

R9#sh mpls forwarding-table | i ^17 17 Pop Label 10.1.5.2/32 16758 AT4/0.2 point2point - The CSC transport label(17) is popped

R2#sh mpls forwarding-table | i ^20 20 16 10.1.5.6/32[V] 13658 Fa0/0.24 100.10.24.4 - The CSC VPN label(20) is swapped with CC LDP label(16)

R4#sh mpls forwarding-table | i ^16 16 Pop tag 10.1.5.6/32 14318 Et0/0.46 100.20.46.6 - The CC LDP label(16) is popped

R6#sh ip route 190.8.8.8 - R6 receives an IP packet and performs an IP lookup Routing entry for 190.8.8.8/32 Known via "bgp 20", distance 20, metric 0 Tag 80, type external Last update from 100.20.68.8 00:26:52 ago Routing Descriptor Blocks: * 100.20.68.8, from 100.20.68.8, 00:26:52 ago - The interface facing R8

Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 80


TOC 260

CSC-5 – MPLS with LDP and BGP

Figure 11-13: Walk the LSP - CSC-5 - MPLS VPN with LDP and BGP - Label Flow

- The end-to-end LSP using CSC-5 is build using a m ix of LDP, BGP and VPN label distribution. - This makes troubleshooting a l i ttle trickier, but the ful l details are i llustra ted in the output section below. - This is about as di fficu lt as i t gets :)

R7#traceroute 190.8.8.8 source lo0 Tracing the route to 190.8.8.8 1 100.20.57.5 0 msec 20 msec 8 msec 2 100.20.35.3 [MPLS: Labels 23/22 Exp 0] 108 msec 60 msec 68 msec 3 100.10.13.1 [MPLS: Labels 24/22 Exp 0] 60 msec 60 msec 64 msec 4 100.10.19.9 [MPLS: Labels 17/27/22 Exp 0] 68 msec 64 msec 52 msec - The traceroute indicates the label stack depth 5 100.10.24.2 [MPLS: Labels 27/22 Exp 0] 80 msec 80 msec 44 msec 6 100.10.24.4 [MPLS: Labels 16/22 Exp 0] 80 msec 60 msec 68 msec 7 100.20.68.6 [MPLS: Label 22 Exp 0] 80 msec 56 msec 56 msec 8 100.20.68.8 56 msec * 52 msec

R5#sh ip route vrf CLIENT 190.8.8.8 - How was the destination learned? Routing entry for 190.8.8.8/32 - VRF learned route = VPN label is used Known via "bgp 20", distance 200, metric 0 - Learned via MP-iBGP Tag 80, type internal Last update from 10.1.5.6 00:05:19 ago Routing Descriptor Blocks: * 10.1.5.6 (Default-IP-Routing-Table), from 10.1.5.6, 00:05:19 ago - Via the BGP next-hop (R6)

Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 80

R5#sh ip bgp vpnv4 all labels | i 190.8.8.8 - Since learned via MP-iBGP R6 should be 190.8.8.8/32 10.1.5.6 nolabel/22 advertising a CC VPN label(22)

R5#sh ip route 10.1.5.6 | i Known - How was the next-hop IP (10.1.5.6) learned? Known via "ospf 20", distance 110, metric 1 - IGP learned route = LDP label is used


TOC 261

R5#sh mpls forwarding-table 10.1.5.6 - The LFIB table shows an outgoing LDP label Local Outgoing Prefix Bytes tag Outgoing Next Hop used to reach the destination R6 tag tag or VC or Tunnel Id switched interface 23 23 10.1.5.6/32 0 Et0/0.35 100.20.35.3 - (23) is CC-LDP transport label from R3

R5#sh ip cef vrf CLIENT 190.8.8.8 | i tags fast tag rewrite with Et0/0.35, 100.20.35.3, tags imposed: {23 22} - Shows the imposed label stack

(23) = CC transport label from R3 (22) = CC VPN label from R6

R3#sh ip route 10.1.5.6 | i Known - How was the destination learned? Known via "bgp 20", distance 20, metric 0 - BGP learned route = BGP label is used

R3#sh ip bgp labels | i _23 10.1.5.6/32 100.10.13.1 23/24 - The CC transport label is swapped

R3#sh mpls forwarding-table det | b ^23 - The LFIB table confirms above 23 24 10.1.5.6/32 5029 Et0/0.13 100.10.13.1

MAC/Encaps=18/22, MRU=1500, Tag Stack{24} - R3 has no knowledge of the CC VPN label(22)

R1#sh ip route vrf CC 10.1.5.6 | i Known - How was the destination learned? Known via "bgp 10", distance 200, metric 12, type internal - BGP learned route = BGP used label

R1#sh ip bgp vpnv4 vrf CC labels | i _24 - The top in-label(24) is the out-label(27) which is 10.1.5.6/32 10.1.5.2 24/27 the CSC VPN label from R2

R1#sh ip route 10.1.5.2 | i Known - How to reach R2, not directly connected? Known via "ospf 1", distance 110, metric 3, type intra area - IGP learned route = LDP used label

R1#sh mpls forwarding-table 10.1.5.2 - What is the LDP label to reach R2? Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface 17 17 10.1.5.2/32 0 AT4/0.1 point2point - 17 is the CSC transport label from R9

R1#sh mpls forwarding-table det | b ^24 - The LFIB confirms the CC transport label will be 24 27 10.1.5.6/32[V] 6139 AT4/0.1 point2point swapped with (27) and another that another

MAC/Encaps=12/20, MRU=4466, Label Stack{17 27} label the CSC VPN label (17) is imposed.

R9#sh ip route 10.1.5.2 | i Known - How to reach R2 which is directly connected? Known via "ospf 1", distance 110, metric 2, type intra area


TOC 262

R9#sh mpls forwarding-table | i ^17 - PHP removes the CSC transport label of the stack 17 Pop Label 10.1.5.2/32 24598 AT4/0.2 point2point before forwarding to R2

R2#sh ip route vrf CC 10.1.5.6 | i Known - How was the destination learned? Known via "ospf 20", distance 110, metric 12, type intra area - IGP learned route = LDP used label

R2#sh mpls forwarding-table | i 2̂7 - Packet arrives with the CSC VPN label (27) as top 27 16 10.1.5.6/32[V] 9468 Fa0/0.24 100.10.24.4 label which is swapped with the CC transport

label (16) received from R4

R4#sh ip route 10.1.5.6 | i Known - How was the destination learned? Known via "ospf 20", distance 110, metric 11, type intra area - IGP learned route = LDP used label

R4#sh mpls forwarding-table | i ^16 - PHP removes the CC transport label of the stack 16 Pop tag 10.1.5.6/32 17876 Et0/0.46 100.20.46.6 before forwarding to R6

R6#sh ip route vrf CLIENT 190.8.8.8 | i Known - R6 is the egress CC PE router for 190.8.8.8 Known via "bgp 20", distance 20, metric 0 - The CLIENT destination is known via BGP in the VRF

R6#sh ip bgp vpnv4 vrf CLIENT labels | i _22 - Packet arrives with the CC-VPN label (22) as top label 190.8.8.8/32 100.20.68.8 22/nolabel - 22 is the local VPN label the R6 assigned.

- The last label in the stack is removed, and the IP packet is destined to next-hop 100.20.68.8

R6#sh ip route vrf CLIENT 100.20.68.8 - What is the exit interface for 100.20.68.8 Routing entry for 100.20.68.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via Ethernet0/0.68 - The VRF CLIENT interface connected to R8

Route metric is 0, traffic share count is 1


TOC 263

Chapter 12

MULTICAST


TOC 264

Multicast Overview

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Multicast Configuration Guide Library, Cisco IOS Release 12.2 SR | | IP Multicast: PIM Configuration Guide

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Multicast Configuration Guide | | Implementing Multicast Routing on Cisco IOS XR Software

- The three primary methods of delivering tra ffic between nodes are: > Unicast - provides a one-to-one rela tionship. > Broadcast - provides a one-to-a ll rela tionship. > Multicast - provides a one-to-many or some-to-many rela tionship.

- The m ost commonly used (and well understood) method of data delivery is unicast. - The In ternet was bui l t using primari ly unicast and i t operates well using unicas t. - Al though well designed and purposeful , unicast does have s hortcomings in forwarding certain kinds of data tra ffic. - If the same data content were destined to a multi tude of hosts , unicast would duplicate the data for each des tination before sending i t. - With a linear increase in bandwidth requi red for each destination, del ivering one data s tream to many destinations quickly becomes inefficient. - In th is regard unicast scales poorly due to the duplication of tra ffic.

- IP Multicas t was originally defined in RFC-1112. - Multicast is a technology that can efficiently deliver data to a multi tude end nodes simultaneously without needing duplicate s treams of same data. - A single data stream is transmi tted by the source and the network (IP multicas t protocol sui te) is responsible for del ivering this to the in tended recipients. - The operation of multicast bears resemblance with analog radio and television broadcast. One s tation sends a single s tream to a m ulti tude of listeners. - Multicast forwarding is typical ly UDP based, with error checking le ft to the multicas t application of the end hos t.

Figure 12-1: Multicast Connectivity Overview

- Different protocols are used to enable m ulticas t in different parts of a network. > IGMP

>> Is the protocol used by multicas t hosts to express in terest in receiving m ulticas t tra ffic. > IGMP Snooping

>> Is used to optimize the forward ing behavior of multicas t traffic in layer2 envi ronment. > PIM

>> Is the protocol used by routers to communicate in formation about multicas t senders and receivers.


TOC 265

- Common use-cases of IP multicas t today includes : > Commercial stock exchanges applications. > Some CDNs (Content Delivery Networks) applications. > Distance E-learn ing and whi te-boarding solutions. > IPTV - Delivering TV content via IP networks . > Varie ty of video s treaming applications . > Some In ternet Radio delivery. > Conference Calling Sys tems.

- This chapter will take a look at two multicas t implementation models, commonly re ferred to as ASM and SSM. > ASM ( Any Source Multicast)

>> Refers to a multicast implementation model where a l istener expresses in teres t in a multicast group. The listener does not specify the source. >> It is up to the network to discover the source(s) that can deliver the content to the group. >> This implementation of multicas t was defined in RFC-1112. >> The general lack of understanding with multicas t can be contributed to the network complexi ty in providing the control -plane element requi red to implement an

ASM m odel . >> Majori ty of th is chapter wi ll focus on ASM im plementation.

> SSM (Source Speci fic Multicast) >> Defined in RFC-4607, SSM offers a new approach using exis ting multicas t protocols . >> With SSM, the source discovery function is the responsib ili ty of the lis tener (i .e ., i ts multicast application). >> When a l is tener wants to receive m ulticas t traffic, i t specifies the source and group address not just the group address. >> With the in formation provided by the lis tener, the las t-hop router is not requi re to partake in control -plane learn ing of the multicas t sources. >> SSM is covered in more detai l la ter in the chapter.

IOS-COMMANDS

# sh ip multicast - Shows global multicast parameters # sh ip multicast interface [int] - Shows multicast information for the interfaces

#ip multicast-routing - Enables multicast routing globally on a router

#ip multicast-routing distributed - Enables multicast routing globally on a switches like the 3560

XR-COMMANDS

# sh run multicast - Shows the multicast configuration

#multicast-routing - Enters multicast routing configuration mode

#address-family ipv4 - Enters the IPv4 address-family mode #interface all enable - Enables multicast routing on all interfaces


TOC 266

Multicast Terminology

- Multicast Source > Is a host that sends multicast tra ffic over the network to a group address.

- Multicast Listener > Is a host that is in terested in receiving m ulticast tra ffic for a specific group address. > A m ulticas t lis tener may also be called a multicast receiver or multicast group mem ber.

- Last Hop Router > Refers to a router directly attached to a multicas t lis tener or the LAN the multicast l istener(s ) resides on.

- Firs t Hop Router > Refers to a router directly attached to a multicas t source or the LAN the multicast source resides on.

- Multicast Address Range > Multicast uses the reserved address range: 224.0.0.0 - 239.255.255.255. > In classful network terminology this would be the class D range (high-order four bi ts 1110) of the IPv4 address space.

- Multicast Group Address > Is the term used to describe an ind ividual multicas t IP address. > Multicast sources send multicast packets with a destination IP address set to the group address. > Multicast lis teners use the group address to express in teres t in receiving m ulticast tra ffic sent to that group address.

- Multicast Dis tribution Tree > Describes the tree-l ike path for each group address that data packets fo llow to one/mul tip le multicas t listeners. > Downstream is always in the direction towards the l isteners . > Ups tream is always in the direction of the root of a multicas t tree, e.g. multicas t source or RP (Rendezvous Point). > There are two types of distribution trees :

>> Source Trees or SPT (Shortes t Path Tree). >> Shared Trees or RPT (Rendezvous Point Tree).

- OIL (Outgoing In terface List) > Is a l ist of the downs tream interfaces specific to a group address. > A router can have m ultip le in terface part of the OIL.

- IIF (Incoming In terface) > Is the single upstream in terface specific to a group address. > The IIF m ay also be called the RPF interface. > Multicast packet m ay only be received on the IIF in terface.

- Multicast Forwarding State > Is the in formation in the OIL and IIF for each group address. > The forwarding state is described using the fo llowing notations :

>> (S,G) - Pronounced as "ess-comma-gee". >> (* ,G) - Pronounced as "s tar-comma-gee".

> 'S' re fers to the unicast IP address of the multicas t source. Copyright © 2013 Routing-Bits.com

TOC 267

> 'G' indicates the multicast IP group address used. > '* ' indicates that any/m ul tip le sources could be sending to the group, i .e . the source is not known..

- RPF (Reverse Path Forwarding) > RPF is a multicast loop avoidance m echanism performed by every router taking part in multicas t forward ing. > A router determines the one in terface closest to the root of the dis tribution tree. > This in terface becomes the IIF, or RPF in terface for a group address. > Multicast tra ffic received on a non-RPF in terface is discarded.

- RP (Rendezvous Point) > RP keeps track of all the sources and forwards multicas t packets down to the last hop routers . > There can be only one active RP for a group. > The RP is a function of PIM-SM.

Multicast Addressing

- Each m ulticast group address is treated independently as a hos t entry with a mask of /32. - In multicast the subnet mask is used to indicate range/grouping of multicas t addresses serving a similar function.

- Multicast Address Range Formats > Range 224.0.0.0 - 239.255.255.255 > Prefix 224.0.0.0/4 > Subnet mask 224.0.0.0 240.0.0.0 > Inverse mask 224.0.0.0 15.255.255.255

- The fo llowing lis t highlights some of the multicas t address reservations as per RFC-2365. - Well -Known Reserved Ranges

> Link Local Addresses 224.0.0.0/24 >> These are non-routable addresses used only on a local l ink (TTL=1).

> Local Routed Addresses 224.0.1.0/24 >> Reserved for local network protocols.

> SSM (Source-Specific Multicas t) 232.0.0.0/8 >> Reserved for the SSM implementation model . Refer to the SSM section la ter.

> GLOP Addressing 233.0.0.0/8 >> Meant to be used by registered ASN owners for global uniqueness. >> The 2nd and 3rd octet gets mapped a unique ASN and the 4th octet adminis tra tively assigned. >> It 's not compatib le with 4-bytes ASN numbers and allows only 256 group addresses per ASN. >> Defined by RFC-3180.

> Private Multicast Addresses 239.0.0.0/8 >> Adm inis tratively scoped address range. >> Private in ternal usage to a network ONLY. >> 239.232.0.0/16 is typical used for in ternal SSM applications.


TOC 268

- Well -Known Reserved Multicast Groups > 224.0.0.1 - All m ulticast hosts > 224.0.0.2 - All m ulticast routers > 224.0.0.5 - OSPF routers > 224.0.0.6 - OSPF DR routers > 224.0.0.9 - RIPv2 routers > 224.0.0.10 - EIGRP routers > 224.0.0.13 - PIM routers > 224.0.0.22 - IGMPv3 > 224.0.0.25 - RGMP > 224.0.1.39 - Auto-RP Announce (RP) > 224.0.1.40 - Auto-RP Discovery (MA)

IGMP (Internet Group Management Protocol)

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Multicast Configuration Guide Library, Cisco IOS Release 12.2 SR | | IP Multicast: PIM Configuration Guide | | Customizing IGMP

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Multicast Configuration Guide | | Implementing Multicast Routing on Cisco IOS XR Software | | Internet Group Management Protocol and Multicast Listener

Discovery

- IGMP is an IPv4 l ink local protocol used to communicate the group memberships between hosts and routers on a LAN segment.

- IGMP is used by a host to noti fy routers attached to the LAN of i ts multicas t in terest. - IGMP is enabled automatica lly on a router in terface when PIM is enabled. - IGMP messages are encapsulated in IP datagrams , with an IP protocol number of 2 and a TTL=1.

- Multicast MAC Addressing > On a LAN s egment all Ethernet devices use a unique 48 bi t layer2 MAC address for reachabili ty. > A layer3 multicas t group address mus t somehow map to a layer2 multicas t MAC address to reach only the in tended listeners. > The IEEE assigned a specific MAC address OUI (0100.5E) for multicas t traffic on LAN segments . > The fi rs t 24 bi ts of the layer2 multicas t MAC address are s tatic, plus 1 bi t reserved, leaving the last 23 bi ts for variance. > The high-order 4 bi ts of Class D address space is always 1110 leaving 28 bi ts for layer3 multicas t address variance. > This created the requi rement to map the 28 bits in to to a 23 bi ts. > This was done by only converting the low-order 23 bi ts of a multicas t IP address to the MAC address. > The fi rs t 9 bi ts of a multicas t IP address is thus ignored leaving a oversubscription of 1 MAC address to 32 multicas t IP addresses. > The hos t application handles the oversubscrip tion problem by discarding the received m ulticas t traffic i t did not subscribe to . > The m ulticas t MAC is generated when the host application attem pts to join a multicast group.

> The m ulticas t MAC address is calculated as fol low: >> The m ulticas t MAC address OUI s tarts with 0100.5E.

>> Followed by a binary 0 for the reserved bi t. >> Followed by the last 23 bi ts of the multicast IP address converted to HEX.


TOC 269

> Example >> Multicast IP: 231.205.98.177 = 01-00-5E-4D-62-B1. >> Take the IP in to binary: 11100111.11001101.01100010.10110001. >> Convert the last 23 bi ts in HEX:

Figure 12-2: Multicast MAC Addressing

Combine the last output to get the multicas t MAC address of 01-00-5E-4D-62-B1

- IGMP Snooping > The forwarding behavior at layer2 differs from forwarding at layer3. > A fram e received with an unknown destination MAC address, is broadcasted out all s wi tch ports except the port i t was received on. > Multicast frames follow the same behavior, since a multicast MAC never belongs to jus t one swi tch port. > This inefficient forwarding of multicast tra ffic is addressed by IGMP snooping. > IGMP snooping enables the swi tch to look at the IGMP frames and learn the ports of the multicas t listeners and the i r joined groups. > This results in the efficient forward ing of IGMP frames only out the ports of the in tended listeners.

- IGMP Version 1 > Was defined in RFC-1112. > Hosts can jo in multicast groups at anytime by sending membership reports expressing the groups they are in terested in . > Every query in terva l (60 sec) routers send a general membership query to 224.0.0.1 to discover which groups s til l have active hos ts. > Hosts respond with membership reports to indicate the ir active groups. > Hosts have no m echanism with version 1 to indicate of them leaving a group. > Ins tead routers use a tim e-out based mechanism to discover when group traffic is not needed any m ore.

- IGMP Version 2 > Defined in RFC-2236. > The key enhancements over version 1 are:

>> Leave Group Message - Is a noti fication sent from hosts noti fying routers when leaving a group. >> Group Specific Query - I t is a m ore specific group membership query instead of using the all multicast hosts group. >> Querier Election Process - IGMP selects a single router to send query messages on a segment with multiple routers . >> MRT (Maximum Response Time) - Configurable field to adjus t the max query-response tim e.

> IGMPv2 Timers: >> IGMP query in terval is 60 sec. >> IGMP querier timeout is 120 sec. >> IGMP m ax query response time is 10 sec. >> Last m ember query response in terval is 1 sec.


TOC 270

- IGMP Version 3 > Defined in RFC-3376 with some update in RFC-4604. > In troduces two new source-fil tering m odes :

>> Include - Is the abil i ty for a host to express in teres t in receiving packets only from specific sources for a group. >> Exclude - Is the abil i ty for a host to express in teres t in receiving packets from all but specific sources for a group.

> The source include fi l tering option is used to implement SSM. > The IGMPv3 m embership report messages allows for the source and the group to be specified. > Includes a group-and-source-speci fic membership query:

>> Allows a router to determine i f any attached hosts are still interes ted group tra ffic from list of specified sources. >> Is sent with an IP destination address equal to the multicas t group of in teres t.

> IGMP v3 membership reports are sent with an IP des tination address of 224.0.0.22, to which all IGMPv3-capable multicas t routers listen.

- IGMP Querier > Is the elected router on a segment sending membership queries when there are m ultiple routers. > The router with the lowes t IP address on the subnet is elected the IGMP Querier.

IOS-COMMANDS

# ping {m-ip} - Emulates a server multicasting to a group # sh ip igmp groups - Shows IGMP group membership information # sh ip igmp interfaces - Shows IGMP interface information # sh ip igmp summary - Shows a summary of IGMP group information

#ip igmp limit {number} - Enables per-router limit on mroute state created by IGMP reports

#interface {int} #ip igmp version {1|2|3} - Sets the IGMP version on the interface (def = v2) #ip igmp join-group {m-ip} [source-ip] - Allows an interface to emulate a client by joining a multicast group

- Interface processes multicast traffic, i.e. it will respond to pings #ip igmp static-group {m-ip}[source-ip] - Only emulates the join, but won't process multicast traffic

- Interface will not respond pings #ip igmp limit {number} - Enables per-interface limit on mroute state created by IGMP reports #ip igmp access-group {acl} - Limit what hosts may join multicast groups #ip igmp helper-address {ip} - Forwards IGMP reports and leaves to a upstream router

#ip igmp querier-timeout {sec} - Sets the time to wait before starting IGMP querier election

#ip igmp query-interval {sec} - Sets the frequency at which IGMP query messages are sent (def = 60sec)

XR-COMMANDS

# ping {m-ip} - Emulates a server multicasting to a group # sh igmp groups - Shows IGMP group membership information # sh igmp interfaces - Shows IGMP interface information # sh ip igmp summary - Shows a summary of IGMP group information

#router igmp - Enters the IGMP configuration mode #version {1|2|3} - Sets the IGMP version on the interface (def = v2)


TOC 271

#maximum groups {number} - Sets a global limit on the IGMP groups accepted #maximum groups-per-interface {number} - Sets a global per-interface limit on the IGMP groups accepted #interface {int} - Enters the IGMP interface configuration mode #join-group {m-ip} [source-ip-] - Allows an interface to emulate a client by joining a multicast group

- Interface processes multicast traffic, i.e. it will respond to pings #static-group {m-ip} [source-ip] - Only emulates the join, but won't process multicast traffic

- Interface will not respond pings #maximum {number} - Sets a per-interface limit on the IGMP groups accepted #access-group {acl} - Limit what hosts may join multicast groups #querier-timeout {sec} - Sets the time to wait before starting IGMP querier election #query-interval {sec} - Sets the frequency at which IGMP query messages are sent (def = 60sec)

PIM (Protocol-Independent Multicast)

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Multicast Configuration Guide Library, Cisco IOS Release 12.2 SR | | IP Multicast: PIM Configuration Guide | | Configuring Basic IP Multicast

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Multicast Configuration Guide | | Implementing Multicast Routing on Cisco IOS XR Software | | Protocol Independent Multicast

- PIM is a m ulticas t routing protocol . - PIM builds dis tribution trees by exchanging m ulticas t forwarding state between multicas t routers . - PIM termed as protocol -independent, uses the routing in formation supplied by unicast routing protocols . - PIM version 1 messages are sent as an IGMP message (protocol number 2). - PIM version 2 messages use protocol number 103. - All routers on the same subnet should use the same PIM version. - PIM messages received with a version di fferent than that configured on the in terface are dropped (This could be used to fil ter tra ffic).

- PIM Hello Messages > Are sent every hello in terva l (defaul t = 30 sec) on all PIM enabled in terfaces to discover other PIM routers and form PIM neighbor relationships. > Are sent to the ALL-PIM-ROUTERS group (224.0.0.13) with a TTL = 1.

- Variants of PIM: > PIM-DM (Dense Mode PIM) > PIM-SM (Sparse Mode PIM) > PIM Sparse-Dense Mode > PIM-BIDIR (Bi-Directional PIM) > PIM-SSM (Source Specific Multicas t)

- PIM-DM > Defined in RFC-3973. > Builds implici t SPTs by flooding multicas t tra ffic domain wide and pruning the branches where no receivers are present. > When a PIM-DM router receives a m ulticas t packet, i t fi rst performs an RPF check towards the source. > If the RPF check succeeds, the router forwards a copy of the packet out of all interfaces except the fol lowing:

>> The in terface the on which the packet was received.


TOC 272

>> In terfaces where a prune message was received from downstream routers that do not want that traffic. > When a router's OIL becomes empty, due to receiving prune messages, the router prunes i tsel f from the branch by sending a prune message ups tream . > A graft message is sent upstream requesting a previously pruned OIL in terface to be placed in forwarding state again. > The root of a distribution tree with PIM-DM is the source i tsel f. > Multicast s tate with PIM-DM is noted as (S,G). > An IIF with 'Null,RPF neighbor 0.0.0.0 ' indicates that the source is stil l unknown. > An IIF with 'RPF nbr of 0.0.0.0 ' indicates that the local device is connected to the source of the group. > PIM-DM is a very s imple protocol and easy to setup, but PIM-DM poor and inefficient use of bandwidth lim i ts i ts abi li ty to scale. > The SPT example below would be relevant after the source s tarted transmi tting and all routers pruned thei r OIL in terface due to lack of in terested hos ts.

- PIM-SM > Defined in RFC-4601. > Builds explici t RPTs from last hop routers to a designated core router known as the RP (Rendezvous Point). > The RP keeps track of all the sources and forwards multicas t packets down to the last hop routers. > There can be only one active RP for a group. > All las t-hop routers need only know of the RP(s) and the groups they serve. This is called a group-to-RP mapping. > PIM-SM uses a RPT to m anage the forwarding of multicas t traffic from the RP to listeners (* ,G) and a SPT between the source and the RP (S,G). > An IIF of 'RPF neighbor 0.0.0.0 ' indicates this router is the RP. > An OIL of 'Nu ll ' indicates the RP does not know of any l isteners . > A PIM (* .G) is send with the des tination IP address of 224.0.0.13, and the IP address of the RP i f lis ted in the PIM header, not the IP header. > PIM-SM is more difficul t to implement/m aintain and might forward traffic sub-optimally ini tially, but scales well domain-wide and between domains . > For PIM-SM to operate correctly, all routers in a domain mus t agree on the active RP for each group, i .e ., the group-to-RP mapping. > Refer to the RP Assignment section below to see the di fferent ways of doing the group-to-RP m appings. > Refer to the Multicast Operations section below to how the RPT is buil t.

- PIM Sparse-Dense Mode > As the name suggests, i t is a combination of sparse and dense mode. > An in terface is enabled to operate as ei ther sparse or dense mode on a per-group basis. > A group on the in terface will operate as sparse i f a matching group-to-RP m apping is available. > A group will operate in dense mode i f the group-to-RP m apping is not available. > This PIM mode is mainly used to implement auto-RP with PIM-SM (Refer to RP-Assignment section la ter).

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IP Multicast Configuration Guide Library, Cisco IOS Release 12.4T | | IP Multicast: PIM Configuration Guide, Cisco IOS Release 12.4T | | Configuring Basic IP Multicast | | Configuring

Bidirectional PIM

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Multicast Configuration Guide | | Implementing Multicast Routing on Cisco IOS XR Software | | Bidir-PIM Configuration on Cisco IOS XR Software: Example

- PIM-BIDIR

> Dis tribution trees are normal ly unidi rectional, whereby m ulticas t data flows down the tree toward the listeners and control tra ffic flows up the tree toward the source. > PIM BI-DIR creates a two-way forwarding tree. > PIM-BIDIR uses a RPT between the multicas t source and the RP (* ,G) and a RPT to manage the forwarding of multicas t traffic from the RP to receivers (* ,G). > Since there is no SPT, a SPT swi tchover is not possible and tra ffic will always be forwarded through the RP. > The benefi t of PIM-BIDIR is that very l i ttle state is requi red, as each group requires on entry (* ,G).


TOC 273

> With PIM-BIDIR, m ulticast tra ffic may be passed up the RPT toward the RP, no RPF check is performed. > To avoid m ulticas t packets from looping, PIM-BIDIR in troduces a new mechanism called the DF (Designated Forwarder) election, which establishes a loop-free tree

rooted at the RP. > DF-Election

>> On every network segment, all PIM routers elect one router as the DF for every RP of bidirectional groups . >> The DF-elected router is responsible for forward ing multicast packets received on that network segment ups tream to the RP. >> The election of a DF is based on the best unicast route to the RP. >> This ensures that only one copy of every multicast packet will be sent to the RP.

> PIM-SM and PIM-BIDIR can coexist using the same RPs. > If PIM-BIDIR is requi red in a multicas t domain, all routers including the RP m ust be configured to support i t. > The RP m us t be configured operate in PIM-BIDIR m ode, else i f the keyword 'bid ir ' is omitted, groups specified wil l defaul t to PIM-SM. > If 'b id ir ' is configured, the RP advertises all groups as bidi rectional by defaul t. An ACL on the RP m ay be used to specify a l ist of groups to be advertised as bidi rectional .

CONFIG-SET: Using PIM-BIDIR, PIM-SM and PIM-DM together

|Example 224/8 includes bidirectional groups, 225/8 is dense mode and 226/8 is sparse mode. |Refer to the RP Assignment section for more detail on the RP selection used here. | |RP# | ip multicast-routing - Enables multicast routing | ip pim bidir-enable - Enables PIM-BIDIR globally | ! | access-list 45 permit 224.0.0.0 0.255.255.255 - Matches groups that operate in PIM-BIDIR | access-list 45 deny 225.0.0.0 0.255.255.255 - Groups with the 'deny' keyword will operate in dense mode | access-list 46 permit 226.0.0.0 0.255.255.255 - Matches groups that operate in PIM-SM | ! | ip pim send-rp-announce lo0 scope 10 group 45 bidir - Enables PIM-BIDIR group support on the RP for ACL-45 | ip pim send-rp-announce lo1 scope 10 group-list 46 - Enables PIM-SM group support on the RP for ACL-46 | ip pim send-rp-discovery lo0 scope 10 | ! | interface loopback0 - Configures loopback used for the PIM-BIDIR RP | ip address 10.5.224.1 255.255.255.255 | ip pim sparse-mode | ! | interface loopback1 - Configures loopback used for the PIM-SM RP | ip address 10.5.226.1 255.255.255.255 | ip pim sparse-mode | ! | interface fastethernet0/0 | ip address 10.5.2.5 255.255.255.0 | ip pim sparse-mode |


TOC 274

|Other routers# - Configuration the same as usual on other multicast routers | ip multicast-routing | ip pim bidir-enable | ! | interface fastethernet0/0 | ip address 10.5.2.4 255.255.255.0 | ip pim sparse-mode |

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Multicast Configuration Guide Library, Cisco IOS Release 12.2 SR | | IP Multicast: PIM Configuration Guide | | Configuring Source Specific Multicast

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Multicast Configuration Guide | | Implementing Multicast Routing on Cisco IOS XR Software | | PIM-Source Specific Multicast

- PIM-SSM > With ASM a l istener expresses in terest in receiving m ulticas t traffic for a group. > The function of discovering the source(s) for a group is the responsibili ty of the network routers. > There-in lies the complexi ty with multicast in discovering the sources and electing RPs to del iver the multicast tra ffic from sources to listeners. > SSM is an implementation model that supports one-to-many multicas t delivery exclusively through the use of SPTs. > With SSM the source discovery function is the responsibili ty of the listener's multicas t application. > I t is up to the lis tener to in form the router on i ts LAN of i ts in teres t for a group from only the specified source. > The l istener specifies a source-group tup le , which is re ferred to as a multicast SSM channel . > When a l is tener subscribes to a multicast channel, the last hop PIM-SM router joins the SPT by sending a (S,G) ups tream to i ts RPF neighbor for the source. > The SPT is buil t hop by hop as normal until i t ei ther reaches a router al ready on the SPT, or the fi rst hop router connected to the source.

> SSM Support >> SSM in implemented using PIM-SM and IGMPv3. Hosts are requi red to support IGMPv3 (i .e . the IGMPv3 include source-fi l tering). >> IGMP v3l i te and URD (URL Rendezvous Directory) are two Cisco-developed transi tion solutions that enable supporting SSM application when full IGMPv3 hos t

support is not yet available. >> The SSM m ap feature can be used to determine the source of a given group when IGMPv2 is used beyond the last hop router.

> SSM Addressing >> The m ulticas t range 232.0.0.0/8 is reserved for SSM use. >> SSM is not l imi ted to this default range, al though SSM behavior from this range is usually guaranteed. >> Each SSM channel (s ource-group tuple) provides uniqueness for every group. Traffic from two source for the same group is considered di fferent

> SSM Benefits >> Network simplici ty since no RP or source discovery function is requi red. >> The SSM channel provides addi tional source based securi ty. >> SSM arguably creates less state than RPT with SPT switchover. >> An SPT always use the mos t efficient path from the source the listeners >> In ter-domain multicas t connectivi ty without needing to support MSDP.


TOC 275

CONFIG-SET: Using PIM-SSM with a Non-Default Group Range

| ip multicast-routing - Enables multicast routing | ! | access-list 1 permit 238.0.0.0 0.0.0.255 - Specify a non-default SSM multicast range | ip pim ssm range 1 - Enable SSM with a non-default group range | | interface gi0/1 | description uplink interface | ip address 150.5.0.1 | ip pim sparse-mode - Enables PIM and IGMP on the interface

| interface gi0/2

| description LAN-connected to listeners | ip address 10.5.0.1 | ip pim sparse-mode - Enables PIM and IGMP on the interface | ip igmp version 3 - Set the IGMP version to 3 on the interface

- DR (Designated Router) > One last hop router on each LAN segment elected as the DR, is responsible for sending the jo in /reg ister messages for each group ups tream for which the LAN has active

members . > Cisco allows a DR priori ty to be configured under the interface to influence the DR election process. > If priori ty values are configured on participating routers :

1- The router with the highest priori ty becomes DR. 2- If the priori ties are equal , the router with the highes t configured IP address becomes the DR.

> If the priori ty value is not advertised in the PIM hello messages, the router with the highes t configured IP address becomes the DR. > Configured with "ip pim dr-priori ty" and have defaul t priori ty of 1.

- AF (Assert Forwarder) > PIM routers connected to the same LAN segment will elect a single AF. That device is responsible for forwarding multicast tra ffic downstream to the hosts on that LAN. > The non-elected routers on that segment wil l prune i ts LAN in terface and not send group multicast tra ffic out that in terface. > Ind icated by the 'A' outgoing flag from the command "show ip m route". > The AF is elected based on the fo llowing rules:

1- The lowest admin distance to the source. 2- The lowest IGP m etric to the source. 3- If there is a s till tie , the router with the highest IP address will be elected.

IOS-COMMANDS # mrinfo {m-ip} - Shows info about PIM neighbor connectivity # sh ip multicast - Shows global multicast parameters # sh ip multicast int [int] - Shows interface multicast parameters # sh ip multicast topology - Shows the multicast topology # sh ip pim int {int} [detail] - Shows the PIM enabled interfaces, PIM neighbors, DR information # sh ip pim int count - Shows the number of sent/received packets


TOC 276

# sh ip pim int stats - Shows the interfaces throughput statistics # sh ip pim neighbor [int] - Shows information about the PIM neighbors # sh ip rpf {ip} {group} - Shows the RPF check result information # sh ip rpf events - Shows the last 15 events that triggered RPF check events # sh ip mroute - Shows whether a multicast group supports SSM service or whether a source-

specific host report was received

#ip multicast-routing - Globally enables multicast routing

#ip pim bidir-enable - Enables PIM-BIDIR support globally #interface {int} #ip pim dense-mode - Enables PIM-DM

#interface {int} #ip pim sparse-mode - Enables PIM-SM

#interface {int} #ip pim sparse-dense-mode - Enables PIM sparse-dense mode

#ip pim ssm [default|range-acl] - Enables SSM using the default of user defined group range

#interface {int} #ip igmp version 3 - Enables IGMPv3 on this interface. IGMPv3 required for SSM (def = v2)

#interface {int}

#ip pim dr-priority {value} - Sets the DR priority on the interface to influence DR election

#ip pim rp-address {ip} [group] [override] bidir - Configures a static RP and enables PIM-BIDIR

XR-COMMANDS

# mrinfo {m-ip} - Shows info about PIM neighbor connectivity # sh run multicast - Shows the multicast configuration # sh pim neighbor [count|detail} - Shows the PIM discovered neighbors # sh pim interface [int|detail] - Shows information about the PIM interfaces # sh pim range-list - Shows the group-to-RP mappings # sh pim ipv4 group-map - Shows the group-to-PIM mappings # sh pim topology [g.g.g.g] [s.s.s.s] [detail] - Shows the PIM routing table # sh pim bsr election - Shows the PIM BSR and c-RP # sh mfib route - Shows the multicast routing table # sh mfib route rate - Shows the (S,G) rates # sh mfib route statistic - Shows the hardware and software forwarding statistics

#multicast-routing - Enters multicast configuration mode

#address-family ipv4 - Enters the IPv4 address-family configuration mode #ssm range {acl} - Defines the SSM IP range #interface {int} - Enables PIM-SM on the specified interface #interface all enable - Enables PIM-SM all the interfaces #rate-per-route - Enables (S,G) rate calculation, useful with troubleshooting #accounting per-prefix - Enables per-prefix counters in hardware


TOC 277

#router igmp - Enters the IGMP configuration mode #version 3 - Changes the IGMP version for the router to support SSM (def = v2)

#router pim - Enters the PIM configuration mode

#address-family ipv4 - Enters the IPv4 address-family configuration mode #dr-priority {value} - Sets the DR priority on the interface to influence DR election #rp-address {ip} [group] [override] [bidir] - Configures a static RP and enables PIM-BIDIR

Multicast Operation

- Multicast packets are forwarded through a network using one of two types of distribution trees : > Source Trees or SPT (Shortes t Path Tree). > Shared Trees or RPT (Rendezvous Point Tree).

- SPT (Shortest Path Tree) > With a source tree, (better known as SPT), m ulticas t traffic is delivered from the source directly to the listeners. > With a SPT the root of the dis tribution tree is the multicas t source and the listeners are located at the ends of the branches. > When using SPT, the RPF check is performed against the source of multicast tra ffic. > A source tree s tate is designated as (S,G).

Figure 12-3: Multicast - SPT Construction

- Overview of a SPT Construction 1- A new host comes online and sends an IGMP jo in for 228.0.0.1 to i ts gateway router (R4) across the LAN. 2- The las t-hop router (R4) somehow discovers (s omehow depends on the PIM protocol used) the source serving this group and does a RPF check on the IP address of

source(10.5.0.1) to determine the IIF/RPF in terface. 3- The las t-hop router (R4) sends a PIM (S,G) join message (10.5.0.1,228.0.0.1) out the RPF in terface towards the source to in form the ups tream router (R3) of i ts

interest to receive tra ffic for that group. 4- The ups tream router (R3):

>> That receives the PIM (S,G) join message, adds the in terface on which the join was received to i ts OIL for that group. >> Does an RPF check on the source to determine the RPF in terface. >> Sends a PIM (S,G) join out the RPF in terface, in forming the upstream router that i t wants to jo in the group.

5- Step 4 repeats until this new branch reaches: >> The router di rectly attached to the source, i .e ., the fi rs t-hop router (R1).


TOC 278

>> A router that al ready has the forward ing s tate for the source-group pai r. 6- Once each of the routers in the path from the listener to the source has the forwarding s tate, can multicast packets be forwarded successfully from the source to the

lis tener.

- RPT (Rendezvous Point Tree) > With shared trees (better known as RPT), a router somewhere in a core network is appointed the root of all/specific trees . > With PIM-SM th is router is called a RP (Rendezvous Point). Since Cisco supports PIM exclusively, the remainder of the chapter will re fer th is router as a RP. > Multicast tra ffic is sent from one/mul tip le sources to the RP for dis tribution to the subscribed listeners . > When using RPT, the RPF check is performed against the RP for the group. > A shared tree is designated as (* ,G).

Figure 12-4: Multicast - RPT Construction

- Overview of a RPT Cons truction (PIM-SM) 1- A new host comes online and sends an IGMP join for 228.0.0.1 to i ts gateway router (R5) across the LAN. 2- Not knowing the source, but knowing the RP mapping for the group, the last-hop router (R4) does a RPF check on the IP address of the RP (R2) to determine the

IIF/RPF in terface. 3- The las t-hop router (R4) sends a PIM (* ,G) jo in message (* ,228.0.0.1) out the RPF in terface towards the RP to inform the ups tream router (R3) that i t wants to jo in the

group. 4- The ups tream router (R3):

>> That receives the PIM (* ,G ) jo in message, adds the in terface on which the jo in was received to i ts OIL for that group. >> Does a RPF check on the RP to determine the RPF in terface. >> Sends a PIM (* ,G) jo in out the RPF in terface, in forming the ups tream router (R2) that i t wants to join the group.

5- Step 4 repeats until this new branch reaches: >> The router di rectly attached to the RP (R2). >> A router that al ready has the forward ing s tate for the source-group pai r.

6- When the RP (R2) receives the PIM (* ,G) jo in message, adds the in terface on which the join was received to i ts OIL for that group. 7- At th is stage the RPT is bui l t from the listener to the RP.

>> I f the RP is not yet receiving tra ffic from the source, i t cannot forward any tra ffic to the l istener(s). >> I f the RP previously had a source regis ter for that group, the RP would simply join SPT to that source by sending an PIM (S,G) Join towards the source.

8- Once each of the routers in the path from the listener to the source via the RP has the forwarding s tate, can multicas t packets be forwarded down the tree to the lis tener. But data tra ffic wi ll be forwarded via the RP at th is s tage. This is often results in sub-optimal forward ing.


TOC 279

Figure 12-5: Multicast - SPT Switchover

- Shortest Path Switchover > By defaul t in PIM-SM the last-hop router wil l ini tia te a swi tchover of distribution trees (RPT to SPT) to optimally forward multicast tra ffic. > The s hortest path swi tchover can be disabled or changed to ini tia te the swi tchover at a given kbps ra te using the command "ip pim spt-threshold". > The swi tchover can be seen as a double hop in a traceroute. > The swi tchover is indicated in the m route table as a 'T' when the SPT bi t is set. > Changing the tree type from a SPT to RPT could be used as a workaround with an RPF failure, especially when the use of s tatic mroutes or changing of the unicast

routing is not allowed.

- Overview of the Shortest Path Switchover 1- By default, the last-hop router (R4) wi ll in i tia te join ing the SPT directly to the source when i t receives the fi rst multicas t data packet via the RPT. This process is called

shortes t path switchover. 2- The ups tream router (R3) wi ll process the PIM (S,G) jo in as normal , with regards to RPF and forward ing i t upstream . 3- When the SPT is buil t multicas t data wil l be delivered via both distribution trees (RPT and SPT) to the lis tener. 4- The m ulticas t data tra ffic forward via the RP wil l be removed from the RPT by sending a RPT specific PIM prune message towards the RP (R2). The RP (R2) will remove

the in terface the prune was received on from i ts OIL. 5- If th is resul ts in the RP (R2) OIL for that s tate (* ,G) being empty, the RP (R2) wi ll send a PIM prune message to the ups tream router (R1) for that source.

IOS-COMMANDS

#ip pim spt-threshold {kbps|infinity} [group-list] - Alters the default behavior of the RPT to SPT switchover - [kbps] Defines the rate at which the switchover is triggered - [infinity] Disables the switchover leaving traffic on the RPT - [group-list] Indicates which groups the command applies to

XR-COMMANDS

#router pim - Enters the PIM configuration mode #address-family ipv4 - Enters the IPv4 address-family configuration mode #spt-threshold infinity [group-list] - Disables the switchover leaving traffic on the RPT

- [group-list] Indicates which groups the command applies to


TOC 280

RP Assignments

- A PIM-SM domain is defined as a group of PIM-SM router that agree on the group-to-RP m appings for the 224/4 address range. - There are 3 di fferent ways to create the group-to-RP m apping with PIM-SM:

> Static group-to-RP m apping. > Dynamically using Cisco's Auto-RP. > Dynamically using standards based BSR (Bootstrap Router).

- There are 2 ways to load-share RP function: > Multiple BSRs (Boots trap Routers). > Anycast RP using the MSDP (Mul ticast Source Discovery Protocol ).

- Static RP Assignments > Every router in the PIM-SM domain is manually configured with the address of the RP for each multicast group. > The RP i ts el f does not require any configuration to be a RP. > When a router receives a (* ,G) jo in with the RP address matching an IP address of a local interface with PIM configured, i t assumes i tsel f to be the RP. > Static RP assignments offer great simpl ici ty at the cost of admin istra tive implementation and maintenance. > Static RP assignments are by defaul t are LESS preferred than any dynamically learned RP assignments. > The 'override ' keyword can be used to make static RP assignments MORE preferred than dynamically learned RP assignments.

CONFIG-SET: PIM-SM using Static RP Assignment

| On non-RP routers configured the following to make 10.5.0.1 the RP for the matching ACL groups | | access-list 55 permit 235.0.0.0 0.255.255.255 - Specify the group ranges the 10.5.0.1 is RP for | access-list 55 permit 236.0.0.0 0.255.255.255 | ! | ip pim rp-address 10.5.0.1 55 override - Sets 10.5.0.1 to be the RP | - [override] gives the static assignments preference |

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Multicast Configuration Guide Library, Cisco IOS Release 12.2 SR | | IP Multicast: PIM Configuration Guide | | Configuring Sparse Mode with Auto-RP

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Multicast Configuration Guide | | Implementing Multicast Routing on Cisco IOS XR Software | | Auto-RP

- Auto-RP > Origina lly Cisco proprie tary protocol . > Steps used by auto-RP to determine the RP:

>> Each c-RP (candidate-RP) configured to use auto-RP announces i tsel f (every 60 seconds) as the in tended RP for a lis t of multicas t groups using the CISCO-RP- ANNOUNCE messages (224.0.1.39).

>> The MA (Mapping Agent), which m ay or m ay not be the RP router, joins the 224.0.1.39 group and builds a mapping table by listening to c-RP announce messages. >> The MA chooses which RP is the active RP for each group using the fo llowing cri teria :

>>> If m ultip le c-RPs announce the same group prefix and mask the RP announcement from the RP with the highest IP address is accepted. Copyright © 2013 Routing-Bits.com

TOC 281

>>> If one c-RP announces two overlapping group prefixes, only the less specific prefix is accepted (i .e ., 228.1.0.0/16 and 228.1.1.0/24 is announced, only 228.1.0.0/16 will be accepted).

>>> If di fferent c-RPs announce two overlapping group prefixes, both prefix are accepted, but the c-RP with the more specific announcement is chosen as the RP for that group.

>>> All other prefixes are accepted. >> Once the MA has buil t the group-to-RP m apping tab le , the mapping table is sent to the CISCO-RP-DISCOVER group (224.0.1.40) address. >> All m ulticas t routers join 224.0.1.40 to learn the group-to-RP m appings and find the correct RP to use for each multicast group. >> Auto-RP announcements are subject to a RPF check! >> Auto-RP is configured on the:

>>> C-RP with "ip pim send-rp-announce". >>> MA with "ip pim send-rp-discovery".

> PIM m us t be enabled on the loopback in terface used for discovery or advertisement. > Auto-RP has a design flaw. It was designed for sparse mode but to find the group-to-RP m appings , dense mode behavior is required. > The c-RP announce and MA discovery messages requi re dense mode behavior, which can be implemented with one of the following two workarounds :

>> Sparse-Dense m ode >>> With this workaround, dense mode is used for all groups without a known RP (this includes: 224.0.1.39 and 224.0.1.40). >>> Sparse mode is used for all other groups where the RP is known. >>> For every group where the RP is unknown, the tree will fall back to dense m ode. >>> The fall back to dense can be disabled with the command "no ip pim dm -fal lback". >>> Configured on all transi t interfaces with "sparse-dense-mode".

>> Auto-RP Lis tener >>> With this workaround ONLY 224.0.1.39 and 224.0.1.40 run in dense mode. >>> Sparse-mode is used for all other groups. >>> The in terfaces are required to be in sparse mode. >>> Configured on all routers with "ip pim autorp lis tener". >>> Typically used when there are only sparse mode transi t interfaces.


TOC 282

CONFIG-SET: PIM-SM Using Auto-RP Assignment with Auto-RP Listener instead of using Sparse-Dense interface mode

|R1 is configured as a candidate-RP, R2 as a mapping agent and R3 as just another multicast router | |R1# ip multicast-routing - Enables multicast globally | ip pim autorp listener - Enables auto-RP alone to operate in dense mode | ip pim send-rp-announce loopback0 scope 16 - Configures R1 to announce itself as the c-RP for all groups | ! | int loopback0 | ip pim sparse-mode - Enables PIM sparse mode on the loopback interface | int gi0/1 | ip pim sparse-mode - Enables PIM sparse mode on the transit interface | |R2# ip multicast-routing - Enables multicast globally | ip pim autorp listener - Enables auto-RP alone to operate in dense mode | ip pim send-rp-discovery scope 16 - Configures R2 as the MA | ! | int loopback0 | ip pim sparse-mode | int gi0/1 | ip pim sparse-mode | |R3# ip multicast-routing - Enables multicast globally | ip pim autorp listener - Enables auto-RP alone to operate in dense mode | ! | int gi0/0 | ip pim sparse-mode

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Multicast Configuration Guide Library, Cisco IOS Release 12.2 SR | | IP Multicast: PIM Configuration Guide | | Configuring Sparse Mode with a Bootstrap Router

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Multicast Configuration Guide | | Implementing Multicast Routing on Cisco IOS XR Software | | PIM Bootstrap Router

- BSR (Bootstrap Router) > Defined in RFC-5059, works similar to auto-RP. > BSR is often referred to as PIMv2. !!Watch out for this terminology!! > One router acts as the BSR, which is similar to the MA in auto-RP. > The BSR receives mapping in formation from the c-RPs and then advertises the in formation to other routers. > However there are differences between the BSR and the auto-RP MA:

>> The BSR router does not pick the best RP for each group. >> Ins tead the BSR floods all the group-to-RP m apping in formation in boots trap messages sent to the all-PIM-routers multicast address (224.0.0.13). >> Each PIM-SM router joins 224.0.0.13 and independently picks the best RP for each multicast group by running a hash algori thm on the in formation in the boots trap

messages.


TOC 283

>> The flooding of boots trap messages does not require the routers to know of an RP or to support dense mode behavior. > PIM-SM routers flood boots trap messages out of all non-RPF interfaces , downs tream /away from the BSR, which guarantees that at least one copy of the message makes

i t to every router. > With BSR, c-RPs can m ake use of a priori ty value to give preference to one RP over another. > The highest priori ty value is preferred (defaul t = 0). > When m ultip le c-RPs advertises the same group addresses, a hash calculation on each router chooses the active RP for that group as fol low:

>> The c-RP announcing the m ore specific group prefix. >> The c-RP with the lowest priori ty. >> The c-RP with highes t hash value. >> The c-RP with the highest IP address.

> BSR supports redundant RPs and redundant BSRs. > Copy subtly owned by James Gibson. > Multiple BSR routers .

>> Each candidate BSR (c-BSR) router sends boots trap messages, which include the priori ty of the BSR router and its IP address. >> The highes t-priori ty BSR wins , or i f a tie occurs, the highest BSR IP address wins. >> The winning BSR, or the preferred BSR, will continue to send bootstrap messages, while the other BSRs lis ten. >> I f the preferred BSR's bootstrap messages s top the redundant BSRs will attempt to take over.

CONFIG-SET: PIM-SM Using BSR for RP Assignment

|BSR can be used if all routers run PIMv2. R1 is configured as the C-RP and R2 as the BSR. | |R1# ip multicast-routing - Enables multicast globally | ip rp-candidate loopback0 2 - Configures R1 to announce itself to the BSR as C-RP | ! - Configures the c-RP with a priority of 2 (lower is better) | int loopback0 | ip pim sparse-mode - Enables PIM sparse mode on the loopback interface | int gi0/1 | ip pim sparse-mode - Enables PIM sparse mode on the transit interfaces | |R2# ip multicast-routing - Enables multicast globally | ip bsr-candidate loopback0 5 - Configures R2 to announce itself as the BSR | ! - Configures the BSR with a priority of 5 (higher is better) | int loopback0 | ip pim sparse-mode - Enables PIM sparse mode on the loopback interface | int gi0/1 | ip pim sparse-mode - Enables PIM sparse mode on the transit interfaces


TOC 284

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Multicast Configuration Guide Library, Cisco IOS Release 12.2 SR | | IP Multicast: PIM Configuration Guide | | Configuring Sparse Mode with Anycast RP

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Multicast Configuration Guide | | Implementing Multicast Routing on Cisco IOS XR Software | | MSDP Anycast RP Configuration on Cisco IOS XR Software

- Anycast RP > With PIM-SM, only one RP can be active for a single group, which is not ideal in production networks . > Anycast addresses this inefficiency by allowing multip le routers to be configured with the same IP address. > This anycas t address is usually configured on a loopback in terface, advertised by the IGP and used for the group-to-RP m apping. > Routers forward packets (includ ing reg ister messages and (* ,G) join messages) to the anycas t address. > These packets are delivered to the topological ly closest (lowes t IGP m etric) router with the anycast address. > If th is router becomes unavailable the packets are delivered to the next closest router with the same anycas t address. > Anycast RP creates sub-domains with in one domain to allow redundancy when a RP fails. > Anycast RP can be used in conjunction with static RP, Auto-RP or BSR.

CONFIG-SET: PIM-SM using Anycast-RP with MSDP and Static RP Assignments

|R1 and R2 are both configured with the IP address (150.150.150.1) of the RP. MSDP is used to exchange source information. |Others routers have the RP address statically assigned | |R1# ip multicast-routing | ip pim rp-address 150.150.150.1 - Statically configure the anycast RP address | ! | ip msdp peer 150.2.2.2 connect-source lo0 - Configures R2 as a MSDP peer | ip msdp originator-id loopback0 - Configures the source address for MSDP messages | ! | int loopback0 | ip address 150.1.1.1 255.255.255.255 - Configures the R1 loopback identifier | ip pim sparse-mode | int loopback1 | ip address 150.150.150.1 255.255.255.255 - Configures the anycast IP address | ip pim sparse-mode | ! | int gi0/0 | ip pim sparse-mode - Enables PIM sparse mode on the transit interfaces | |


TOC 285

|R2# ip multicast-routing | ip pim rp-address 150.150.150.1 - Statically configure the anycast RP address | ! | ip msdp peer 150.1.1.1 connect-source lo0 - Configures R1 as a MSDP peer | ip msdp originator-id loopback0 - Configures the source address for MSDP messages | ! | int loopback0 | ip address 150.2.2.2 255.255.255.255 - Configures the R2 loopback identifier | ip pim sparse-mode | int loopback1 | ip address 150.150.150.1 255.255.255.255 - Configures the anycast IP address | ip pim sparse-mode | ! | int gi0/0 | ip pim sparse-mode - Enables PIM sparse mode on the transit interfaces | | |R* ip multicast-routing >>> Configuration for every other multicast router <<< | ip pim rp-address 150.150.150.1 - Statically configure the anycast RP address | int gi0/0 | ip pim sparse-mode - Enables PIM sparse mode on the transit interfaces

IOS-COMMANDS

# mrinfo - Shows information about PIM neighbor connectivity # sh ip pim interface - Shows the interfaces with PIM configured

- Shows the mode, query interval and DR per segment # sh ip pim bsr-router - Shows information about the BSR router # sh ip pim rp - Shows the active RPs and their groups # sh ip pim rp mapping - Shows the group-to-RP mapping # sh ip pim rp metric - Shows the routing metric to RPs # sh ip pim rp-hash - Shows (with BSR) which RP is selected for a specific group

>>> Static RP Configuration <<<

#ip pim rp-address {ip}[acl] [override] - Statically configures the RP. Apply on all routers including the RP - [acl] Limits the groups a RP will advertise via PIM-JOIN messages - [override] Overrides dynamically learnt RP mappings

>>> Auto-RP Configuration <<<

#ip pim send-rp-announce {src-int} scope {ttl} [group-list {acl} interval {sec}] - Configures a c-RP for auto-RP - {src-int} The IP address to advertise as the c-RP - {ttl} The TTL of the advertisement messages - {interval} How often the candidate announcements are sent

#ip pim send-rp-discovery {src-int} scope {ttl} - Configures the auto-RP MA - {src-int} The IP address to advertise as the MA


TOC 286

- {ttl} Is the TTL of the discovery messages

#interface {int} >>> Auto-RP with Dense Behavior <<<

#ip pim sparse-dense-mode - Uses sparse mode if the RP is known else dense mode is used - Alternative to this is "ip autorp listener"

#no ip pim dm-fallback - Disables the tree to fallback to dense mode if RP is unknown

>>> Auto-RP with Auto-RP Listener <<<

#ip pim autorp listener - Uses dense mode for 224.0.1.39 and 224.0.1.40 only - Alternative to using sparse-dense mode

>>> BSR Configuration <<<

#ip pim bsr-candidate {int} [priority] - Enables the router to announce itself as a BSR - [priority] Cisco default is 0, higher value preferred

#ip pim rp-candidate {int} [group-list {acl} interval {sec}][priority] - Enables the router to advertise itself as a BSR c-RP - [priority] Cisco default is 0, lower value preferred

#interface {int} #ip pim bsr-border - Allows exchange of PIM message, but not BSR messages

XR-COMMANDS

# sh run multicast - Shows the multicast configuration # sh pim neighbor [count|detail} - Shows the PIM discovered neighbors # sh pim interface [int|detail] - Shows information about the PIM interfaces # sh pim range-list - Shows the group-to-RP mappings # sh pim ipv4 group-map - Shows the group-to-PIM mappings # sh pim topology [g.g.g.g] [s.s.s.s] [detail] - Shows the PIM routing table # sh pim bsr election - Shows the PIM BSR and c-RP

# clear pim autorp - Clears the auto-RP entries from the PIM mapping cache

# clear pim bsr - clears the BSR entries from the PIM mapping cache # clear pim topology [ipv4|ipv6] [ip] - Clears the PIM topology table and resets the neighbor sessions

#router pim >>> Static RP Configuration <<<

#address-family ipv4 - Enters the IPv4 address-family configuration mode #rp-address {ip} [acl] [override] - Statically configures the RP. Apply on all routers including the RP

- [acl] Limits the groups a RP will advertise via PIM-JOIN messages - [override] Overrides dynamically learnt RP mappings

#router pim >>> Auto-RP Configuration <<<

#address-family ipv4 - Enters the IPv4 address-family configuration mode #auto-rp candidate-rp {src-int} scope {ttl} [group-list {acl} interval {sec}]

- Configures a c-RP for auto-RP - {src-int} The IP address to advertise as the c-RP - {ttl} The TTL of the advertisement messages


TOC 287

- {interval} How often the candidate announcements are sent #auto-rp mapping-agent {src-int} scope {ttl} - Configures the auto-RP MA

- {src-int} The IP address to advertise as the MA - {ttl} Is the TTL of the discovery messages

#router pim >>> BSR Configuration <<<

#address-family ipv4 - Enters the IPv4 address-family configuration mode #bsr candidate-bsr {ip} [hash] [priority] - Enables the router to announce itself as a BSR

- [priority] Higher value preferred (default = 1)

#bsr candidate-rp {ip} [group-list] [interval] [priority]- Enables the router to advertise itself as a BSR c-RP

- [priority] Higher value preferred (default = 1) #interface {int} - Enters the PIM interface configuration mode #bsr-border - Allows exchange of PIM message, but not BSR messages

MSDP (Multicast Source Distribution Protocol)

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Multicast Configuration Guide Library, Cisco IOS Release 12.2 SR | | IP Multicast: PIM Configuration Guide | | Using MSDP to Interconnect Multiple PIM-SM Domains

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Multicast Configuration Guide | | Implementing Multicast Routing on Cisco IOS XR Software | | MSDP Configuration Sub-mode

- PIM-SM's abili ty to scale well has enabled i t to become the defacto m ulticast routing protocol . - But PIM-SM is somewhat limi ted in areas of redundancy, load-balancing and in terdomain connectivi ty. - MSDP defined in RFC-3618 was developed to address some of these shortcomings. - MSDP is used to advertise the existence of m ulticas t sources in two scenarios:

> With in a PIM-SM domain MSDP enables load balancing and redundancy through multip le RPs. > Between PIM-SM domains MSDP enables in terdomain multicas ting by exchanging source in formation between RPs.

- MSDP does not announce the presence of multicas t receivers.

- RP routers form peering relationships, s imilar to BGP, using TCP connection on the well -known port 639. - The states of the MSDP peering re la tionships :

> Disabled - MSDP peer is not configured. > Inactive - MSDP peer is configured but not lis tening. > Connect - MSDP peer actively attempts ini tia ting a TCP session. > Listen - MSDP peer is lis tening on TCP port 639. > Established - TCP session is established and the neighbors are ready to exchange SA (Source-Active) messages.

- When a MSDP enabled RP receives a PIM Register message, MSDP generate a SA message for the source-group pai r. - The SA message contains :

> The source address. > The group address the source is sending to .


TOC 288

> The originator-ID, which is a unique IP address of the RP that created the SA. - This SA message is forwarded to all configured MSDP neighbors (re ferred to as peer-RPF flooding). - When a MSDP router receives a SA message:

> I t veri fies that the packet was received from a MSDP RPF-peer. > If not, the SA messages are discarded. > If the RPF-peer is valid , the SA message is flooded to all i ts configured MSDP neighbors.

- If the receiving MSDP router happens to be an RP too, the router determines if i ts local PIM-SM domain has any in teres t in the groups included in the SA message. > If the domain has in terest in the group:

>> The content of the SA message is forwarded down the RPT for the group. >> A PIM (S,G) join is sent towards i ts RPF neighbor for the source to jo in the SPT.

- With in terdomain MSDP each domain only speaks to i ts local RP to learn about available sources. RPs use MSDP to exchange source in formation. - The addresses of all MSDP peers mus t be known in BGP or MP-BGP.

- Caching MSDP SA State > By defaul t, a MSDP router does not cache source-group pairs from received SA messages. > I t is discarded after forwarded to MSDP peers. > Caching the MSDP SA s tate wi ll prevent jo in la tency, i f a member joins a group shortly after the SA message was deleted. > Configured with "ip msdp cache-sa-state".

- MSDP Mesh Groups > The concept is s imilar to the IS-IS mesh group feature. > Mesh groups are used to reduce the SA peer-RPF flooding. > Mesh groups requi re that all m ember MSDP speakers have fu l ly meshed MSDP connectivi ty between one another. > Any SA messages received from a peer in a mesh group are not forwarded to other peers in the same mesh group.

- MSDP Fil tering > SA messages can be fi ltered based on the source address, group address, or the MSDP peer address. > SA messages in any production network should be fil tered to only allow what is necessary. > The fo llowing SA messages should never be leaked out of an AS.

>> SSM group address (232.0.0.0/8). >> Adm inis tratively scoped addresses (239.0.0.0/24). >> RFC-3330 address space (10.0.0.0/8, 172.16.0.0/12, … etc.). >> Protocol specific group addresses (224.0.1.39, 224.0.1.40, … etc.).

- MSDP was created prior to SSM implementation model being standard ized. MSDP is not needed in SSM deployments .

IOS-COMMANDS

# sh ip msdp summary - Shows MSDP peer status and SA message counts # sh ip msdp count [asn] - Shows the number of sources and groups originated in MSDP SAs # sh ip msdp peer [ip] - Shows detailed information about MSDP peers # sh ip msdp sa-cache [group|source] [asn] - Shows (S,G) state learned from MSDP peers # clear ip msdp peer [ip] - Clears the TCP session for a MSDP peer # clear ip msdp statistics [ip] - Clears the counters for a MSDP peer # clear ip msdp sa-cache [ip] - Clears the SA cache entries


TOC 289

# debug ip msdp peer - Shows MSDP activity for the peer-address # debug ip msdp routes - Shows more detailed debugging information # debug ip msdp detail - Shows the contents of source-active messages # debug ip msdp resets - Shows MSDP peer reset reasons

#ip msdp peer {peer-ip} connect {int} - Configures MSDP peer within the same AS

#ip msdp peer {peer-ip} connect {int} remote-as {asn} - Configures MSDP peer in different AS

#ip msdp cache-sa-state [list] - Caches the MSDP SAs for all or some groups

#ip msdp originator-id {int} - Changes the originator-ID #ip msdp redistribute [list] [asn] [route-map] - Filters the sources that originates SA messages #ip msdp sa-filter out [ip] [list] [route-map] - Filters the SA messages sent based on a peer/ACL/tag value #ip msdp sa-filter in [ip] [list] [route-map] - Filters the SA messages received based on a peer/ACL/tag value #ip msdp mesh-group {name} [ip] - Enables an MSDP peer in a mesh group

XR-COMMANDS

# sh msdp summary - Shows MSDP peer status and SA message counts # sh msdp peer [ip] - Shows detailed information about MSDP peers # sh msdp rpf {rpf-ip} - Shows the RPF rules for SA messages # sh msdp sa-cache [group|source] [asn] - Shows (S,G) state learned from MSDP peers # clear msdp peer [ip] - Clears the TCP session for a MSDP peer # clear msdp sa-cache [ip] - Clears the SA cache entries

#router msdp - Enters the MSDP configuration mode

#connect-source {int} - Sets the source address used for MSDP sessions #originator-id {int} - Sets the address used as the RP address in SA messages #peer {ip} - Specifies the MSDP peer #remote-as{asn} - Sets the ASN of the peer #mesh-group {name} - Configures a peer a member of a mesh-group #sa-filter {in|out} {list} - Configures incoming/outgoing SA filters #password {pwd} - Enables authentication for the peer

#ttl-threshold {ttl} - Limits the multicast packets send in SA messages

RPF (Reverse Path Forwarding)

- RPF is the fundamenta l multicast mechanism used in the: > Control-Plane to determine RPF in terface/neighbor to send PIM jo in /prune to . > Data-Plane to check the incoming in terface of multicast tra ffic and ensuring loop-free forwarding.

- RPF fa ilure is the single mos t disruptive feature for CCIE candidates. - A RPF check veri fies that the incoming interface for multicas t traffic is the outgoing in terface for traffic back towards the source or the RP. - PIM being protocol independent relies on unicast routing protocols for provid ing the in formation used for RPF checks. - If RPF checks were performed against the unicast routing table only, m ulticast source routing would be res tricted to the unicast topology. - Using a dedicated multicast routing table allows for incongruent multicas t and unicast topologies. - The multicas t routing table is not visible on mos t Cisco IOS routers . On some newer IOS/ versions , i t is visible with the command "show ip route multicas t".


TOC 290

- On Cisco IOS-XR the multicas t table is seen with the command "show m fib". - I t is im portant to unders tand that "show ip m route" shows the PIM jo in state and not a multicas t routing table. - On Cisco routers however the RPF s tate and table orig in for a specific prefix can be viewed with the command "show ip rp f". - A m ulticas t routing table does not contain any multicas t (class D 224.0.0.0/4) routes .

- There are three tables that contribute in formation for RPF checks: > Unicast routing table (RIB). > Static Mroutes (Mul ticast Routes) tab le . > MP-BGP (Mul tiprotocol BGP) multicas t tab le .

- Static Mroutes (Multicas t Routes) > Are s tatic routes used to calculate m ulticas t RPF in formation. > Are not used to forward tra ffic. > Are m anually applied and requi res manual maintenance. > Have a defaul t admin distance of 0.

- MP-BGP (Mul tiprotocol BGP) > MP-BGP or Multiprotocol extensions for BGP defined in RFC-2858, extends the in formation carried in the NLRI (Network Layer Reachabili ty In form ation) field in the BGP

update message. > This enables MP-BGP to carry prefix in formation (like multicas t) separately from IPv4 prefixes . > The MP-BGP multicast prefix in formation is used to calculate m ulticas t RPF in formation. It is not used to forward tra ffic. > Multicast MP-BGP prefixes have a defaul t admin distance of 20 for eBGP prefixes and 200 for iBGP prefixes .

- The RPF Route-Selection Process > Is di fferent from the unicast route-selection process. > By defaul t:

>> The prefix with the lowest admin distance is selected fi rs t. >> A longer match prefix will be selected only when there are m ultiple prefixes from the same lowest admin distance protocol .

> This behavior can be changed in newer codes with "ip multicast longest-match" by preferring longer match prefixes firs t.

- The output of the "show ip rp f" command: > The "RPF type" field shows the routing table from which the route was selected. > The possible values of in teres t for the "RPF type" field are:

>> Unicast. >> Static Mroute. >> MP-BGP.

- To veri fy RPF fa ilure examine the output from these commands : >"show ip m route count" - The 'RPF failed ' counter indicates RFP failures. >"debug ip mpacket" - A message of 'not RPF in terface' usually points to a RPF failure.

- A message of 'm forward ' means multicast tra ffic is being forwarded.

!!NOTE!! The command "no ip mroute-cache" under the interfaces is required to debug transi t multicast tra ffic.

IOS-COMMANDS

# sh ip rpf {ip} - Shows the RPF table # sh ip mroute - Shows the PIM state table


TOC 291

# sh ip mroute summary - Shows a summary of the PIM routes # sh ip mroute active - Shows the active multicast traffic # sh ip mroute count - Shows multicast routing statistics

- "RPF failed" counter will point out RFP failures - "Other Drops" could indicate a lack of client requests

# sh ip route multicast - Shows the MRIB on newer platforms and IOS versions

# debug ip pim - Shows the PIM events and transactions

# debug ip mpacket - Shows the packet information of process switched transit traffic - Requires "no ip mroute-cache" on transit interfaces

#ip multicast longest-match - Changes the RPF selection preference to longest prefix length first

#ip mroute {source ip} {mask} {next-hop} - Alters the RPF result, allowing a different interface to the IIF - {NH} Unicast next-hop could be IP or interface. For NBMA must be an IP

address #ip mroute 0.0.0.0 0.0.0.0 {next-hop} - Prevents the unicast and MP-BGP tables from being used for RPF

XR-COMMANDS

# sh pim rpf {ip} - Shows the RPF table # sh pim topology - Shows the PIM state table # sh pim topology summary - Shows a summary of the PIM routes # sh pim range-list - Shows the group-to-RP mapping

#router static - Enters the static route configuration mode

#address-family ipv4 multicast - Enters the multicast address-family #{source ip} {mask} {next-hop} - Alters the RPF result, allowing a different interface to the IIF #0.0.0.0/0 {next-hop} - Prevents the unicast and MP-BGP tables from being used for RPF

Multicast VPN

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.2 Family > Cisco IOS Software Releases 12.2 SR | | Configuration Guides | | IP Multicast Configuration Guide Library, Cisco IOS Release 12.2 SR | | IP Multicast: MVPN Configuration Guide | | Configuring Multicast VPN

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | Multicast Configuration Guide | | Implementing Multicast Routing on Cisco IOS XR Software | | Configuring Multicast VPN

- With the success of MPLS and MPLS VPNs, the requirement to support customer multicas t in a VRF was inevi tab le. - Building GRE tunnels between CE routers , was /can be used to do this , but involves complicated designs with poor scalabili ty. - MVPN provides the abi li ty to join cus tomer multicast sites in isolation over a service provider backbone. - Cisco firs t defined in tra-AS multicas t VPNs in RFC-6037.

- With standard MPLS unicast VPNs:


TOC 292

> CE (Cus tomer Edge) routers at different sites do not maintain adjacencies with each other. > Ins tead the CE router exchanges routing in formation with the attached MPLS PE (Provider Edge) router. > Unicast VPN CE-to-CE tra ffic is delivered using an overlay of LDP or TE tunnels between PE routers . > The MPLS P (provider) routers mainta in only global routing in formation about the PE routers and no per-VPN routing in formation.

- Multicast VPN is delivered over MPLS with the same operational behavior as unicast VPN. - MVPN tra ffic however is delivered using an overlay of dynamic point-to-mul tipoint GRE tunnels between the PE routers . - The GRE tunnels are buil t using native multicas t dis tribution trees between the PE routers. - These GRE tunnels connect cus tomer multicas t sites while re ta ining the cus tomer isolation. - Customer m ulticas t traffic is forwarded by means of multicas t-in-mul ticast packets using GRE encapsulation through an MPLS core. - An MDT is used to carry GRE encapsulated customer multicas t traffic between PE routers participating in the same multicas t domain. - The destination address of the GRE packets are the MDT (Mul ticast Distribution Tree) group address assigned to each individual cus tomer. - The source address of the GRE packets is the VPNv4 MP-BGP peering address of the originating (ingress) PE router. - The MDT s tate entry in the global multicas t table is illustra ted as a (S,G) entry. - The P routers are only aware of this (S,G) s tate entries , i .e ., the PE reachabi li ty in formation and the MDT groups . - As a resul t the P routers have no, nor need visibil ity of the cus tomer multicas t state. - IPv4 MDT (an addi tion to the BGP address-families) advertises the multicas t MDT s tate in formation for each MVPN between PE routers.

- A MVRF (Mul ticast VRF) is a logical container on a PE router that contains the multicast routing in formation for a cus tomer MVPN. - A set of MVRFs on PE routers that send multicas t tra ffic to each other cons ti tu tes a MVPN. - The multicas t routing used in the MPLS core can be PIM-SM, PIM-BIDIR, or PIM-SSM. - The MVPN isolation allows a cus tomer to run any implementation of multicas t with in his own multicas t domain.

- Types of MDTs: > Defaul t MDT

>> Is a unique native multicast tree per-MVPN in the MPLS core between PE routers . >> Is prim arily used to carry multicast control tra ffic between all PE routers in a multicas t domain. >> Can also carry low bandwidth cus tomer multicast tra ffic between all PE routers in a multicas t domain. >> Every MVRF instance on a PE router is connected to a default MDT and therefore will receive all the traffic from that defaul t MDT. >> A unique default MDT is requi red for every cus tomer MVPN.

> Data MDTs >> Are special purpose native multicast trees buil t to carry high bandwidth cus tomer multicast tra ffic between only the PE routers with in terested listeners. >> Are created dynamically i f a tra ffic s tream for a particular customer group exceeds the bandwidth threshold of the i r defaul t MDT. >> Helps avoids unnecessary flooding of customer multicas t tra ffic to all PE routers in a multicast domain. >> When a tra ffic threshold is exceeded, the PE router attached to the source signals the other PE routers to swi tch the (S,G) group to a data MDT group. >> The signaling is done using a special PIM data MDT join sent via the defaul t MDT to 224.0.0.13 with UDP port 3232. >> A PE router that receives the data MDT mapping (S,G,data -mdt) with in teres ted listeners will join the data MDT. >> The source PE router will wai t 3 seconds before s wi tching to the new data MDT group. >> PE router that do not have in teres ted MVRF listeners for the data MDT wi ll cache the (S,G,data-mdt) mapping to avoid jo in latency for subsequent new listeners. >> Data MDTs are only triggered by customer (S,G) entries in the MVRF. (* ,G) entries are exem pt from the tr iggering the swi tchover. >> Data MDTs are not created for MVPN dense mode multicas t s tream . >> Data MDTs are encapsulated in the same manner as the defaul t MDT. The only difference is the destination group address is from the MDT pool . >> Data MDTs are dynamically assigned from an assigned pool . Data MDTs may be reused for di fferent multicas t s treams.

- MTI (Mul ticas t Tunnel In terface) > Is a tunnel in terface created per-MVRF that represents the access to the MDT. > Think of the MDT as a pseudo LAN connecting all the PE routers and the MTI the in terface to that pseudo LAN. > Each MTI is created dynamical ly upon the configuration of the defaul t MDT.


TOC 293

> The defaul t MDT and data MDTs forward tra ffic out the same MTI. > The MTI is the PIM in terface used to bui ld adjacencies to remote PE routers. > The MTI forms part of the RPF check for multicast tra ffic received from the MDT.

- MVPN PIM Neighborships > The fo llowing pictures portrays the end-to-end neighborships used to s tructure a MVPN:

Figure 12-6: Multicast - MVPN Overview

>> CE routers form PIM neighborships with the MVRF-specific PIM instances on the PE routers . >> PE routers form PIM neighborships in the global PIM instance with the P routers . >> MDTs are bui l t between the PE routers for every MVPN. >> PE routers form MVRF-specific PIM neighborships with rem ote PE routes through the MTI over the MDT. >> All customer multicas t groups are mapped to the MDT addresses associated with the i r MVPN.

- MVPN RPF Checks > MVPN creates a nested m ulticas t archi tecture. Naturally the MVPN RPF checks vary s lightly to normal RPF checks. > The RPF check used depends on the in terface where the packet was received:

>> For native multicas t tra ffic in the core the RPF check confi rms the tra ffic was received on the global in terface that leads back to the originating PE router. >> For cus tomer CE traffic arriving on the PE router, the RPF check confirms whether the unicast path back to the cus tomer source is indeed via the PE-CE in terface. >> For cus tomer tra ffic arriving from the MTI in terface, RPF check confirms the source address of the packet was learned via MP-BGP and is that of the orig inating PE

router.


TOC 294

Figure 12-7: Multicast - MVPN Data Flow Example

- MVPN Data Flow Example

> Multicast source 10.1.1.1 attached to CE1 is sending a packet to 228.0.0.1. An interested lis tener is connected to CE3. > The m ulticas t packet arriving on PE1 is classified to a MVPN based on the in terface i t was received on. > A RPF check confi rms the RPF interface is the PE-CE in terface and packet is forwarded out the MTI, which should be part of the OIL for the MVRF. > The cus tomer multicas t packet is encapsulated using GRE before i t is forwarded to P1.

>> The source of the GRE packet is the VPNv4 MP-BGP peering address (150.1.1.1) of PE1. >> The des tination of the GRE packet is the MDT group address (232.0.0.8) assigned to the MVPN of CE1 and CE3.

> The packet is forwarded to P1 as a normal multicas t packet. > P1 performs a global table RPF check on the source address of the outer packet header, i .e ., PE1 peering address (150.1.1.1). > If i t passes P1 forwards the packet out every in terface in the OIL. This would reach every PE router configured with the MDT 232.0.0.8, in th is case PE3. > When PE3 receives the packet from the MDT, i t performs a RPF check on the source (PE1) and removes the GRE encapsulation. > PE3 derive the MVPN membership and the des tination in terface from the MDT group address of the encapsulated GRE header. > The origina l cus tomer multicas t packet is forward to CE3 as a native multicast packet.

- Using PIM-SSM in the MPLS Core > In rea l production networks i t is unlike ly that PIM-SM (wi th BSR or Auto-RP) wil l be used. > PIM-SSM offers greater simplici ty and i t requires no RP, which is typically a single point of fai lure. > For SSM to work across a MPLS network, each PE router uses MP-BGP to advertise the newly created MDT group and the root of the tree. > From every PE router's perspective i t sees itself as the root of the tree for the packets i t sends and the remote PE routers as the l isteners . > With PIM-SSM th is means the source (originating PE router) of a tree is jo ined immediately and a (S,G) state established. > If the routing used in a multicast core is PIM-SSM, then the defaul t and data MDT groups m us t be assigned from the SSM defaul t/configured range.

- If PIM-SM auto-RP is requi red in a MVPN, the PE-CE per-VRF in terface should be configured as sparse-dense mode - The "ip mroute-cache" command mus t be enabled on the loopback in terface used as the BGP peering interface. By defaul t i t is enabled. - Most of the IP multicas t feature are available to MVPN through the addi tion of the 'vrf' keyword in CLI commands.

- The basic prerequisi tes before im plementing MVPN are: > A working MPLS core with end-to-end reachabi li ty between PE routers. > Standard MPLS VPNs on the MPLS PE devices.

- Steps to enable MVPN support in a MPLS core 1- Enable multicast routing globally on all P and PE routers . 2- Enable PIM on:

>> All transi t in terface.


TOC 295

>> The loopback in terface used for the MP-BGP router-id (required to build the MDT). 3- Configure a RP i f PIM-SSM is not used. 4- Veri fy the expected PIM neighbors are present on each l ink before continuing.

>> For the CCIE lab, might be a good idea to tes t multicas t in the core at this point. >> Enable one PE as the multicas t lis tener with "ip igmp join" command. >> Confirm the routers between the lis tener PE and RP shows the test s tate entry. >> Enable another PE router as the source by using the "ping (group)" command.

5- MDT tunnels >> On each PE router enable BGP IPv4 MDT for all other PE routers (i t is normally the VPNv4 neighbors ).

- Steps to enable customer MVRF support 1- Enable multicast for the customer VRF. 2- Enable PIM under the client VRF in terface. 3- Configure the RP assignment per VRF as needed. 4- Confi rm the CE-PE VRF aware PIM neighbor relationship comes up. 5- Specify the MDT defaul t address per-VRF, and optionally the MDT-Data address per-VRF.

- Steps to configure m ulticas t on the CE routers 1- Enable multicast routing globally. 2- Configure PIM in terface according to the PIM mode used. 3- Configure the RP assignment (sta tic, auto-RP, BSR, etc.)

Figure 12-8: Multicast - MVPN Example

CONFIG-SET: Multicast - MVPN Example using SSM in the Core

|This shows only the relevant config portions once. PE1, PE4 are PE routers each with a multicast CE client router. |Client multicast also uses PIM-SSM. | |#On all P and PE routers | ip multicast-routing - Enables multicast routing globally | ip pim ssm default - Enables PIM-SSM using the default range 232.0.0.0/8 | ! | int xx/x - On all transit interface | ip pim sparse-mode - Enables sparse mode | int loopback0 | ip pim sparse-mode - Enables PIM on the loopback interface | ! |


TOC 296

|PE1#router bgp 100 | neighbor 150.0.0.14 remote-as 100 - Specifies PE4 as a neighbor | neighbor 150.0.0.14 update-source lo0 | address-family vpnv4 | neighbor 150.0.0.14 activate - Enables PE4 as a VPNv4 MP-BGP neighbor | neighbor 150.0.0.14 send-community both | address-family ipv4 mdt | neighbor 150.0.0.14 activate - Enables PE4 as a VPNv4 MP-BGP neighbor | neighbor 150.0.0.14 send-community both | ! | |PE1#ip multicast-routing vrf VRF-1 - Enables multicast for the VRF | ip vrf VRF-1 | rd 100:1 | route-target both 100:1 | mdt default 232.0.0.1 - Specifies the client MDT default address | mdt data 232.0.1.0 0.0.0.255 threshold 200 - Specifies the data MDT switchover threshold at 200kbps | ! | interface gi0/0.1 | ip vrf forwarding VRF-1 | ip pim sparse-mode - Enables PIM on the PE-CE interface | ! | ip pim vrf VRF-1 ssm range 1 - Enables PIM-SSM within the client MVRF | access-list 1 permit 235.0.0.1

IOS-COMMANDS

# sh ip rpf vrf {vrf} {ip} {group} - Shows the per-VRF RPF check result information # sh ip pim vrf {vrf} rp - Shows the per-VRF active RPs and their groups # sh ip pim vrf {vrf} rp mapping - Shows the per-VRF group-to-RP mapping # sh ip pim vrf {vrf} rp metric - Shows the per-VRF routing metric to RPs # sh ip pim vrf {vrf} neighbor - Shows the per-VRF PIM neighbors # sh ip pim vrf {vrf} int {int} - Shows per-VRF PIM enabled interfaces # sh ip pim vrf {vrf} bsr-router - Shows per-VRF information about the BSR router # sh ip pim vrf {vrf} mdt bgp - Shows the RD advertisement for the MDT # sh ip pim vrf {vrf} mdt history - Shows how often a MDT was reused

#ip multicast-routing >>> ENABLE NATIVE MULTICAST IN THE MPLS CORE <<<

#ip pim ssm {default|range} - Enables PIM-SSM using the default or user defined range #interface {int} #ip pim {sparse-mode|sparse-dense-mode] - Configures the PIM interface mode

#interface loopback{no} #ip pim sparse-mode - Enable PIM on the loopback used to source PIM traffic

#router bgp {asn}


TOC 297

#neighbor x.x.x.x remote-as {asn} - Specifies the remote PE router or route-reflector #neighbor x.x.x.x update-source loopback{x} - Specifies the source interface address #address-family ipv4 mdt - Enters the BGP IPv4 MDT address-family #neighbor x.x.x.x activate - Activate remote PE routers as MDT peers #neighbor x.x.x.x send-community [both] - Enables community exchange with the neighbor

#ip multicast vrf {VRF} >>> ENABLE PER-VRF MULTICAST <<<

#ip pim vrf {VRF} ssm {default|range} - Enables per-VRF PIM-SSM using the default or user defined range #interface {int} #vrf forwarding {VRF} - Assigns the interface to a VRF #ip pim sparse-mode - Enables PIM on the PE-CE link

#ip pim vrf {VRF} rp-address - Statically configures per-MVRF client RP #ip pim vrf {VRF} send-rp-announce int {int} - Define per-VRF RP using auto-RP #ip pim vrf {VRF} send-rp-discovery int {int} - Define per-VRF MA using auto-RP

#vrf definition {VRF}

#rd {rd} #address-family ipv4 #mdt default {m.m.m.m} - Configures the default MDT group for the MVRF #mdt data {m.m.m.m y.y.y.y} [threshold|limit] - Configures the data MDT range for the MVRF

XR-COMMANDS

# sh run multicast - Shows the multicast configuration # sh pim neighbor [count|detail} - Shows the PIM discovered neighbors # sh pim interface [int|detail] - Shows information about the PIM interfaces # sh pim range-list - Shows the group-to-RP mappings # sh pim topology [g.g.g.g] [s.s.s.s] [detail] - Shows the PIM routing table # sh pim bgp-safi - Shows the PIM MDT/MVRF entries # sh pim bsr election - Shows the PIM BSR and c-RP # sh mfib route - Shows the multicast routing table # sh mfib route rate - Shows the (S,G) rates # sh mfib route statistic - Shows the hardware and software forwarding statistics # sh bgp ipv4 mdt summary - Shows the IPv4 MDT neighbors and their state/prefixes # sh bgp ipv4 mdt [rd|vrf] - Shows MDT neighbor loopback IPs for all/specific MVPNs # sh bgp ipv4 mdt {rd|vrf} [prefix] - Shows the MDT neighbor attributes and MDT group address

# sh pim vrf {VRF} neighbor - Shows per-VRF PIM discovered neighbors

# sh pim vrf {VRF} interface [int|detail] - Shows information about the per-VRF PIM interfaces

>>> ENABLE NATIVE MULTICAST IN THE MPLS CORE <<<

#multicast-routing - Enters multicast configuration mode #address-family ipv4 #interface {int} - Enters the interface multicast configuration #enable|disable - Enables/Disables multicast and PIM on the interface


TOC 298

#interface all enable - Enables multicast and PIM on all interfaces #mdt source loopback {no} - Specifies the source address of the MDT


#address-family ipv4 mdt - Enables the IPv4 MDT BGP SAFI for the BGP process #neighbor {ip} - Enters the BGP neighbor configuration mode #remote-as {asn} - Specifies the neighbors ASN #update-source loopback {no} - Specifies the source interface #address-family ipv4 mdt - Enables the BGP neighbor for IPv4 MDT exchange

>>> ENABLE PER-VRF MULTICAST <<<

#multicast-routing - Enters multicast configuration mode #vrf {VRF} address-family IPv4 - Enters the MVRF instance #interface all enable - Enables PIM all the PE-CE VRF interfaces #mdt default {m.m.m.m} - Configures the default MDT group for the MVPN #mdt data {m.m.m.m /{mask}} [threshold] - Configures the data MDT range for the MVPN #rate-per-route - Enables (S,G) rate calculation, useful with troubleshooting #accounting per-prefix - Enables per-prefix counters in hardware


TOC 299

Walking the Tree - MVPN

Walking the multicast tree from CE1 to CE4 > Simple MVPN setup. Two CE routers are connected to MPLS. > CE4 was configured as the RP for Cus tomer-1. > PE4 and CE4 are IOS-XR boxes, so the output varies slightly.

Figure 12-9: Multicast - Walk the MVPN Tree

CE1(config)#interface fa0/0 - CE send a IGMP join for the group 229.1.1.1 CE1(config-if)#ip igmp join 229.1.1.1

PE1#sh ip igmp vrf VRF-1 groups 229.1.1.1 IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 229.1.1.1 FastEthernet1/0 00:00:45 00:02:50 10.11.21.21 - First verify that the IGMP report was received on PE1

PE1#sh ip mroute vrf VRF-1 229.1.1.1 | b \( - Next look for the per-VRF (*,G) entry to the RP (CE4) (*, 229.1.1.1), 00:01:59/00:02:39, RP 10.0.0.24, flags: SJC - The RP learned is CE4 via the Tu0 interface (MTI) Incoming interface: Tunnel0, RPF nbr 150.0.0.14 - The RPF neighbor (150.0.0.14) is the remote PE router Outgoing interface list: attached to Tu0

FastEthernet1/0, Forward/Sparse, 00:01:59/00:02:39 - The OIL should be the interface the IGMP report was received

PE1#sh ip bgp ipv4 mdt vrf VRF-1 150.0.0.14 | i for|group - Find the MDT address associated with the RPF neighbor BGP routing table entry for 100:1:150.0.0.14/32 version 2 for VRF-1

MDT group address: 232.0.0.1 - Default MDT = 232.0.0.1 (VRF-1)

PE1#sh ip mroute 232.0.0.1 150.0.0.14 | b \( - The (remote-PE,MDT) is now known, which is the (S,G) (150.0.0.14, 232.0.0.1), 01:07:49/stopped, flags: sTIZ used in the global multicast table for forwarding Incoming interface: FastEthernet0/0, RPF nbr 150.1.11.11 - The IIF shows next-hop interface/neighbor to PE4 Outgoing interface list: - The next-hop router is P1

MVRF VRF-1, Forward/Sparse, 01:07:49/00:01:10 - The OIL shows the MVRF from the global perspective

P1#sh ip mroute 232.0.0.1 150.0.0.14 | b \( (150.0.0.14, 232.0.0.1), 01:16:48/00:02:34, flags: sT Incoming interface: FastEthernet0/0, RPF nbr 150.1.2.2 Outgoing interface list:

FastEthernet0/1, Forward/Sparse, 01:16:48/00:02:34 - The next-hop router is P2 Copyright © 2013 Routing-Bits.com

TOC 300

P2#sh ip mroute 232.0.0.1 150.0.0.14 | b \( (150.0.0.14, 232.0.0.1), 01:19:12/00:03:05, flags: sT Incoming interface: FastEthernet0/0, RPF nbr 150.2.14.2 Outgoing interface list:

FastEthernet0/1, Forward/Sparse, 01:19:12/00:03:05 - The next-hop router is PE4

RP/0/0/CPU0:PE4#sh pim topology 232.0.0.1 | b 150.0 - The global table confirms PE4 is the remote PE (150.0.0.14,232.0.0.1)SPT SSM Up: 01:28:38 - Any further checks would be VRF-1 specific JP: Join(never) RPF: Loopback0,150.0.0.14* Flags: GigabitEthernet0/1/0/0 01:26:43 fwd Join(00:03:19) - Interface facing P2 where the PIM join was received Loopback0 01:28:38 fwd LI LH - PE4 source interface is lo0 (150.0.0.14)

RP/0/0/CPU0:PE4#sh pim vrf VRF-1 topology 229.1.1.1 | be 229 - Shows the PIM join received from CE1 via the MDT (*,229.1.1.1) SM Up: 00:23:16 RP: 10.0.0.24 JP: Join(00:00:33) RPF: POS0/6/0/0,10.14.24.24 Flags: - The IIF shows the interface to the RP mdtVPN/1 00:23:16 fwd Join(00:02:54) - The OIL shows MDT for the VRF-1

RP/0/0/CPU0:PE4#sh pim vrf VRF-1 neighbor | b Nei - Shows the per-VRF PIM sessions Neighbor Address Interface Uptime Expires DR pri Flags 150.0.0.11 mdtVPN/1 01:34:48 00:01:25 1 P - Shows the session over the MDT to PE1 10.14.24.24 POS0/6/0/0 01:37:43 00:01:22 1 (DR) B - Shows the CE4 session

RP/0/3/CPU0:CE4#sh pim topology 229.1.1.1 | b 229 - The CE shows the native client multicast state (*,229.1.1.1) SM Up: 00:38:10 RP: 10.0.0.24* - CE4 (10.0.0.24) is the RP JP: Join(never) RPF: Decapstunnel0,10.0.0.24 Flags: - Shows RPF neighbor as itself POS0/7/0/0 00:38:10 fwd Join(00:03:18) - The OIL lists the interface facing MPLS

RP/0/3/CPU0:CE4#ping 229.1.1.1 count 3 - Send traffic to the listener (CE1) shows that Sending 3, 100-byte ICMP Echos to 229.1.1.1, timeout is 2 seconds: distribution tree was setup successfully. Reply to request 0 from 10.11.21.21, 5 ms Reply to request 1 from 10.11.21.21, 3 ms Reply to request 2 from 10.11.21.21, 4 ms

RP/0/3/CPU0:CE4#sh pim topology 229.1.1.1 | b 229 Tue Mar 12 17:38:49.979 UTC 5036906871 (*,229.1.1.1) SM Up: 00:40:42 RP: 10.0.0.24* JP: Join(never) RPF: Decapstunnel0,10.0.0.24 Flags: POS0/7/0/0 00:40:42 fwd Join(00:02:47)

(10.0.0.24,229.1.1.1)SPT SM Up: 00:01:16 JP: Join(never) RPF: Loopback0,10.0.0.24* Flags: KAT(00:02:14) RA RR (00:04:13) - PIM table confirms the (S,G) state from CE4 to CE1-group POS0/7/0/0 00:01:16 fwd Join(00:03:17)


TOC 301

Troubleshooting Multicast

- Some of the input in terface flags from the command "show ip mroute" are important for troubleshooting: >D - Used for PIM-DM groups. > S (uppercase) - Used for PIM-SM groups . > s (lowercase) - Used for PIM-SSM groups >B - Used for PIM-BIDIR groups. >C - A l is tener or group member is present on a connected in terface. With MVPN 'C' indicates the MVRF is locally connected. >L - The local router is a group m ember. >P - Indicates a route was pruned. State is kept for some time to avoid jo in la tency. >R - Indicates the RPT bi t is set, which means the tra ffic from a source is to be pruned from the shared tree. >T - Indicates the SPT bi t is set, which means tra ffic was received on the SPT appose to the RPT. >I - Indicates a SSM hos t report. >M - Used for MSDP entries . >A - Indicates the route is a MSDP candidate to be advertised. >Z - Identi fies the MDT tunnel endpoints when MVPN packets are encapsulated/decapsulated. > y (lowercase) - Indicates the MDT s wi tchover since tra ffic is sent on a data MDT group with MVPN. > Y (uppercase) - Indicates the MDT s wi tchover since tra ffic is received on a data MDT group with MVPN.

- To troubleshoot end-to-end multicast, there are three separate portions to troubleshoot with PIM-SM: 1-(* ,G) From the listeners to RP, (* ,G) s tate. Does not apply to troubleshooting PIM-SSM. 2-(S,G) From the source (regis ter) to RP (S,G) s tate. Does not apply to troubleshooting PIM-SSM. 3-(S,G) From the source to listeners to the RP after RPT swi tchover (S,G).

- For general troubleshooting, consider the fol lowing: > Have you tr ied emulating an IGMP jo in on a client's router interface? # sh ip igmp groups > Have you tr ied emulating the multicast tra ffic from the source? # ping {m-ip} > Do all the transi t routers have m ulticas t-routing enabled? # sh ip multicast | i Routing > Are you sending and receiving m ulticas t tra ffic on an interface? # sh ip pim in t {int} s tats > Does the router connected to the source list the join membership reports? # sh ip igmp group {int} > Is the same IGMP version used throughout? # sh ip igmp in terface > Do all the transi t interfaces have the correct PIM-mode enabled? # sh ip pim in t > Are the expected PIM neighbors showing? # sh ip pim neighbor

>> I f not, are any s tub fi lters configured (look at 'PIM neighbor fil ter')? # sh ip pim in t {int} detai l > Are the expected m route entries showing? # sh ip m route {m-ip} > Are there any issues with the multicast fast-swi tching cache entries? # sh ip mcache {m-ip} > Is the expected m ulticast path taken from a source to a group? # m trace {s rc-ip} {m-ip}

>> I f you want more in formation about the path, use th is command # ms tat {s rc-ip} {m-ip} > Are any in terface TTLs exceeded on transi t routers (look at 'bad hop count')? # sh ip tra ffic > Is there a limi t on the number of allowed multicas t routes? # sh ip multicast | i l imi t > Are there any input packet drops for multicast flows? # sh in t {int} | i flushes

>> I f so, increase the SPT value to in fini ty. #ip pim spt-threshold in fin i ty


TOC 302

- When troubleshooting sparse mode, consider the fo llowing: > Was a s tatic RP configured correctly on all routers? # sh ip pim rp mapping > Should a s tatic RP be preferred over a dynamical ly learned RP? # sh run | i rp-add.*override > Is the dynamically-chosen RP the expected RP? # sh ip pim rp mapping > If auto-RP is us ed:

>> Was sparse-dense mode enabled on the interfaces? # sh ip pim in t >> Or was auto-RP l is tener configured? # sh run | i line |l istener

> Confi rm RP reachabili ty to all the multicas t routers. # ping {rp-ip} > Does the RP know about the source tra ffic (S,G)? # sh ip m route > Does the RP and transi t routers list the clients /des tinations (* ,G)? # sh ip m route > Does the elected DR know the RP's IP-address? # sh ip pim rp mapping

>> Confirm the elected DR is correctly placed and forward ing the PIM reg ister tra ffic to the RP.

- When troubleshooting RPF failures, consider the following: # sh ip rp f > Has the 'RPF failed' counter increased on any router? # sh ip m route count > Are the expected incoming in terface and outgoing interfaces listed? # sh ip m route > Is the incoming multicast in terface the next-hop back to the unicast source? # sh ip route {s rc-ip} > Confi rm the unicast source in terface was enabled for multicas t. # sh ip pim in t {int} > For m ultiple paths, was RPF check enabled across equal-cos t paths? # sh ip multicast | i Multi > As a last resort use a debug to find the cause. # debug ip m packet {m-ip}

>> Remember in order to see transi t traffic, disable multicast route-cache! #no ip mroute-cache

- Consider the following solutions to RFP fa ilures : > Change the unicast routing to match the expected incoming interfaces. > Use a s tatic multicas t route to receiving m ulticast tra ffic on a specific in terface. > In some scenarios influencing the tree type could be used as a workaround.

- Is there a NON-broadcast or unicast only network between the source and a group? > If so, configure PIM over a GRE tunnel . > The tunnel source and des tination should NOT be routed via the tunnel .

- Logging Error: > %PIM-6-INVALID_RP_JOIN : Received (* ,224.1.1.1) > Could be caused by

>> Wrongly configured static RP mappings # sh run | i rp >> Client is fi l tering the accepted RPs # sh run | i pim.*accept


TOC 303

Bibliography


RFC-1112 Host Extensions for IP Multicasting http ://www.ie tf.org/rfc/rfc1112.txt

RFC-2236 In ternet Group Management Protocol, Version 2 http ://www.ie tf.org/rfc/rfc2236.txt

RFC-3376 In ternet Group Management Protocol, Version 3 http ://www.ie tf.org/rfc/rfc3376.txt

RFC-2365 Adm inis tra tively Scoped IP Multicast http ://www.ie tf.org/rfc/rfc2365.txt

RFC-3180 GLOP Addressing in 233/8 http ://www.ie tf.org/rfc/rfc3180.txt

RFC-4604 IGMPv3 and MLDv2 for Source-Specific Multicast http ://www.ie tf.org/rfc/rfc4604.txt

RFC-4607 Source-Speci fic Multicas t for IP http ://www.ie tf.org/rfc/rfc4607.txt

RFC-3973 Protocol Independent Multicast - Dense Mode (PIM-DM) http ://www.ie tf.org/rfc/rfc3973.txt

RFC-4601 Protocol Independent Multicast - Sparse Mode (PIM-SM) http ://www.ie tf.org/rfc/rfc4601.txt

RFC-5059 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) http ://www.ie tf.org/rfc/rfc5059.txt

RFC-6226 PIM Group-to-Rendezvous-Point Mapping http ://www.ie tf.org/rfc/rfc6226.txt

RFC-3618 Multicas t Source Discovery Protocol (MSDP) http ://www.ie tf.org/rfc/rfc3618.txt

RFC-6037 Cisco Sys tems' Solution for Multicas t in BGP/MPLS IP VPNs http ://www.ie tf.org/rfc/rfc6037.txt


TOC 304



TOC 305

Chapter 13

IPv6


TOC 306

Overview

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IPv6 Configuration Guide, Release 12.4T | | Implementing IPv6 Addressing and Basic Connectivity | | Configuration Examples for Implementing IPv6 Addressing and Basic Connectivity

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR 12000, Release 4.1 | | IP Addresses and Services Configuration Guide | | Implementing Network Stack IPv4 and IPv6 | | IPv6 for Cisco IOS XR Software

- Advantages of IPv6 over IPv4 > Much la rger address space since an IPv6 address consists of 128 bi ts compared to the 32 bi ts in IPv4 address. > Address scopes are new to IPv6. > State less address auto-configuration. > Multicast is part of the base specifications in IPv6, unlike IPv4. > No m ore broadcasts . > No IPv6 header checksum. > Simpli fied header: IPv4 header (12 fields) vs . IPv6 header (8 fields). > New flow label field in header. > Fixed packet header sizes, 40-bytes IPv6 com pared to 20-bytes + for IPv4. > Fragmentation mandatory on clients with PMTU. > Mobile IPv6 allows a mobile node to change i ts locations and addresses seamlessly. > Network-layer securi ty through native IPSEC.

- PMTU (Path Maxim um Transmission Uni t) Discovery > Enabled by defaul t with IPv6. > With IPv6 fragmentation is mandatory on clients through PMTU. > Fragmentation is handled by the source of a packet when the path MTU of one link along a given data path is not large enough to accommodate the size of the packets .

Addressing

- The IPv6 addressing archi tecture is defined in RFC-3513.

- IPv4: x. x. x. x > Each octet(x) denotes 1 byte.

- IPv6: xxxx: xxxx: xxxx: xxxx : xxxx: xxxx: xxxx: xxxx > Each hex character(x) denotes 1 tup le(4 bi ts ). > Two tup les (2 hex characters) denotes 1 byte (8 bi ts). > 1s t 8 bytes = network address portion. > 2nd 8 bytes = hos ts addresses portion.

- Well -Known IPv6 addresses > ::A.B.C.D - IPv4-compatible IPv6 address. > : :1 - Loopback (127.0.0.1). > :: - Unspecified address (0 .0.0.0) used for ini tial automatic address assignment. > ::/0 - Defaul t route.


TOC 307

- Global Unicast Addresses > 2000 - 3FFF - Format prefix. > Structure consists of

>> 48-b i t Global Prefix assigned to regional reg istries. >> 16-b i t Subnet ID or SLA (Si te -Level Aggregator). >> 64-b i t Host ID.

- Link-Local Addresses > FE80::/10 - Format prefix. > Nodes on a local link can use link-loca l addresses to communicate. They do not need globally unique addresses to communicate. > IPv6 routers should not forward packets that have l ink-local source or destination addresses to other l inks .

- Site-Local Addresses > FEC0::/10 - Format prefix. > RFC 3879 deprecated use of site-local addresses and replaced them with unique local address.

- Unique Local Addresses > FC00::/7 - Format prefix. > Is an IPv6 unicast address that is globally unique BUT is in tended for local site communications replacing Si te-Local Addresses. > Are not expected to be routable on the global in ternet but should be routable within a si te /domain. > Structure consists of

>> 41-b i t Global identi fier used to create a globally unique prefix. >> 16-b i t Subnet identi fier of a subnet with in a si te .

- EUI-64 > Are IPv6 hos t addresses generated from in terface MAC addresses. > A MAC address is 48-b i ts and IPv6 hos t address is 64-b i ts. > The extra 16-bi ts are derived as fo llows:

>> MAC address 1234.5678.9012 >> In vert the 7th mos t significant bi t (in binary) = 00010010 > 00010000 (thus 12 becomes 10).

= 1034.5678.9012 >> Ins ert FFFE in the middle.

= 1034.56FF.FE78.9012

- Multicast IPv6 Addresses > FF00::/8 - Format prefix. > FF3x::/96 - SSM address range. > All m ulticast addresses begin with the form at prefix 1111 1111, wri tten as FF in hex. > The format prefix, FF, is followed by two fields : flags and scope. These two fields are 4-b i ts each. > The remaining 112 bi ts are used as the group ID. > Refer to the IPv6 Multicast section for more detail .

- Anycast Addresses > One single address assigned to a set of interfaces on di fferent nodes. > Using the routing table , a packet sent to an anycast address wi ll be delivered to the closest device with that address. > There is no specially allocated range for anycast, as anycas t addresses are allocated from the unicast address space. > Assigning a unicast address to more than one interface m akes a unicast address an anycas t address. > Anycast addresses mus t not be used as the source address of an IPv6 packet.


TOC 308

> Configured with the 'anycas t' keyword.

- IPv4-Compatible IPv6 Address > Is an IPv6 unicast address with all zeros in the high-order 96 bi ts and an IPv4 address in the low-order 32 bi ts of the address. > ::A.B.C.D - IPv4-Compatible IPv6 address.

- IPv4 to IPv6 Conversion > Needed with IPv6 6-to-4 tunnels. > Let's take 192.168.99.1

1- Divide each octet by 16 (since HEX is base-16) I.e ., 192/16 = 12 times exactly with 0 le ft over. And 12 in HEX is represented as C Thus 192 in HEX is C0.

2- Second octet 168/16 = 10 tim es with 8 le ft over. And 10 in HEX is A Thus 168 in HEX is A8.

3- Third Octet 99/16 = 6 times with 3 le ft over. Thus 99 in HEX is 63.

4- Fourth Octet 1/16 = 0 tim es with 1 le ft over. Thus 1 in HEX is 01.

> So IPv4 (192.168.99.1) = IPv6 portion to be used(C0A8.6301) which makes a ful l 6-to-4 address 2002:c0a8:6301:1::1 /64.

- IPv6 to IPv4 Conversion > Let's take the IPv6 address portion of C0A8.6301:

1- Break the address in to 2 tuple groupings (2 hex characters ) = C0 A8 63 01. 2- Take C0 and multip ly the firs t character 'C' by 16 and the second character '0 ' by 1. 3- Add the two decimal values together to get the IPv4 decimal equivalent of C0 as 192 ((c=12)*16) + (0*1) . 4- Same with A8, (( A=10)*16) + (8*1) = 168. 5- Same with 63, (6*16) + (3*1) = 99. 6- Same with 01, (0*16) + (1*1) = 1. 7- This will give a IPv4 address of 192.168.99.1.

- With IPv6, multiple IPv6 addresses can be configured per in terface. There are no primary and secondary address as in IPv4. - When pinging a link-local IP, the outgoing in terface mus t be specified, since the same address could be used on multiple interfaces.

IOS-COMMANDS

# sh ipv6 int {int} - Shows detailed information about the IPv6 interfaces # sh ipv6 int brief - Shows summarized information about the IPv6 interfaces # sh ipv6 neighbor - Shows the IPv6 link-layer information # sh ipv6 route - Shows the IPv6 RIB


TOC 309

# sh ipv6 traffic - Shows statistics about IPv6 traffic

# debug ipv6 packets - Shows detailed messages for IPv6 packets

# debug ipv6 nd - Shows messages for IPv6 ICMP neighbor discovery

# ping ipv6 {ip} [exit-int] - [exit-int] Must be specified if pinging a link-local address

# telnet {ip} /ipv6 /source-interface {int} - Telnetting to a link-local host requires the source to be specified

#ipv6 unicast-routing - Enables IPv6 routing

#ipv6 cef - Enables CEF for IPv6 (default = disabled) #interface {int} #mac-add 1034.5678.9012 -(o) Used the specified MAC appose to the BIA (Built In Address) #ipv6 enable -(o) Enable link-local EUI-64 address (auto generates link-local IP) #ipv6 add FE80::1 link-local -(o) Or manually create a link-local address

#interface {int}

#ipv6 add 2001::/64 eui-64 - Manually configures the global unicast address and enables EUI-64 #ipv6 add 2001:155:1:146::1/64 - Manually configures a full IPv6 address

#interface {int}

#ipv6 add 2001:0DB8:c058:6301::/128 anycast - Configures the anycast address

#interface {int}

#ipv6 add autoconfig - Address is then based on stateless auto-config

XR-COMMANDS

# sh ipv6 int {int} - Shows detailed information about the IPv6 interfaces # sh ipv6 int brief - Shows summarized information about the IPv6 interfaces # sh ipv6 neighbor - Shows the IPv6 link-layer information # sh ipv6 route - Shows the IPv6 RIB # sh ipv6 traffic - Shows statistics about IPv6 traffic

# ping {ip} [exit-interface] - [exit-int] Must be specified if pinging a link-local address

# telnet {ip} source-interface {int} - Telnetting to a link-local host requires the source to be specified

#interface {int}

#ipv6 enable - Enables IPv6 processing on the interface #ipv6 address {ip}/{mask}[eui-64] {route-tag] - Manually configures the global unicast address #ipv6 address {ip} link-local - Manually configures a link-local address

ICMPv6

- The IPv6 neighbor and router discovery ful fills the equivalent functionali ty as IPv4 ARP. - The neighbor discovery process uses ICMPv6 messages for transport. - The router discovery functional i ty enables IPv6 routers to send router-advertisements so that IPv6 hosts can automatically discover the routers on that local l ink.


TOC 310

- Neighbor discovery in IPv6 is a way for IPv6 hosts to discover the presence of other IPv6 hosts on the same link and then to keep track of them .

- NS (Neighbor Solici ta tion) - Asks for in formation about neighbors. - NA (Neighbor Advertisement) - Advertises presence to other neighbors . - RS (Router Solici ta tion) - Asks for in formation about the local routers . - RA (Router-Advertisement) - Advertises an active router.

- The sending of RA messages is automatically enabled on Ethernet and FDDI interfaces when the IPv6 unicas t-routing is enabled. - For other in terface types, the sending of RA messages mus t be manual ly configured by using "no ipv6 nd suppress-ra".

- IPv6 ICMP Rate Limi ting > A feature that implements a token bucket algori thm for l imi ting the ra te at which IPv6 ICMP error messages are sent out onto the network.

IOS-COMMANDS

#ipv6 neighbor {ip}{int} {mac} - Configures a static MAC entry in the IPv6 neighbor discovery cache #ipv6 icmp error-interval {ms} {bucketsize} - Limits IPv6 ICMP error messages interval and bucket size #interface {int} #no ipv6 nd ra suppress - Disables the sending of RA messages on non Ethernet interfaces (Old version) #no ipv6 nd suppress-ra - Newer version of above command

XR-COMMANDS

#ipv6 neighbor {ip}{int} {mac} - Configures a static MAC entry in the IPv6 neighbor discovery cache #ipv6 icmp error-interval {ms} {bucketsize} - Limits IPv6 ICMP error messages interval and bucket size #interface {int} #no ipv6 nd suppress-ra - Disables the sending of RA messages on non Ethernet interfaces

IPv6 on Catalyst 3560

DOC-CD REFERENCE | Switches > LAN Switches – Access > Cisco Catalyst 3750-E Series Switches > Configuration Guides | | Catalyst 3750-E and 3560-E Switch Software Configuration Guide, Release 12.2(58)SE | | Configuring IGMP Snooping and MVR | | Configuring SDM Templates

- Configuration steps

> Confi rm the configured SDM (Swi tch Database Manager) template, with "show sdm prefer". > Change the SDM template to support IPv4 and IPv6 with the command "sdm prefer dual -ipv4-and-ipv6". > Then reload the swi tch.

IOS-COMMANDS

# sh sdm prefer - Will display the current SDM profile and statistics

#sdm prefer dual-ipv4-and-ipv6 {default|routing|vlan} - Changes SDM template to support IPv6


TOC 311

IPv6 over Frame-Relay

- NBMA (Non Broadcast Multi-Access) networks : > Requires s tatic resolution on m ultipo int interfaces . > This is required for global unicast addresses and link-local addresses otherwise recursion will break. > Inverse neighbor discovery (s imilar to InARP) is not yet implemented.

IOS-COMMANDS

# sh frame-relay map - Shows the DLCI mappings, status, dynamic/static, LMI types # sh frame-relay pvc [dlci] - Shows the DLCI status, messages, packets TX/RX

#ipv6 unicast-routing - Enables IPv6

#interface {int} #ipv6 add {ip}/{mask} #frame map ipv6 {ip} {dlci} broadcast - Configures static layer3-to-layer2 mapping for the global unicast address #frame map ipv6 {FE80::}{dlci} - Configures static layer3-to-layer2 mapping for the link-local address

#interface {int} #ipv6 address {ip} link-local - Manually create a link-local address

#interface {int.sub} point-to-point #ipv6 address {ip}/{mask} EUI-64 - Creates a global unicast address with EUI-64 #frame-relay interface-dlci {dlci} - Maps the DCLI to the interface

XR-COMMANDS

#interface {interface} #encapsulation frame-relay ietf - Sets the interface encapsulation to frame-relay #ipv6 enable - Enabled IPv6 on the interface #ipv6 address {ip} link-local - Manually create a link-local address #ipv6 address {ip}/{mask} [EUI-64] - Creates a global unicast address with EUI-64 #pvc {dlci} - Assigns a DLCI to the sub-interface #encap ietf - Changes the encapsulation for the DLCI

IPv6 Static Routing

- IPv6 s tatic routing has the same implications as IPv4 s tatic routing: > If routed to a next-hop IP address, the next-hop is resolved recursively to an exi t interface. > Multipo int interfaces resolve the final des tinations . > Point-to-point links requi re no next-hop resolution.

- Static to next-hop > With ICMP ND (Neighbor Discovery) there is no proxy abili ty to learn the remote neighbor (such as in InARP discovery).


TOC 312

> When a s tatic route is directed out an in terface, i t should be pointed to the next-hop instead of the in terface.

!!NOTE!! Dynamic in formation recurses to the remote link-local address, not to the global unicas t address!

IOS-COMMANDS

# sh ipv6 static [detail] - Shows information about the IPv6 static routes

#ipv6 route {ip}/{mask} {exit-int} {next-hop} [ad] - Configures a static IPv6 route

XR-COMMANDS

# sh route ipv6 static - Shows the static IPv6 routes in the RIB

#router static - Enters the static router configuration mode

#address-family ipv6 unicast - Enters the IPv6 address-family #{ip}/{mask} {exit-int} {next-hop} [ad] - Configures a static IPv6 route

RIPnG

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IPv6 Configuration Guide, Cisco IOS Release 12.4T | | Implementing RIP for IPv6

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR Software, Release 3.9 | | Routing Configuration Guide | | Implementing RIP on Cisco IOS XR Software

- Defined in RFC-2080. - Differences from RIPv2

> Tags are jus t locally signi ficant arb i trary numbers /words . > Uses UDP port 521. > Multicasts are sent to FF02::9 .

- Similar to RIPv1/RIPv2 > Spl it-horizon is enabled by defaul t, which needs to be disabled on multipo int NBMA l inks. > RIP timers . > Defaul t routing. > Summarization. > Offs et-lis t. > Dis tribute-lis t.

IOS-COMMANDS

# sh ipv6 protocols - Shows if RIP is enabled and on which interfaces # sh ipv6 rip - Shows RIP protocol statistics and counters


TOC 313

# sh ipv6 rip next-hops - Shows information about the next-hop addresses # sh ipv6 route rip - Shows only the IPv6 RIP routes in the table # clear ipv6 route * - This refreshes the routing table from the routing database

- This works differently to IPv4 # clear ipv6 rip {process} - Refreshes the routing database # debug ipv6 rip - Shows the sent and received RIPv6 updates

#ipv6 router rip {tag} - Enables RIPnG the {tag} is locally significant

#interface {int} #ipv6 rip {tag} enable - Interface level command that auto enables the global RIP process

- The tag number/name is locally significant #no ip split-horizon - Needs to be disabled on multipoint NBMA links #ipv6 rip {tag} summary-address {prefix} - Configures address summarization

XR-COMMANDS

# sh run router rip - Shows the RIP configuration # sh protocols rip - Shows RIP protocol information # sh rip - Shows information about the RIP process # sh rip database - Shows RIP database entries # sh route ipv6 rip - Shows the RIB routes in the RIB # clear rip [all] - Refreshes the routing database

#router rip - Enters the RIP configuration mode

#validate-update-source disable - Disables the validating of incoming routing updates #interface {int} - Enabled RIP processing on the interface #split-horizon disable - Disables split-horizon

EIGRP – IPv6

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IPv6 Configuration Guide, Cisco IOS Release 12.4T | | Implementing EIGRP for IPv6

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR Software, Release 3.9 | | Routing Configuration Guide | | Implementing EIGRP on Cisco IOS XR Software

- Uses protocol number 88.

- Uses multicast address FF02::A. - A ping to the multicast address could be used to veri fy IPv6 neighbors . - To configure EIGRP for IPv6, you mus t enable IPv6 on the interface and enable the EIGRP routing process. - EIGRP for IPv6 has a s hutdown feature. The routing process should be "no s hut" to start. - The router-id used for the IPv6 EIGRP process is stil l a 32-bi t field . - EIGRP for IPv6 transmi ts hello packets with the link-local address of the transmi tting in terface as the source address.


TOC 314

IOS-COMMANDS

# sh ipv6 eigrp {asn} neighbors - Shows the neighbors discovered, holdtime, uptime, SRTT, RTO # sh ipv6 eigrp {asn} topology - Shows entries in the EIGRP topology table # sh ipv6 route eigrp - Shows the current EIGRP routes in the IPv6 routing table

#ipv6 router eigrp {asn} - Enters EIGRP configuration mode

#router-id {32-bit value} - Configures a router-id #no shutdown - Starts the EIGRP routing process

#interface {int}

#ipv6 address {ip} - Specifies an IPv6 address #ipv6 enable - Generates an IPv6 address #ipv6 eigrp {asn} - Enables EIGRP on the interface

#ipv6 bandwidth-percent eigrp {asn} {%} - Configures the bandwidth percent EIGRP may use on a interface (def = 75)

#ipv6 summary eigrp 1 2001:0DB8:0:1::/64 - Examples of an aggregate address sent from a interface

#no ipv6 next-hop-self eigrp {asn} - Instructs EIGRP to use the received next-hop value instead of default

#no ipv6 split-horizon eigrp {asn} - Disables EIGRP IPv6 split horizon on the interface

XR-COMMANDS

# sh protocols eigrp - Shows EIGRP protocol information # sh eigrp ipv6 neighbors - Shows the neighbors discovered, holdtime, uptime, SRTT, RTO, etc # sh eigrp ipv6 topology - Shows entries in the EIGRP topology table # sh route ipv6 eigrp - Shows the current EIGRP IPv6 routes in the RIB

#router eigrp {asn} - Enters the EIGRP process configuration mode

#address-family ipv6 #router-id {ip} - Configures the EIGRP RID #no auto-summary - Disables auto-summarization at classful boundary #log-neighbor-changes - Enable EIGRP neighbor logging #log-neighbor-warnings - Enable EIGRP neighbor warnings #default-metric {b d l r m} - Configures the default metric for redistributed routes #route-policy {route-policy} {in|out} - Applies a route-policy #interface {int} - Advertises the interface via EIGRP

#passive-interface - Disables sending and receiving hello messages #hello-interval {sec} - Configures the EIGRP hello interval #hold-time {sec} - Configures the EIGRP holdtime interval #summary-address {ip} [mask] [ad] - Sends an aggregate address for the interface #next-hop-self disable - Instructs EIGRP to use the received next-hop value instead of default #split-horizon disable - Disables EIGRP IPv6 split horizon on the interface #stub [receive-only][connected][redistributed][static][summary]

- Configures the router as a EIGRP stub router


TOC 315

OSPFv3

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IPv6 Configuration Guide, Cisco IOS Release 12.4T | | Implementing OSPFv3

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR Software, Release 3.9 | | Routing Configuration Guide | | Implementing OSPF on Cisco IOS XR Software

- Defined in RFC-5340, OSPFv3 s til l uses protocol number 89. - Multicast addresses used are FF02::5 (All SPF-Routers) and FF02::6 (All DR-Routers). - OSPFv3 has per-link, instead of per-subnet protocol processing compared to OSPFv2. - Multiple addresses are possible per in terface. - Operation is sti ll very similar to OSPFv2. - One requirement is that the router-id should s till be a val id IPv4 address.

> Should ei ther have an UP/UP in terface with a IPv4 address, or > The "router-id" command should be used.

- Network types and timers are the same as OSPFv2.

- OSPFv3 Authentication > OSPFv3 doesn 't include any authentication capabilities of i ts own. Instead, i t relies enti rely on IPv6 IPSEC. > IPSEC authentication can be configured ei ther per-in terface or per-area. > AH (Authentication Header) provides authentication via ei ther SHA1 or MD5. > Note that the key lengths mus t be exact: 40hex digi ts for SHA1 or 32hex dig its for MD5. > The key s tring used for the SA mus t be the same in each di rection between two OSPFv3 neighbors . > The fi rs t parameter to specify is the SPI (Securi ty Policy Index). > The SPI functions similarly to key numbers in a key-chain, but is communicated via AH and mus t match at both ends of the adjacency. > The SPI number is arb i trary, but m us t be a value between 256 and 4,294,967,295 (32-b i t).

- There are two new LSAs (L ink State Advertisements): > Link LSA

>> Advertises the l ink-local address to all routers attached to that l ink. >> Advertises the IPv6 prefixes on the link to the routers attached to that l ink. >> Advertises OSPF options.

> In tra -Area LSA >> Either associates a list of IPv6 prefixes with a transi t network by referencing a network LSA. >> Or associates a l ist of IPv6 prefixes with a Router-By referencing a router LSA.

- LSA flooding scopes have also changed to > Link-Local scope. > Area scope. > AS ( Autonomous Sys tem) scope.


TOC 316

IOS-COMMANDS

# sh ipv6 ospf neighbors - Shows the OSPFv3 neighbors # sh ipv6 ospf database - Shows the LSA's for each area # sh ipv6 ospf interface - Shows the authentication method used # sh crypto ipsec sa - Shows the security associations # sh crypto ipsec policy - Shows an overview of the authentication policies in use

#ipv6 router ospf 1 - Configures OSPF area authentication

#area 0 authentication ipsec spi {spi no} {md5|sha1} {key-string}

#interface {int}

#ipv6 ospf {pid} area {aid} - Automatically enables the global process for OSPF v3 #ipv6 ospf neighbor {link-local} - Manually defines a neighbor by specifying the link-local address #ipv6 ospf network {network type} - Changes the OSPF interface type along with counters #ipv6 ospf database-filter all out - Filters outgoing link-state advertisements (LSAs) on interface #ipv6 ospf authentication ipsec spi {no} {md5|sha1} {key-string}

- Configures OPSF authentication for the interface

XR-COMMANDS

# sh protocols ospfv3 - Shows OSPFv3 protocol information # sh ospfv3 - Shows general information about the OSPF process # sh ospfv3 neighbors - Shows the OSPFv3 neighbors # sh ospfv3 database - Shows the LSA's for each area # sh ospfv3 interface - Shows the authentication method used # sh crypto ipsec sa - Shows the security associations # sh crypto ipsec policy - Shows an overview of the authentication policies in use

#router ospfv3 {pid} - Enters the OSPF routing configuration mode #router-id {ip} - Configures the OSPF RID #area {aid} - Enters the OSPF area configuration mode #authentication ipsec spi {spi no} {md5|sha1} {key-string}

- Configures OPSF authentication for the area #interface {int} - Enables OSPF processing on the interface #network {network type} - Changes the OSPF interface type along with counters #neighbor {link-local} - Manually defines a neighbor by specifying the link-local address

#range {prefix/mask} [advertise|not-advertise] [cost] - Creates aggregate routes at an area boundary

#cost {value} - Configures the OSPF cost of the interface #database-filter all out - Filters outgoing link-state advertisements (LSAs) on interface #authentication ipsec spi {spi no} {md5|sha1} {key-string}

- Configures OPSF authentication at the interface


TOC 317

IS-IS - IPv6

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IPv6 Configuration Guide, Cisco IOS Release 12.4T | | Implementing IS-IS for IPv6

DOC-CD REFERENCE

| Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR Software, Release 3.9 | | Routing Configuration Guide | | Implementing BGP on Cisco IOS XR Software

- Defined in RFC-5308. - IS-IS IPv6 extends the address families supported to include IPv6, in addi tion to OSI and IPv4. - To carry the IPv6 two new m ulti topology TLVs were added:

> 232 - IPv6 In terface Address > 236 - IPv6 Reachabili ty

- The steps to configure IS-IS IPv6 is the same as IPv4: > Enable the IS-IS routing process. > Enable IS-IS IPv6 on the interfaces. > Speci fy the metrics and IS-IS parameters .

- IS-IS in IPv6 supports ei ther single -topology mode or multip le topology mode. - The two mode are not compatib le . Either one m ode m ust be used or transi tion mode mus t be enabled to accept both m ulti topology TLVs and old-style TLVs.

- IS-IS Single Topology Mode > Due a single SPF instance, the address-families , (IPv4, and IPv6) mus t have the same link s tate topology. > All in terfaces mus t be configured with the same address-families. > L1 and L2 areas mus t also be identical for all address-families. > The configured m etric is always the same for both IPv4 and IPv6. > IOS devices by defaul t operate in single topology mode.

- IS-IS Multi Topology Mode > A separate SFP instance is calculated for each address-families , which allows address-families to have incongruent topologies. > There are no res trictions on the interfaces or the areas. > IPv4 and IPv6 use thei r own set metrics with the command " isis ipv6 metric". > Requires that new-s tyle TLVs be enabled with "metric-s tyle side". > IOS-XR devices by defaul t operate in multi topology mode.

IOS-COMMANDS

# sh isis neighbors - Shows the neighbors, interfaces, addresses, states, holdtimes and types # sh isis database [level-1|level-2|detail] - Shows the link-state database for L1, L2 and the contents for each LSP # sh isis database verbose - Shows detailed information about the IS-IS database # sh isis spf-log - Shows the IS-SPF events and counters # sh isis topology - Shows a list of all connected routers in all areas

#router isis [tag] - Starts the IS-IS routing process, [tag] is optional with IOS

#net {nsap address} - Configures the NET address


TOC 318

#is-type {level-1|level-1-2|level-2-only} - Configures the system type (def = L1-L2) #metric {value} [level-1|level-2] - Globally sets a new default metric value for all IS-IS interfaces

- The level specifies the metric for that interface type (def = 10) #metric-style wide [level-1|level-2|level-1-2] [transition]

- Configures a router to use new-style TLV metrics - [transition] allows the router to accept old and new style metrics

#address-family {ipv4|ipv6} unicast - Enters the IS-IS router address-family configuration mode #multi-topology [transition] - Enables single topology mode

#interface {int}

#isis metric {value|maximum} [level1|level2] - Configures the IS-IS interface metric (def = 10) - {maximum} Excludes a link from the SPF calculation - [level-1|level-2] Applies to the specified level (def = both)

#interface {int}

#ip router isis [tag] - Enables IS-IS IPv4 on the interface #ipv6 router isis - Enables IS-IS IPv6 on the interface

XR-COMMANDS

# sh isis - Shows brief protocol overview, filter-lists, interfaces, etc. # sh isis interface - Shows information about the IS-IS enabled interfaces # sh isis neighbors [detail] - Shows the neighbors, interfaces, addresses, states, holdtimes, and types # sh isis database [level-1|level-2|detail] - Shows the link-state database for L1, L2 and the contents for each LSP # sh isis database verbose - Shows detailed information about the IS-IS database # sh isis spf-log - Shows the IS-SPF events and counters # sh isis topology - Shows a list of all connected routers in all areas

#router isis {pid} - Starts the IS-IS routing process, {pid} is an not optional with IOS-XR

#net {nsap address} - Configures the NET address #is-type {level-1|level-1-2|level-2-only} - Configures the system type (def = L1-L2) #address-family {ipv4|ipv6} unicast - Enters the IS-IS router address-family configuration mode #metric {value|max} [level-1|level-2] - Changes the default metric value of 10 to custom/max value on all-interfaces #metric-style wide [transition] [level-1|level-2] - Configures a router to use new-style TLV metrics #single-topology - Enabled single topology mode #no single-topology - Enables the IOS-XR default multi topology mode

#interface {int} - Enters the IS-IS interface configuration mode #address-family {ipv4|ipv6} [unicast|multicast] - Enables the IS-IS interface address-family configuration mode #metric {value|max} [level-1|level-2] - Changes the default metric value of 10 to custom/max value per-interface


TOC 319

MPBGP - IPv6

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IPv6 Configuration Guide, Cisco IOS Release 12.4T | | Implementing Multiprotocol BGP for IPv6

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS XR > Cisco IO-XR Software | | Configuration Guides | | Cisco XR Software, Release 3.9 | | Routing Configuration Guide | | Implementing BGP on Cisco IOS XR Software

- Only one BGP process is allowed per router, thus IPv6 configuration is done using the address-family configuration. - RFC-2858 defines extensions to BGP-4 which enables i t to carry multiple network layer protocols . - The multi -protocol extensions are negotia ted between BGP peers using an optional capabilities parameter in the BGP Open message.

- Multi -protocol extensions for BGP-4 defines two new BGP optional transitive attributes used to advertise or withdraw routes. - The attributes are MP_REACH_NLRI and MP_UNREACH_NLRI (Network Layer Reachabi lity In form ation). - The fi rs t two fields in these new attributes contain the AFI and the SAFI values. - The AFI (Address Family Identi fier) value identi fies the network layer protocol . - The SAFI (Subsequent Address Family Identi fier) value identi fies addi tional in formation about the type of NLRI carried. - When the BGP peers exchange the multiprotocol extension capabili ty, they also exchange AFI and SAFI numbers to identi fy what the other BGP peer is capable of.

- AFI Values: > AFI 1 - IPv4 > AFI 2 - IPv6

- SAFI Values: > SAFI 1 - Unicast > SAFI 2 - Multicast > SAFI 3 - Unicast and Multicas t > SAFI 4 - MPLS Label > SAFI 128 - MPLS Labeled VPN.

- E.g. I f BGP is carrying IPv6 traffic, AFI equals 2, and SAFI equals 1 for unicas t, or SAFI equals 2 for multicas t.

- The im plementation of multiprotocol extensions within BGP are known and configured as address-families (also known as contexts ): > "address-family ipv6" - Enters and configuration the IPv6 BGP context parameters .

- Normal BGP rules s till apply for MP-BGP > MPBGP requi res an underlying IGP for transport. > iBGP loop prevention:

>> iBGP-learned routes are not advertised to other iBGP neighbors. >> Exceptions are route-reflection or confederations .

> eBGP loop prevention: >> Routes are not accepted i f the local AS is lis ted in the received AS-path.

> The same bes t-path selection process is used with the same BGP attributes.

- An IPv6 neighbor m ust be activated under the IPv6 address-family, which is disabled by defaul t (unl ike IPv4). > If not activated the neighbor wi ll only exchange IPv4 routes .


TOC 320

IOS-COMMANDS

# sh protocol bgp - Similar to the IPv4 command. Older command, it will be deprecated # sh bgp ipv6 summary - Newer command to accomplish the same as previous command # sh bgp ipv6 unicast - Shows the IPv6 BGP table # sh bgp ipv6 unicast {prefix} - Shows details related to the specified prefix # debug bgp all - Shows the states, capabilities negotiation, AFT/SAFI, holdtime

#router bgp {asn}

#neighbor {ip} remote-as {asn} - Configures a neighbor using IPv6 transport #neighbor {ip} update-source {int} - Specifies source address for the session #address-family ipv6 #neighbor ip} activate - Enables negotiation of IPv6 address-family for the neighbor #neighbor {ipv6 ip} route-reflector-client - Enables RR for the neighbor

XR-COMMANDS

# sh protocols bgp - Shows BGP protocol information # sh bgp ipv6 summary - Newer command to accomplish the same as previous command # sh bgp ipv6 unicast - Shows the IPv6 BGP table # sh bgp ipv6 unicast {prefix} - Shows details related to the specified prefix


#address-family ipv6 unicast - Enables the BGP IPv6 unicast address-family globally #bgp router-id {ip} - Configures the RID for BGP Process #neighbor {ip} - Enters the BGP neighbor configuration mode #remote-as {asn} - Defines an external/internal neighbor ASN #update-source {int} - Specifies the source interface for the TCP session that carries BGP traffic #password {pwd} - Enables MD5 authentication for a neighbor #address-family ipv6 unicast - Activates IPv6 unicast for the neighbor #route-policy {name} - Applies a route policy to neighbor

CE-to-CE Tunneling & Transitioning Techniques

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IPv6 Configuration Guide, Cisco IOS Release 12.4T | | Implementing Tunneling for IPv6

- Overlay tunneling encapsulates IPv6 packets in IPv4 packets for delivery across an IPv4 in frastructure. - Manual - IPv6IP

> Usage: A m anual ly configured tunnel is equivalent to a permanent l ink between two IPv6 domains over an IPv4 backbone. > Can carry IPv6 packets only. > Least overhead of all tunnel methods, but has no CLNS transport (IS-IS).


TOC 321

> Uses protocol 41. > Tunnel source address should be an IPv4 address, or reference an IPv4 in terface with IP-unnumbered. > Tunnel des tination address should be an IPv4 address. > Tunnel in terface address should be an IPv6 address. > Configuration tunnel mode 'ipv6ip '.

CONFIG-SET: Configuring Manual IPv6-IP Tunnel on Router-A

| interface ethernet 0 | ip address 192.168.99.1 255.255.255.0 | ! | interface tunnel 0 | ipv6 address 3ffe:b00:c18:1::3/127 | tunnel source ethernet 0 - This should be Router-B destination address | tunnel destination 192.168.30.1 - Router-B source address | tunnel mode ipv6ip - Specifies the tunnel mode |

- Manual GRE/IPv4 Compatible > Usage: Simple point-to-point tunnels that can be used within a site , or between sites. > Can carry IPv6, Connectionless Network Service (CLNS), and m any other types of packets. > Is the defaul t tunnel mode when configuring a tunnel in terface. > Uses protocol 47. > Tunnel source address, should be a IPv4 address or reference an IPv4 in terface. > Tunnel des tination address should be an IPv4 address. > Tunnel in terface address should be an IPv6 address. > Configuration tunnel mode 'g re ipv6 '.

CONFIG-SET: Configuring IPv6 GRE tunnel on Router-A

| interface tunnel 0 | ipv6 address 3ffe:b00:c18:1::3/127 | tunnel source 192.168.20.1 - This would be Router-B destination address | tunnel destination 192.168.30.1 - Router-B Ethernet 0 address | tunnel mode gre ipv6 |

- Automatic 6to4

> Usage: Allows an isolated IPv6 dom ain to be connected over an IPv4 network to remote IPv6 networks . > Unlike m anual tunnels, 6to4 is point-to-m ul tipo int. > Si tes use addresses from the 2002::/16 prefix, where the form at is 2002:border-router-IPv4-address ::/48. > The IPv4 address, embedded in the IPv6 address, is used to find the other end of the automatic tunnel . > Tunnel source address should be an IPv4 address or reference an IPv4 in terface. > Tunnel des tination address is not required as this is a point-to-mul tipo int tunnel ing type. The IPv4 des tination address is calculated, on a per-packet basis, from the

IPv6 des tination. > Tunnel in terface address should be an IPv6 address. The prefix mus t embed the tunnel source IPv4 address. > Configuration tunnel mode 'ipv6 ip 6to4 '.


TOC 322

CONFIG-SET: Configuring IPv6 Automatic 6to4 Tunnel

| interface ethernet0 | description IPv4 uplink | ip address 192.168.99.1 255.255.255.0 | ! | interface ethernet1 | description IPv6 local network 1 | ipv6 address 2002:c0a8:6301:1::1/64 - Subnet 1 of the IPv6 major address range | ! | interface ethernet2 | description IPv6 local network 2 | ipv6 address 2002:c0a8:6301:2::1/64 - Subnet 2 of the IPv6 major address range | ! | interface tunnel0 | description IPv6 uplink | ipv6 address 2002:c0a8:6301::1/64 - IPv4 address converted to HEX: c0.a8.63.01 (covered in beginning) | tunnel source Ethernet 0 - Then into IPv6: 2002:c0a8:6301::1 | tunnel mode ipv6ip 6to4 | ! - Ensures any other traffic to 2002::/16 is directed to tunnel | ipv6 route 2002::/16 tunnel 0 interface 0 for automatic tunneling |

- ISATAP > Usage: Point-to-mul tipoin t tunnels that can be used to connect s ystems within a site . > Si tes can use any IPv6 unicast addresses. > Supports automatic hos t-to-Router-And hos t-to-hos t tunnel ing. > ISATAP is designed for transporting IPv6 packets within a site , not between sites. > The ISATAP router provides s tandard Router-Advertisement network configuration, which allows clients to automatical ly configure themselves . > The in terface identi fier is created in m odi fied EUI-64 format in which the fi rst 32 bi ts contain the value 0000:5EFE to indicate that the address is an IPv6 ISATAP. > The IPv4 address is encoded in the last 32 bi ts of the IPv6 address, enabling automatic IPv6-in-IPv4 tunnel ing. > Deriving the ISATAP address:

>> The prefix is 2001:0DB8:1234:5678::/64 and the embedded IPv4 address is 10.173.129.8 in hexadecimal as 0AAD:8108. >> wi ll give the following address 2001:0DB8:1234:5678:0000:5EFE:0AAD:8108.

> Tunnel source address should be an IPv4 address or reference an IPv4 in terface. > Tunnel des tination address is not required as this is a point-to-mul tipo int tunnel ing type. The IPv4 des tination address is calculated, on a per-packet basis, from the

IPv6 des tination. > Tunnel in terface address should be an IPv6 prefix in modi fied EUI-64 format. The IPv6 address is generated from the prefix and the tunnel source IPv4 address. > Configuration tunnel mode 'ipv6 ip isatap '.


TOC 323

CONFIG-SET: Configuring IPv6 Automatic ISATAP Tunnel

| interface ethernet 0 | ip address 10.27.0.1 255.255.255.0 | ! | interface tunnel 1 | ipv6 address 2001:0DB8::/64 eui-64 | tunnel source ethernet 0 | tunnel mode ipv6ip isatap | no ipv6 nd ra suppress - Router-Adverts are enabled to allow client auto-configuration |

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IPv6 Configuration Guide, Cisco IOS Release 12.4T | | Implementing Tunneling for IPv6

- NAT-PT (Protocol Translation)

> Due to numerous problems , NAT-PT defined in RFC-2766 was obsoleted by RFC-4966. > A translation mechanism, allowing IPv6-only devices to communicate directly with IPv4-only devices and vice versa using NAT. > Before im plementing NAT-PT, you mus t configure IPv4 and IPv6 on the router interfaces that need to communicate between IPv4-only and IPv6-only networks .

> Static NAT-PT >> Uses s tatic translation rules to map one IPv6 address to one IPv4 address. >> IPv6 network nodes communicate with IPv4 network nodes using an IPv6 m apping of the IPv4 address configured on the NAT-PT router. >> Example- A NAT-PT device wi ll map the source IPv6 address of 2001:0db8:bbbb:1::1 to the IPv4 address 192.168.99.2 and vice versa.

> Dynamic NAT-PT >> Allows m ultiple NAT-PT m appings by allocating addresses from a pool . >> NAT-PT is configured with a pool of IPv6 and/or IPv4 addresses. >> At the s tart of a NAT-PT session a temporary address is dynamically allocated from the pool . >> The number of addresses available in the address pool determines the maximum number of concurrent sessions. >> The NAT-PT device records each mapping between addresses in a dynamic s tate table . >> Dynamic NAT-PT translation operation requires at least one s tatic mapping for the IPv4 DNS s erver.

> Overload-PT (a .k.a . NAPT-PT) >> PAT (Port Address Translation), also known as overload, allows a single IPv4 address to be used for multiple sessions by multiplexing on the port number to

associate several IPv6 users with a single IPv4 address. >> PAT can be accomplished through a specific in terface or through a pool of addresses same as NAT-IPv4.

> IPv4-Mapped NAT-PT: >> Sends tra ffic from the IPv6 network to an IPv4 network without configuring IPv6 des tination address mapping. >> I f the NAT-PT router has a NAT-PT prefix mapped, an ACL is used to find the source address for translation.


TOC 324

CONFIG-SET: Static NAT-PT Configuration

| ipv6 unicast-routing - Required to be enabled | ! | interface Ethernet3/1 | ipv6 address 2001:0db8:3002::9/64 - Interface connecting to the IPv6 only network | ipv6 enable | ipv6 nat | ! | interface Ethernet3/3 - Interface connecting to the IPv4 only network | ip address 192.168.30.9 255.255.255.0 | ipv6 nat | ! | ipv6 nat v4v6 source 192.168.30.1 2001:0db8:0::2 - Enables a static IPv4 to IPv6 NAT-PT mapping | ipv6 nat v6v4 source 2001:0db8:bbbb:1::1 192.168.30.2 - Enables a static IPv6 to IPv4 NAT-PT mapping | ipv6 nat prefix 2001:0db8:0::/96 - Assigns an IPv6 prefix as a global NAT-PT prefix |

IOS-COMMANDS

# sh interface tunnel {int} - Shows the interfaces state, counters, etc. # sh ipv6 tunnel - Shows IPv6 tunnel information # sh ipv6 nat statistics - Shows NAT-PT statistics # sh ipv6 nat translations [verbose] - Shows active NAT-PT translations # clear ipv6 nat translation * - Clears dynamic NAT-PT translations # debug ipv6 nat [detail] - Shows debugging messages for NAT-PT translation

#interface tunnel {no} - Configures a default mode GRE tunnel for IPV6 transport (protocol=47)

#tunnel mode ipv6ip - Enables manual IPv6IP tunnel transport (protocol=41) - IPv6 is passenger and IPv4 as the encap and transport protocol

#tunnel mode gre ipv6 - Enables Manual IPv6 GRE tunnel transport - IPv6 is passenger, GRE the encap, IPv4 as transport protocol

#tunnel mode ipv6ip auto-tunnel - Enables automatic tunneling using IPv4 compatible address #tunnel mode ipv6ip 6to4 - Enables automatic tunneling using 6to4 #tunnel mode ipv6ip isatap - Enables automatic tunneling using ISATAP

#ipv6 nat prefix {ipv6}/{prefix} - Assigns an IPv6 prefix as a global NAT-PT prefix

#interface {int} #ipv6 nat - Enables NAT-PT on the interface

#ipv6 nat v6v4 source {ipv6} {ipv4} - Enables a static IPv6 to IPv4 address mapping using NAT-PT

#ipv6 nat v6v4 source {list} {pool} - Enables a dynamic IPv6 to IPv4 address mapping using NAT-PT #ipv6 nat v6v4 pool {name}{start-ip}{end-ip}{prefix} - Specifies a pool of IPv4 addresses to be used by dynamic NAT-PT

#ipv6 nat v4v6 source {ipv4} {ipv6} - Enables a static IPv4 to IPv6 address mapping using NAT-PT

#ipv6 nat v4v6 source {list} {pool} - Enables a dynamic IPv4 to IPv6 address mapping using NAT-PT #ipv6 nat v4v6 pool {name} {start-ip}{end-ip}{prefix}


TOC 325

- Specifies a pool of IPv6 addresses to be used by dynamic NAT-PT #interface {int} #ipv6 nat prefix {ipv6}/{prefix} v4-mapped map-acl - Allows traffic from an IPv6 network to an IPv4 network without configuring

IPv6 destination address mapping

IPv6 Multicast

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IPv6 Configuration Guide, Cisco IOS Release 12.4T | | Implementing IPv6 Multicast

- All multicast addresses begin with the format prefix 1111 1111, wri tten as FF. - The format prefix, FF, is followed by two fields : Flags and Scope.

> These two fields are each 4 bi ts . - The remaining 112 bi ts are the group ID.

- Multicast address range - FF00::/8 - SSM address range - FF3x::/96

- Well-known IPv6 Multicas t Addresses > FF02::1 - All m ulticast nodes on a subnet. > FF02::2 - All m ulticast routers on a subnet. > FF02::5 - OSPFv3 routers. > FF02::6 - OSPFv3 designated routers. > FF02::9 - RIPnG routers. > FF02::A - EIGRP routers . > FF02::D - PIM routers .

- IPv6 Multicas t Mapping Over Ethernet > MAC address = 48-bi ts (6-bytes)

>> 1s t 24-bi ts (3-bytes) - OUI (Organizational Unit Identi fier) >> 2nd 24-bi ts (3-bytes) - Serial number

> The OUI for IPv4 m ulticas t is 01:00:5E with the least significant bi t of the most significant byte s et. > The OUI for IPv6 m ulticas t is 33:33. > So all IPv6 multicast addresses on Ethernet will have th is address form at 33:33:xx: xx: xx: xx: where X is the last 32 bi ts of the 128-bi t multicast address. > E xample:

>> Multicast address FF02::2100:FF17:FC05 will be mapped to the Ethernet MAC-address 33:33:FF:17:FC:05

- As with IPv4, IPv6 m ulticas t addresses are always destinations , never source addresses. - IPv6 nodes (hosts and routers ) are required to join (receive packets destined for) the fo llowing multicas t groups :

> All-nodes multicas t group FF02::1 > Al l -routers multicas t group FF02::2 > Solici ted-node m ulticas t group, formed by s tarting with the 104-bi t prefix FF02::1 :FF00:0000 and adding the lowest 24 bits of the unicast/anycast address on the end.


TOC 326

- MLD (Mul ticast Listener Discovery) > The IPv6 equivalent of IPv4 IGMP is called MLD, which is a sub protocol of ICMPv6. > MLDv2 = IGMP v3. MLDv2 therefore enables IPv6 to use the SSM operation. > MLD uses ICMPv6 messages in i ts operations . > MLD performs the same tasks as IGMP. > With MLD, routers act as queriers to determine which hosts want to receive tra ffic for a multicast group. > Hosts (including routers) are receivers that will send report messages to MLD queriers to in form them they want to receive m ulticas t traffic.

- Auto-RP is not currently available. There is BSR for IPv6. As well as static configuration of an RP or embedded RP.

- IPv6-PIM (Protocol-Independent Multicast) > Operates the same way as IPv4-PIM with only a few di fferences: > IPv6-PIM has two modes of operation: SM (Sparse Mode) and SSM (Source-Speci fic Multicas t). > IPv6 m ulticast does not support Dense Mode multicast. > There is no MSDP protocol in IPv6 m ulticas t, since i t offers al ternative options such as embedded RP and SSM. > Requires a RP (Rendezvous Point) to be s tatically defined. Other routers learn about the RP through embedded in fo in MLD report messages and PIM messages. > SSM is derived from sparse mode and is more efficient. Uses a (S,G) model from the s tart to deliver multicast tra ffic to a group member from only one source which the

joining hos t specifies, ra ther than all senders for that group. > BSR (Boots trap Router) wil l automatica lly associate the IPv6 address of an RP with a multicast group. It wil l adapt to changes in RP mappings in case of failure.

IOS-COMMANDS

# sh ipv6 mroute - Shows the contents of the IPv6 multicast routing table # sh ipv6 mroute active - Shows the active multicast streams on the router # sh ipv6 rpf {ipv6-prefix} - Checks RPF information for a given unicast host address and prefix # sh ipv6 mld groups - Shows the multicast groups directly connected and learned via MLD # sh ipv6 mld interface - Shows multicast-related information about an interface # sh ipv6 mld ssm-map- Shows SSM mapping information # sh ipv6 pim interface - Shows information about interfaces configured for PIM # sh ipv6 pim neighbor [detail] - Shows the PIM neighbors discovered # sh ipv6 pim group-map - Shows an IPv6 multicast group mapping table # sh ipv6 pim bsr {election | rp-cache | c-rp} - Shows information related to PIM BSR protocol processing

# clear ipv6 pim counters - Resets the PIM traffic counters

# debug ipv6 mld - Enables debugging on MLD protocol activity # debug ipv6 pim - Enables debugging on PIM protocol activity

#ipv6 multicast-routing - Turns multicast routing on for the router/switch

#ipv6 route {ip}/{mask} {nh} [ad] {uni|multicast} - Configure static IPv6 unicast/multicast route #no ipv6 pim rp embedded - Disables embedded RP support in IPv6 PIM

>>> Configuring MLD <<<

#ipv6 mld state-limit {no} - Limits the number of MLD states globally #interface {int} #ipv6 mld join-group {group} {incl|excl} {src} - Configures MLD reporting for a specified group and source #ipv6 mld static-group {group} {incl|excl}{src} - Statically forwards traffic for the multicast group as MLD joiner #ipv6 mld limit number {no} - Limits the number of MLD states on a per-interface basis


TOC 327

#ipv6 mld access-group {acl} - Allows the user to perform IPv6 multicast receiver access control #ipv6 mld explicit-tracking {acl} - Allows for the tracking of host behavior within a multicast v6 network #no ipv6 mld router - Disables MLD router-side processing on a specified interface

>>> Configuring PIM <<<

#ipv6 pim rp-address {ip} [acl] [bidir] - Statically sets the RP address - Optional for a particular group range

#ipv6 pim spt-threshold infinity - Sets the SPT threshold to infinity to prevent switchover to the source tree

#ipv6 pim spt-threshold infinity group {acl} - Configures when a PIM leaf router joins the SPT for the specified groups #ipv6 pim accept-register {list | route-map} - Accepts or rejects registers at the RP #interface {int} #no ipv6 pim - Turns off IPv6 PIM on a specified interface

>>> Configuring BSR <<<

#ipv6 pim bsr candidate bsr {ip}{mask} priority {no} - Configures a router to be a candidate BSR #ipv6 pim bsr candidate rp {ip}[group][pri][scope] - Sends PIM RP advertisements to the BSR #ipv6 pim bsr announced rp {ip}[group][pri][scope] - Announces scope-to-RP mappings directly from the BSR for the candidate RP #interface {int} #ipv6 pim bsr border - Configures a border for all BSMs of any scope on a specified interface #no ipv6 pim - Turns off IPv6 PIM on a specified interface

>>> Configuring SSM <<<

#ipv6 mld ssm-map enable - Enables the SSM mapping feature for groups in the configured SSM range #ipv6 mld ssm-map static {acl} {Source} - Configures static SSM mappings #no ipv6 mld ssm-map query dns - Disables DNS-based SSM mapping

Access-List Filtering

DOC-CD REFERENCE | Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T | | Configuration Guides | | IPv6 Configuration Guide, Cisco IOS Release 12.4T | | Implementing Traffic Filters and Firewalls for IPv6 Security

- The s tandard ACL functional i ty in IPv6 is s imilar to s tandard ACLs in IPv4.

- The 'auth ' keyword allows matching tra ffic against the presence of the authentication header in combination with the specified protocol TCP or UDP.


TOC 328

CONFIG-SET: IPv6 ACL Example

| ipv6 access-list example1 | permit tcp any any - Allows any TCP traffic regardless of whether or not an AH is present | ! | ipv6 access-list example2 - Allows TCP/UDP only when AH is present(without AH no match) | deny tcp host 2001::1 any log sequence 5 | permit tcp any anyauth sequence 10 | permit udp any anyauth sequence 20 | ! | interface fastethernet0/1 | ipv6 address 3FFE:C000:1:7::/64 eui-64 | ipv6 enable | ipv6 traffic-filter example2 in - Applies the IPv6 ACL to the interface | ipv6 traffic-filter example1 out |

IOS-COMMANDS

#ipv6 access-list {name} - Creates the IPv6 ACL #{permit|deny} {prot} {IP|any|host|auth} {options} - Specifies the ACL options

#interface {int} #ipv6 traffic-filter {name} {in|out} - Applies the IPv6 ACL to the interface

#line vty 0 4 #ipv6 access-class {name} {in|out} - Applies the IPv6 ACL to the terminal line

Static IPv6 DNS Entries

- DNS Record Types > AAAA - Maps a hostname to an IPv6 address. > PTR - Maps an IPv6 address to a hostname.

IOS-COMMANDS

#ipv6 host {name} [port] {ipv6} {type} - Defines a static hostname-to-address mapping #ipv6 domain-name {name} - Defines the domain suffix #ipv6 name-server {ipv6} - Specifies one or more hosts that supply name information #no ipv6 domain-lookup - Disables DNS-based address translation (default = enabled)


TOC 329

Troubleshooting IPv6

- When troubleshooting IPv6, consider the fol lowing: > Was IPv6 enabled? # sh run| i ipv6 > Was IPv6 CEF enabled? # sh ipv6 cef in terface > Double check the typed IPv6 addresses! # sh ipv6 in t brie f > On serial in terfaces , i f needed, was RA (Router-Advertisements) enabled? # sh ipv6 in t {int}| i advert > On the 3560 switches was the SDM tem plate changed to support IPv6? # sh sdm prefer > For frame-relay multipoint interfaces, was a mapping configured for the link-local address? # sh run | i frame.*FE80 > Are any ACLs blocking protocol number 41? # sh ipv6 in terface | i l ine |l ist > IPv6, IPv6IP and GRE-IPv4 tunnels

>> Are the tunnel source and destination IPv4 addresses? # sh run in t tunnel {t-int} >> Is the tunnel address an IPv6 address? # sh run in t tunnel {t-int}

- When troubleshooting IGPs for IPv6, apply the same troubleshooting as with IPv4! > For RIPng

>> Are the RIPng interfaces sending updates? # debug ipv6 rip >> Was RIPng enabled on the interface? # sh ipv6 rip >> Are RIPng routes being received and entered in to the RIPng database? # sh ipv6 rip database >> Do the RIPng routes appear in the table? # sh ipv6 route rip >> Are individual routes of a summary suppressed? # sh ipv6 rip | i {prefixes } >> I f only a defaul t route was to be sent out of an in terface,

was the 'only' keyword used? # sh run | i rip .*only

> For EIGRP >> Are the interfaces correctly added to EIGRP? # sh ipv6 eigrp interfaces >> Are the expected EIGRP adjacencies showing? # sh ipv6 eigrp neighbors >> On m ultipo int interfaces , was spli t-horizon disabled? # sh run | i ipv6.*spl i t

> For OSPFv3 >> Are the expected adjacencies showing? # sh ipv6 ospf neighbor

>>> If not what is the cause? # debug ipv6 ospf adj >> Is the router sending and receiving hellos? # debug ipv6 ospf hello >> Do the timers match? # sh ipv6 ospf in t {int} | i Dead >> Do the MTU values match? # debug ipv6 ospf adj >> Are any interfaces wrongly in Passive mode, due to "passive-interface defaul t" # sh run | i passive-in t >> Are the interfaces configured to the correct areas? # sh ipv6 ospf in t brie f >> Are the network types compatib le between neighbors? # sh ipv6 ospf in t {int} | i Netw


TOC 330

Bibliography


RFC-3513 IPv6 Addressing Archi tecture http ://www.ie tf.org/rfc/rfc3513.txt

RFC-3879 Deprecating Site Local Addresses http ://www.ie tf.org/rfc/rfc3879.txt

RFC-2080 RIPng for IPv6 http ://www.ie tf.org/rfc/rfc2080.txt

RFC-5340 OSPF for IPv6 http ://www.ie tf.org/rfc/rfc5340.txt

RFC-5308 Routing IPv6 with IS-IS http ://www.ie tf.org/rfc/rfc5308.txt

RFC-2766 Network Address Translation - Protocol Translation (NAT-PT) http ://www.ie tf.org/rfc/rfc2766.txt

RFC-4966 Reasons to Move the NAT-PT to Historic Status http ://www.ie tf.org/rfc/rfc4966.txt


TOC 331

Chapter 14

QOS


TOC 332

COMING SOON...


TOC 333

Appendix A

CONFIG-SET INDEX


TOC 334

LAYER 2 3

CONFIG-SET: EXAMPLES OF FRAME-RELAY ENCAPSULATIONS PER-INTERFACE AND PER-DLCI 4

CONFIG-SET: PINGING THE LOCAL IP ON A FRAME-RELAY INTERFACE 5 CONFIG-SET: (IOS) FRAME-RELAY INTERFACE TYPES 6 CONFIG-SET: (IOS-XR) FRAME-RELAY POINT-TO-POINT INTERFACE 6 CONFIG-SET: (IOS) MFR - MULTILINK FRAME-RELAY (FRF.16.1) 7 CONFIG-SET: (IOS-XR) MFR - MULTILINK FRAME-RELAY (FRF.16.1) 8 CONFIG-SET: PPP ONE-WAY PAP AUTHENTICATION 11

CONFIG-SET: PPP TWO-WAY PAP AUTHENTICATION 11 CONFIG-SET: PPP ONE-WAY CHAP AUTHENTICATION 12 CONFIG-SET: PPP TWO-WAY CHAP AUTHENTICATION 13 CONFIG-SET: MLP - CONFIGURING A MULTILINK PPP BUNDLE 13

CORE IGP: IS-IS 19

CONFIG-SET: BASIC IS-IS CONFIGURATION 23

CONFIG-SET: IS-IS ADJACENCY FILTER 23 CONFIG-SET: IS-IS ROUTE LEAKING ON IOS 31 CONFIG-SET: USING MESH GROUPS TO LIMIT LSP FLOODING 32

CORE IGP: OSPF 41

CONFIG-SET: OSPF- DIFFERENT METHODS TO ENABLE OSPF ON INTERFACES IN IOS 45

CONFIG-SET: OSPF-ROUTE FILTERING EXAMPLES 56 CONFIG-SET 1: CONFIGURING MAX-METRIC ADVERTISEMENTS ON STARTUP 58 CONFIG-SET 2: CONFIGURING MAX-METRIC ADVERTISEMENTS UNTIL ROUTING TABLES CONVERGE 58 CONFIG-SET 3: CONFIGURING MAX-METRIC ADVERTISEMENTS FOR A GRACEFUL SHUTDOWN 58

CONFIG-SET: CONDITIONAL OSPF DEFAULT ROUTE WITH A NON-DEFAULT COST 60 CONFIG-SET: CONDITIONAL OSPF DEFAULT ROUTE WITH A ROUTE-MAP 61 CONFIG-SET: OSPF STUB AREA'S DEFAULT ROUTE USING A NON-DEFAULT COST 61

BGP 69

CONFIG-SET: BGP CONFEDERATIONS EXAMPLE 76

CONFIG-SET: SETTING BGP COMMUNITIES IN A ROUTE-MAP 80

CONFIG-SET: ORIGINATING PREFIXES WITH BGP 83 CONFIG-SET: BGP ROUTE-MAP EXAMPLE FILTERING ROUTES 85 CONFIG-SET: ROUTE-MAP CONTINUE FEATURE 86 CONFIG-SET: BGP DISTRIBUTE-LIST EXAMPLE 87 CONFIG-SET: BGP PREFIX-LIST EXAMPLES 87

CONFIG-SET: RPL-NAMED SET: MATCHING SPECIFIC AS-PATHS 90 CONFIG-SET: RPL-NAMED SET: MATCHING SPECIFIC BGP COMMUNITIES 90


TOC 335

CONFIG-SET: RPL-INLINE SET: MATCHING SPECIFIC BGP COMMUNITIES 90

CONFIG-SET: RPL-NAMED SET: MATCHING SPECIFIC BGP EXT-COMMUNITIES 91

CONFIG-SET: RPL-INLINE SET: MATCHING SPECIFIC BGP EXT-COMMUNITIES 91 CONFIG-SET: RPL-NAMED SET: MATCHING SPECIFIC BGP PREFIXES 92 CONFIG-SET: RPL-NAMED SET: MATCHING SPECIFIC RD VALUES 92 CONFIG-SET: RPL EXAMPLE FILTERING EBGP ROUTES 93 CONFIG-SET: BGP CONDITIONAL ROUTE ADVERTISEMENT 96 CONFIG-SET: BGP CONDITIONAL ROUTE INJECTION 97

CONFIG-SET: ORF EXAMPLE ON IOS-XR 99 CONFIG-SET: BGP FAST PEERING SESSION FALL-OVER 104

MPLS 111

CONFIG-SET: (IOS) CONDITIONAL LABEL ADVERTISING FOR THE LOOPBACK IPS 121

CONFIG-SET: (IOS-XR) CONDITIONAL LABEL ADVERTISING FOR THE LOOPBACK IPS 121

CONFIG-SET: (IOS)-FILTERING INBOUND LABEL BINDINGS 121 CONFIG-SET: (IOS-XR) FILTERING INBOUND LABEL BINDINGS 122

MPLS – L3VPNS 127

CONFIG-SET: MPLS-VPN - LAYER3 VPN BETWEEN THE TWO CLIENT SITES 131

CONFIG-SET: MPLS-VPN - VRF IMPORT FILTERING EXAMPLE 132 CONFIG-SET: MPLS-VPN - SELECTIVE VRF EXPORT OPTION-1 133

CONFIG-SET: MPLS-VPN - SELECTIVE VRF EXPORT OPTION-2 133 CONFIG-SET: MPLS-VPN HUB-SPOKE DESIGN EXAMPLE WITH A PITFALL 134 CONFIG-SET: MP-BGP- LIMIT THE ROUTE-EXCHANGE FOR NEIGHBORS TO SPECIFIC ADDRESS-FAMILIES 138 CONFIG-SET: MPLS OSPF SHAM-LINK BETWEEN TWO PES (R1 AND R2) 144

CONFIG-SET: VRF-LITE CE CONFIGURATION EXAMPLE 148

MPLS – TE 153

CONFIG-SET: (IOS) MPLS TE BASIC CONFIGURATION USING OSPF 157

CONFIG-SET: (IOS-XR) MPLS TE BASIC CONFIGURATION USING OSPF 158 CONFIG-SET: (IOS) MPLS TE BASIC CONFIGURATION USING IS-IS 159 CONFIG-SET: (IOS-XR) MPLS TE BASIC CONFIGURATION USING IS-IS 160

CONFIG-SET: (IOS) MPLS TE EXPLICIT PATHS WITH DYNAMIC PATH BACKUP 162 CONFIG-SET: (IOS-XR) MPLS TE EXPLICIT PATHS WITH DYNAMIC PATH BACKUP 163 CONFIG-SET: TE TUNNEL BANDWIDTH WITH PATH-OPTION BANDWIDTH OVERRIDE 164 CONFIG-SET: MPLS TE USING CLASS-BASED TUNNEL SELECTION 170 CONFIG-SET: MPLS TE LINK PROTECTION USING FAST REROUTE 173

CONFIG-SET: MPLS TE NODE PROTECTION USING FAST REROUTE 174 CONFIG-SET: MPLS VPN OVER MPLS TE - PE TO PE 178


TOC 336

CONFIG-SET: MPLS VPN OVER MPLS TE - PE TO P (PASSIVE OPTION) 179

CONFIG-SET: MPLS VPN OVER MPLS TE - PER-VRF MPLS-TE 181

MPLS – L2VPNS 189

CONFIG-SET: ATOM- ETHERNET CONFIGURATION MODES OVER MPLS ON IOS 193

CONFIG-SET: ATOM- FRAME-RELAY OVER MPLS CONFIGURATION MODES 194 CONFIG-SET: ATOM TUNNEL SELECTION USING MPLS TE 195 CONFIG-SET: L2VPN PSEUDOWIRE SWITCHING 196 CONFIG-SET: L2TPV3 DYNAMIC ETHERNET VLAN MODE WITH CHAP AUTHENTICATION 200

CONFIG-SET: L2TPV3 DYNAMIC FRAME RELAY DLCI MODE WITH DIGEST AUTHENTICATION 201 CONFIG-SET : DYNAMIC L2TPV3 SESSION ALTERNATIVE FOR LOCAL HDLC SWITCHING 202 CONFIG-SET : LOCAL CONNECT - FRAME RELAY DLCI TO DLCI SWITCHING 207 CONFIG-SET : (IOS) LOCAL CONNECT - ETHERNET PORT TO ETHERNET VLAN SWITCHING 207 CONFIG-SET : (IOS-XR) LOCAL CONNECT - ETHERNET PORT TO ETHERNET VLAN SWITCHING 207

CONFIG-SET: ATOM PSEUDOWIRE REDUNDANCY WITH HDLC 209 CONFIG-SET : (IOS-XR) VPLS PE ROUTER CONFIGURATION EXAMPLE 212

INTER-AS 217

CONFIG-SET: OPTION-1: BACK-TO-BACK VRF CONFIGURATION 221

CONFIG-SET: OPTION-2A: VPNV4 EBGP PEERING USING NEXT-HOP-SELF CONFIGURATION 223 CONFIG-SET: OPTION-2B: VPNV4 EBGP PEERING USING REDISTRIBUTE CONNECTED CONFIGURATION 225

CONFIG-SET: OPTION-2C: VPNV4 EBGP PEERING BETWEEN LOOPBACKS CONFIGURATION 227 CONFIG-SET: OPTION-3: MULTIHOP VPNV4 EBGP BETWEEN RRS CONFIGURATION 229

CSC 239

CONFIG-SET: CSC-1 - NATIVE IP WITH STATIC ROUTES 243

CONFIG-SET: CSC-2 - NATIVE IP WITH LDP LABELS 245

CONFIG-SET: CSC-3 - MPLS WITH LDP LABELS 248 CONFIG-SET: CSC-4 - MPLS WITH BGP LABELS (IPV4+LABEL) 251 CONFIG-SET: CSC-5 - MPLS VPN WITH LDP AND BGP LABELS 254

MULTICAST 263

CONFIG-SET: USING PIM-BIDIR, PIM-SM AND PIM-DM TOGETHER 273

CONFIG-SET: USING PIM-SSM WITH A NON-DEFAULT GROUP RANGE 275

CONFIG-SET: PIM-SM USING STATIC RP ASSIGNMENT 280 CONFIG-SET: PIM-SM USING AUTO-RP ASSIGNMENT WITH AUTO-RP LISTENER INSTEAD OF USING SPARSE-DENSE INTERFACE MODE 282 CONFIG-SET: PIM-SM USING BSR FOR RP ASSIGNMENT 283 CONFIG-SET: PIM-SM USING ANYCAST-RP WITH MSDP AND STATIC RP ASSIGNMENTS 284

CONFIG-SET: MULTICAST - MVPN EXAMPLE USING SSM IN THE CORE 295 Copyright © 2013 Routing-Bits.com

TOC 337

IPV6 305

CONFIG-SET: CONFIGURING MANUAL IPV6-IP TUNNEL ON ROUTER-A 321

CONFIG-SET: CONFIGURING IPV6 GRE TUNNEL ON ROUTER-A 321 CONFIG-SET: CONFIGURING IPV6 AUTOMATIC 6TO4 TUNNEL 322 CONFIG-SET: CONFIGURING IPV6 AUTOMATIC ISATAP TUNNEL 323 CONFIG-SET: STATIC NAT-PT CONFIGURATION 324 CONFIG-SET: IPV6 ACL EXAMPLE 328


TOC 338



TOC 339

Appendix B

FIGURE INDEX


TOC 340

BGP 69

FIGURE 5-1 : BGP CONDITIONAL ROUTE ADVERTISEMENT 95

MPLS 111

FIGURE 6-1: MPLS LABEL FORMAT 114

MPLS – L3VPNS 127

FIGURE 7-1: MPLS VPN PROTOCOLS 129

FIGURE 7-2: MPLS VPN ROUTE PROPAGATION 130

FIGURE 7-3: MPLS VPN PACKET FORWARDING 130 FIGURE 7-4: TROUBLESHOOTING MPLS L3VPNS 150

MPLS – TE 153

FIGURE 8-1: MPLS TE ARCHITECTURE 154

FIGURE 8-2: RSVP PATH SIGNALING EXAMPLE 155

FIGURE 8-3: MPLS TE TRAFFIC FORWARDING EXAMPLE 156 FIGURE 8-4: MPLS TE PATH OPTIONS EXAMPLE 162 FIGURE 8-5: MPLS TE CLASS-BASED TUNNEL SELECTION 169 FIGURE 8-6: MPLS TE LINK PROTECTION USING FRR 172 FIGURE 8-7: MPLS TE NODE PROTECTION USING FRR 174

FIGURE 8-8: MPLS VPNS OVER MPLS TE PE-TO-PE 177 FIGURE 8-9: MPLS VPNS OVER MPLS TE PE-TO-P 179 FIGURE 8-10: MPLS VPNS OVER MPLS TE – PER-VRF TE EXAMPLE 180 FIGURE 8-11: WALKING THE LSP FROM THE HEAD-END LSR TO A TAIL-END LSR 183 FIGURE 8-12: WALKING THE LSP WITH TE TUNNELS BETWEEN MPLS PE ROUTERS 184

FIGURE 8-13: WALKING THE LSP WHEN A TE TUNNEL ENDS ON A MPLS P POUTER 185

MPLS – L2VPNS 189

FIGURE 9-1: ATOM ARCHITECTURE 191

FIGURE 9-2: ATOM HEADER 191 FIGURE 9-3: ATOM TRAFFIC FORWARDING EXAMPLE 192

FIGURE 9-4: ATOM TUNNEL SELECTION USING MPLS TE 195 FIGURE 9-5: L2VPN PSEUDOWIRE SWITCHING 196 FIGURE 9-6: L2TPV3 ARCHITECTURE 198 FIGURE 9-7: L2TPV3 HEADER STRUCTURE 199 FIGURE 9-8: VPLS 210


TOC 341

FIGURE 9-9: HVPLS ARCHITECTURE 212

INTER-AS 217

FIGURE 10-1: INTER-AS CHAPTER TOPOLOGY 219

FIGURE 10-2: INTER-AS OPTION-1: BACK-TO-BACK VRF 220 FIGURE 10-3: INTER-AS OPTION-2A: VPNV4 EBGP PEERING USING NEXT-HOP-SELF 222 FIGURE 10-4: INTER-AS OPTION-2B: VPNV4 EBGP PEERING USING REDISTRIBUTE CONNECTED 224 FIGURE 10-5: INTER-AS OPTION-2C: VPNV4 EBGP PEERING BETWEEN LOOPBACKS 226 FIGURE 10-6: INTER-AS OPTION-3: MULTIHOP VPNV4 EBGP BETWEEN RRS 228

FIGURE 10-7: INTER-AS OPTION-3: WALKING THE LSP (CE7-TO-CE8) 234 FIGURE 10-8: INTER-AS OPTION-3: WALKING THE LSP (CE8-TO-CE7) 236

CSC 239

FIGURE 11-1: BASIC MPLS SERVICE PROVIDER 240

FIGURE 11-2: CSC MPLS SERVICE PROVIDER 240

FIGURE 11-3: CSC CHAPTER TOPOLOGY 241 FIGURE 11-4: CSC-1 - NATIVE IP WITH STATIC ROUTES MODEL 242 FIGURE 11-5: CSC-2 - NATIVE IP WITH LDP LABEL MODEL 244 FIGURE 11-6: CSC-3 - MPLS WITH LDP LABELS MODEL 246 FIGURE 11-7: CSC-3 - MPLS WITH LDP - LABEL FLOW 247

FIGURE 11-8: CSC-4 - MPLS WITH BGP LABELS (IPV4+LABEL) MODEL 249 FIGURE 11-9: CSC-4 - MPLS WITH BGP - LABEL FLOW 250 FIGURE 11-10: CSC-5 - MPLS VPN WITH LDP AND BGP LABELS 252 FIGURE 11-11: CSC-5 - MPLS VPN WITH LDP AND BGP - LABEL FLOW 253 FIGURE 11-12: WALK THE LSP - CSC-3 - MPLS WITH LDP LABELS 258

FIGURE 11-13: WALK THE LSP - CSC-5 - MPLS VPN WITH LDP AND BGP - LABEL FLOW 260

MULTICAST 263

FIGURE 12-1: MULTICAST CONNECTIVITY OVERVIEW 264

FIGURE 12-2: MULTICAST MAC ADDRESSING 269 FIGURE 12-3: MULTICAST - SPT CONSTRUCTION 277

FIGURE 12-4: MULTICAST - RPT CONSTRUCTION 278 FIGURE 12-5: MULTICAST - SPT SWITCHOVER 279 FIGURE 12-6: MULTICAST - MVPN OVERVIEW 293 FIGURE 12-7: MULTICAST - MVPN DATA FLOW EXAMPLE 294 FIGURE 12-8: MULTICAST - MVPN EXAMPLE 295 FIGURE 12-9: MULTICAST - WALK THE MVPN TREE 299


cover page - ipmanager.iripmanager.ir/r/ebook/routing-bits-ccie_service-provider_1_ebook.ip...v the...

Documents