Juniper E Series Broadband Services Routers software Configuration Guide
Below you will find brief information for software E Series Broadband Services Routers. This document covers the configuration of BGP and MPLS on the routers. The guide includes details on how to configure, monitor and troubleshoot BGP and MPLS features.
advertisement
JunosE™ Software for E Series™ Broadband Services Routers
BGP and MPLS Configuration Guide
Release
14.3.x
Published: 2013-07-18
Copyright © 2013, Juniper Networks, Inc.
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000 www.juniper.net
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United
States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312,
6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.
JunosE™ Software for E Series™ Broadband Services Routers BGP and MPLS Configuration Guide
Release 14.3.x
Copyright © 2013, Juniper Networks, Inc.
All rights reserved.
Revision History
July 2013—FRS JunosE 14.3.x
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at http://www.juniper.net/support/eula.html
. By downloading, installing or using such software, you agree to the terms and conditions of that EULA.
ii Copyright © 2013, Juniper Networks, Inc.
Part 1
Part 2
Part 3
Part 4
Part 5
Part 6
Abbreviated Table of Contents
Border Gateway Protocol
Multiprotocol Layer Switching
Configuring BGP-MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Layer 2 Services Over MPLS
Configuring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Monitoring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Virtual Private LAN Service
Virtual Private Wire Service
Index
Copyright © 2013, Juniper Networks, Inc.
iii
JunosE 14.3.x BGP and MPLS Configuration Guide iv Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Part 1
E Series and JunosE Documentation and Release Notes . . . . . . . . . . . . . . xxxiii
E Series and JunosE Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . xxxiii
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . xxxvi
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvi
Border Gateway Protocol
Exchange of IPv6 Routing Information over TCP IPv4 . . . . . . . . . . . . . . . 13
Exchange of IPv6 Routing Information over TCP IPv6 . . . . . . . . . . . . . . . 14
Link-Local Next Hops in MP-BGP Packets . . . . . . . . . . . . . . . . . . . . . . . . 14
Understanding BGP Command Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Copyright © 2013, Juniper Networks, Inc.
v
JunosE 14.3.x BGP and MPLS Configuration Guide vi
Specifying a Source Address for a BGP Session . . . . . . . . . . . . . . . . . . . . . . . 30
Specifying Peers That Are Not Directly Connected . . . . . . . . . . . . . . . . . . . . . 32
Specifying a Single-Hop Connection for IBGP Peers . . . . . . . . . . . . . . . . . . . . 34
Removing Private AS Numbers from Updates . . . . . . . . . . . . . . . . . . . . . . . . . 35
Enabling MD5 Authentication on a TCP Connection . . . . . . . . . . . . . . . . . . . . 37
Setting the Maximum Size of Update Messages . . . . . . . . . . . . . . . . . . . . . . . 38
Automatic Summarization of Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Configuring BGP for Overload Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Enabling Route Storage in Adj-RIBs-Out Tables . . . . . . . . . . . . . . . . . . . . . . . 41
Effects of Changing Outbound Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Configuring Promiscuous Peers and Dynamic Peering . . . . . . . . . . . . . . . . . . 47
Redistributing Default Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Setting the Minimum Interval Between Routing Updates . . . . . . . . . . . . . . . . 58
Advertising IPv4 Routes Between IPv6 BGP Peers . . . . . . . . . . . . . . . . . . . . . 63
Advertising a Route Only When Another Route is Present . . . . . . . . . . . . 65
Advertising a Route Only When Another Route is Absent . . . . . . . . . . . . 67
Advertising a Default Route Only When Another Route Is Present . . . . . 68
Filtering AS Paths with a Filter List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Filtering AS Paths with a Route Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Configuring the Community Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Configuring Route Flap Dampening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Global Route Flap Dampening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Policy-Based Route Flap Dampening . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Using the neighbor weight Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Using an AS-Path Access List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Using the bgp default local-preference Command . . . . . . . . . . . . . . . . . 113
Using a Route Map to Set the Local Preference . . . . . . . . . . . . . . . . . . . . 115
Comparing MED Values Within a Confederation . . . . . . . . . . . . . . . . . . . 123
Dynamic Capability Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Configuring Hold Timers for Successful Graceful Restart in Scaled
Setting the Administrative Distance for a Route . . . . . . . . . . . . . . . . . . . . . . 135
Setting the Maximum Number of Equal-Cost Multipaths . . . . . . . . . . . . . . . 139
Copyright © 2013, Juniper Networks, Inc.
vii
JunosE 14.3.x BGP and MPLS Configuration Guide
Route Reflection and Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Route Reflection and Looping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Setting the Default Output Fields While Displaying Summarized Status of BGP
Setting the Default BGP Routing Table Output Fields . . . . . . . . . . . . . . . . . . . . . . 161
Monitoring BGP Routes with Nonnatural Network Masks . . . . . . . . . . . . . . . . . . . 172
Monitoring BGP Community Routes in the Community List . . . . . . . . . . . . . . . . . 175
Monitoring BGP Routes with Matching AS Paths and AS-Path Access Lists . . . . 178
Monitoring BGP Routes with Inconsistent AS Paths . . . . . . . . . . . . . . . . . . . . . . . 181
Monitoring Dampened BGP Routes of Specified Neighbors . . . . . . . . . . . . . . . . 188
Monitoring Prefix List Outbound Route Filters Received from the BGP
Monitoring Routes Originating from a BGP Neighbor Before Application of
Monitoring Routes Originating from a BGP Neighbor After Application of Inbound
Monitoring Networks in an Autonomous System . . . . . . . . . . . . . . . . . . . . . . . . . 194
Monitoring BGP Routes with Matching AS Paths and Regular Expressions for
Monitoring BGP Routes with Matching AS Paths and Regular Expressions for
Monitoring the Routes Permitted by IP Community Lists . . . . . . . . . . . . . . . . . . . 207
viii Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Part 2
Multiprotocol Layer Switching
MPLS Label Switching and Packet Forwarding Overview . . . . . . . . . . . . . . . . . . 222
MPLS Label Switching: Push, Look Up, and Pop . . . . . . . . . . . . . . . . . . . . . . 223
TTL Processing in the Platform Label Space Overview . . . . . . . . . . . . . . . . . . . . 226
TTL Processing on Incoming MPLS Packets . . . . . . . . . . . . . . . . . . . . . . . . . 227
TTL Processing on Outgoing MPLS Packets . . . . . . . . . . . . . . . . . . . . . . . . . 228
Rules for Processing on an LSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Rules for Processing on an LER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
IP Data Packet Mapping onto MPLS LSPs Overview . . . . . . . . . . . . . . . . . . . . . . 233
Statistics for IP Packets Moving On or Off MPLS LSPs . . . . . . . . . . . . . . . . . . . . . 235
MPLS Forwarding and Next-Hop Tables Overview . . . . . . . . . . . . . . . . . . . . . . . . 237
IP and IPv6 Tunnel Routing Tables and MPLS Tunnels Overview . . . . . . . . . . . . 238
MPLS Interfaces and Interface Stacking Overview . . . . . . . . . . . . . . . . . . . . . . . 240
RSVP-TE Messages and Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
RSVP-TE State Refresh and Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
MPLS Connectivity Verification and Troubleshooting Methods . . . . . . . . . . . . . . 249
Point-to-Multipoint LSPs Connectivity Verification at Egress Nodes
Ping Extensions for Point-to-Multipoint LSPs Connectivity Verification at Egress
RSVP P2MP IPv4 Session Sub-TLV Overview . . . . . . . . . . . . . . . . . . . . . . . . 251
P2MP Responder Identifier TLV Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Copyright © 2013, Juniper Networks, Inc.
ix
JunosE 14.3.x BGP and MPLS Configuration Guide x
TLVs and Sub-TLVs Supported for Point-to-Multipoint LSPs Connectivity
P2MP Responder Identifier TLV Operations . . . . . . . . . . . . . . . . . . . . . . . . . 253
Egress Address P2MP Responder Identifier Sub-TLVs . . . . . . . . . . . . . 254
Node Address P2MP Responder Identifier Sub-TLVs . . . . . . . . . . . . . . 254
LDP Extended Discovery Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Methods for Configuring RSVP-TE Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Tracking Resources for MPLS Traffic Engineering Overview . . . . . . . . . . . . . . . . 258
Configuring Traffic-Engineering Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Synchronization Behavior During Graceful Restart . . . . . . . . . . . . . . . . . . . . 264
Synchronization Behavior on LAN Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 264
Synchronization Behavior on IGP Passive Interfaces . . . . . . . . . . . . . . . . . . 264
Use of RSVP-TE Hello Messages to Determine Peer Reachability . . . . . . . . . . . 264
Sequence of Hello Message Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Determination That a Peer Has Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Behavior of the Requesting Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Behavior of the Acknowledging Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Announcement of the Graceful Restart Capability . . . . . . . . . . . . . . . . . . . . 267
Preservation of an Established LSP Label . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
RSVP-TE Hellos Based on Node IDs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Tunneling Model for Differentiated Services Overview . . . . . . . . . . . . . . . . . . . . . 271
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
LDP and RSVP-TE Interface Profile Configuration Tasks . . . . . . . . . . . . . . . . . . . 284
LDP Interface Profile Configuration Tasks and Commands . . . . . . . . . . . . . 285
RSVP-TE Interface Profile Configuration Tasks and Commands . . . . . . . . . 285
Specifying Configured Explicit Paths on a Tunnel . . . . . . . . . . . . . . . . . . . . . 291
Configuring Dynamic Explicit Paths on a Tunnel . . . . . . . . . . . . . . . . . . . . . . 291
Configuring RSVP-TE Fast Rerouting with RSVP-TE Bypass Tunnels . . . . . . . . . 299
Configuring RSVP-TE Hello Messages to Determine Peer Reachability . . . . . . . 302
Configuring RSVP-TE Hellos Based on Node IDs . . . . . . . . . . . . . . . . . . . . . . . . . 304
Configuring the IGPs for Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . 307
Configuring MPLS and Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Configuring the Tunneling Model for Differentiated Services . . . . . . . . . . . . . . . 309
Example Differentiated Services Application and Configuration . . . . . . . . . . . . . 310
Differentiated Services Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . 311
Configuring Static EXP-to-PHB Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Signaled Mapping for RSVP-TE Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Preference of per-VR Versus per-LSP Behavior . . . . . . . . . . . . . . . . . . . . . . . 317
Copyright © 2013, Juniper Networks, Inc.
xi
JunosE 14.3.x BGP and MPLS Configuration Guide xii
Example Traffic Class Configuration for Differentiated Services . . . . . . . . . . . . . 318
Configuration on the Ingress and Transit Routers . . . . . . . . . . . . . . . . . . . . . 320
Configuration on the Transit and Egress Routers . . . . . . . . . . . . . . . . . . . . . . 321
Setting a Baseline for MPLS Major Interface Statistics . . . . . . . . . . . . . . . . . 326
Enabling and Setting a Baseline for MPLS Forwarding Table Statistics . . . . 327
Enabling and Setting a Baseline for MPLS Next-Hop Table Statistics . . . . . 327
Setting a Baseline for MPLS Tunnel Statistics . . . . . . . . . . . . . . . . . . . . . . . . 328
Enabling Statistics Collection for Policies Attached to MPLS Tunnels . . . . . 328
Clearing and Re-Creating Dynamic Interfaces from MPLS Major Interfaces . . . . 328
Clearing and Refreshing IPv4 Dynamic Routes in the Tunnel Routing Table . . . . 329
Clearing and Refreshing IPv6 Dynamic Routes in the Tunnel Routing Table . . . . 329
Monitoring ATM VCs and VPI/VCI Ranges Used for MPLS . . . . . . . . . . . . . . . . . . 330
Monitoring Global Call Admission Control Configuration . . . . . . . . . . . . . . . . . . . 331
Monitoring Interfaces Configured with Traffic Engineering Bandwidth
Monitoring Interfaces That are Synchronizing with LDP . . . . . . . . . . . . . . . . . . . . 338
Monitoring LDP Targeted Hello Receive and Send Lists . . . . . . . . . . . . . . . . . . . . 347
Monitoring MPLS Labels Used for Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Monitoring the Configured Mapping between PHB IDs and Traffic Class/Color
Monitoring RSVP-TE Profiles and MPLS Tunnel Profiles . . . . . . . . . . . . . . . . . . . 363
Monitoring RSVP-TE Interfaces Where BFD is Enabled . . . . . . . . . . . . . . . . . . . . 369
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Monitoring RSVP-TE Hello Adjacency Instances . . . . . . . . . . . . . . . . . . . . . . . . . 373
Monitoring Status and Configuration for MPLS Tunnels . . . . . . . . . . . . . . . . . . . . 375
Verifying and Troubleshooting MPLS Connectivity . . . . . . . . . . . . . . . . . . . . . . . . 377
Sending an MPLS Echo Request Packet to an IP or IPv6 Address . . . . . . . . 378
Tracing the Path of an MPLS Echo Request Packet to an IP or IPv6
Sending an MPLS Echo Request Packet to a Martini Circuit . . . . . . . . . . . . . 378
Tracing the Path of an MPLS Echo Request Packet to a Martini Circuit . . . . 378
Sending an MPLS Echo Request Packet to an L3VPN IP or IPv6 Prefix . . . . 378
Tracing the Path of an MPLS Echo Request Packet to an L3VPN IP or IPv6
Sending an MPLS Echo Request Packet to an RSVP-TE Tunnel . . . . . . . . . 379
Tracing the Path of an MPLS Echo Request Packet to an RSVP-TE
Sending an MPLS Echo Request Packet to a VPLS Instance . . . . . . . . . . . . 379
Tracing the Path of an MPLS Echo Request Packet to a VPLS Instance . . . 379
Packet Flow Examples for Verifying MPLS Connectivity . . . . . . . . . . . . . . . . . . . 379
Packet Flow Examples for MPLS LSPs to an IP Prefix . . . . . . . . . . . . . . . . . 380
Packet Flow Example for the ping mpls Command . . . . . . . . . . . . . . . 380
Packet Flow Example for the trace mpls Command . . . . . . . . . . . . . . . 382
Packet Flows for ping and trace to L3VPN IPv4 Prefixes . . . . . . . . . . . . . . . 383
Packet Flows to L3VPN IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Troubleshooting MTU Problems in Point-to-Point LSPs . . . . . . . . . . . . . . . . . . . 386
Configuring BGP-MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Example: Simple ECMP Scenario for BGP/MPLS VPN . . . . . . . . . . . . . . . . . . . . . 393
BGP/MPLS VPN Components Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Example: Distribution of Routes and Labels with BGP . . . . . . . . . . . . . . . . . . . . 398
BGP/MPLS VPN Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Packet Transport Across an IP Backbone with MPLS Overview . . . . . . . . . . . . . 403
Example: Transporting Packets Across an IP Backbone with MPLS . . . . . . . . . . 406
Copyright © 2013, Juniper Networks, Inc.
xiii
JunosE 14.3.x BGP and MPLS Configuration Guide xiv
Understanding Intra-AS IPv6 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
BGP Control Plane Behavior Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
MPLS Data Plane Behavior Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
IPv4 VPN Services Across Multiple Autonomous Systems . . . . . . . . . . . . . . . . . . 412
Understanding IPv4 VPN Services Across Multiple Autonomous
Example: Intra-AS Option B IPv4 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Inter-AS Option C with Route Reflectors Overview . . . . . . . . . . . . . . . . . . . . 420
Understanding IPv6 VPN Services Across Multiple Autonomous Systems . . . . . 421
Understanding Route-Target Filtering for MBGP VPNs Overview . . . . . . . . . 427
Understanding Route-Target Membership Information Exchange . . . . . . . . 428
Understanding RT-MEM-NLRI Routing Updates Exchange . . . . . . . . . . . . . 429
Understanding the Conditions for Advertising RT-MEM-NLRI Routes . . . . . 431
Default Route Advertisement Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Understanding Route Selection When Route-Target Filtering Is Enabled . . 433
Configuring a VRF to Provide BGP VPN Services . . . . . . . . . . . . . . . . . . . . . 435
Configuring a PE Router to Provide BGP VPN Services . . . . . . . . . . . . . . . . . 437
Creating a VRF and Assigning a Route Distinguisher . . . . . . . . . . . . . . . . . . . . . . 438
Understanding Route Distribution for a VRF using Maps . . . . . . . . . . . . . . . . . . . 443
Characteristics of Import and Global Import Maps . . . . . . . . . . . . . . . . . . . . . . . 444
Characteristics of Export and Global Export Maps . . . . . . . . . . . . . . . . . . . . . . . 445
Exporting IPv6 VPN Routes Globally into the Global BGP IPv6 RIB . . . . . . . . . . 448
Configuring Secondary Routing Table Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Disablement of Automatic Route-Target Filtering . . . . . . . . . . . . . . . . . . . . . . . . 452
Example: Enabling BGP ECMP for BGP/MPLS VPN IBGP . . . . . . . . . . . . . . . . . . 454
Example: Enabling BGP ECMP for BGP/MPLS VPN EBGP . . . . . . . . . . . . . . . . . . 455
Example: Configuring PE-to-CE BGP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Route Advertisements to Customers Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Disabling the Exchange of Routes for a Specific Peer . . . . . . . . . . . . . . . . . . 459
Disabling the Exchange of Routes for all Peers . . . . . . . . . . . . . . . . . . . . . . . 459
Example: Using a Single AS Number for All CE Sites . . . . . . . . . . . . . . . . . . . . . . 460
Prefix Advertisement with Duplicate AS Numbers Overview . . . . . . . . . . . . . . . . 463
Fast Reconvergence in VPN Networks Overview . . . . . . . . . . . . . . . . . . . . . . 467
Fast Reconvergence with Unique RDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Fast Reconvergence by Means of Reachability Checking . . . . . . . . . . . . . . . 470
Understanding BGP Sending of Labeled and Unlabeled Unicast Routes . . . 471
Understanding BGP Processing of Received Routes . . . . . . . . . . . . . . . . . . . 472
Unlabeled Unicast Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Resolving IPv6 Indirect Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Understanding Internet Access and VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Traffic Flow from the VPN to the Internet Overview . . . . . . . . . . . . . . . . . . . 475
Example: Configuring a Default Route to a Shared Interface . . . . . . . . . . . . 476
Example: Configuring a Fallback Global Option . . . . . . . . . . . . . . . . . . . . . . 477
Example: Configuring a Global Import Map for Specific Routes . . . . . . . . . . 478
Creation of a BGP Session Between the CE Router and the Parent VR
Example: Creating a BGP Session Between the CE Router and the Parent
Traffic Flow from the Internet to the VPN Overview . . . . . . . . . . . . . . . . . . . 483
Example: Adding Static Routes to a Shared IP Interface . . . . . . . . . . . . . . . 483
Copyright © 2013, Juniper Networks, Inc.
xv
JunosE 14.3.x BGP and MPLS Configuration Guide xvi
Part 3
Example: Exporting VPN Routes to Global BGP RIB Using Global Export
Carrier-of-Carriers IPv4 VPNs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Customer Carrier as an Internet Service Provider . . . . . . . . . . . . . . . . . . . . . 487
Configuring Customer Carrier as an Internet Service Provider . . . . . . . . . . . 488
Customer Carrier as a VPN Service Provider . . . . . . . . . . . . . . . . . . . . . . . . . 489
Configuring Customer Carrier as a VPN Service Provider . . . . . . . . . . . . . . . 491
Carrier-of-Carriers IPv6 VPNs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Connection of IPv6 Islands Across IPv4 Clouds with BGP Overview . . . . . . 493
Connection of IPv6 Islands Across Multiple IPv4 Domains Overview . . . . . 494
Configuring IPv6 Tunneling over IPv4 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 495
Understanding Usage of BGP/MPLS VPNs to Connect OSPF Domains . . . 496
Distributing OSPF Routes from CE Router to PE Router . . . . . . . . . . . . 497
Distributing Routes Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . 497
Preservation of OSPF Routing Information Across the MPLS/VPN Backbone
OSPF Domain Identifier Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
OSPF Route Type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Distribution of OSPF Routes from PE Router to CE Router Overview . . . . . 499
Prevention of Routing Loops Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Understanding Remote Neighbors Usage to Configure OSPF Links . . . . . . 500
Understanding OSPF Sham Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Layer 2 Services Over MPLS
Layer 2 Services over MPLS Platform Considerations . . . . . . . . . . . . . . . . . . . . . 528
Local Cross-Connects Between Layer 2 Interfaces Using MPLS Overview . . . . . 531
MPLS Shim Interfaces for Layer 2 Services over MPLS Overview . . . . . . . . . . . . . 531
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
AAL0 Raw Cell Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Cell Concatenation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Cell Concatenation and Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
CE-Side MPLS L2VPNs over LAG Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Ethernet Raw Mode Encapsulation for Martini Layer 2 Transport Overview . . . . 540
S-VLAN Subinterface with an Untagged C-VLAN ID Overview . . . . . . . . . . . . . . 542
Multiple ATM Virtual Circuits over a Single Pseudowire Overview . . . . . . . . . . . . 542
Guidelines for Configuring VPI/VCI Ranges of ATM Virtual Circuits . . . . . . . 545
Performance Impact and Scalability Considerations . . . . . . . . . . . . . . . . . . 546
Configuring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Before You Configure Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . 547
Configuring Interoperation with Legacy Frame Relay Layer 2 Services . . . . . . . . 549
Configuring S-VLAN Tunnels for Layer 2 Services . . . . . . . . . . . . . . . . . . . . . . . . 550
Configuring Local Cross-Connects Between Ethernet/VLAN Interfaces . . . . . . . 551
Configuring Local ATM Cross-Connects with AAL5 Encapsulation . . . . . . . . . . . 552
Copyright © 2013, Juniper Networks, Inc.
xvii
JunosE 14.3.x BGP and MPLS Configuration Guide
Part 4
Configuring an MPLS Pseudowire with VCC Cell Relay Encapsulation . . . . . . . . 554
Configuring HDLC Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . 556
Local Cross-Connects for HDLC Layer 2 Services Configuration
CE-Side Load Balancing for Martini Layer 2 Transport . . . . . . . . . . . . . . . . . . . . . 557
Understanding CE Load Balancing for Martini Layer 2 Transport . . . . . . . . . 558
Configuration of Many Shim Interfaces with the Same Peer, VC Type, and
Load-Balancing Group Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Configuring Load-Balancing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Adding a Member Interface to a Group Circuit . . . . . . . . . . . . . . . . . . . . 562
Removing Member Subinterfaces from a Circuit . . . . . . . . . . . . . . . . . . 562
Example: Configuring Frame Relay over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Example: Configuring MPLS L2VPN Tunnel over VLAN over LAG . . . . . . . . . . . . 566
Configuration on CE1 (Local CE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Configuration on PE1 (Local PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Configuration on PE2 (Remote PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 568
Configuration on CE2 (Remote CE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Example: Configuring MPLS L2VPN Tunnel over LAG . . . . . . . . . . . . . . . . . . . . . 570
Configuration on CE1 (Local CE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Configuration on PE1 (Local PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Configuration on PE2 (Remote PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Configuration on CE2 (Remote CE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Examples: Ethernet Raw Mode Encapsulation for Martini Layer 2 Transport . . . 573
Examples: Configuring S-VLAN Subinterface with an Untagged C-VLAN ID . . . . 577
Example: Multiple ATM Virtual Circuits over a Single Pseudowire . . . . . . . . . . . . 579
Monitoring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Setting Baselines for Layer 2 Services over MPLS Statistics . . . . . . . . . . . . . . . . . 581
Monitoring ATM Martini Cell Packing Timers for Layer 2 Services over MPLS . . . 582
Monitoring ATM Subinterfaces for Layer 2 Services over MPLS . . . . . . . . . . . . . . 582
Monitoring ATM Cross-Connects for Layer 2 Services over MPLS . . . . . . . . . . . . 584
Monitoring MPLS Forwarding for Layer 2 Services over MPLS . . . . . . . . . . . . . . . 584
Monitoring MPLS Layer 2 Interfaces for Layer 2 Services over MPLS . . . . . . . . . 586
Virtual Private LAN Service
xviii Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Subscriber Policies for VPLS Network Interfaces Overview . . . . . . . . . . . . . . . . . 597
Considerations for VPLS Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 599
Designated VE Device Selection for a Multihomed Site . . . . . . . . . . . . . . . . 603
Multihoming Reaction to Failures in the Network . . . . . . . . . . . . . . . . . . . . . 605
Configuring VPLS with BGP Signaling on a PE Router . . . . . . . . . . . . . . . . . . . . . 610
Configuring VPLS Instances with BGP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 610
Configuring Optional Attributes for VPLS Instances . . . . . . . . . . . . . . . . . . . . . . . 613
Configuring the Loopback Interface and Router ID for VPLS . . . . . . . . . . . . . . . . 615
Example: Configuring VPLS with BGP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Topology Overview of VPLS with BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 619
Configuration on PE 1 (Local PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Configuration on PE 2 (Remote PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Configuring VPLS with LDP Signaling on a PE Router . . . . . . . . . . . . . . . . . . . . . 622
Configuring VPLS Instances with LDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 623
Configuring Routing in the Core Network for VPLS . . . . . . . . . . . . . . . . . . . . . . . 624
Topology Overview of VPLS with LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 626
Configuration on PE 1 (Local PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Configuration on PE 2 (Remote PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Setting a Baseline for a VPLS Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Setting a Baseline for a Network Interface associated with a VPLS
Copyright © 2013, Juniper Networks, Inc.
xix
JunosE 14.3.x BGP and MPLS Configuration Guide
Part 5
Setting a Baseline for the VPLS Virtual Core Interface associated with a
Clearing Dynamic MAC Addresses from the VPLS Forwarding Table . . . . . . . . . 630
Clearing All Dynamic MAC Addresses from the VPLS Forwarding Table . . . 631
Clearing a Specific Dynamic MAC Addresses from the VPLS Forwarding
Clearing BGP Reachability Information for the L2VPN Address Family . . . . 632
Clearing BGP Route Flap Dampening Information for the L2VPN Address
Clearing BGP Route Flap Dampening Information for the VPWS Address
Clearing the Wait for End-of-RIB Marker for the L2VPN Address Family . . . 632
Monitoring VPLS Configuration and Statistics for a Specific VPLS Instance . . . 633
Monitoring VPLS Configuration and Statistics for All VPLS Instances . . . . . . . . 634
Monitoring Configuration, Statistics, and Status for VPLS Network Interfaces . . 637
Monitoring Configuration, Statistics, and Status for VPLS Core Interfaces . . . . 640
Monitoring Configuration, Statistics, and Status for VPLS Ports . . . . . . . . . . . . . 642
Monitoring MAC Address Entries for a Specific VPLS Instance . . . . . . . . . . . . . . 644
Virtual Private Wire Service
VPWS and BGP/MPLS VPNs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
Designated VE Device Selection for a Multihomed Site . . . . . . . . . . . . . . . . . . . . 667
Multihoming Reaction to Failures in the Network . . . . . . . . . . . . . . . . . . . . . . . . 669
xx Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Part 6
Types of Interfaces to Configure in the VPWS Instance . . . . . . . . . . . . . . . . . . . . 676
Configuring Customer-Facing Interfaces in the VPWS Instance . . . . . . . . . . . . . 676
Configuring a Local Cross-Connect for VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
BGP Loopback Interface and Router ID Overview . . . . . . . . . . . . . . . . . . . . . . . . 678
Configuring the Loopback Interface and Router ID for BGP for VPWS . . . . . . . . 678
Example: Configuring VPWS on Local and Remote Routers . . . . . . . . . . . . . . . . 681
Configuration on PE 1 (Local PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
Configuration on PE 2 (Remote PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . 684
Clearing BGP Reachability Information for the L2VPN Address Family . . . . 687
Clearing BGP Route Flap Dampening Information for the L2VPN Address
Clearing the Wait for the End-of-RIB Marker for the L2VPN Address
Monitoring BGP-Related Settings for VPWS L2VPNS . . . . . . . . . . . . . . . . . . . . . 688
Monitoring BGP Next Hops for VPWS L2VPNS . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Monitoring MPLS Forwarding Table for VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Index
Copyright © 2013, Juniper Networks, Inc.
xxi
JunosE 14.3.x BGP and MPLS Configuration Guide xxii Copyright © 2013, Juniper Networks, Inc.
List of Figures
Part 1
Border Gateway Protocol
Figure 18: Advertising a Route When Another Route is Present . . . . . . . . . . . . . . . 66
Figure 19: Advertising a Route When Another Route is Absent . . . . . . . . . . . . . . . 67
Figure 20: Advertising a Default Route When Another Route is Present . . . . . . . . 69
Figure 29: Next-Hop Behavior for Broadcast Multiaccess Media . . . . . . . . . . . . . 107
Figure 30: Next-Hop Behavior for Nonbroadcast Multiaccess Media . . . . . . . . . 108
Figure 31: Assigning a Weight to a Neighbor Connection . . . . . . . . . . . . . . . . . . . . 110
Copyright © 2013, Juniper Networks, Inc.
xxiii
JunosE 14.3.x BGP and MPLS Configuration Guide xxiv
Part 2
Figure 39: Administrative Distance and Synchronization . . . . . . . . . . . . . . . . . . . 138
Figure 41: A Fully Meshed Autonomous System . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Figure 42: A Confederation of Subautonomous Systems . . . . . . . . . . . . . . . . . . . 145
Figure 45: Route Reflection: Physical and Logical Redundancy . . . . . . . . . . . . . . 148
Multiprotocol Layer Switching
Figure 51: TTL Processing on Incoming MPLS Packets . . . . . . . . . . . . . . . . . . . . . 228
Figure 52: TTL Processing on Outgoing MPLS Packets . . . . . . . . . . . . . . . . . . . . 230
Figure 53: LSP Creation, Downstream-on-Demand, Ordered Control . . . . . . . . . 232
Figure 54: LSP Creation, Downstream-Unsolicited, Independent Control . . . . . . 233
Figure 56: MPLS Interface Stacking for the Platform Label Space . . . . . . . . . . . . 241
Figure 57: MPLS Interface Stacking for the Interface Label Space . . . . . . . . . . . . 242
Figure 58: LDP Tunneled Through an RSVP-TE Core . . . . . . . . . . . . . . . . . . . . . . 260
Figure 59: Flow for Initial Setting of EXP Bits for the First Label Pushed . . . . . . . 274
Figure 60: Flow for Setting EXP Bits for All Pushed Labels . . . . . . . . . . . . . . . . . 275
Figure 62: FEC Aggregation and Equal-Cost Paths . . . . . . . . . . . . . . . . . . . . . . . . 293
Figure 64: Differentiated Services over an MPLS Network . . . . . . . . . . . . . . . . . . . 311
Figure 65: Associations Between PHB ID, EXP Bits, and Traffic
Configuring BGP-MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Figure 68: ECMP BGP/MPLS VPN Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Figure 70: BGP/MPLS VPN Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Figure 72: Standard and Extended BGP Update Messages . . . . . . . . . . . . . . . . . 401
Figure 73: BGP/MPLS VPN Route Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Figure 74: LSP Creation for BGP/MPLS VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Figure 75: Traffic Across the MPLS Backbone of a BGP/MPLS VPN . . . . . . . . . . 406
Figure 76: Traffic Across the MPLS Backbone of a BGP/MPLS VPN . . . . . . . . . . 408
Copyright © 2013, Juniper Networks, Inc.
List of Figures
Part 3
Figure 78: Inter-AS Topology with VRFs on Each AS Boundary Router . . . . . . . . 413
Figure 79: Inter-AS Topology with End-to-End Stacked MPLS Tunnels . . . . . . . . 414
Figure 80: Topology for Three-label Stack Configuration for Inter-AS Option
Figure 81: Topology for Inter-AS Option C with Route Reflectors . . . . . . . . . . . . . 421
Figure 84: Route Target Configuration for a Full-Mesh VPN . . . . . . . . . . . . . . . . 423
Figure 85: Site Connectivity in a Hub-and-Spoke VPN . . . . . . . . . . . . . . . . . . . . 424
Figure 86: Route Target Configuration for a Hub-and-Spoke VPN . . . . . . . . . . . 424
Figure 87: Site Connectivity in an Overlapping VPN . . . . . . . . . . . . . . . . . . . . . . . 425
Figure 88: Route Target Configuration for an Overlapping VPN . . . . . . . . . . . . . 426
Figure 94: BGP/MPLS VPN IBGP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Figure 95: BGP/MPLS VPN EIBGP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Figure 97: Network with Potential Routing Loops . . . . . . . . . . . . . . . . . . . . . . . . 462
Figure 98: Preventing Potential Routing Loops in the Network . . . . . . . . . . . . . . 463
Figure 99: Allowing Local AS in VPNv4 Address Family . . . . . . . . . . . . . . . . . . . . 464
Figure 100: Topology for Fast Reconvergence by Means of Unique VRF RDs,
Figure 101: Topology for Fast Reconvergence by Means of Reachability Checking,
Figure 104: Global Import Map Applied to Routes Imported from VRF BGP
Figure 105: BGP Session Between CE Router and Parent VR . . . . . . . . . . . . . . . 480
Figure 106: BGP Session Between CE Router and Parent VR . . . . . . . . . . . . . . . . 481
Figure 108: Global Export Map Applied to Routes Exported from VRF BGP
Figure 114: OSPF Topology with Backdoor Link . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Layer 2 Services Over MPLS
Figure 116: Layer 2 Services over a Provider’s MPLS Network . . . . . . . . . . . . . . . . 528
Copyright © 2013, Juniper Networks, Inc.
xxv
JunosE 14.3.x BGP and MPLS Configuration Guide
Part 4
Part 5
Figure 118: E Series Router Replacing Remote ATM Switch . . . . . . . . . . . . . . . . . 534
Figure 119: AAL5 Pseudowire and MPLS Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Figure 120: CE-Side MPLS L2VPN Tunnel over LAG . . . . . . . . . . . . . . . . . . . . . . . 539
Configuring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Figure 121: Local Cross-Connect Between Ethernet/VLAN Interfaces . . . . . . . . . 551
Figure 123: Sample Frame Relay over MPLS Configuration . . . . . . . . . . . . . . . . . 563
Figure 124: MPLS L2VPN Tunnel over VLAN over LAG Configuration Example . . 567
Figure 125: MPLS L2VPN Tunnel over LAG Configuration Example . . . . . . . . . . . . 571
Figure 126: MPLS L2VPN Tunnel over LAG Configuration Example . . . . . . . . . . . 574
Figure 127: Ethernet Packet Distribution over Martini Circuits . . . . . . . . . . . . . . . . 576
Figure 128: Martini Circuit with Two Pseudowires Between PE-Facing
Virtual Private LAN Service
Figure 131: Topology for VPLS Configuration Example with BGP Signaling . . . . . 619
Figure 132: Topology for VPLS Configuration Example with LDP Signaling . . . . . 625
Virtual Private Wire Service
Figure 136: Topology for VPWS Configuration Example . . . . . . . . . . . . . . . . . . . . 682
xxvi Copyright © 2013, Juniper Networks, Inc.
List of Tables
Part 1
Border Gateway Protocol
Table 6: Commands Affecting All Address Families in a VRF . . . . . . . . . . . . . . . . . 19
Table 7: Commands Affecting the Current Address Family . . . . . . . . . . . . . . . . . . . 19
Table 8: Commands Affecting All Address Families for the Specified Peer or
Table 9: Commands Affecting Only the Current Address Family for the Specified
Table 12: Commands That Do Not Override Inherited Outbound Policy . . . . . . . . 25
Table 13: Source Addresses and Default Next Hop Addresses for Various
Table 14: Commands That Create Match-and-Set Route Maps . . . . . . . . . . . . . . 70
Table 15: Clauses Supported in BGP Match-and-Set Route Maps . . . . . . . . . . . . . 71
Table 16: Commands That Create Match-Only Route Maps . . . . . . . . . . . . . . . . . . 71
Table 17: Clauses Not Supported in BGP Route Maps . . . . . . . . . . . . . . . . . . . . . . . 71
Table 18: Set Clauses Supported in Route Maps Applied with the Table-Map
Table 19: Action Based on Well-Known Community Membership . . . . . . . . . . . . 90
Table 20: Origin and AS Path for Routes Viewed on Different Routers . . . . . . . . . 117
Table 21: Default Administrative Distances for Route Sources . . . . . . . . . . . . . . . 135
Table 24: show ip as-path-access-list Output Fields . . . . . . . . . . . . . . . . . . . . . . 164
Table 26: show ip bgp advertised-routes Output Fields . . . . . . . . . . . . . . . . . . . . 170
Table 27: show bgp ipv6 aggregate-address Output Fields . . . . . . . . . . . . . . . . . 172
Table 29: show ip bgp community Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 174
Table 30: show ip bgp community-list Output Fields . . . . . . . . . . . . . . . . . . . . . . 176
Copyright © 2013, Juniper Networks, Inc.
xxvii
JunosE 14.3.x BGP and MPLS Configuration Guide xxviii
Part 2
Table 31: show ip bgp dampened-paths Output Fields . . . . . . . . . . . . . . . . . . . . . 177
Table 34: show ip bgp inconsistent-as Output Fields . . . . . . . . . . . . . . . . . . . . . . 181
Table 36: show ip bgp neighbors dampened-routes Output Fields . . . . . . . . . . . 188
Table 37: show ip bgp neighbors paths Output Fields . . . . . . . . . . . . . . . . . . . . . 190
Table 38: show ip bgp neighbors received prefix-filter . . . . . . . . . . . . . . . . . . . . . 190
Table 39: show ip bgp neighbors received-routes Output Fields . . . . . . . . . . . . . . 191
Table 40: show bgp ipv6 neighbors routes Output Fields . . . . . . . . . . . . . . . . . . . 193
Table 44: show ip bgp peer-group Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 197
Table 45: show ip bgp quote-regexp Output Fields . . . . . . . . . . . . . . . . . . . . . . . 200
Table 47: show bgp ipv6 summary Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 204
Table 48: show ip community-list Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 208
Multiprotocol Layer Switching
Table 52: Sub-TLVs Supported for the Target FEC Stack TLV . . . . . . . . . . . . . . . 248
Table 53: Sub-TLVs Supported for the P2MP Responder Identifier TLV . . . . . . . 253
Table 54: Summary of LDP Graceful Restart States . . . . . . . . . . . . . . . . . . . . . . . 261
Table 55: Configuration Tasks by Type of Network . . . . . . . . . . . . . . . . . . . . . . . 280
Table 56: Incoming L-LSP PHB Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Table 57: Examples of Incoming L-LSP PHB Determination . . . . . . . . . . . . . . . . . 314
Table 58: Outgoing L-LSP PHB Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Table 62: show ip tunnel route and show ipv6 tunnel-route Output Fields . . . . 334
Table 64: show ldp binding and show mpls binding Output Fields . . . . . . . . . . . 337
Copyright © 2013, Juniper Networks, Inc.
List of Tables
Part 3
Table 73: show mpls explicit-paths Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 351
Table 76: show mpls forwarding Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Table 78: show mpls minor-interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . 361
Table 83: show mpls rsvp authentication Output Fields . . . . . . . . . . . . . . . . . . . 369
Table 84: show mpls rsvp bfd interfaces Output Fields . . . . . . . . . . . . . . . . . . . . 369
Table 86: show mpls rsvp hello graceful restart Output Fields . . . . . . . . . . . . . . 373
Table 87: show mpls rsvp hello instance Output Fields . . . . . . . . . . . . . . . . . . . . 374
Configuring BGP-MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Table 89: Route-Target Filtering Advertisement Rules for Routes Received from
Table 90: Characteristics of Import and Global Import Maps . . . . . . . . . . . . . . . 445
Table 91: Characteristics of Export and Global Export Maps . . . . . . . . . . . . . . . . 445
Table 93: Advertising Action Taken Following Best Route Selection . . . . . . . . . . 474
Table 95: show ip bgp next-hop Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Table 100: show mpls l2transport load-balancing-group Output Fields . . . . . . 520
Layer 2 Services Over MPLS
Configuring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Table 102: Martini Circuit Scenarios Without Ethernet Raw Mode . . . . . . . . . . . . 574
Table 103: Martini Circuit Scenarios with Ethernet Raw Mode . . . . . . . . . . . . . . . 575
Monitoring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Table 104: show atm mcpt-timers Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 582
Table 105: show atm subinterface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 583
Table 106: show mpls cross-connects atm Output Fields . . . . . . . . . . . . . . . . . . 584
Table 108: show mpls interface and show mpls l2transport interface Output
Copyright © 2013, Juniper Networks, Inc.
xxix
JunosE 14.3.x BGP and MPLS Configuration Guide xxx
Part 4
Part 5
Virtual Private LAN Service
Table 109: VPLS Forwarding Table on PE 1 for VPLS A . . . . . . . . . . . . . . . . . . . . 596
Table 110: VPLS Forwarding Table on PE 1 for VPLS B . . . . . . . . . . . . . . . . . . . . . 596
Table 111: VPLS Forwarding Table on PE 2 for VPLS A . . . . . . . . . . . . . . . . . . . . . 596
Table 112: VPLS Forwarding Table on PE 2 for VPLS B . . . . . . . . . . . . . . . . . . . . . 597
Table 113: Default Subscriber Policies for VPLS Network Interfaces . . . . . . . . . . 598
Table 114: Commands to Configure Subscriber Policies . . . . . . . . . . . . . . . . . . . . 599
Table 115: Commands to Configure Basic VPLS Instances . . . . . . . . . . . . . . . . . . 610
Table 116: Commands to Configure BGP Signaling for VPLS . . . . . . . . . . . . . . . . 617
Table 117: Commands to Configure LDP Signaling for VPLS . . . . . . . . . . . . . . . . 624
Table 118: Commands to Configure OSPF for a VPLS Network . . . . . . . . . . . . . . 624
Table 120: show bridge groups details Output Fields . . . . . . . . . . . . . . . . . . . . . . 635
Table 123: show bridge interface vpls Output Fields . . . . . . . . . . . . . . . . . . . . . . 640
Table 129: show ip bgp next-hops Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 650
Table 132: show vpls connections Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 654
Virtual Private Wire Service
Table 134: Commands to Configure Basic VPWS Instances . . . . . . . . . . . . . . . . 674
Table 135: Commands to Configure BGP Signaling for VPWS . . . . . . . . . . . . . . . 679
Table 136: Commands for Monitoring BGP Settings for the VPWS Address
Table 137: Commands for Monitoring BGP Settings for the VPWS Address
Table 139: show ip bgp l2vpn all next-hops Output Fields . . . . . . . . . . . . . . . . . . 693
Table 140: show l2vpn connections Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 696
Copyright © 2013, Juniper Networks, Inc.
List of Tables
Copyright © 2013, Juniper Networks, Inc.
xxxi
JunosE 14.3.x BGP and MPLS Configuration Guide xxxii Copyright © 2013, Juniper Networks, Inc.
About the Documentation
•
E Series and JunosE Documentation and Release Notes on page xxxiii
•
•
E Series and JunosE Text and Syntax Conventions on page xxxiii
•
Obtaining Documentation on page xxxv
•
Documentation Feedback on page xxxv
•
Requesting Technical Support on page xxxv
E Series and JunosE Documentation and Release Notes
For a list of related JunosE documentation, see http://www.juniper.net/techpubs/software/index.html
.
If the information in the latest release notes differs from the information in the documentation, follow the JunosE Release Notes.
To obtain the most current version of all Juniper Networks
® technical documentation, see the product documentation page on the Juniper Networks website at http://www.juniper.net/techpubs/ .
Audience
This guide is intended for experienced system and network specialists working with
Juniper Networks E Series Broadband Services Routers in an Internet access environment.
E Series and JunosE Text and Syntax Conventions
defines notice icons used in this documentation.
Copyright © 2013, Juniper Networks, Inc.
xxxiii
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 1: Notice Icons
Icon Meaning
Informational note
Caution
Warning
Laser warning
Description
Indicates important features or instructions.
Indicates a situation that might result in loss of data or hardware damage.
Alerts you to the risk of personal injury or death.
Alerts you to the risk of personal injury from a laser.
defines text and syntax conventions that we use throughout the
E Series and JunosE documentation.
Table 2: Text and Syntax Conventions
Convention Description Examples
Bold text like this
Bold text like this
Represents commands and keywords in text.
•
•
Issue the clock source command.
Specify the keyword exp-msg.
Represents text that the user must type.
host1(config)#traffic class low-loss1
Fixed-width text like this Represents information as displayed on your terminal’s screen.
host1#show ip ospf 2
Routing Process OSPF 2 with Router
ID 5.5.0.250
Router is an Area Border Router
(ABR)
Italic text like this
•
•
•
Emphasizes words.
Identifies variables.
Identifies chapter, appendix, and book names.
•
•
•
There are two levels of access: user and
privileged.
clusterId, ipAddress.
Appendix A, System Specifications
Plus sign (+) linking key names Indicates that you must press two or more keys simultaneously.
Press Ctrl + b.
Syntax Conventions in the Command Reference Guide
Plain text like this Represents keywords.
Italic text like this
Represents variables.
terminal length
mask, accessListName xxxiv Copyright © 2013, Juniper Networks, Inc.
About the Documentation
Table 2: Text and Syntax Conventions (continued)
Convention Description
| (pipe symbol)
[ ] (brackets)
[ ]* (brackets and asterisk)
{ } (braces)
Examples
Represents a choice to select one keyword or variable to the left or to the right of this symbol. (The keyword or variable can be either optional or required.) diagnostic | line
Represent optional keywords or variables.
Represent optional keywords or variables that can be entered more than once.
Represent required keywords or variables.
[ internal | external ]
[ level1 | level2 | l1 ]*
{ permit | deny } { in | out }
{ clusterId | ipAddress }
Obtaining Documentation
To obtain the most current version of all Juniper Networks technical documentation, see the Technical Documentation page on the Juniper Networks Web site at http://www.juniper.net/ .
To download complete sets of technical documentation to create your own documentation CD-ROMs or DVD-ROMs, see the Portable Libraries page at http://www.juniper.net/techpubs/resources/index.html
Copies of the Management Information Bases (MIBs) for a particular software release are available for download in the software image bundle from the Juniper Networks Web site at http://www.juniper.net/
.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation to better meet your needs. Send your comments to [email protected]
, or fill out the documentation feedback form at https://www.juniper.net/cgi-bin/docbugreport/ . If you are using e-mail, be sure to include the following information with your comments:
• Document or topic name
• URL or page number
•
Software release version
Requesting Technical Support
Technical product support is available through the Juniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,
Copyright © 2013, Juniper Networks, Inc.
xxxv
JunosE 14.3.x BGP and MPLS Configuration Guide or are covered under warranty, and need post-sales technical support, you can access our tools and resources online or open a case with JTAC.
•
JTAC policies—For a complete understanding of our JTAC procedures and policies, review the JTAC User Guide located at http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf
.
• Product warranties—For product warranty information, visit http://www.juniper.net/support/warranty/
.
•
JTAC hours of operation—The JTAC centers have resources available 24 hours a day,
7 days a week, 365 days a year.
Self-Help Online Tools and Resources
For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called the Customer Support Center (CSC) that provides you with the following features:
• Find CSC offerings: http://www.juniper.net/customers/support/
• Search for known bugs: http://www2.juniper.net/kb/
• Find product documentation: http://www.juniper.net/techpubs/
• Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/
• Download the latest versions of software and review release notes: http://www.juniper.net/customers/csc/software/
•
Search technical bulletins for relevant hardware and software notifications: https://www.juniper.net/alerts/
•
Join and participate in the Juniper Networks Community Forum: http://www.juniper.net/company/communities/
• Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/
To verify service entitlement by product serial number, use our Serial Number Entitlement
(SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/
Opening a Case with JTAC
You can open a case with JTAC on the Web or by telephone.
• Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .
• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, see http://www.juniper.net/support/requesting-support.html
.
xxxvi Copyright © 2013, Juniper Networks, Inc.
PART 1
Border Gateway Protocol
•
Configuring BGP Routing on page 3
•
Copyright © 2013, Juniper Networks, Inc.
1
JunosE 14.3.x BGP and MPLS Configuration Guide
2 Copyright © 2013, Juniper Networks, Inc.
CHAPTER 1
Configuring BGP Routing
This chapter contains the following sections:
•
•
Platform Considerations on page 14
•
•
•
Before You Configure BGP on page 17
•
Configuration Tasks on page 17
•
Basic Configuration on page 17
•
Configuring BGP Peer Groups on page 27
•
•
Configuring BGP Routing Policy on page 70
•
Selecting the Best Path on page 104
•
Interactions Between BGP and IGPs on page 132
•
Detecting Peer Reachability with BFD on page 140
•
Managing a Large-Scale AS on page 143
•
Configuring BGP Multicasting on page 152
•
Using BGP Routes for Other Protocols on page 155
•
Configuring BGP/MPLS VPNs on page 156
•
Testing BGP Policies on page 156
Overview
The Border Gateway Protocol (BGP) provides loop-free interdomain routing between autonomous systems (ASs). This section describes some of the main concepts of BGP.
Conventions in This Chapter
Certain terms used with BGP, such as the names of attributes and messages, are typically expressed in all uppercase letters in the RFCs. For improved readability, those terms are represented in lowercase in this chapter.
lists the terms and their variant spellings.
Copyright © 2013, Juniper Networks, Inc.
3
JunosE 14.3.x BGP and MPLS Configuration Guide
AS-set atomic-aggregate cluster-list keepalive local-pref multiexit discriminator or MED new-as-path new-aggregator next-hop or next hop no-advertise no-export no-export-subconfed notification open origin originator-ID route-refresh update
Table 3: Conventions for BGP Terms
In This Chapter In RFCs aggregator
AS-confed-set
AS-path or AS path
AS-sequence
AGGREGATOR
AS_CONFED_SET
AS_PATH
AS_SEQUENCE
AS_SET
ATOMIC_AGGREGATE
CLUSTER_LIST
KEEPALIVE
LOCAL_PREF
MULTI_EXIT_DISC
NEW_AS_PATH
NEW_AGGREGATOR
NEXT_HOP
NO_ADVERTISE
NO_EXPORT
NO_EXPORT_SUBCONFED
NOTIFICATION
OPEN
ORIGIN
ORIGINATOR_ID
ROUTE-REFRESH
UPDATE
4 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Autonomous Systems
An autonomous system (AS) is a set of routers that use the same routing policy while running under a single technical administration. An AS runs interior gateway protocols
(IGPs) such as RIP, OSPF, and IS-IS within its boundaries. ASs use exterior gateway protocols (EGPs) to exchange routing information with other ASs. BGP is an EGP.
The outside world views an AS as a single entity, even though it can be a collection of
IGPs working together to provide routing within its interior.
Each AS has an identification number provided by an Internet registry or by an Internet service provider (ISP) that uniquely identifies it to the outside world.
BGP Speaker
A router that has been configured to run the BGP routing protocol is called a BGP speaker.
BGP Peers and Neighbors
Unlike some other routing protocols, BGP speakers do not automatically discover each other and begin exchanging information. Instead, each BGP speaker must be explicitly configured with a set of BGP peers with which it exchanges routing information. BGP peers do not have to be directly connected to each other in order to share a BGP session.
Another term for BGP peer is BGP neighbor. A BGP peer group consists of two or more
BGP peers that share a common set of update policies.
In
Figure 1 on page 5 , router NY and router Chicago are peers. Router NY and router LA
are peers. Router NY and router Boston are peers. Router NY and router Philly are not peers. Router Chicago and router LA are not peers.
NOTE: The figures in this chapter indicate a BGP session with a dotted line.
A physical link is represented by a solid line.
Figure 1: BGP Peers
BGP Session
When two BGP speakers have both been configured to be BGP peers of each other, they will establish a BGP session to exchange routing information. A BGP session is simply a
Copyright © 2013, Juniper Networks, Inc.
5
JunosE 14.3.x BGP and MPLS Configuration Guide
TCP connection over which routing information is exchanged according to the rules of the BGP protocol.
Because BGP relies on TCP to provide reliable and flow-controlled transmission of routing information, the BGP protocol itself is very simple. However it also implies that two routers can be BGP peers of each other only if they are reachable from each other in the sense that they can exchange IP packets.
In practice this means that either of the following must be true:
• The BGP peers must be connected to a common IP subnet.
• The BGP peers must be in the same AS, which runs an IGP enabling the BGP peers to reach each other.
IBGP and EBGP
When two BGP speakers are in the same autonomous system, the BGP session is called an internal BGP session, or IBGP session. When two BGP speakers are in different autonomous systems, the BGP session is called an external BGP session, or EBGP session.
BGP uses the same types of message on IBGP and EBGP sessions, but the rules for when to send which message and how to interpret each message differ slightly; for this reason some people refer to IBGP and EBGP as two separate protocols.
IBGP requires that BGP speakers within an autonomous system be fully meshed, meaning that there must be a BGP session between each pair of peers within the AS. IBGP does not require that all the peers be physically connected. EBGP does not require full meshing of BGP speakers. EBGP sessions typically exist between peers that are physically connected.
shows an example of the exchange of information between routers running IBGP and EBGP across multiple ASs.
Figure 2: Internal and External BGP
6 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Interior Gateway Protocols
Not all the routers within an AS have to be BGP peers. For example, in some large enterprise networks, ASs generally have many more non-BGP routers. These routers communicate using an interior gateway protocol (IGP) such as the following:
• Intermediate System-to-Intermediate System (IS-IS)
• Open Shortest Path First (OSPF)
•
Routing Information Protocol (RIP)
shows that the routers in AS 53 all communicate with each other using an IGP. Routing information internal to AS 53 is redistributed from the IGP into BGP at router Chicago. Router Chicago redistributes into the IGP the routing information it receives from its external BGP peer, router Atlanta. Router Atlanta has an internal BGP link within its AS, and an external BGP link to router Topeka.
Figure 3: Interior Gateway Protocols
BGP Messages
BGP speakers exchange routing information with each other by exchanging BGP messages over a BGP session. BGP uses the following five message types:
•
Open BGP messages—When two BGP speakers establish a BGP session with each other, the first message they exchange after the underlying TCP session has been established is an open message. This message contains various bits of information that enable the two BGP peers to determine whether they want to establish a BGP session with each other—for example, the AS number of the BGP speaker—and to negotiate certain parameters for the BGP session—for example, how often to send a keepalive message.
• Update messages—The update message is the most important message in the BGP protocol. A BGP speaker sends update messages to announce routes to prefixes that it can reach and to withdraw routes to prefixes that it can no longer reach.
Copyright © 2013, Juniper Networks, Inc.
7
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Keepalive messages—BGP speakers periodically exchange keepalive messages to determine whether the underlying TCP connection is still up.
• Notification messages—If a BGP speaker wishes to terminate a BGP session (either because it has been configured to do so or because it has detected some error condition), it will send a notification message to its peer specifying the reason for terminating the BGP session.
If the session is being terminated for a nonfatal error, the notification messages includes the error code cease. Subcodes sent in the notification message can inform network operators about peering problems and help them better understand network events.
lists the subcodes defined for BGP notification messages bearing the cease code.
Table 4: Cease Notification Message Subcodes
Subcode Reason Symbolic Name
1
2
The number of address prefixes received from the peer has exceeded the upper bound configured with the neighbor maximum-prefix command. The notification message can include address family and upper bound information in the data field.
Maximum Number of Prefixes Reached
The BGP speaker is administratively shutting down the session.
Administratively Shutdown
3
4
5
6
The BGP speaker is removing the peer configuration.
The BGP speaker is administratively resetting the session.
The BGP speaker is rejecting the connection (for example, because the peer is not configured locally on the speaker) after accepting a transport protocol connection.
The BGP speaker is administratively resetting the session for some other configuration.
Peer Unconfigured
Administratively Reset
Connection Rejected
Other Configuration Change
•
Route-refresh messages—BGP speakers can send route-refresh messages to peers that advertise the route-refresh capability. The messages contain a request for the peer to resend its routes to the router. This feature enables the BGP speaker to apply modified or new policies to the routes when it receives them again.
8 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
BGP Route
A BGP route consists of two parts, a prefix and a set of path attributes. It is not uncommon to use the term path to refer to a BGP route, although that term technically refers to one of the path attributes of that route.
Routing Information Base
BGP routes are stored in a BGP speaker’s routing information base (RIB), also known as its routing table, which conceptually consists of the following three parts:
•
Adj-RIBs-In store unprocessed routes learned from update messages received by the
BGP speaker.
• Loc-RIB contains local routes resulting from the BGP speaker applying its local policies to the routes contained in its Adj-RIBs-In.
•
Adj-RIBs-Out store routes that the BGP speaker will advertise to its peers in the update messages it sends.
Prefixes and CIDR
A prefix describes a set of IP addresses that can be reached using the route. For example, the prefix 10.1.1.0/24 indicates all IP addresses whose first 24 bits contain the value 10.1.1.
The term network is sometimes used instead of prefix to describe a set of addresses. To reduce confusion, this chapter restricts network to its more common usage, to refer to a physical structure of routers and links.
Prefixes are made possible by classless interdomain routing (CIDR). CIDR addresses have largely replaced the concept of classful addresses (such as Class A, Class B, and
Class C) in the Internet. Classful addresses have an implicit, fixed-length mask corresponding to the predefined class boundaries. For example, 192.56.0.0 is a Class B address with an implicit (or natural) mask of 255.255.0.0.
CIDR uses network prefixes and explicit masks, represented by a prefix length, enabling network prefixes of arbitrary lengths. CIDR represents the sample address above as
192.56.0.0/16. The /16 indicates that the high-order 16 bits (the first 16 bits counting from left to right) in the address mask are all 1s.
CIDR enables you to aggregate multiple classful addresses into a single classless advertisement, reducing the number of advertisements that must be made to provide full access to all the addresses. Suppose an ISP has customers with the following addresses:
192.168.128.0
192.168.129.0
192.168.130.0
192.168.131.0
Copyright © 2013, Juniper Networks, Inc.
9
JunosE 14.3.x BGP and MPLS Configuration Guide
192.168.132.0
192.168.133.0
...
192.168.255.0
Without CIDR, the ISP has to advertise a route to each address, as shown in
.
Figure 4: Routing Without CIDR
With CIDR, the ISP can aggregate the routes as 192.168.128.0/17 and advertise a single address to that prefix, as shown in
.
10 Copyright © 2013, Juniper Networks, Inc.
Figure 5: Routing with CIDR
Chapter 1: Configuring BGP Routing
Path Attributes
A path attribute provides some additional information about a route. If a BGP speaker has more than one route to the same destination prefix, it selects one of those routes to use (the “ best” route) based on the path attributes. BGP as implemented on the Juniper
Networks E Series Broadband Services Router specifies detailed and complex criteria for picking the best route; this helps ensure that all routers will converge to the same routing table, a necessary behavior to avoid routing loops. See
“Selecting the Best Path” on page 104
for more information.
The following are some of the most important path attributes:
• AS-path specifies the sequence of autonomous systems that must be crossed to reach a certain destination. This path attribute is used to avoid routing loops and to prefer shorter routes over longer routes.
•
Next-hop specifies the IP address of the ingress router in the next autonomous system on the path to the destination.
• Local-pref and multiexit discriminator (MED) are metrics that administrators can tune to ensure that certain routes are more attractive over other routes. The local-pref attribute specifies a degree of preference that enables a router to select among multiple routes to the same prefix. The MED is used for ASs that have more than one connection to each other. The administrator of one AS sets the MED to express a degree of preference for one link versus another; the BGP peer in the other AS uses this MED to optimize traffic.
• Originator-ID specifies the IP address of the router that originates the route. The router ignores updates that have this attribute set to its own IP address.
•
Atomic-aggregate and aggregator inform peers about actions taken by a BGP speaker regarding aggregation of routes. If a BGP speaker aggregates routes that have differing path attributes, it includes the atomic-aggregate attribute with the aggregated prefix to inform update recipients that they must not deaggregate the prefix. A BGP speaker
Copyright © 2013, Juniper Networks, Inc.
11
JunosE 14.3.x BGP and MPLS Configuration Guide aggregating routes can include the aggregator attribute to indicate the router and AS where the aggregation was performed.
• Community and extended community identify prefixes as sharing some common attribute, providing a means of grouping prefixes and enacting routing policies on the group of prefixes. A prefix can belong to more than one community. You can specify a community name as a 32-bit string, a standards-defined well-known community, or an AS number combined with a 32-bit number to create a unique identifier. An extended community name consists of either an IP address or an AS number, combined with a
32-bit or 16-bit number to create a unique identifier.
Transit and Nontransit Service
While an ISP provides connectivity to its customers, it also provides connectivity to customers of other ISPs. In doing this, an ISP must be able to ensure the appropriate use of its resources.
For example,
shows three ISPs and three customers. ISP 1, ISP 2, and
ISP 3 are directly connected to one another through a physical link and a corresponding
EBGP session (represented here by a single line). Customer 1 is connected to ISP 1 through a physical link and corresponding EBGP session. Customer 2 is similarly connected to
ISP 2, and Customer 3 is similarly connected to ISP 3. Each ISP provides transit service to its own customers.
illustrates how the ISP permits traffic to transit across its backbone from its own customers or to its own customers.
Figure 6: Transit Service
Each ISP provides nontransit service to other ISPs. For example,
shows that ISP 1 does not permit traffic between ISP 2 and ISP 3 to cross its backbone. If ISP 1 permits such traffic, it squanders its own resources with no benefit to its customers or itself.
12 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Figure 7: Nontransit Service
IPv6 BGP Support
Most of the extensions and features available in BGP for IPv4 are also available for the
IPv6 address family, such as policy-based routing, redistributing routes to and from other protocols, route aggregation, route flap dampening, and confederations. For a description of IPv6, see Configuring IPv6 in JunosE IP, IPv6, and IGP Configuration Guide.
Multiprotocol Extensions for BGP-4 (MP-BGP) allow the exchange of IPv6 routing
information over TCP IPv4 ( Figure 8 on page 13 ) or TCP IPv6 transport
Exchange of IPv6 Routing Information over TCP IPv4
illustrates the exchange of IPv6 routing information over a TCP IPv4 connection.
Figure 8: IPv6 Routing over TCP IPv4
The E Series router’s MP-BGP implementation uses BGP update messages to announce the feasible routes to an associated IPv6 BGP next hop and also to announce the nonfeasible routes that need to be withdrawn from the peer. The E Series router announces only IPv6 global addresses as the BGP next-hop address; it does not use the optional link-local IPv6 address as the BGP next hop.
BGP determines the next-hop addresses to be announced by using the IPv4-compatible
IPv6 address. For example, the following table shows the translation of an IPv4 address.
IPv4 address
10.1.1.1
IPv6 address
::10.1.1.1
When a BGP speaker receives a BGP update message carrying IPv6 feasible routes, the speaker resolves the announced IPv6 BGP next hop by performing a route lookup to the
IPv6 address in the IPv6 route table.
Copyright © 2013, Juniper Networks, Inc.
13
JunosE 14.3.x BGP and MPLS Configuration Guide
Exchange of IPv6 Routing Information over TCP IPv6
illustrates the exchange of IPv6 routing information over a TCP IPv6 connection.
Figure 9: IPv6 Routing over TCP IPv6
Link-Local Next Hops in MP-BGP Packets
When the router has an external directly connected (non-multihop) BGP peer, the router advertises two next hops. It advertises the global next hop and a next hop with a link-local address. The link-local next hop is advertised even when the router has been configured with the next-hop self feature. Advertising the link-local next hop enables the configuration of single-hop EBGP sessions for IPv6 next hops.
For all other types of peers, the router advertises only the global BGP IPv6 next hop.
You can overwrite the global and link-local IPv6 next-hop addresses by configuring and applying a route map that sets the addresses. The set ipv6 next-hop clause in the route map can specify a global address, a link-local address, or both for the next hop.
However, a neighbor outbound route map that adds a link-local IPv6 address for peers where the router should not advertise a link-local next hop is considered an invalid configuration.
The router accepts both global and link-local BGP IPv6 next-hop addresses received from its BGP IPv6 peers. As a consequence, when advertising a route to an internal peer, the router can modify the network address of the next-hop field by removing the link-local
IPv6 address of the next hop.
For static BGP peers, the JunosE Software does not support the use of link-local addresses when you configure BGP peers. You cannot configure the local interface for a neighbor that has been configured with a link-local address. Although you can configure a neighbor with a link-local address, a BGP session to that peer over TCP IPv6 does not come up.
For dynamic BGP peers, an E Series router can accept incoming TCP sessions with the link-local address as the source address. However, the BGP peering does not come up for such a connection.
Platform Considerations
For information about modules that support BGP on the ERX7xx models, ERX14xx models, and the Juniper Networks ERX310 Broadband Services Router:
• See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
14 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
References
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the modules that support BGP.
For information about modules that support BGP on Juniper Networks E120 and E320
Broadband Services Routers:
• See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module specifications.
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information about the modules that support BGP.
For more information about the BGP protocol, consult the following resources:
•
Address Prefix Based Outbound Route Filter for
BGP-4—draft-chen-bgp-prefix-orf-07.txt (March 2004 expiration)
• BGP Extended Communities Attribute—draft-ietf-idr-bgp-ext-communities-07.txt
(February 2004 expiration)
•
Connecting IPv6 Islands across IPv4 Clouds with
BGP—draft-ietf-ngtrans-bgp-tunnel-04.txt (July 2002 expiration)
• Cooperative Route Filtering Capability for BGP-4—draft-ietf-idr-route-filter-09.txt
(February 2003 expiration)
•
Dynamic Capability for BGP-4—draft-ietf-idr-dynamic-cap-04.txt (February 2004 expiration)
• JunosE Release Notes, Appendix A, System Maximums—Refer to the Release Notes corresponding to your software release for information about maximum values.
•
RFC 1657—Definitions of Managed Objects for the Fourth Version of the Border Gateway
Protocol (BGP-4) using SMIv2 (July 1997)
• RFC 1745—BGP4/IDRP for IP—OSPF Interaction (December 1994)
•
RFC 1772—Application of the Border Gateway Protocol in the Internet (March 1995)
•
RFC 1773—Experience with the BGP-4 protocol (March 1995)
• RFC 1774—BGP-4 Protocol Analysis (March 1995)
• RFC 1863—A BGP/IDRP Route Server alternative to a full mesh routing (October 1995)
•
RFC 1930—Guidelines for creation, selection, and registration of an Autonomous System
(AS) (March 1996)
• RFC 3065—Autonomous System Confederations for BGP (February 2001)
• RFC 1966—BGP Route Reflection An alternative to full mesh IBGP (June 1996)
•
RFC 1997—BGP Communities Attribute (August 1996)
•
RFC 1998—An Application of the BGP Community Attribute in Multi-home Routing
(August 1996)
Copyright © 2013, Juniper Networks, Inc.
15
JunosE 14.3.x BGP and MPLS Configuration Guide
•
RFC 2270—Using a Dedicated AS for Sites Homed to a Single Provider (January 1998)
• RFC 2385—Protection of BGP Sessions via the TCP MD5 Signature Option (August
1998)
•
RFC 2439—BGP Route Flap Damping (November 1998)
•
RFC 2519—A Framework for Inter-Domain Route Aggregation (February 1999)
• RFC 2545—Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
(March 1999)
•
RFC 2796—BGP Route Reflection—An Alternative to Full Mesh IBGP (April 2000)
•
RFC 3392—Capabilities Advertisement with BGP-4 (November 2002)
• RFC 4760—Multiprotocol Extensions for BGP-4 (January 2007)
• RFC 2918—Route Refresh Capability for BGP-4 (September 2000)
•
RFC 3032—MPLS Label Stack Encoding (January 2001)
•
RFC 3065—Autonomous System Confederations for BGP (February 2001)
• RFC 3392—Capabilities Advertisement with BGP-4 (November 2002)
• RFC 4271—A Border Gateway Protocol (BGP-4) (January 2006)
•
RFC 4364—BGP/MPLS IP Virtual Private Networks (VPNs) (February 2006)
•
RFC 4721—Graceful Restart Mechanism for BGP (January 2007)
• RFC 4893—BGP Support for Four-octet AS Number Space (May 2007)
• Subcodes for BGP Cease Notification Message—draft-ietf-idr-cease-subcode-05.txt
(March 2004 expiration)
NOTE: IETF drafts are valid for only 6 months from the date of issuance.
They must be considered as works in progress. Please refer to the IETF
Web site at http://www.ietf.org for the latest drafts.
Features
16
Some of the more important BGP features supported by the E Series router are the following:
•
Access lists
•
Advertisement intervals
• Aggregation
• BGP/MPLS VPNs
•
Communities
•
Confederations
• EBGP multihop
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
IBGP single hop
• Highly scalable BGP-4 architecture
• Multicast
•
Next-hop self
•
Peer groups
• Route dampening (also referred to as route damping)
• Route mapping and attribute manipulation
•
Route origins
•
Route redistribution
• Route reflectors
• Soft-reconfiguration inbound
•
Synchronization enabling and disabling
•
Update source
Before You Configure BGP
Configuration Tasks
Before you attempt to configure BGP, ensure that you have TCP/IP reachability to the
BGP peers with which you want your router to communicate. This may include tasks such as setting up interfaces and creating routes.
See the JunosE Link Layer Configuration Guide and JunosE Physical Layer Configuration
Guide for information about how to configure appropriate interfaces. See JunosE IP
Services Configuration Guide, for information about setting up routing information.
Basic Configuration
BGP is a very flexible protocol, often providing more than one way to achieve a routing goal. The configuration tasks required therefore vary depending on your needs and decisions. Read all of the following sections to determine the best method for configuring
BGP for your needs.
Two tasks are common to every BGP configuration: You must enable the BGP routing process, and you must configure BGP neighbors. All other basic configuration tasks are optional.
You can configure certain BGP attributes globally, for peer groups, or for individual peers.
The most specific level of configuration takes precedence. For example, if you configure an attribute both globally and for a peer group, the peer group configuration takes precedence for that peer group, but does not affect other peer groups. If you configure an attribute both for a peer group and for a peer, the peer configuration takes precedence for that peer, but does not affect other members of that peer group.
Copyright © 2013, Juniper Networks, Inc.
17
JunosE 14.3.x BGP and MPLS Configuration Guide
Enabling BGP Routing
All BGP configurations require that you enable the BGP routing process on one or more routers.
router bgp
•
Use to enable the BGP routing protocol and to specify the local AS—the AS to which this BGP speaker belongs.
•
All subsequent BGP configuration commands are placed within the context of this router and AS; you can have only a single BGP instance per virtual router.
•
Specify only one BGP AS per virtual router.
•
This command takes effect immediately.
•
Example host1(config)#router bgp 100
•
Use the no version to remove the BGP process.
•
See router bgp.
Understanding BGP Command Scope
BGP commands can be sorted into the following categories, each of which has a different scope; that is, each configures parameters within a different area of applicability. Individual command descriptions in this chapter and in
“Configuring BGP-MPLS Applications” on page 389 , provide more information about
command behavior.
18 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
The commands listed in
configure parameters for the BGP process globally, regardless of address family.
Table 5: Commands Affecting BGP Globally
bgp advertise-inactive bgp graceful-restart path-selection-defer-time bgp advertise best-external-to-internal bgp graceful-restart restart-time bgp always-compare-med bgp bestpath med confed bgp graceful-restart stalepaths-time bgp log-neighbor-changes bgp bestpath missing-as-worst bgp client-to-client reflection bgp maxas-limit bgp redistribute-internal bgp cluster-id bgp confederation identifier bgp confederation peers bgp default local-preference bgp default route-target filter bgp enforce-first-as bgp fast-external-fallover bgp graceful-restart bgp router-id bgp shutdown ip bgp-community new-format overload shutdown rib-out disable router bgp timers bgp
• The commands listed in
configure parameters for all address families within the current VRF context.
Table 6: Commands Affecting All Address Families in a VRF
distance bgp synchronization
•
The commands listed in
configure parameters only for the current address family context.
Table 7: Commands Affecting the Current Address Family
address family disable-dynamic-redistribute aggregate-address auto-summary external-paths ip route-type
Copyright © 2013, Juniper Networks, Inc.
19
JunosE 14.3.x BGP and MPLS Configuration Guide
20
Table 7: Commands Affecting the Current Address Family (continued)
bgp dampening maximum-paths bgp wait-on-end-of-rib check-vpn-next-hops network redistribute default-information originate table-map
• The commands listed in
configure parameters for a peer or peer group, regardless of address family. If the peer or peer group is activated in more than one address family, the values are changed in all those address families. These commands are said to apply on a per-VRF basis. In the following example, EBGP multihop is configured for the session, but when you configure an address family, it is not available—that is, EBGP multihop is not configurable per address family: host1(config-router)#neighbor 10.1.3.4 remote-as 1234 host1(config-router)#neighbor 10.2.3.4 ebgp-multihop 5 host1(config-router)#address-family ipv4 multicast host1(config-router-af)#neighbor 10.2.3.4 ebgp-multihop ?
% Invalid input detected at '^' marker.
host1(config-router-af)#exit-address-family
Table 8: Commands Affecting All Address Families for the Specified Peer or Peer Group
neighbor advertisement-interval neighbor maximum-update-size neighbor allow neighbor bfd-liveness-detection neighbor capability neighbor passive neighbor password neighbor peer-type neighbor description neighbor ebgp-multihop neighbor graceful-restart neighbor graceful-restart restart-time neighbor graceful-restart stalepaths-time neighbor ibgp-singlehop neighbor lenient neighbor remote-as neighbor rib-out disable neighbor shutdown neighbor site-of-origin neighbor timers neighbor update-source neighbor weight
• The commands listed in
configure parameters separately for each address family exchanged over the BGP session. If you configure these parameters for
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing a peer or peer group that is activated in more than one address family, the values are affected only for the current address family. The inbound route map is such a parameter; the following example demonstrates that a BGP session can have a different inbound route map for each address family.
host1(config-router)#neighbor 1.1.3.4 remote-as 1234 host1(config-router)#neighbor 1.2.3.4 route-map ucast-map in host1(config-router)#address-family ipv4 multicast host1(config-router-af)#neighbor 1.2.3.4 activate host1(config-router-af)#neighbor 1.2.3.4 route-map mcast-map in host1(config-router-af)#exit-address-family
Table 9: Commands Affecting Only the Current Address Family for the Specified Peer or Peer Group
neighbor activate neighbor peer-group neighbor advertise-map neighbor allowas-in neighbor prefix-list neighbor prefix-tree neighbor as-override neighbor default-originate neighbor distribute-list neighbor filter-list neighbor local-as neighbor maximum-prefix neighbor next-hop-self neighbor next-hop-unchanged neighbor remote-private-as neighbor route-map neighbor route-reflector-client neighbor send-community neighbor send-label neighbor soft-reconfiguration inbound neighbor unsuppress-map
Inheritance of Configuration Values
Peer groups inherit all configuration values that are globally configured. However, attributes configured for a peer group override inherited global configuration values.
Individual peers that are members of peer groups inherit all configuration values from the peer group. However, attributes configured on a peer override values inherited from the peer group of which it is a member.
The neighbor commands enable you to control features or set parameters for individual peers or for peer groups. These commands can be classified into the four categories shown in
Table 10 on page 22 , based on whether the command enables a feature or sets
parameters, the levels at which it behaves, and how the no version of the command compares with the default version.
Copyright © 2013, Juniper Networks, Inc.
21
JunosE 14.3.x BGP and MPLS Configuration Guide
22
Table 10: Behavior of Neighbor Commands
Category B:
Category A:
Enable or disable a feature that can be configured for a peer or for a peer group
•
•
•
•
•
•
•
•
•
•
•
•
•
•
• neighbor activate neighbor advertise-map neighbor as-override neighbor bfd-liveness-detection neighbor capability neighbor ebgp-multihop neighbor ibgp-singlehop neighbor lenient neighbor next-hop-self neighbor next-hop-unchanged neighbor passive neighbor remove-private-as neighbor route-reflector-client neighbor send-community neighbor soft-reconfiguration inbound
Enable or disable a feature that can be configured for a peer, for a peer group, or globally
•
• neighbor defaultoriginate neighbor gracefulrestart
•
• neighbor rib-out disable neighbor shutdown
Category D:
Category C:
Set parameters for a peer or for a peer group
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
• neighbor advertisement-interval neighbor allow
•
•
•
•
•
• neighbor allowas-in neighbor description neighbor distribute-list neighbor filter-list neighbor graceful-restart restart-time neighbor graceful-restart stalepaths-time neighbor local-as neighbor maximum-orf-entries neighbor maximum-prefix neighbor maximum-update-size neighbor password neighbor peer-group neighbor peer-type neighbor prefix-list neighbor prefix-tree neighbor remote-as neighbor route-map neighbor send-label neighbor site-of-origin neighbor unsuppress-map neighbor update-source neighbor weight
Set parameters for a peer, for a peer group, or globally
• neighbor timers
Some of the commands in
inherit global values set by other commands.
describes the relationship between these commands.
Table 11: Inheritance from Other Commands
Category B Command Inherits Global Values Set By neighbor default-originate default-information originate
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Table 11: Inheritance from Other Commands (continued)
Category B Command Inherits Global Values Set By neighbor graceful-restart neighbor rib-out disable neighbor shutdown neighbor graceful-restart restart-time bgp graceful-restart rib-out disable bgp shutdown bgp graceful-restart restart-time neighbor graceful-restart stalepaths-time bgp graceful-restart stalepaths-time
Example 1 For category A and B commands, the behavior of the no version of the command is different from the behavior of the default version of the command. The no version explicitly disables the feature:
•
Applied to a peer, the no version disables the feature regardless of whether the feature is enabled for any peer group to which it belongs.
•
Applied to a peer group, the no version disables the feature regardless of whether the feature is enabled for BGP globally or by default.
The default version simply unconfigures the feature for the peer or peer group.
•
Applied to a peer, the default version causes the peer to inherit the state of the feature
(enabled or disabled) from any peer group to which it belongs.
•
Applied to a peer group, the default version causes the peer group to inherit the state of the feature (enabled or disabled) from the BGP global configuration.
The following example illustrates this difference and the inheritance concept with the neighbor soft-reconfiguration inbound command.
host1(config-router)#neighbor lisbon peer-group host1(config-router)#neighbor 10.19.7.8 peer-group lisbon
Inbound soft-reconfiguration is disabled by default, hence it is currently disabled for both the lisbon peer group and peer 10.19.7.8.
host1(config-router)#neighbor lisbon soft-reconfiguration inbound
Inbound soft-reconfiguration is now enabled for the lisbon peer group. Because the peer inherits values from the peer group, inbound soft-reconfiguration is now also enabled for peer 10.19.7.8.
host1(config-router)#no neighbor 10.19.7.8 soft-reconfiguration inbound
The no command disables inbound soft-reconfiguration for peer 10.19.7.8, overriding the configuration of the peer group to which the peer 10.19.7.8 belongs. The configuration of an individual peer takes precedence over the configuration of the peer group to which the peer belongs.
Copyright © 2013, Juniper Networks, Inc.
23
JunosE 14.3.x BGP and MPLS Configuration Guide host1(config-router)#default neighbor 10.19.7.8 soft-reconfiguration inbound
The default version returns the peer to inheriting the peer group configuration. Because inbound soft-reconfiguration is still enabled for lisbon, it is now also enabled for peer
10.19.7.8.
host1(config-router)#default neighbor lisbon soft-reconfiguration inbound
Finally, this last command returns the peer group configuration to the default value, disabling inbound soft-reconfiguration. The peer 10.19.7.8 inherits this value.
Example 2 For category C and D commands, the behavior of the no version of the command is the same as the behavior of the default version of the command. The following example illustrates this behavior and the inheritance concept for the neighbor timers command.
By default, the BGP global keepalive timer is 30 seconds and the global hold-time timer is 90 seconds.
host1(config-router)#neighbor eastcoast peer-group host1(config-router)#neighbor 10.10.21.23 peer-group eastcoast
Peer group eastcoast and peer 10.10.21.23 both have the default timer values. The peer group inherits the global timer values; the peer is a member of eastcoast and inherits the timer values from the peer group.
host1(config-router)#neighbor eastcoast timers 15 40
Now peer group eastcoast has a keepalive timer of 15 seconds and a hold-time timer of
40 seconds. Peer 10.10.21.23 inherits these values from the peer group.
host1(config-router)#no neighbor 10.10.21.23 timers
Now peer 10.10.21.23 has its timers reset to the global values of 30 and 90 seconds. The configuration of an individual peer takes precedence over the configuration of the peer group to which the peer belongs, which in turn takes precedence over the global configuration.
host1(config-router)#default neighbor 10.10.21.23 timers
Nothing changes. For commands in categories C and D, the behavior of the default version is the same as the no version. Peer 10.10.21.23 still has the global timer values.
host1(config-router)#neighbor eastcoast timers 20 20
The eastcoast peer group now has timer values of 20 seconds. Peer 10.10.21.23 still has the global timer values.
Limitations on Inheritance
All BGP peers that are members of the same peer group must send essentially the same updates. Accordingly, all members of a peer group must be the same kind of peer; that is, all must be internal peers, all must be external peers, or all must be confederation peers.
24 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Outbound policies configured for peer groups are still inherited by peer group members, but you cannot override this inherited outbound policy by configuring a different outbound policy on individual members of that peer group with the following commands:
Table 12: Commands That Do Not Override Inherited Outbound Policy
neighbor as-override neighbor next-hop-unchanged neighbor route-map out neighbor default-originate neighbor prefix-list out neighbor distribute-list out neighbor prefix-tree out neighbor filter-list out neighbor remove-private-as neighbor next-hop-self neighbor route-reflector-client neighbor send-community neighbor unsuppress-map
NOTE: This restriction does not apply to inbound policy, which you can still override per peer.
The update messages can vary for members of a peer group as follows:
• The next hop can be different for each update sent to peer group members if the members are all external peers.
•
The AS path can be different for each update sent to peer group members if the members are all external peers if you have enabled AS override with the neighbor as-override command.
Setting the BGP Identifier
By default, the router ID of the router is used as the BGP identifier. You can use the bgp router-id command to configure an IP address as the BGP identifier.
bgp router-id
•
Use to configure an IP address as the BGP identifier.
•
Example host1(config-router)#bgp router-id 10.25.1.1
•
The new BGP identifier is used in open messages sent after you issue the command.
To use the new BGP identifier for sessions already in the established state, you must use the clear ip bgp command to perform a hard clear.
•
Use the no version to restore the router ID as the BGP identifier.
•
See bgp router-id
Copyright © 2013, Juniper Networks, Inc.
25
JunosE 14.3.x BGP and MPLS Configuration Guide
Configuring Neighbors
Use the neighbor remote-as command to create a BGP peering session with a given BGP peer—identified by its IP address—in a given AS. Note that the neighbor remote-as command must be issued on both routers on either side of a BGP session for the BGP session to become established.
Consider the simple network structure shown in
Figure 10 on page 26 . Routers LA and
SanJose are IBGP peers within AS 873. Router SanJose has an EBGP peer, router Boston, in AS 17.
Figure 10: Configuring Neighbors
neighbor remote-as
The following commands configure router Boston with router SanJose as a peer: host1(config)#router bgp 17 host1(config-router)#neighbor 10.5.5.4 remote-as 873
The following commands configure router SanJose with router LA and router Boston as peers: host2(config)#router bgp 873 host2(config-router)#neighbor 10.2.2.3 remote-as 873 host2(config-router)#neighbor 10.5.5.1 remote-as 17
The following commands configure router LA with router SanJose as a peer: host3(config)#router bgp 873 host3(config-router)#neighbor 10.2.2.4 remote-as 873
•
Use to add an entry to the BGP neighbor table.
•
Specifying a neighbor with an AS number that matches the AS number specified in the router bgp command identifies the neighbor as internal to the local AS. Otherwise, the neighbor is treated as an external neighbor.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
This command takes effect immediately.
26 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
Use the no version to remove an entry from the table.
•
See neighbor remote-as
Configuring BGP Peer Groups
You will often want to apply the same policies to most or all of the peers of a particular
BGP speaker. Update policies are usually defined by route maps, filter lists, and distribution lists. You can reduce the configuration effort by defining a peer group made up of these peers.
A peer group is defined relative to a particular BGP speaker.
shows two peer groups, eastcoast and leftcoast. Each of these peer groups is defined for router
Chicago, the hub router. Routers Boston, NY, and Miami have no knowledge of being members of Router Chicago’s eastcoast peer group. Similarly, routers SanFran, LA, and
SanDiego have no knowledge of being members of router Chicago’s leftcoast peer group.
The following commands configure the eastcoast peer group on router Chicago: host1(config)#router bgp 23 host1(config)#route-map wtset permit 10 host1(config-route-map)#set weight 25 host1(config-route-map)#exit host1(config-router)#neighbor eastcoast peer-group host1(config-router)#neighbor eastcoast route-map wtset in host1(config-router)#neighbor 10.6.6.2 remote-as 12 host1(config-router)#neighbor 10.6.6.2 peer-group eastcoast host1(config-router)#neighbor 10.7.3.2 remote-as 12 host1(config-router)#neighbor 10.7.3.2 peer-group eastcoast host1(config-router)#neighbor 10.4.4.2 remote-as 12 host1(config-router)#neighbor 10.4.4.2 peer-group eastcoast
The following commands configure the leftcoast peer group on router Chicago: host1(config-router)#neighbor leftcoast peer-group host1(config-router)#neighbor 10.3.3.2 remote-as 78 host1(config-router)#neighbor 10.3.3.2 peer-group leftcoast host1(config-router)#neighbor 10.3.2.2 remote-as 2143 host1(config-router)#neighbor 10.3.2.2 peer-group leftcoast host1(config-router)#neighbor 10.3.1.2 remote-as 136 host1(config-router)#neighbor 10.3.1.2 peer-group leftcoast
The multiprotocol extensions to BGP enable the exchange of information within different types of address families. By default, peers and peer groups exist in the unicast IPv4 address family and exchange unicast IPv4 addresses. For information on configuring and activating BGP peer groups within address families, see
“Configuring the Address Family” on page 43
.
Copyright © 2013, Juniper Networks, Inc.
27
JunosE 14.3.x BGP and MPLS Configuration Guide
Figure 11: BGP Peer Groups
neighbor peer-group
•
Two versions of this command exist. Use to create a BGP peer group or to configure a
BGP neighbor to be a member of a peer group.
•
To create a BGP peer group, specify a peerGroupName for the new peer group. Use the no version to remove a peer group.
•
To assign members to a peer group, specify an ip-address and a peerGroupName of a
BGP neighbor that belongs to this group.
•
This command takes effect immediately.
•
Use the no version to remove a neighbor from a peer group.
•
See neighbor peer-group
NOTE: You cannot mix IPv4 and IPv6 peer members in a peer group. Only one type peer is allowed, IPv4 or IPv6. For example, the following error is generated if an IPv6 peer group member is added to a peer group that already has IPv4 members; that is, where the peer-group type is IPv4: host1(config-router)# neighbor 1::1 peer-group hamburg
% Unable to set 'peer-group' for address family ipv4:unicast for peer
1::1 in core (IPv6 peer cannot be member of a peer-group of type IPv4)
For information about the inheritance of configuration values by peer groups and peers, see
“Inheritance of Configuration Values” on page 21 .
Setting the Peer Type
Each peer group must have a peer type before any BGP sessions for members of that peer group are allowed to come up and before the Adj-RIBs-Out table of that peer group
28 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing can be filled. You can use the neighbor peer-type command to explicitly configure a peer type for a peer group.
Alternatively, you can implicitly configure the peer type of a peer group by either of the following methods:
•
Configure a remote AS for the peer group.
• Assign a peer with a configured remote AS as a member of the peer group.
In both of these implicit cases, the remote AS is combined with the local AS, the configured confederation ID, and the configured confederation peers to determine the peer type of the peer group.
neighbor peer-type
•
Use to specify a peer type for a peer group.
•
This command is supported only for peer groups; it is not available for individual peers.
•
Use the internal keyword to specify that peers must be in the same AS or, if confederations are employed, in the same sub-AS in the same confederation.
•
Use the external keyword to specify that peers must be in a different AS.
•
Use the confederation keyword to specify that peers must be in a different sub-AS in the same confederation. Use this keyword only if confederations are employed.
•
This command takes effect immediately. If the command changes the peer type of the peer group, all BGP sessions for members of that peer group are automatically bounced.
•
All the members of the peer group inherit the characteristic configured with this command. It cannot be overridden for a specific peer, because the command applies only to peer groups.
•
Example host1(config-router)#neighbor promispeers peer-type internal
•
Use the no version to remove the configuration from the peer group.
•
See neighbor peer-type
Assigning a Description
You can associate a description with a BGP neighbor or a peer group. This is a convenient way to store minimal pertinent information about the neighbor.
neighbor description
•
Use to associate a textual description of up to 80 characters with a BGP neighbor or peer group.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
Copyright © 2013, Juniper Networks, Inc.
29
JunosE 14.3.x BGP and MPLS Configuration Guide
•
This command takes effect immediately.
•
Example host1(config-router)#neighbor 10.11.0.5 description bostonmetropeer
•
Use the no version to remove the description.
•
See neighbor description
Logging Neighbor State Changes
You can force BGP to log a message whenever a peer enters or leaves the Established state.
bgp log-neighbor-changes
•
Use to log a notice message to the bgpNeighborChanges log when a neighbor enters or leaves the Established state for any reason.
•
The severity of the log message is notice by default.
•
Issue the log destination console severity notice command to display the messages on the console.
•
This command takes effect immediately.
•
Example host1:3(config)#bgp log destination console severity notice host1:3(config)#router bgp 100 host1:3(config-router)#bgp log-neighbor-changes
NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,4.4.4.4): peer 4.4.4.4 in core leaves established state
NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,5.5.5.5): peer 5.5.5.5 in core leaves established state
NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,6.6.6.6): peer 6.6.6.6 in core leaves established state
NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,13.13.13.1): peer 13.13.13.1 in core leaves established state
NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,4.4.4.4): peer 4.4.4.4 in core enters established state
NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,5.5.5.5): peer 5.5.5.5 in core enters established state
NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,6.6.6.6): peer 6.6.6.6 in core enters established state
NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,13.13.13.1): peer 13.13.13.1 in core enters established state
•
Use the no version to stop logging.
•
See bgp log-neighbor-changes
Specifying a Source Address for a BGP Session
By default, BGP uses the IP address of the outgoing interface toward the peer as the source IP address for the TCP connection over which the BGP session runs. If the outgoing
30 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing interface goes down, the BGP session is dropped because the IP source address is no longer valid. This is appropriate behavior for EBGP sessions because the EBGP peers typically can reach each other only by virtue of being connected to a common subnet.
For IBGP sessions, however, you typically want BGP sessions to be automatically rerouted around interfaces that are down. You can issue the neighbor update-source command to accomplish this. This command instructs BGP to use the IP address of a specified interface as the source address of the underlying TCP connection. Typically, a loopback interface is used because it is inherently stable.
For example, you can specify that BGP use loopback interface 2 as the source for messages that it sends to peer 192.50.30.1: host1(config)#neighbor 192.50.30.1 update-source loopback 2
neighbor update-source
•
Use to allow a BGP session to use the IP address of a specific operational interface as the source address for TCP connections.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
This command takes effect immediately and automatically bounces the BGP session.
•
If you specify an interface in this command and the interface is later removed, then this command is also removed from the router configuration.
•
Use the no version to restore the interface assignment to the closest interface.
•
See neighbor update-source
The source address that you specify with the neighbor update-source command is also used by BGP as the default value for the next hop address advertised for IPv4 or IPv6 prefixes.
The source addresses and next hop address that result from using the neighbor update-source command vary depending on the configuration of the command.
lists the results for different configurations.
Table 13: Source Addresses and Default Next Hop Addresses for Various Configurations
Configured Neighbor
Address
Configured Update
Source Address
Source Address used for TCPv4 and TCPv6
Connection
Default Next Hop
Value for IPv4
Prefixes
Default Next Hop
Value for IPv6
Prefixes
IPv4 neighbor address IPv4 source address IPv4 source address IPv4 source address
IPv4 neighbor address IPv6 source address Not allowed Not allowed
IPv4 source address mapped to an IPv6 address
Not allowed
Copyright © 2013, Juniper Networks, Inc.
31
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 13: Source Addresses and Default Next Hop Addresses for Various Configurations
(continued)
Configured Neighbor
Address
Configured Update
Source Address
Source Address used for TCPv4 and TCPv6
Connection
Default Next Hop
Value for IPv4
Prefixes
Default Next Hop
Value for IPv6
Prefixes
IPv4 neighbor address Interface name IPv4 address of the interface. If the interface does not have an IPv4 address, then the session does not come up.
IPv4 address of the interface
IPv6 address of the interface. If the interface does not have an IPv6 address, then the IPv4 address of the interface is mapped to an IPv6 address.
IPv6 neighbor address IPv6 source address
IPv6 neighbor address IPv4 source address
IPv6 neighbor address Interface name
IPv6 source address
Not allowed
0.0.0.0
Not allowed
IPv6 source address
Not allowed
IPv6 address of the interface. If the interface does not have an IPv6 address, then the session does not come up.
IPv4 address of the interface. If the interface does not have an IPv4 address, then
0.0.0.0.
IPv6 address of the interface
You can override a native IPv6 next-hop address with either the neighbor update-source command or an outbound route map.
When you specify an interface with the neighbor update-source command, the
IPv4-mapped IPv6 address of the interface is used instead of the native IPv6 address for the next hop.
host1(config)#interface loopback 0 host1(config-if)#ip address 10.1.1.1/32 host1(config-if)#exit host1(config)#router bgp 100 host1(config-router)#neighbor 2::2 update-source loopback 0
In this example, the IPv4-mapped IPv6 address of the loopback 0 interface is the next-hop address sent when IPv6 prefixes are advertised. However, if loopback 0 has an IPv6 address, then that address is used as the default next hop for advertising IPv6 prefixes.
Specifying Peers That Are Not Directly Connected
Normally, EBGP speakers are directly connected. When you cannot connect EBGP speakers directly, you can use the neighbor ebgp-multihop command to specify that the neighbor is more than one hop away. You generally need static routes to configure multihop connections. By default, the one-hop limitation per EBGP peers is enforced by the time-to-live attribute. You can override this default limit by using the ttl variable to specify the maximum number of hops to the peer.
In
Figure 12 on page 33 , router Boston and router LA are connected together through
router NY, rather than by a direct connection. Routers Boston and LA are configured as
32 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing external peers with the neighbor ebgp-multihop command because no direct connection exists between them. Because router NY is not a BGP speaker, static routes are configured on routers Boston and LA. The configuration for router NY is not shown, because it does not involve BGP.
Figure 12: Using EBGP-Multihop
neighbor ebgp-multihop
The following commands achieve the BGP configuration.
To configure router Boston: host1(config)#ip route 10.7.4.0 255.255.255.0 10.1.10.2
host1(config)#router bgp 100 host1(config-router)#neighbor 10.7.4.3 remote-as 300 host1(config-router)#neighbor 10.7.4.3 ebgp-multihop
To configure router LA: host2(config)#ip route 10.1.10.0 255.255.255.0 10.7.4.4
host2(config)#router bgp 300 host2(config-router)#neighbor 10.1.10.1 remote-as 100 host2(config-router)#neighbor 10.1.10.1 ebgp-multihop
•
Use to configure BGP to accept route updates from external peers in networks that are not directly connected to the local peer.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
Any external BGP peering that is not resolved by a connected route is treated as a multihop. Configurations with loopback-to-loopback external BGP peering require the neighbor ebgp-multihop command to work properly. In these configurations, the neighbor remote-as command is issued with the address of a loopback interface.
•
This command takes effect immediately and automatically bounces the BGP session.
•
Use the no version to return BGP to halt acceptance of such routers. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor ebgp-multihop
Copyright © 2013, Juniper Networks, Inc.
33
JunosE 14.3.x BGP and MPLS Configuration Guide
Specifying a Single-Hop Connection for IBGP Peers
IBGP peers are multihop by default. However, you can use the neighbor ibgp-single-hop command to enable single-hop connections for IBGP peers.
neighbor ibgp-singlehop
•
Use to specify an internal BGP peer as a single-hop peer for IBGP sessions.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
If the neighbor session type is anything other than internal BGP, issuing this command generates an error message.
•
This command takes effect immediately and automatically bounces the BGP session.
•
Example host1(config-router)#neighbor 192.168.32.15 ibgp-singlehop
•
Use the no version to restore the default behavior, wherein the internal peer cannot be a single-hop peer. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor ibgp-singlehop
Controlling the Number of Prefixes
As the routing table increases in size, the processor and memory resources required to process routing information increases. Some peers send so much routing information that a BGP speaker can be overwhelmed by the updates. You can use the neighbor maximum-prefix command to limit how many prefixes can be received from a neighbor.
The router resets the BGP connection when the specified maximum is exceeded. You can use the warning-only keyword to log a warning rather than reset the connection.
You can also configure the router so that a warning is logged when a specified percentage of the maximum is exceeded.
In the following example, the router is configured to reset the BGP connection when it receives more than 1,000 prefixes from its neighbor at 2.2.2.2: host1(config)#router bgp 100 host1(config-router)#neighbor 2.2.2.2 maximum-prefix 1000
neighbor maximum-prefix
•
Use to control how many prefixes can be received from a neighbor.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
By default, BGP checks the maximum prefix limit only against accepted routes. You can specify the strict keyword to force BGP to check the maximum prefix against all
34 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing received routes. The accepted and received routes will likely differ when you have configured inbound soft reconfiguration and route filters for incoming traffic.
•
This command takes effect immediately. To prevent a peer from continually flapping, when it goes to state idle because the maximum number of prefixes has been reached, the peer stays in state idle until you use the clear ip bgp command to issue a hard clear.
•
Use the no version to remove the maximum number of prefixes.
•
See neighbor maximum-prefix
Removing Private AS Numbers from Updates
You might choose to conserve AS numbers by assigning private AS numbers to some customers. You can assign private AS numbers from the range 64,512 to 65,535. However, when BGP advertises prefixes to other ISPs, it is undesirable to include the private AS numbers in the path. Configure the external neighbors to drop the numbers with the neighbor remove-private-as command.
neighbor remove-private-as
•
Use to remove private AS numbers only in updates sent to external peers.
•
All private AS numbers are removed regardless of their position in the AS-path attribute and regardless of the presence of public AS numbers.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override the characteristic for a specific member of the peer group.
•
Example host1(config-router)#neighbor 10.10.128.52 remove-private-as
•
New policy values are applied to all routes that are sent (outbound policy) or received
(inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
•
Use the no version to halt the removal of private AS numbers in updates sent to external peers. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor remove-private-as
Copyright © 2013, Juniper Networks, Inc.
35
JunosE 14.3.x BGP and MPLS Configuration Guide
Checking AS-Path Length
You can use the bgp maxas-limit command to prevent the forwarding of routes having
AS paths longer than a specified limit.
bgp maxas-limit
•
Use to require BGP to check the AS path in all received update messages.
•
If a received AS path is longer than the specified limit:
•
The route is stored in the BGP routing table and therefore is displayed by the show ip bgp commands.
•
The route is not a candidate for being selected as a best path, is not stored in the forwarding information base, and is not propagated to external or internal peers.
•
Changes in the limit do not affect routes previously received. Clearing the BGP sessions
(clear ip bgp) forces a resend of all routes; the new limits are then applied on receipt of the routes.
•
Example host1(config-router)#bgp maxas-limit 42
•
Causes BGP to check the AS path of all routes received after you issue the command.
To apply the new behavior to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
•
Use the no version to halt checking of received AS-Path lengths.
•
See bgp maxas-limit
If you use the fields as-path option with the show ip bgp command, the display indicates routes whose AS path exceeds the limit. The following display illustrates the result of setting the AS-Path length limit to 5: host1:3# show ip bgp fields intro best peer loc-pref as-path
Local router ID 13.13.13.3, local AS 200
10 paths, 5 distinct prefixes (520 bytes used)
6 paths selected for route table installation
14 path attribute entries (1943 bytes used)
Status codes: > best
Prefix Peer LocPrf AS-path
10.23.40.1/32 192.168.13.1 200 100 211 32 15 67 44 (too long)
> 10.23.40.1/32 172.123.23.2 100 100 211
> 10.23.40.2/32 192.168.13.1 200 100 211 32 15 67
10.23.40.2/32 172.123.23.2 100 100 211 32
> 10.23.40.3/32 192.168.13.1 100 211 32 15
10.23.40.3/32 172.123.23.2 100 211 32 15
10.23.40.4/32 192.168.13.1 100 100 211 32
> 10.23.40.4/32 172.123.23.2 200 100 211 32 15 67
> 10.23.40.5/32 192.168.13.1 100 100 211
10.23.40.5/32 172.123.23.2 200 100 211 32 15 67 44 (too long)
36 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Enabling MD5 Authentication on a TCP Connection
You can use the neighbor password command to enable MD5 authentication on a TCP connection between two BGP peers. Enabling MD5 authentication causes each segment sent on the TCP connection between them to be verified.
You must configure MD5 authentication with the same password on both BGP peers; otherwise, the router does not make the connection between the BGP peers.
The MD5 authentication feature uses the MD5 algorithm. When you specify this command, the router generates and checks the MD5 digest on every segment sent on the TCP connection.
In the following example, the password is set to “ opensesame” : host1(config)#router bgp 100 host1(config-router)#neighbor 2.2.2.2 password opensesame
The show ip bgp neighbors command does not reveal the password, but does indicate whether MD5 authentication is configured for the session. The output of the show configuration command varies as follows:
• If you use the 8 keyword to specify that the password is encrypted, then the output of the show configuration command displays the text that you entered (the ciphertext password).
• If you do not use the 8 keyword (that is, you use the 0 keyword or no encryption keyword), and if the service password-encryption command has not been issued, then the output of the show configuration command displays the text that you entered
(the plaintext password).
• If you do not use the 8 keyword (that is, you use the 0 keyword or no encryption keyword) but the service password-encryption command has been issued, then the output of the show configuration command displays an encrypted password that is equivalent to the cleartext password that you entered.
neighbor password
•
Use to enable MD5 authentication on a TCP connection between two BGP peers.
•
If you configure a password for a neighbor, an existing session is torn down and a new one established.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
If a router has a password configured for a neighbor, but the neighbor router does not, a message indicating this condition appears on the console while the routers attempt to establish a BGP session between them.
•
Similarly, if the two routers have different passwords configured, a message appears on the console indicating that this condition exists.
Copyright © 2013, Juniper Networks, Inc.
37
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Use the 8 keyword to indicate that the password is encrypted (entered in ciphertext).
Use the 0 keyword to indicate that the password is unencrypted (entered in plaintext).
•
This command takes effect immediately and automatically bounces the BGP session.
•
Use the no version to disable MD5 authentication.
•
See neighbor password
Setting the Maximum Size of Update Messages
You can use the neighbor maximum-update-size command to set the maximum size of update messages transmitted to a BGP peer.
For example, to set the maximum update size to 2,000 octets: host1(config)#router bgp 100 host1(config-router)#neighbor 10.12.2.5 maximum-update-size 2000
neighbor maximum-update-size
•
Use to set the maximum size for transmitted BGP update messages.
•
Set the maximum-update-size to a range: 256–4096.
•
The default is 1024 octets.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
BGP always accepts updates of up to 4096 octets, regardless of the setting for transmitted updated messages.
•
Applies to all update messages sent after you issue the command.
•
Use the no version to restore the default value.
•
See neighbor maximum-update-size.
Setting Automatic Fallover
You can use the bgp fast-external-fallover command to specify that in the event of the failure of a link to any adjacent external peer, the BGP session is immediately and automatically brought down rather than waiting for the TCP connection to fail or for the hold timer to expire.
bgp fast-external-fallover
•
Use to immediately bring down a BGP session if the link to an adjacent external peer fails.
•
If you do not issue this command, the BGP session is not brought down in the event of a link failure until the TCP connection fails or the hold timer expires.
•
This command takes effect immediately.
38 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
Use the no version to stop automatically bringing down the session in the event of link failure.
•
See bgp fast-external-fallover.
Setting Timers
neighbor timers timers bgp
BGP uses a keepalive timer to control the interval at which keepalive messages are sent.
A hold-time timer controls how long BGP waits for a keepalive message before declaring a peer not available.
BGP negotiates the hold time with each neighbor when establishing the BGP connection.
The peers use the lower of the two configured hold times. BGP sets the keepalive timer based on this negotiated hold time and the configured keepalive time.
•
Use to set the keepalive and hold-time timers for the specified neighbor or peer group.
•
Overrides timer values set with the timers bgp command.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
If you set the keepalive timer to 0, BGP does not send any keepalive messages.
•
If you do not expect the peer to send any keepalives, set the hold-time timer to 0.
•
This command takes effect immediately and automatically bounces the session to force BGP to send a new open message to renegotiate the new timer values.
•
Example host1(config-router)#neighbor 192.168.21.5 timers 90 240
•
Use the no version to restore the default values on the specified neighbor or peer group—30 seconds for the keepalive timer and 90 seconds for the hold-time timer.
•
See neighbor timers.
•
Use to set the keepalive and hold-time timers for all neighbors.
•
If you set the keepalive timer to 0, BGP does not send any keepalive messages.
•
If you do not expect the peer to send any keepalives, set the hold-time timer to 0.
•
Example host1(config-router)#timers bgp 75 300
•
The new timer values are used by every session that comes up after you issue the command; timers configured specifically for the sessions take precedence over these values.
To force sessions that are already established to use the new timer values, you must use the clear ip bgp command to perform a hard clear.
Copyright © 2013, Juniper Networks, Inc.
39
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Use the no version to restore the default values on all neighbors—30 seconds for the keepalive timer and 90 seconds for the hold-time timer.
•
See timers bgp.
Automatic Summarization of Routes
By default, all routes redistributed into BGP from an IGP are automatically summarized to their natural network masks.
auto-summary
•
Use to reenable automatic summarization of routes redistributed into BGP.
•
Automatic summarization is enabled by default. However, creating an address family for a VRF automatically disables automatic summarization for that address family.
•
This command takes effect immediately.
•
Use the no version to disable automatic summarization of redistributed routes.
•
See auto-summary.
Administrative Shutdown
You can administratively shut down particular BGP neighbors or peer groups without removing their configuration from BGP by using the neighbor shutdown command.
You can also administratively shut down BGP globally by using the bgp shutdown command.
bgp shutdown
•
Use to shut down BGP globally.
•
This command takes effect immediately.
•
Example host1(config-router)#bgp shutdown
•
Use the no version to reenable BGP.
•
See bgp shutdown.
neighbor shutdown
•
Use to shut down a neighbor or peer group without removing their configuration.
•
This command takes effect immediately.
•
Use the no version to reenable a neighbor or peer group that was previously shut down.
Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor shutdown.
40 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Configuring BGP for Overload Conditions
You can specify how you want BGP to behave when it is running out of memory in an overload condition. You can have BGP either shut itself down or continue running; in the latter case, BGP performance might be altered because of the lack of resources.
overload shutdown
•
Use to shut down BGP if it runs out of memory.
•
The default behavior is for BGP to transition from the Up state to the Overload state and continue running.
•
This command takes effect immediately.
•
Example host1(config-router)#overload shutdown
•
Use the no version to restore the default behavior.
•
See overload shutdown.
The following partial outputs show how the BGP state is indicated by the show ip bgp summary command: host1# show ip bgp summary
Local router ID 10.1.0.1, local AS 1
Administrative state is Start
Operational state is Overload
Shutdown in overload state is disabled
Default local preference is 100
...
host1# show ip bgp summary
Local router ID 10.1.0.1, local AS 1
Administrative state is Start
Operational state is Down due to transition from Overload state
Shutdown in overload state is enabled
Default local preference is 100
...
Enabling Route Storage in Adj-RIBs-Out Tables
By default, a BGP speaker does not store a copy of each route it sends to a BGP peer in the Adj-RIBs-Out table for that peer. However, you can force BGP to store a copy of routes in the Adj-RIBs-Out table for a particular peer or peer group by enabling that
Adj-RIBs-Out table (“ enabling rib-out” ) with the no neighbor rib-out disable command.
Alternatively, you can use the no rib-out disable command to affect all BGP peers. The details of route storage vary between peers and peer groups.
For peers, BGP stores a single bit with each route in the table to indicate whether it has previously advertised the route to the peer, enabling the avoidance of spurious withdrawals. The full set of attributes for each route is not stored in the peer Adj-RIBs-Out table.
After enabling rib-out for a peer, you can issue the show ip bgp neighbors advertised-routes command to display the routes that have been advertised to the peer.
Copyright © 2013, Juniper Networks, Inc.
41
JunosE 14.3.x BGP and MPLS Configuration Guide
The attributes displayed for the routes are those from the local routing table, not those that were advertised. In other words, BGP stores the attributes prior to the application of any outbound policy.
For peer groups, BGP stores the full set of attributes associated with the route after the application of any outbound policy; that is, it stores the attributes as they will be advertised. BGP does not store a bit to track whether a route was advertised to the peer group. Storing the full attribute set for each peer group route is memory intensive but acceptable for peer groups, because the number of peer groups is relatively small. An advantage of enabling rib-out for peer groups is that convergence is accelerated because the attributes for each route are already determined for all routes to be advertised to the peer group. BGP has to apply outbound policy only once for each route rather than once for each peer for each route.
After enabling rib-out for a peer group, you can issue the show ip bgp advertised-routes command to display the routes that will be advertised to the peer group and the attributes
(after the application of any outbound policy) that will be advertised with the routes.
When you have enabled rib-out for individual peers or a peer group, before sending an advertisement or withdrawal the router compares the route it is about to send with the last route sent for the same prefix (and stored in the Adj-RIBs-Out table for the peer or peer group) and sends the update message only if the new information is different from the old.
The comparison prevents the sending of unnecessary withdrawals for both peers and peer groups, because the BGP speaker will not send a withdrawal if the table indicates it has not previously advertised that route to the peer. However, because the route attributes are no longer stored with the routes in peer Adj-RIBs-Out tables, BGP cannot compare them with the attributes in the new update message. Consequently, BGP cannot determine whether the update contains new attributes or the same attributes as those previously advertised, and might send superfluous advertisements to peers. This circumstance does not happen for peer groups, because their Adj-RIBs-Out tables store the full attribute set.
Effects of Changing Outbound Policies
After you change the outbound policy for a peer or peer group, the policy changes do not take effect until you issue either a hard clear or an outbound soft clear. (See
“Resetting a BGP Connection” on page 96
for information about performing clears with the clear ip bgp command.) The clear action causes BGP to reapply the outbound policy of the peer or peer group to each route in the BGP routing table. BGP then stores the results in the
Adj-RIBs-Out table for that peer or peer group. The BGP session with each peer or peer group member takes the routes from the appropriate Adj-RIBs-Out table and sends them in update messages to the peer or peer group member.
NOTE: You cannot change outbound policy for an individual peer group member. You can change outbound policy only for a peer group as a whole or for peers that are not members of a peer group.
42 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
neighbor rib-out disable
•
Use to disable storage of routes (disable rib-out) in the specified neighbor’s
Adj-RIBs-Out table or in a single Adj-RIBs-Out table for the entire specified peer group.
•
Route storage is disabled by default.
•
If you enable storage for a peer, the peer’s Adj-RIBs-Out table contains all routes actually sent to the peer. By contrast, if you enable storage for a peer group, the peer group’s Adj-RIBs-Out table contains those routes that the BGP speaker intends to send to the peer group members; individual members might or might not have already received updates that advertise the routes.
•
If you specify a BGP peer group by using the peerGroupName argument, a single
Adj-RIBs-Out table is enabled for the entire peer group. You can override this configuration for a member of the peer group by issuing the command for that peer.
•
Limit the number of Adj-RIBs-Out tables to no more than ten for peer groups to conserve memory resources. No limit applies to peers.
•
This command takes effect immediately and automatically bounces the BGP session(s) if the command changes the current configuration.
•
Example host1(config-router)#no neighbor 10.15.24.5 rib-out disable
•
Use the no version to enable the route storage. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor rib-out disable.
rib-out disable
•
Use to disable storage of routes in the Adj-RIBs-Out tables (disable rib-out) for all
BGP peers.
•
Route storage is disabled by default.
•
This command takes effect immediately and automatically bounces the BGP session if the command changes the current configuration.
•
Example host1(config)#rib-out disable
•
Use the no version to enable the route storage. Use the default version to remove the explicit global configuration from all peers and reestablish inheritance of the feature configuration.
•
See rib-out disable.
Configuring the Address Family
The BGP multiprotocol extensions specify that BGP can exchange information within different types of address families. The JunosE BGP implementation defines the following different types of address families:
Copyright © 2013, Juniper Networks, Inc.
43
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Unicast IPv4—If you do not explicitly specify the address family, the router is configured to exchange unicast IPv4 addresses by default. You can also configure the router to exchange unicast IPv4 routes in a specified VRF.
•
Multicast IPv4—If you specify the multicast IPv4 address family, you can use BGP to exchange routing information about how to reach a multicast source instead of a unicast destination. For information about BGP multicasting commands, see
“Configuring BGP Routing” on page 3
. For a general description of multicasting, see
JunosE Multicast Routing Configuration Guide.
•
VPN IPv4—If you specify the VPN-IPv4 (also known as VPNv4) address family, you can configure the router to provide IPv4 VPN services over an MPLS backbone. These
VPNs are often referred to as BGP/MPLS VPNs. For detailed information, see
“Configuring BGP-MPLS Applications” on page 389 .
•
Unicast IPv6—If you specify the IPv6 unicast address family, you can configure the router to exchange unicast IPv6 routes or unicast IPv6 routes in a specified VRF. For a description of IPv6, see JunosE IP, IPv6, and IGP Configuration Guide.
•
Multicast IPv6—If you specify the multicast IPv6 address family, you can use BGP to exchange routing information about how to reach an IPv6 multicast source instead of an IPv6 unicast destination. For a general description of multicasting, see JunosE
Multicast Routing Configuration Guide.
•
VPN IPv6—If you specify the VPN-IPv6 address family, you can configure the router to provide IPv6 VPN services over an MPLS backbone. These VPNs are often referred to as BGP/MPLS VPNs.
• L2VPN—If you specify the L2VPN address family, you can configure the PE router for
VPLS L2VPNs or VPWS L2VPNs to exchange layer 2 network layer reachability information (NLRI) for all VPLS or VPWS instances. Optionally, you can use the signaling keyword with the address-family command for the L2VPN address family to specify BGP signaling of L2VPN reachability information. Currently, you can omit the signaling keyword with no adverse effects. For a description of VPLS, see
“Configuring VPLS” on page 609
. For a description of VPWS, see
“Configuring VPWS” on page 673 .
• Route-target—If you specify the route-target address family, you can configure the router to exchange route-target membership information to limit the number of routes redistributed among members. For a description of route-target filtering, see
“Configuring BGP-MPLS Applications” on page 389 .
• VPLS—If you specify the VPLS address family, you can configure the router to exchange layer 2 NLRI for a specified VPLS instance. For a description of VPLS, see
“Configuring VPLS” on page 609
.
• VPWS—If you specify the VPWS address family, you can configure the PE router to exchange layer 2 NLRI for a specified VPWS instance. For a description of VPWS, see
“Configuring VPWS” on page 673 .
Any command issued outside the context of an address family applies to the unicast
IPv4 address family by default.
44 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
address-family
To limit the exchange of routes to those from within the address family and to set other desired BGP parameters:
1.
Access Router Configuration mode and create peers and peer groups. These peers and peer groups are in the default IPv4 address family.
host1(config)#router bgp 100 host1(config-router)#neighbor 10.10.2.2 remote-as 100 host1(config-router)#neighbor 10.10.3.3 remote-as 100 host1(config-router)#neighbor ibgp peer-group
2.
In Router Configuration mode, create the address family within which the router exchanges addresses; this creation accesses Address Family Configuration mode.
host1(config-router)#address-family vpn4 unicast
3.
From within the address family, activate individual neighbors or peer groups to exchange routes from within the current address family. These peers or peer groups must first be created in the IPv4 address family.
host1(config-router-af)#neighbor ibgp activate
4.
If you have activated a peer group, from within the address family add peers as members of the peer group. These peers must first be created in the IPv4 address family.
host1(config-router-af)#neighbor 10.10.2.2 peer-group ibgp host1(config-router-af)#neighbor 10.10.3.3 peer-group ibgp
5.
From within the address family, configure BGP parameters for the address family.
6.
Exit Address Family Configuration mode.
host1:vr1(config-router-af)#exit-address-family
•
Use to configure the router or VRF to exchange IPv4 or IPv6 addresses by creating the specified address family.
•
IPv4 and IPv6 addresses can be exchanged in unicast, multicast, or VPN mode.
•
The default setting is to exchange IPv4 addresses in unicast mode from the default router.
•
Creating an address family for a VRF automatically disables both synchronization and automatic summarization for that VRF.
•
This command takes effect immediately.
•
Examples host1:vr1(config-router)#address-family ipv4 multicast host1:vr1(config-router)#address-family ipv4 unicast host1:vr1(config-router)#address-family ipv4 unicast vrf vr2 host1:vr1(config-router)#address-family vpn4 unicast host1:vr1(config-router)#address-family ipv6 unicast
•
Use the no version to disable the exchange of a type of prefix.
•
See address-family.
Copyright © 2013, Juniper Networks, Inc.
45
JunosE 14.3.x BGP and MPLS Configuration Guide
bgp default ipv4-unicast
•
Use to configure all neighbors to exchange addresses in the IPv4 unicast address family.
•
All neighbors must be activated with the neighbor activate command in the IPv4 address family.
•
Example host1:vr1(config-router)#bgp default ipv4-unicast
•
Affects only neighbors created after you issue the command. To affect existing neighbors created before you issued the command, you must use the neighbor activate command in the context of the IPv4 unicast address family.
•
Use the no version to disable the exchange of IPv4 addresses on all neighbors.
•
See bgp default ipv4-unicast.
exit-address-family
•
Use to exit Address Family Configuration mode and access Router Configuration mode.
•
Example host1:vr1(config-router-af)#exit-address-family
•
There is no no version.
•
See exit-address-family.
neighbor activate
•
Use to specify a peer or peer group with which routes of the current address family are exchanged.
•
A peer or peer group can be activated in more than one address family. By default, a peer is activated only for the IPv4 unicast address family.
•
The peer or peer group must be created in unicast IPv4 before you can activate it in another address family.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
The address families that are actively exchanged over a BGP session are negotiated when the session is established.
•
This command takes effect immediately. If dynamic capability negotiation was not negotiated with the peer, the session is automatically bounced so that the exchanged address families can be renegotiated in the open messages when the session comes back up.
If dynamic capability negotiation was negotiated with the peer, BGP sends a capability message to the peer to advertise or withdraw the multiprotocol capability for the address family in which this command is issued. If a neighbor is activated, BGP also sends the full contents of the BGP routing table of the newly activated address family.
•
Example
46 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing host1:vr1(config-router-af)#neighbor 192.168.1.158 activate
•
Use the no version to indicate that routes of the current address family are not to be exchanged with the peer. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor activate.
If you have configured some or all neighbors to be in the multicast or VPN-IPv4 address families, you can quickly configure all neighbors to be part of the IPv4 unicast address family by issuing the bgp default ipv4-unicast command.
Enabling Lenient Behavior
You can use the neighbor lenient command to enable the BGP speaker to attempt to recover from malformed packet errors and finite state machine errors generated by a peer. If BGP can recover from the error, it logs a warning message and attempts to maintain the session with the peer. The normal, nonlenient behavior is for the BGP speaker to send a notification message to the peer generating the error and to terminate the session. By default, lenient behavior is disabled.
neighbor lenient
•
Use to enable a BGP speaker to be more tolerant of some errors generated by a peer, such as malformed BGP messages or finite state machine errors.
•
The speaker attempts to recover from the errors and avoid bringing down the BGP session with the peer.
•
Lenient behavior is disabled by default.
•
Example host1(router-config)#neighbor 10.12.45.23 lenient
•
Use the no version to restore the default condition, disabling lenient behavior.
•
See neighbor lenient.
Configuring Promiscuous Peers and Dynamic Peering
You can use the neighbor allow command to enable a peer group to accept incoming
BGP connections from any remote address that matches an access list. Such a peer group is known as a promiscuous peer group; the member peers are sometimes referred to as promiscuous peers.
Promiscuous peers are useful when the remote address of the peer is not known ahead of time. An example is in B-RAS applications, in which interfaces for subscribers are created dynamically and the remote address of the subscriber is assigned dynamically from a local pool or by using RADIUS or some other method.
BGP automatically creates a dynamic peer when a peer group member accepts the incoming BGP connection. Dynamic peers are passive, meaning that when they are not in the established state, they will accept inbound connections but they will not initiate
Copyright © 2013, Juniper Networks, Inc.
47
JunosE 14.3.x BGP and MPLS Configuration Guide outbound connections. You cannot configure any attributes for the dynamic peers. You cannot remove a dynamic peer with the no neighbor ip-address command.
When a dynamic peer goes from the established state to the idle state for any reason,
BGP removes the dynamic peer only if it does not go back to the established state within
1 minute. This delay enables you to see the dynamic peer in show command output; for example, you might want to see the reason for the last reset or how many times the session flapped.
While a dynamic peer is not in the established state, the show ip bgp neighbor command displays the number of seconds remaining until the dynamic peer will be removed.
If you have configured the neighbor allow command for multiple peer groups, when an incoming BGP connection matches the access list of more than one of these peer groups, the dynamic peer is created only in the first peer group. (BGP orders peer groups alphabetically by name.)
When the BGP speaker receives an open message from a dynamic peer, the remote AS number must match one of the following criteria; the connection is closed if it does not:
• If the peer group has a configured remote AS number, then the received AS number must be the same as the configured remote AS number.
•
If the peer group does not have a configured AS number, then the received AS number must be consistent with the peer type of the peer group. Use the neighbor peer-type command to configure the type of the peer-group.
If a peer group has been configured with a peer type but not a remote AS, then the remote
AS for dynamic peers is not known until an open message has been received from the peer. Until then, show commands display the remote AS as “ ?” or “ unknown.”
Static peers that you configure with the neighbor remote-as or neighbor peer-group commands take precedence over the dynamic peers created as a result of the neighbor allow command. If the remote address of an incoming BGP connection matches both a static peer and the access list, the static peer is used and no dynamic peer is created. If you configure a new static peer while a dynamic peer for the same remote address already exists, BGP automatically removes the dynamic peer.
You can optionally specify the maximum number of dynamic peers that BGP can create for the peer group. There is no default maximum. In the absence of a specified maximum, the number of dynamic peers allowed is determined by the available memory and CPU.
Dynamic peers consume about the same resources as static peers.
When the maximum number of dynamic peers has been created for a peer group, BGP rejects all subsequent connection attempts for that group. This behavior means that you can specify a maximum to help protect against denial-of-service attacks that attempt to create many dynamic peers to overwhelm your router resources.
BGP generates a log message whenever a dynamic peer is created, rejected because the maximum has been reached, or removed. BGP maintains counters for each peer group for the current number of dynamic peers, the highest number of concurrent dynamic
48 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing peers ever reached, and the number of times a dynamic peer was rejected because the maximum was reached.
Because dynamic peers always fully inherit their configuration from a peer group, any features that are available for peers but not for peer group members are not supported for the dynamic peers. Currently, only ORFs are not supported for peer group members and therefore are not supported for dynamic peers.
clear bgp ipv6 dynamic-peers clear ip bgp dynamic-peers
•
Use to remove all dynamic peers in the specified scope.
•
You can specify the IP address of a BGP neighbor or the name of a BGP peer group as the scope. For IPv4 only, you can also include a VRF in the scope.
•
Use the asterisk (*) to remove all BGP dynamic peers.
•
This command takes effect immediately.
•
Example host1#clear ip bgp 192.168.1.158 vrf boston5 dynamic-peers
•
There is no no version.
•
See clear bgp ipv6 dynamic-peers.
•
See clear ip bgp dynamic-peers.
neighbor allow
•
Use to configure a peer group to accept incoming BGP connections from any remote address that matches the specified access list.
•
When the BGP connection is accepted, a dynamic peer is automatically created.
•
This command is supported only for peer groups; it is not available for individual peers.
These dynamic peers are not displayed by the show configuration command and are not stored in NVS. However, the dynamic peers are displayed by show commands that display information about BGP peers, such as show ip bgp neighbors, show ip bgp summary, and so on.
•
Incoming connections that match the specified access list are rejected if no peer type has been configured for the peer group.
•
This command takes effect immediately. Any existing dynamic BGP sessions that are no longer allowed by the new configuration are removed automatically and immediately.
Preexisting dynamic peers that are still allowed by the new configuration are not affected.
•
All the members of the peer group inherit the characteristic configured with this command. It cannot be overridden for a specific peer, because the command applies only to peer groups.
•
Example host1(config-router)#neighbor promispeers allow remotelist1 max-peers 1023
Copyright © 2013, Juniper Networks, Inc.
49
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Use the no version to remove the configuration from the peer group.
•
See neighbor allow.
Configuring Passive Peers
You can configure BGP to be passive regarding specific peers, meaning that the BGP speaker will accept inbound BGP connections from the peers but will never initiate an outbound BGP connection to the peers. This passive status conserves CPU and TCP connection resources when the neighbor does not exist.
For example, suppose you preprovision a router before installation with a large number of customer circuits to minimize the configuration changes you might have to make to the router. Any peers that do not exist will consume resources as BGP repeatedly attempts to establish a session with them.
If instead you initially configure the router as passive for those peers, BGP will not attempt to establish sessions to those peers but will wait until these remote peers initiate a session, thus conserving CPU resources.
If you configure both sides of a BGP session as passive, then the session can never come up because neither side can initiate the connection.
neighbor passive
•
Use to configure the BGP speaker to only accept inbound BGP connections from the specified peer and never initiate outbound connections to that peer.
•
This command takes effect immediately. If the session is not yet established, BGP immediately stops initiating outbound connections to the peer. If the session is already established, it is not bounced regardless of which side initiated the connection.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
Example host1(config-router)#neighbor 10.12.3.5 passive
•
Use the no version to restore the default condition, permitting the initiation of outbound connections to the peer.
•
See neighbor passive.
Advertising Routes
Each BGP speaker advertises to its peers the routes to prefixes that it can reach. These routes include:
• Routes to prefixes originating within the speaker’s AS
• Routes redistributed from another protocol, including static routes
50 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
By default, BGP does not advertise any route unless the router’s IP routing table also contains the route.
Prefixes Originating in an AS
Use the network command to configure a router with the prefixes that originate within its AS. Thereafter the router advertises these configured prefixes with the origin attribute set to IGP. See
“Understanding the Origin Attribute” on page 115
for more information about origins.
shows a network structure of three autonomous systems, each with a router that originates certain prefixes.
Figure 13: Prefixes Originating in an AS
network
The following commands configure router NY: host1(config)#router bgp 300 host1(config-router)#neighbor 10.2.25.1 remote-as 100 host1(config-router)#neighbor 10.4.4.1 remote-as 400 host1(config-router)#network 192.168.33.0 mask 255.255.255.0
The following commands configure router Boston: host2(config)#router bgp 100 host2(config-router)#neighbor 10.2.25.2 remote-as 300 host2(config-router)#neighbor 10.3.3.1 remote-as 400 host2(config-router)#network 172.19.0.0
Notice that a mask was not specified for the prefix originating with router Boston. The
natural mask is assumed for networks without a mask.
The following commands configure router LA: host3(config)#router bgp 400 host3(config-router)#neighbor 10.3.3.2 remote-as 100 host3(config-router)#neighbor 10.4.4.2 remote-as 300 host3(config-router)#network 172.28.8.0 mask 255.255.248.0
•
Use to specify the prefixes in its AS that the BGP speaker advertises.
•
BGP advertises the specified prefix only if a non-BGP route to the prefix exists in the
IP forwarding table. If the non-BGP route does not exist when you issue the network
Copyright © 2013, Juniper Networks, Inc.
51
JunosE 14.3.x BGP and MPLS Configuration Guide command, then BGP is notified as soon as the route becomes available in the IP routing table or IP tunnel routing table.
•
For IPv4 addressing, specify a network-number and an optional network-mask. For IPv6 addressing, specify the IPv6 prefix.
•
You can specify a route map to filter network routes or modify their path attributes.
•
The default weight for network routes is 32768; use the weight keyword to modify the weight in the range 0–65535.
•
Use the backdoor keyword to lower the preference of an EBGP route to the specified prefix by setting the administrative distance to that of an internal BGP route, 200. Use this option to favor an IGP backdoor route over an EBGP route to a specific network.
BGP does not advertise the specified network. See
“Configuring Backdoor Routes” on page 138
for more information.
•
The next hop for the network is the next hop for the route contained in the routing table.
•
This command takes effect immediately.
•
Use the no version to remove the prefix.
•
See network.
Advertising Best Routes
By default, BGP selects from its routing table one best route to each destination. If BGP learned that best route from an internal peer, then the BGP speaker does not advertise a route to that destination to the speaker’s internal peers.
In earlier software releases, the default behavior was for BGP to select two best routes to any destination. The best route learned from external (including confederation) peers was advertised to the speaker’s internal peers. The best route learned from all sources was advertised to the speaker’s external peers.
You can issue the bgp advertise-external-to-internal command to cause BGP to revert to advertising two potentially different routes to its peers. See
“Selecting the Best Path” on page 104
for information about the process BGP uses to determine best routes.
bgp advertise-best-external-to-internal
•
Use to cause BGP to select two best routes to every destination as follows:
•
For external peers, BGP selects the best route from the complete set of routes known to BGP.
•
For internal peers, BGP selects the best route from the set of routes BGP has received from external and confederation peers.
•
Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix.
•
The behavior enabled by this command is the default behavior for the E Series router running software releases lower than 5.0.0.
52 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
The command is disabled by default.
•
Example host2(config-router)#bgp advertise-best-external-to-internal
•
Use the no version to restore the default condition, wherein BGP selects one best route for each destination from the complete set of routes; if the best route was received from an internal peer, no route to the destination is advertised to the internal peers.
•
See bgp advertise-best-external-to-internal.
Redistributing Routes into BGP
BGP can learn about routes from sources other than BGP updates from peers. Routes known to other protocols can be redistributed into BGP. Similarly, routes manually configured on a router—static routes—can be redistributed into BGP. After the routes are redistributed, BGP advertises the routes. When you redistribute routes, BGP sets the origin attribute for the route to Incomplete. See
“Understanding the Origin Attribute” on page 115
for more information about origins.
The following commands configure three static routes on router Boston and configure router Boston to redistribute the static routes and routes from OSPF into BGP for the network structure shown in
: host2(config)#ip route 172.30.0.0 255.255.0.0 192.168.10.12
host2(config)#ip route 172.16.8.0 255.255.248.0 10.211.5.7
host2(config)#ip route 192.168.4.0 255.255.254.0 10.14.147.2
host2(config)#router bgp 29 host2(config-router)#neighbor 10.1.1.2 remote-as 92 host2(config-router)#redistribute static host2(config-router)#redistribute ospf
Figure 14: Redistributing Routes into BGP
clear bgp ipv6 redistribution clear ip bgp redistribution
•
Use to reapply policy to routes that have been redistributed into BGP.
•
This command takes effect immediately.
Copyright © 2013, Juniper Networks, Inc.
53
JunosE 14.3.x BGP and MPLS Configuration Guide
•
There is no no version.
•
See clear bgp ipv6 redistribution.
•
See clear ip bgp redistribution.
disable-dynamic-redistribute
•
Use to halt the dynamic redistribution of routes that are initiated by changes to a route map.
•
Dynamic redistribution is enabled by default.
•
This command takes effect immediately.
•
Example host1(config-router)#disable-dynamic-redistribute
•
Use the no version to reenable dynamic redistribution.
•
See disable-dynamic-redistribute.
redistribute
•
Use to redistribute static routes and routes from other protocols into BGP.
•
Specify the source protocol from which routes are being redistributed with one of the following keywords: isis, ospf, static, or connected. Use the static keyword to redistribute IP static routes. Use the connected keyword to redistribute routes that are established automatically by virtue of having enabled IP on an interface.
•
You can specify a route map to filter the redistribution of routes from the source routing protocol into BGP. If you do not specify the route-map option, all routes are redistributed.
•
Use the metric keyword to set the multiexit discriminator (MED) for routes redistributed into BGP. The default MED is the value of the IGP metric for the redistributed route.
•
Use the weight keyword to set the weight for routes redistributed into BGP in the range
0–65535. The default weight is 32768.
•
You can specify the type(s) of OSPF routes to redistribute into BGP: internal routes
(ospf match internal), external routes of metric type 1 (ospf match external 1), or external routes of metric type 2 (ospf match external 2).
•
This command takes effect immediately.
•
Use the no version to end the redistribution of routes into BGP.
•
See redistribute.
Redistributing Routes from BGP
If you have redistributed routes from BGP into an IGP, by default only EBGP routes are redistributed. You can issue the bgp redistribute-internal command followed by clearing all BGP sessions to permit the redistribution of IBGP routes in addition to EBGP routes.
54 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
NOTE: This default behavior does not apply to VPN routes. Redistribution of
IBGP routes (routes received from an internal BGP peer) in a VRF is always enabled. You do not have to issue this command to enable redistribution of internal BGP routes in a VRF.
bgp redistribute-internal
•
Use to enable the redistribution of IBGP routes in addition to EBGP routes into IGPs configured for BGP route redistribution.
•
Redistribution of IBGP routes is disabled by default, except within a VRF where IBGP routes are always redistributed.
•
You must clear all BGP sessions after issuing this command for it to take effect.
•
Example host1(config-router)#bgp redistribute-internal host1(config-router)#exit host1(config)#exit host1(config)#clear ip bgp *
•
All IBGP and EBGP routes subsequently placed in the IP routing table are redistributed to IGPs that have route redistribution enabled.
To authorize redistribution of routes that are already present in the IP routing table, you must use the clear ip bgp * command (this command will bounce the BGP sessions) or the clear ip routes * command to reinstall BGP routes in the IP routing table.
•
Use the no version to restore the default of permitting the redistribution only of EBGP routes.
•
See bgp redistribute-internal.
Configuring a Default Route
Default routes can provide backup routes if primary connections fail or if the route information for a destination is unknown. A router uses the default route in its IP forwarding table to route traffic toward a destination for which no routing entry exists. The accepted
BGP convention is to represent a default route by the network prefix 0.0.0.0/0.
Advertising Default Routes
If you want a router to serve as a default destination for traffic from other routers that do not know where to forward traffic, you can configure the router to advertise a default route. Use the neighbor default-originate command to specify the neighbors to which this router will advertise the default route. Said another way, these neighbors will dynamically learn the default route from the router you configure.
If you issue the neighbor default-originate command, BGP sends the default route to that neighbor regardless of whether the default route exists in the IP forwarding table.
In
, router NY originates the default route 0.0.0.0/0 to router Albany only. Router Chicago does not receive the default route.
Copyright © 2013, Juniper Networks, Inc.
55
JunosE 14.3.x BGP and MPLS Configuration Guide
Figure 15: Advertising a Default Route
To configure router NY: host1(config)#router bgp 200 host1(config-router)#network 192.168.42.0 mask 255.255.254.0
host1(config-router)#neighbor 10.3.3.1 remote-as 300 host1(config-router)#neighbor 192.168.10.2 remote-as 100 host1(config-router)#neighbor 192.168.10.2 default-originate
You can also specify a route map to modify the attributes of the default route. If the default route does not match the route map, then the default route is not advertised.
Redistributing Default Routes
By default, the redistribute command does not permit a default route to be redistributed into BGP. You can use the default-information originate command to override this behavior and permit the redistribution of default routes into BGP.
default-information originate
•
Use to enable the redistribution of default routes into BGP.
•
Use the route-map keyword to specify outbound route maps to apply to the default route. The route map can modify the attributes of the default route.
•
This command takes effect immediately. However, if the contents of the route map specified with this command change, the new route map may or may not take effect immediately. If the disable-dynamic-redistribute command has been configured, you must issue the clear ip bgp redistribution command to apply the changed route map.
•
Outbound policy configured for the neighbor (using the neighbor route-map out command) is applied to default routes that are advertised because of the default-information originate command.
•
Policy specified by a route map with the default-information originate command is applied at the same time as the policy for redistributed routes, before any outbound policy for peers.
•
Example host1(config)#router bgp 100 host1(config-router)#default-information originate
56 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
Use the no version to restore the default, preventing the redistribution of default routes.
•
See default-information originate.
Setting a Static Default Route
You might not want your routers to rely on dynamically learned default routes. Instead, you might prefer to specify a static default route that your routers use to forward traffic when they do not have a routing entry for a destination. Use the ip route command to configure a default route on a router. The static route can point to a network number, an
IP address, or a physical interface. You can add a distance value to give preference to a specific static route when multiple entries exist for the same route.
Suppose that in
Figure 16 on page 57 , router KC has been configured to advertise a default
route to router Chicago: host1(config)#router bgp 62 host1(config-router)#network 172.17.24.0 mask 255.255.248.0
host1(config-router)#neighbor 10.8.3.1 remote-as 21 host1(config-router)#neighbor 10.8.3.1 default-originate
You prefer that router Chicago send traffic with unknown destinations to router StLouis, so you configure a static default route on router Chicago: host2(config)#router bgp 21 host2(config-router)#network 192.168.48.0 mask 255.255.240.0
host2(config-router)#neighbor 10.8.3.4 remote-as 62 host2(config-router)#neighbor 10.24.5.1 remote-as 37 host2(config-router)#exit host2(config)#ip route 0.0.0.0 0.0.0.0 172.25.122.0
Router StLouis is configured to advertise network 172.25.122.0/23 to router Chicago: host3(config)#router bgp 37 host3(config-router)#network 172.25.122.0 mask 255.255.254.0
host3(config-router)#neighbor 10.24.5.3 remote-as 21
Figure 16: Setting a Static Default Route
ip route
•
Use to establish static routes.
•
Use the no version to remove static routes.
•
See ip route.
Copyright © 2013, Juniper Networks, Inc.
57
JunosE 14.3.x BGP and MPLS Configuration Guide neighbor default-originate
•
Use to cause a BGP speaker (the local router) to send the default route 0.0.0.0/0 to a neighbor for use as a default route.
•
Use the route-map keyword to specify outbound route maps to apply to the default route. The route map can modify the attributes of the default route.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override the characteristic for a specific member of the peer group.
•
Outbound policy configured for the neighbor (using the neighbor route-map out command) is not applied to default routes that are advertised because of the neighbor default-originate command.
•
This command takes effect immediately.
•
Use the no version to prevent the default route from being advertised by BGP. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor default-originate.
Setting the Minimum Interval Between Routing Updates
You can use the neighbor advertisement-interval command to set the minimum interval between the sending of BGP updates. Lower values for the advertisement interval cause route changes to be reported more quickly, but may cause routers to use more bandwidth and processor time.
In the following example, the minimum time between sending BGP routing updates is set to 5 seconds: host1(config)#router bgp 100 host1(config-router)#neighbor 10.2.2.2 advertisement-interval 5
neighbor advertisement-interval
•
Use to set the minimum interval between the sending of BGP updates for a given prefix.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
This command takes effect immediately.
•
Use the no version to restore the default, 30 seconds for external peers and 5 seconds for internal peers.
•
See neighbor advertisement-interval.
Aggregating Routes
Aggregation applies only to routes that are present in the BGP routing table. BGP advertises an aggregate route only if the routing table contains at least one prefix that is more specific than the aggregate. You aggregate IPv4 routes by specifying the aggregate
IP address, and IPv6 routes by specifying the aggregate IPv6 prefix.
58 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
illustrates an IPv4 network structure where you might use aggregation.
The following commands configure router LA and router SanJose so that router SanJose advertises an IPv4 aggregate route, 172.24.0.0/16, for the more specific prefixes
172.24.1.0/24, 172.24.2.0/24, and 172.24.24.0/21.
Figure 17: Configuring Aggregate Addresses
To configure router LA: host1(config)#router bgp 873 host1(config-router)#neighbor 10.2.2.4 remote-as 873 host1(config-router)#network 172.24.1.0 mask 255.255.255.0
host1(config-router)#network 172.24.2.0 mask 255.255.255.0
To configure router SanJose: host2(config)#router bgp 873 host2(config-router)#neighbor 10.2.2.3 remote-as 873 host2(config-router)#neighbor 10.5.5.1 remote-as 17 host2(config-router)#network 172.24.24.0 mask 255.255.248.0
host2(config-router)#aggregate-address 172.24.0.0 255.255.224.0
As configured above, router SanJose advertises the more specific routes as well as the aggregate route to router Boston. Alternatively, you can use the summary-only option to configure router SanJose to suppress the more specific routes and advertise only the aggregate route: host2(config)#router bgp 873 host2(config-router)#neighbor 10.2.2.3 remote-as 873 host2(config-router)#neighbor 10.5.5.1 remote-as 17 host2(config-router)#network 172.24.24.0 mask 255.255.248.0
host2(config-router)#aggregate-address 172.24.0.0 255.255.224.0 summary-only
Each of these configurations sets the atomic-aggregate attribute in the aggregate route.
This attribute informs recipients that the route is an aggregate and must not be deaggregated into more specific routes.
Aggregate routes discard the path information carried in the original routes. To preserve the paths, you must use the as-set option. This option creates an AS-Set that consists of all the AS numbers traversed by the summarized paths. The AS-Set is enclosed within curly brackets; for example, {3, 2}. Each AS number appears only once, even if it appears in more than one of the original paths. If you use the as-set option, the atomic-aggregate
Copyright © 2013, Juniper Networks, Inc.
59
JunosE 14.3.x BGP and MPLS Configuration Guide
aggregate-address
attribute is not set for the aggregated route. The following commands configure router
SanJose to aggregate the routes while preserving the path information: host2(config)#router bgp 873 host2(config-router)#neighbor 10.2.2.3 remote-as 873 host2(config-router)#neighbor 10.5.5.1 remote-as 17 host2(config-router)#network 172.24.24.0 mask 255.255.248.0
host2(config-router)#aggregate-address 172.24.0.0 255.255.224.0 summary-only as-set
If you do not want to aggregate all more specific routes, you can use a route map to limit aggregation. Consider
again. Suppose you do not want router SanJose to aggregate prefix 172.24.48.0/20. The following commands show how you can configure a route map on router SanJose to match this prefix, and how to invoke the route map with the advertise-map option: host2(config)#router bgp 873 host2(config-router)#neighbor 10.2.2.3 remote-as 873 host2(config-router)#neighbor 10.5.5.1 remote-as 17 host2(config-router)#neighbor 10.2.2.3 route-map lmt_agg in host2(config-router)#network 172.24.24.0 mask 255.255.248.0
host2(config-router)#aggregate-address 172.24.0.0 255.255.224.0 advertise-map lmt_agg host2(config-router)#exit host2(config)#route-map lmt_agg permit 10 host2(config-route-map)#match ip address 1 host2(config-route-map)#exit host2(config)#access-list 1 permit 172.24.48.0 0.240.255.255
You can use the attribute-map option to configure attributes for the aggregated route.
In
Figure 17 on page 59 , suppose that router LA has been configured to set the community
attribute for route 172.24.160.0/19 to no-export. This attribute is passed along to router
SanJose and preserved when the aggregate route is created. As a result, the aggregate route is not advertised outside the AS. The following commands demonstrate how to configure router SanJose to prevent the aggregate from not being advertised: host2(config)#router bgp 873 host2(config-router)#neighbor 10.2.2.3 remote-as 873 host2(config-router)#neighbor 10.5.5.1 remote-as 17 host2(config-router)#network 172.24.24.0 mask 255.255.248.0
host2(config-router)#aggregate-address 172.24.0.0 255.255.224.0 attribute-map conf_agg_att host2(config-router)#exit host2(config)#route-map conf_agg_att permit 10 host2(config-route-map)#set community no-export
•
Use to create an aggregate entry in a BGP routing table that summarizes more specific routes.
•
For IPv4 routes, you must specify an aggregate IP address (address) and aggregate
IP mask (mask). For IPv6 routes, you must specify an aggregate IPv6 prefix (ipv6Prefix).
•
The optional as-set keyword preserves path information by creating an AS-Set that contains all the AS numbers traversed by the aggregated routes.
60 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
NOTE: Do not use the as-set keyword when you have many paths to aggregate. If you do, the aggregated route is continually withdrawn and reupdated as AS-path reachability information changes for the summarized routes.
•
The summary-only keyword advertises only the aggregate route; it suppresses the advertisement of all more specific routes. Contrast with the suppress-map keyword.
•
The suppress-map keyword enables you to specify a route map to filter particular routes covered by the aggregate that will be suppressed. Contrast with the summary-only keyword.
NOTE: If you want to suppress advertisements only to certain neighbors, you can—with caution—use the neighbor distribute-list command. If a more specific route leaks out, all BGP speakers will prefer that route over the less specific aggregate you are generating (using longest-match routing).
•
The advertise-map keyword enables you to specify the advertise-map-tag, a string of up to 32 characters that identifies the route map that sets the routes to create
AS-Set origin communities.
•
The attribute-map keyword enables you to specify the attribute-map-tag, a string of up to 32 characters that identifies the route map that sets the attributes of the aggregate route.
•
This command takes effect immediately.
•
Use the no version to remove the aggregate route entry from the routing table.
•
See aggregate-address.
Advertising Inactive Routes
Under normal circumstances, routes that are not being used to forward traffic—inactive routes—are not advertised to peers unless synchronization is enabled. For example, suppose a BGP speaker receives a route to a particular prefix, determines that it is the best route to the prefix, and stores the route in the IP routing table (sometimes known as the forwarding information base, or FIB). This route might not be used for forwarding to that prefix; for example, if you have configured a static route to the same destination prefix. Because static routes have better administrative distances than BGP received routes, IP will use the static route rather than the BGP received route for forwarding traffic to that prefix. The BGP received route is inactive and is not advertised to peers. You can use the bgp advertise-inactive command to enable the advertisement of inactive received routes.
bgp advertise-inactive
Copyright © 2013, Juniper Networks, Inc.
61
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Use to enable the BGP speaker to advertise inactive routes—best routes in the IP forwarding table that are not being used to forward traffic. This feature is disabled by default.
•
Issuing this command does not affect the BGP rules for best route selection, or how
BGP populates the IP forwarding table.
•
Example host1(config-router)#bgp advertise-inactive
•
The new value is applied to all routes that are subsequently placed in the IP routing table.
To apply the new value to routes that are already present in the IP routing table, you must use the clear ip bgp * command (this command will bounce the BGP sessions).
•
Use the no version to prevent the advertising of received BGP routes unless one or both of the following are true:
•
The received route is in the BGP forwarding table and is being used to forward traffic
(the route is active).
•
Synchronization is enabled.
•
See bgp advertise-inactive.
Verifying an AS Path
You can use the bgp enforce-first-as command to cause BGP to compare the first AS in the AS path of a received route with the configured remote AS number of that EBGP peer. If the check fails, BGP returns a notification message to the peer.
bgp enforce-first-as
•
Use to cause BGP to determine whether the first AS in the AS path of a route received from an EBGP peer matches the remote AS number of that peer.
•
If the AS does not match, BGP sends a notification to the peer with the error code “ update message error” and error subcode “ malformed as-path.”
•
This feature is disabled by default.
•
Example host1(config-router)#bgp enforce-first-as
•
Causes BGP to check the AS path of all routes received after you issue the command.
To apply the new behavior to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
•
Use the no version to prevent the AS comparison from taking place.
•
See bgp enforce-first-as.
62 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Advertising IPv4 Routes Between IPv6 BGP Peers
When an IPv6 network connects two separate IPv4 networks, you can use IPv6 to advertise the IPv4 routes over the BGP session, using TCP IPv6 as the transport mechanism. Similarly, you can advertise IPv6 routes between two IPv4 peers over their
BGP session.
Configure the peers by using IPv6 addresses within the IPv4 unicast address family. You can set the IPv4 next hop with a static route or by configuring an inbound or outbound route map. This action overrides the IPv4 next hop that is advertised to the peer for IPv4 routes over BGP IPv6 peers.
If you do not use the route map, then the advertised IPv4 next hop is set to the BGP router
ID. That value generally makes the next hop unreachable by the other BGP IPv6 peer.
host1(config)#router bgp 100 host1(config-router)#neighbor 21:1 remote-as 200 host1(config-router)#route-map my-v4-nexthop host1(config-router)#set ip next-hop 10.13.5.1
host1(config-router)#address-family ipv4 unicast host1(config-router-af)#neighbor 21:1 activate host1(config-router-af)#neighbor 21:1 route-map my-v4-nexthop out
Advertising Routes Conditionally
By default, a BGP speaker advertises the best routes in its routing table to its peers.
However, in some circumstances, you might prefer that some routes be advertised to a peer or peer group only when another route is in the BGP routing table, or only when that route is not in the routing table. BGP conditional advertisement enables you to control route advertisement without having to rely on only the best routes.
For example, in a multi-homed network, you might want to advertise certain prefixes to one of the providers when a failure occurs in the peering session with a different provider, or when there is only partial reachability to that peer.
In other cases, the advertisement to a peer of certain routes might be useful only in the event that some other routes are present in the BGP routing table.
You can use the neighbor advertise-map command with route maps to configure conditional advertisement of BGP routes to a peer or peer group within an address family.
BGP conditional advertisement does not create routes. The routes specified by the route map in the neighbor advertise-map command must already be present in the BGP routing table.
BGP conditional advertisement is supported in only the following address families:
•
Unicast IPv4
• Unicast IPv6
• Multicast IPv4
•
Multicast IPv6
Copyright © 2013, Juniper Networks, Inc.
63
JunosE 14.3.x BGP and MPLS Configuration Guide
64
•
VPNv4 unicast
• VPNv6 unicast
NOTE: For VPNv4 unicast and VPNv6 unicast address families, we recommend that you include a match extcommunity clause to match a route with a specific route target. However, conditional advertisement in these address families can sometimes result in unintended behaviors: advertisement of or based on an incorrect VPN route or a non-VPN route.
BGP conditional advertisement is not supported in the following address families:
•
L2VPN
•
Route-target
• VPLS
• VPWS
Use the exist-map keyword when you want a route advertised only when another route is present. The determining route must match the specified route map. If the route map you specify with the exist-map keyword references multiple routes, only one of those routes needs to be in the routing table to trigger the conditional advertisement.
Use the non-exist-map keyword when you want a route advertised only when another route is absent. The determining route must match the specified route map. If the route map you specify with the non-exist-map keyword references multiple routes, all of those routes must be absent to trigger the conditional advertisement.
You can optionally specify a sequence number for the advertise route map that matches the determining route. The sequence number specifies the order in which the advertise route maps are processed. It indicates the position the specified advertise route map has in the list of all advertise route maps that are configured for a particular neighbor within the same address family.
If you do not specify a sequence number, the position of the advertise route map is considered to be the sum of the current largest sequence number plus five. An advertise route map with a lower sequence number has a higher priority and is processed before one with a higher sequence number.
If the route matches more than one advertise route map, only the first matching advertise route map, based on the sequence, controls the advertisement of a BGP route.
You can configure a maximum of 50 advertise maps for a given peer or peer group in an address family. However, the name and sequence number for the advertise route map must be unique for each entry. BGP applies any policy specified by the advertise map to the conditionally advertised routes before outbound policy specified for the neighbor is applied.
The route maps referenced by the neighbor advertise-map command must include a match ip-address clause. You can also include additional match clauses. All match
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing commands supported by existing outbound policies are supported. The additional clauses are useful when you want to match only on a specific route with a specific set of attributes.
Only the permit keyword is acted on in a match clause. The deny keyword is ignored.
Only exact matching of a prefix referenced by exist maps or non-exist maps is supported.
Consequently a range specified by the ge or le keyword in the prefix list referenced by these route maps is ignored.
Clauses in a route map that include set commands or the match-set summary prefix-tree command are ignored. To change the attributes of conditionally advertised routes, you must use outbound routing policy.
If the contents of a referenced route map are changed, the new route map takes effect automatically.
neighbor advertise-map
•
Use to specify a peer or peer group within the current address family to which routes specified by a route map are advertised conditionally, depending on whether a second route map is matched by some other routes in the BGP routing table.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. This characteristic cannot be overridden for individual members of the peer group.
•
This command takes effect immediately.
•
Example host1(config-router-af)#neighbor 192.168.2.2 advertise-map advertiseroutes exist-map matchroute sequence 10
•
Use the no version to remove the conditions set for advertising to the peer or peer group the routes specified by the route map. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor advertise-map.
Advertising a Route Only When Another Route is Present
You can use the exist-map keyword with the neighbor advertise-map command to advertise a route only when the routing table contains some other particular route.
In the network shown in
Figure 18 on page 66 , router 2 (R2) has established BGP sessions
with both router 1 (R1) and router 3 (R3). The plan is for router 2 to send router 1 an advertisement for the route to prefix 10.10.20.0/24 only if router 2 has received a route to prefix 172.24.19.0/24 from router 3.
Alternatively, if the route to prefix 172.24.20.0 has been installed in the BGP routing table on router 2, then router 2 advertises to router 1 the route to prefix 10.10.30.0. In this case, the route does not have to be learned from router 3.
Copyright © 2013, Juniper Networks, Inc.
65
JunosE 14.3.x BGP and MPLS Configuration Guide
Figure 18: Advertising a Route When Another Route is Present
66
The following commands represent a partial configuration of router R2: host1(config)#router bgp 200 host1(config-router)#address-family ipv4 unicast host1(config-router-af)#neighbor 10.2.0.1 remote-as 100 host1(config-router-af)#neighbor 10.2.0.1 advertise-map advertisetoR1 exist-map trigger1 sequence 10 host1(config-router-af)#neighbor 10.2.0.1 advertise-map alternatetoR1 exist-map trigger2 host1(config-router-af)#exit
!
host1(config-router)#exit
!
!Configure route map to send one route to R1 host1(config)#access-list 77 permit 10.10.20.0 0.0.0.255
host1(config)#route-map advertisetoR1 permit 10 host1(config-route-map)#match ip address 77 host1(config-route-map)#exit
!
!Configure route map to match one trigger route from R3
!
host1(config)#ip as-path access-list 1 permit ^300 host1(config)#access-list 70 permit 172.24.19.0 0.0.0.255
host1(config)#route-map trigger1 permit 10 host1(config-route-map)#match ip address 70 host1(config-route-map)#match as-path 1
!
host1(config-route-map)#exit
!
!Configure route map to send alternate route to R1 host1(config)#access-list test permit 10.10.30.0 0.0.0.255
host1(config)#route-map alternatetoR1 permit 10 host1(config-route-map)#match ip address test host1(config-route-map)#exit
!
!Configure route map to match alternate route from R3
!
host1(config)#access-list check permit 172.24.20.0 0.0.0.255
host1(config)#route-map trigger2 permit 10 host1(config-route-map)#match ip address check host1(config-route-map)#exit
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
The match as-path clause in the route map referenced by the exist-map keyword ensures that router 2 sends router 1 the route to prefix 10.10.20.0 only if a route to 172.24.19.0/24 with an AS path of 300 is present in the BGP routing table. Similarly, you can impose additional restraints by including any other match clause that is supported by an existing outbound policy.
In this configuration, the condition1 route map has a sequence number of ten. Advertise route maps configured for this peer within the same address family and a lower sequence number are processed before the condition1 route map. The condition2 route map has no sequence number configured, thus giving the route map a sequence number of 15 and ensuring that condition2 is processed after the condition1 route map.
Advertising a Route Only When Another Route is Absent
You can use the non-exist-map keyword with the neighbor advertise-map command to advertise a route only when the BGP routing table does not contain some other particular route.
In the network shown in
Figure 19 on page 67 , router R2 has established BGP sessions
with both router R1 and router R3. The plan is for router R2 to send peergroup1 an advertisement for the route to prefix 10.10.30.0/24 only if the route to prefix 172.24.20.0/24 is not present in the BGP routing table. Alternatively, if router R2 has not received a route to prefix 172.21.30.0 from router R3, then router R2 advertises to peergroup1 the route to prefix 10.10.20.0. In this sample network, router R3 advertises neither of the routes to router R2. Consequently, router R2 advertises both 10.10.20.0/24 and 10.10.30.0/24 to peergroup1.
Figure 19: Advertising a Route When Another Route is Absent
The following commands configure router R2: host1(config)#router bgp 200 host1(config-router)#neighbor peergroup1 peer-group host1(config-router)#neighbor peergroup1 remote-as 100 host1(config-router)#neighbor 10.6.6.2 peer-group peergroup1 host1(config-router)#neighbor 10.7.3.2 peer-group peergroup1
Copyright © 2013, Juniper Networks, Inc.
67
JunosE 14.3.x BGP and MPLS Configuration Guide
68 host1(config-router)#neighbor 10.4.4.2 peer-group peergroup1 host1(config-router)#neighbor peergroup1 advertise-map advertisetoPG1 non-exist-map condition1 sequence 5 host1(config-router)#neighbor peer-group1 advertise-map alternatetoPG1 non-exist-map condition2 host1(config-router)#exit host1(config)#ip as-path access-list 1 permit ^300
!
!Configure route map to send one route to peergroup1
!
host1(config)#access-list 77 permit 10.10.30.0 0.0.0.255
host1(config)#route-map advertisetoPG1 permit 10 host1(config-route-map)#match ip address 77
!
host1(config-route-map)#exit
!
!Configure route map to match one trigger route host1(config)#access-list 70 permit 172.24.20.0 0.0.0.255
host1(config)#route-map condition1 permit 10 host1(config-route-map)#match ip address 70 host1(config-route-map)#exit
!
!Configure route map to send alternate route to peergroup1
!
host1(config)#access-list allow permit 10.10.20.0 0.0.0.255
host1(config)#route-map alternatetoPG1 permit 10 host1(config-route-map)#match ip address allow
!
host1(config-route-map)#exit
!
!Configure route map to match an alternate trigger route host1(config)#access-list test permit 172.21.30.0 0.0.0.255
host1(config)#route-map condition2 permit 10 host1(config-route-map)#match ip address test host1(config-route-map)#match as-path 1 host1(config-route-map)#exit
In this configuration, the condition1 route map has a sequence number of five, placing it high in the list of all configured advertise route maps for this peer group within the same address family. The condition2 route map has no sequence number configured, thus placing it at the bottom of the route map list.
In this configuration, the condition1 route map has a sequence number of ten. Route maps configured for this peer group within the same address family and a lower sequence number are processed before the condition1 route map. The condition2 route map has no sequence number configured, thus giving the route map the sequence number of ten and ensuring that condition2 is processed after the condition1 route map.
Advertising a Default Route Only When Another Route Is Present
In some circumstances, you might want to control the advertisement of a default route based on the reachability of an IGP prefix. Because conditional advertisement tracks the
BGP routing table rather than the IP routing table, the prefixes that govern the advertisement (the conditional prefixes) must be present in the BGP routing table. In
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing order to use the IGP prefix as a condition, you must import the IGP prefixes into the BGP routing table. You must also configure the origination of the default route.
In the network shown in
Figure 20 on page 69 , router R2 has an EBGP session with router
R3 and has an IGP session with router R1. Suppose you want to advertise the default route to router R3 based on the reachability of an IGP prefix, 172.55.55.0/24, on router
R2.
On router R2, configure a conditional advertisement entry for the neighbor R3. The advertise map must match the default route and the route map referenced by the exist-map keyword must match the imported IGP prefix.
In case router R3 must not learn about the IGP prefix 172.55.55.0/24, you must configure an additional outbound route map to deny this prefix so that it is not advertised to router
R3.
With this configuration, the default route is advertised to router R3 only when the IGP prefix 172.55.55.0/24 is reachable on router R2. The default route is withdrawn if this prefix becomes unreachable.
Figure 20: Advertising a Default Route When Another Route is Present
The following commands configure router R2: host1(config)#ip prefix-list default permit 0.0.0.0/0 host1(config)#route-map default permit 10 host1(config-route-map)#match ip address prefix-list default host1(config-route-map)#exit host1(config)#ip prefix-list test-default permit 172.55.0.0/16 host1(config)#route-map test permit 10 host1(config-route-map)#match ip address prefix-list test-default host1(config-route-map)#exit host1(config)#route-map outbound deny 10 host1(config-route-map)#match ip address prefix-list test-default host1(config-route-map)#exit host1(config)#route-map outbound permit 20 host1(config-route-map)#exit host1(config)#router bgp 200 host1(config-router)#neighbor 10.12.12.2 remote-as 300 host1(config-router)#network 172.55.55.0/24 host1(config-router)#aggregate-address 172.55.0.0/16 summary-only
Copyright © 2013, Juniper Networks, Inc.
69
JunosE 14.3.x BGP and MPLS Configuration Guide host1(config-router)#neighbor 10.12.12.2 advertise-map default exist-map test host1(config-router)#neighbor 10.12.12.2 default-originate host1(config-router)#neighbor 10.12.12.2 route-map outbound out host1(config-router)#exit
Configuring BGP Routing Policy
Routing policy determines how the router handles the routes it receives from and sends to BGP peers or other routing protocols. In many cases, routing policy consists of filtering routes, accepting certain routes, accepting and modifying other routes, and rejecting some routes. You can think of routing policy as a way to control the flow of routes into and out of the router.
You can use one or more of the following mechanisms to configure routing policy:
• Access lists
• Community lists
•
Prefix lists
•
Prefix trees
• Route maps
The remainder of this section provides detailed information about using these features with BGP. Before proceeding, please see JunosE IP Services Configuration Guide, for a thorough background on how these features work in general.
Types of BGP Route Maps
A route map consists of match clauses and set clauses. Match clauses, which consist of a match command, specify the attribute values that determine whether a route matches the route map. Set clauses, which consist of a set command, modify the specified attributes of routes that pass all match clauses in the route map.
BGP route maps can be applied to inbound routes, outbound routes, and redistributed routes. BGP route maps are of two types, those that support both match and set clauses, and those that support only match clauses.
The match-and-set route maps consist of the route maps configured with any of the commands listed in
.
Table 14: Commands That Create Match-and-Set Route Maps
aggregate-address attribute-map global import map bgp dampening route-map export map import map neighbor route-map in neighbor route-map out redistribute route-map global export map table-map
70 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
match as-path
BGP supports the clauses listed in
for match-and-set route maps.
Table 15: Clauses Supported in BGP Match-and-Set Route Maps
match as-path set as-path prepend match community set comm-list delete match distance match extcommunity match ip address match ip next-hop match level match metric match metric-type match route-type match tag set community set dampening set extcommunity set ip next-hop set local-preference set metric set metric-type set origin set tag set weight
The match-only route maps consist of the route maps configured with any of the commands listed in
. You can use any of the match clauses listed in
in these route maps. Set clauses have no effect in these route maps.
Table 16: Commands That Create Match-Only Route Maps
aggregate advertise-map aggregate support-map
BGP does not support the clauses listed in
Table 17 on page 71 . However, see
for exceptions for route maps applied with the table-map command.
Table 17: Clauses Not Supported in BGP Route Maps
set automatic-tag set level set distance set route-type
•
Use to match an AS-path access list.
•
The implemented weight is based on the first matched AS path.
Copyright © 2013, Juniper Networks, Inc.
71
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match as-path pathlist5
•
Use the no version to delete the match clause from a route map or a specified value from the match clause.
•
See match as-path.
match community
•
Use to match a community list.
•
Supported for inbound and outbound route maps.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match community comm5
•
Use the no version to delete the match clause from a route map or a specified value from the match clause.
•
See match community
match distance match extcommunity
•
Use to match an extended community list in a route map.
•
You can specify one or more extended community list names in a match clause. If you specify more than one extended community list, the lists are logically joined by the OR operator.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match extcommunity topeka10
•
Use the no version to remove the match clause from a route map or a specified value from the match clause.
•
See match extcommunity.
match ip address
•
Use to match any routes that have the specified administrative distance.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match distance 25
•
Use the no version to delete the match clause from a route map or a specified value from the match clause.
•
See match distance.
72 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
match ip next-hop
•
Use to match any route that has a destination network number that is permitted by an access list, a prefix list, or a prefix tree, or performs policy routing on packets.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match ip address prefix-tree boston
•
Use the no version to delete the match clause from a route map or a specified value from the match clause.
•
See match ip address.
•
Use to match any routes that have a next-hop router address passed by the specified access list, prefix list, or prefix tree.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match ip next-hop 5 192.54.24.1
•
Use the no version to delete the match clause from a route map or a specified value from the match clause.
•
See match ip next-hop.
match level
•
Use to match routes for the specified type.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match level level-1
•
Use the no version to delete the match clause from a route map or a specified value from the match clause.
•
See match level.
match metric
•
Use to match a route for the specified metric value.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match metric 10
•
Use the no version to delete the match clause from a route map or a specified value from the match clause.
•
See match metric.
match metric-type
•
Use to match a route for the specified metric type.
•
Example
Copyright © 2013, Juniper Networks, Inc.
73
JunosE 14.3.x BGP and MPLS Configuration Guide
match route-type
host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match metric-type external
•
Use the no version to delete the match clause from a route map.
•
See match metric-type.
•
Use to match a route for the specified route type.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match route-type level-1
•
Use the no version to delete the match clause from a route map or a specified value from the match clause.
•
See match route-type.
match tag neighbor route-map
•
Use to match the tag value of the destination routing protocol.
•
Example host1(config)#route-map 1 host1(config-route-map)#match tag 25
•
Use the no version to delete the match clause from a route map or a specified value from the match clause.
•
See match tag.
•
Use to apply a route map to incoming or outgoing routes.
•
If you specify an outbound route map, BGP advertises only routes that match at least one section of the route map. For routes that do not match, no further processing takes place with respect to this peer, and those routes are not advertised to this peer. The nonmatching route is still in the BGP RIB and can be sent to other peers depending on the outbound policy applied to those peers.
•
If you specify an inbound route map, BGP processes only the received routes that match at least one section of the route map. The nonmatching routes are rejected from entering the local BGP RIB and no further processing takes place.
•
A clause with multiple values matches a route having any of the values; that is, the multiple values are logically joined by the OR operator.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy.
•
New policy values are applied to all routes that are sent (outbound policy) or received
(inbound policy) after you issue the command.
74 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
route-map set as-path prepend
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
•
Example host1(config)#neighbor 192.168.5.34 route-map nyc1 in
•
Use the no version to remove the route map.
•
See neighbor route-map.
•
Use to define the conditions for redistributing routes from one routing protocol into another, and for filtering or modifying updates sent to or received from peers.
•
Each route-map command has a list of match and set commands associated with it.
•
The match commands specify the match criteria—the conditions under which redistribution is allowed for the current route map.
•
The set commands specify the set actions—the redistribution actions to perform if the criteria enforced by the match commands are set.
•
Use route maps when you wish to have detailed control over how routes are redistributed between routing processes.
•
The destination routing protocol is the one you specify with the router command.
•
The source routing protocol is the one you specify with the redistribute command.
•
A clause with multiple values matches a route having any of the values; that is, the multiple values are logically joined by the OR operator.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
Example host1(config)#route-map nyc1 permit 10
•
Use the no version to delete the route map.
•
See route-map.
Copyright © 2013, Juniper Networks, Inc.
75
JunosE 14.3.x BGP and MPLS Configuration Guide
set comm-list delete
•
Use to remove communities specified by the community list from the community attribute of routes matching the route map.
•
You can use this command to delete communities only if the community list was created with a single community per list entry as shown in the following sample configuration for router Test: host1(config)#ip community-list 1 permit 231:10 host1(config)#ip community-list 1 permit 231:20 host1(config)#router bgp 45 host1(config-router)#neighbor 10.6.2.5 remote-as 5 host1(config-router)#neighbor 10.6.2.5 route-map indelete in host1(config-router)#route-map indelete permit 10 host1(config-route-map)#set comm-list 1 delete
Router Test receives the same route from 10.6.2.5 and applies the indelete route map.
BGP compares each list entry with the community attribute. A match is found for the list entry 231:10, and this community is deleted from the community attribute. Similarly, a match is found for the list entry of 231:20, and this community is deleted from the community attribute.
•
Use the no version to delete the set clause from a route map.
•
See set comm-list delete.
set community
•
Use to modify an AS path for BGP routes by prepending one or more AS numbers or a list of AS numbers to the path list.
•
The only global BGP metric available to influence the best-path selection is the AS-path length. By varying the length of the AS path, a BGP speaker can influence the best-path selection by a peer farther away.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set as-path prepend list list10
•
Use the no version to delete the set clause from a route map.
•
See set as-path prepend.
•
Use to set the community attribute in BGP updates.
•
You can specify a community list number in the range 1–4294967295, or in the new community format of AA:NN, or one of the following well-known communities:
• local-as—Prevents advertisement outside the local AS
• no-advertise—Prevents advertisement to any peer
• no-export—Prevents advertisement beyond the BGP confederation boundary
•
Alternatively, you can use the list keyword to specify the name of a community list that you previously created with the ip community-list command.
76 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
set dampening set extcommunity set ip next-hop
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set community no-advertise
•
Use the none keyword to remove the community attribute from a route.
•
Use the no version to delete the set clause from a route map.
•
See set community.
•
Use to enable BGP route flap dampening only on routes that pass the match clauses of, and are redistributed by, a particular route map.
•
BGP creates a dampening parameter block for each unique set of dampening parameters—such as suppress threshold and reuse threshold—used by BGP. For example, if you have a route map that sets the dampening parameters to one set of values for some routes and to another set of values for the remaining routes, BGP uses and stores two dampening parameter blocks, one for each set.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set dampening 5 1000 1500 45 15
•
Use the no version to delete the set clause from a route map.
•
See set dampening.
•
Use to set the extended community attributes in a route map for BGP updates.
•
You can specify a site-of-origin (soo) extended community and a route target (rt) extended community at the same time in a set clause without overwriting the other.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set extcommunity rt 10.10.10.2:325
•
Use the no version to delete the set clause from a route map.
•
See set extcommunity.
•
Use to set the next hop attribute of a route that matches a route map.
•
This command is not supported for route maps used by the table-map command.
•
You can specify an IP address or an interface as the next hop.
•
Use the peer-address keyword to have the following effect:
•
On outbound route maps, disables the next hop calculation by setting the next hop to the IP address of the BGP speaker
•
On inbound route maps, overrides any third-party next-hop configuration by setting the next hop to the IP address of the peer
Copyright © 2013, Juniper Networks, Inc.
77
JunosE 14.3.x BGP and MPLS Configuration Guide
set local-preference
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set ip next-hop 192.56.32.1
•
Use the no version to delete the set clause from a route map.
•
See set ip next-hop.
•
Use to specify a preference value for the AS path.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set local-preference 200
•
Use the no version to delete the set clause from a route map.
•
See set local-preference.
set metric
•
Use to set the metric value—for BGP, the MED—for a route.
•
To establish an absolute metric, do not enter a plus or minus sign before the metric value.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set metric 10
•
To establish a relative metric, specify a plus or minus sign immediately preceding the metric value. The value is added to or subtracted from the metric of any routes matching the route map. The relative metric value can be in the range 0–4294967295.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set metric -25
•
You cannot use both an absolute metric and a relative metric within the same route map sequence. Setting either metric overrides any previously configured value.
•
Use the no version to delete the set clause from a route map.
•
See set metric.
set metric-type
•
Use to set the metric type for a route.
•
For BGP, affects all types of route maps. If the route map contains both a set metric-type and a set metric clause, the set metric clause takes precedence. Specifying the internal metric type in a BGP outbound route map, BGP sets the MED of the advertised routes to the IGP cost of the next hop of the advertised route. If the cost of the next hop changes, BGP is not forced to readvertise the route.
•
For BGP, you can specify the following:
78 Copyright © 2013, Juniper Networks, Inc.
set origin set tag set weight
Chapter 1: Configuring BGP Routing
• external—Reverts to the normal BGP rules for propagating the MED; this is the BGP default
• internal—Sets the MED of a received route that is being propagated to an external peer equal to the IGP cost of the indirect next hop
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set metric-type internal
•
Use the no version to delete the set clause from a route map.
•
See set metric-type.
•
Use to set the BGP origin of the advertised route.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set origin egp
•
Use the no version to delete the set clause from a route map.
•
See set origin.
•
Use to set the tag value of the destination routing protocol.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set tag 23
•
Use the no version to delete the set clause from a route map.
•
See set tag.
•
Use to specify the BGP weight for the routing table.
•
The weights assigned with the set weight command in a route map override the weights assigned using the neighbor weight and neighbor filter-list weight commands.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set weight 200
•
Use the no version to delete the set clause from a route map.
•
See set weight.
Copyright © 2013, Juniper Networks, Inc.
79
JunosE 14.3.x BGP and MPLS Configuration Guide
Applying Table Maps
You can use the table-map command on a per-address-family basis to apply a route map to modify IP attributes of BGP routes that are about to be added to the IP routing table. In these route maps, you can use only the set clauses in
.
Table 18: Set Clauses Supported in Route Maps Applied with the
Table-Map Command
set distance set metric-type set level set metric set route-type set tag
set distance
•
Use to set the administrative distance attribute on routes being installed into the routing table that match the route map.
•
Distance is used to establish preference between routes to the same prefix to identify the best route to that prefix. Setting distance in any other circumstance has no effect.
•
Example host1(config-route-map)#set distance 5
•
Use the no version to delete the set clause from a route map.
•
See set distance.
set level
•
Use to specify where to import routes when all of a route map’s match criteria are met.
•
Example host1(config-route-map)#set level level-2
•
Use the no version to delete the set clause from a route map.
•
See set level.
set route-type
•
Use to set the routes of the specified type.
•
Example host1(config-route-map)#set route-type internal
•
Use the no version to delete the set clause from a route map.
•
See set route-type.
table-map
80 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
Use to apply a policy to BGP routes about to be added to the IP routing table.
•
The route map can include any of the clauses listed in
•
The new route map is applied to all routes that are subsequently placed in the IP routing table. To apply the new table map to routes that are already present in the IP routing table, you must refresh the IP routing table with the clear ip routes * command or the clear ip bgp * command (this command will bounce the BGP sessions).
•
Example host1(config-router)#table-map distmet1 host1(config-router)#exit host1(config)#exit host1#clear ip routes *
•
Use the no version to halt application of the route map.
•
See table-map.
For example, suppose you want to change the distance and metric attributes to particular values for routes advertised by a members of a particular community. The show ip route bgp command indicates that the routes currently in the table have a variety of values for these attributes: host1# show ip route bgp
Protocol/Route type codes:
I1- ISIS level 1, I2- ISIS level2,
I- route type intra, IA- route type inter, E- route type external,
i- metric type internal, e- metric type external,
O- OSPF, E1- external type 1, E2- external type2,
N1- NSSA external type1, N2- NSSA external type2
Prefix/Length Type Next Hop Dist/Met Intf
------------------ ------- --------------- -------------- ------------
10.100.3.3/32 Bgp 10.12.12.1 20/0 ATM5/1.12
10.63.42.23/32 Bgp 10.45.2.31 12/5 ATM5/1.14
The following commands demonstrate how you can apply the policy to change these values: host1(config)#route-map distmet1 permit 5 host1(config-route-map)#match community boston42 host1(config-route-map)#set distance 33 host1(config-route-map)#set metric 44 host1(config-route-map)#exit host1(config)#router bgp 100 host1(config-router)#table-map distmet1 host1(config-router)#exit host1(config)#exit host1#clear ip routes *
The show ip route bgp command reveals the new values: host1# show ip route bgp
Protocol/Route type codes:
I1- ISIS level 1, I2- ISIS level2,
I- route type intra, IA- route type inter, E- route type external,
i- metric type internal, e- metric type external,
Copyright © 2013, Juniper Networks, Inc.
81
JunosE 14.3.x BGP and MPLS Configuration Guide
O- OSPF, E1- external type 1, E2- external type2,
N1- NSSA external type1, N2- NSSA external type2
Prefix/Length Type Next Hop Dist/Met Intf
------------------ ------- --------------- -------------- ------------
10.100.3.3/32 Bgp 10.12.12.1 33/44 ATM5/1.12
10.63.42.23/32 Bgp 10.45.2.31 33/44 ATM5/1.14
Access Lists
An access list is a sequential collection of permit and deny conditions that you can use to filter inbound or outbound routes. You can use different kinds of access lists to filter routes based on either the prefix or the AS path.
Filtering Prefixes
To filter routes based on the prefix, you can do any of the following:
•
Define an access list with the access list command and apply the list to routes received from or passed to a neighbor with the neighbor distribute-list command.
• Define a prefix list with the ip prefix-list command and apply the list to routes received from or passed to a neighbor with the neighbor prefix-list command.
•
Define a prefix tree with the ip prefix-tree command and apply the list to routes received from or passed to a neighbor with the neighbor prefix-tree command.
The router compares each route’s prefix against the conditions in the list or tree one by one. If the first match is for a permit condition, the route is accepted or passed. If the first match is for a deny condition, the route is rejected or blocked. The order of conditions is critical because testing stops with the first match. If no conditions match, the router rejects or blocks the address; that is, the last action of any list is an implicit deny condition for all routes. The implicit rule is displayed by show access-list and show configuration commands.
You cannot selectively place conditions in or remove conditions from an access list, prefix, list, or prefix tree. You can insert a new condition only at the end of a list or tree.
Consider the network structure in
Figure 21: Filtering with Access Lists
82 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
The following commands configure router Boston to apply access list reject1 to routes inbound from router SanJose. Access list reject1 rejects routes matching 172.24.160.0/19.
host3(config)#router bgp 17 host3(config-router)#neighbor 10.5.5.4 remote-as 873 host3(config-router)#neighbor 10.5.5.4 distribute-list reject1 in host3(config-router)#exit host3(config)#access-list reject1 permit 172.24.48.0 0.0.255
host3(config)#access-list reject1 deny 172.24.160.0 0.0.255
host3(config)#access-list reject1 permit 172.24.24.0 0.0.255
Consider the network shown in
. Router NY originates network
10.16.22.0/23 and advertises it to router LA. Suppose you do not want router LA to advertise that network to router Boston. You can apply an access list to updates from router LA to router Boston that prevents router LA from propagating updates for network
10.16.22.0/23.
Figure 22: Filtering Routes with an Access List
access-list
The following commands configure router LA: host2(config)#router bgp 400 host2(config-router)#network 172.24.160.0 mask 255.255.224.0
host2(config-router)#neighbor 10.72.4.2 remote-as 300 host2(config-router)#neighbor 10.5.5.1 remote-as 100 host2(config-router)#neighbor 10.5.5.1 distribute-list 1 out host2(config-router)#exit host2(config)#access-list 1 deny 10.16.22.0 0.254.255.255
•
Use to define an IP access list to permit or deny routes based on the prefix.
•
Each access list is a set of permit or deny conditions for routes based on matching a route’s prefix.
•
Use the neighbor distribute-list command to apply the access list to routes received from or forwarded to a neighbor.
•
Use the log keyword to log an Info event in the ipAccessList log whenever an access-list rule is matched.
•
Use the no version to delete an IP access list or the specified entry in the access list.
•
See access-list.
Copyright © 2013, Juniper Networks, Inc.
83
JunosE 14.3.x BGP and MPLS Configuration Guide
clear access-list
•
Use to clear IP access list counters.
•
Each access list has a counter for its entries.
•
Example host1#clear access-list reject1
•
There is no no version.
•
See clear access-list.
neighbor distribute-list
•
Use to filter routes to selected prefixes as specified in an access list.
•
Using distribute lists is one of three ways to filter BGP advertisements. The other ways are as follows:
•
Use AS-path filters with the ip as-path access-list and the neighbor filter-list commands.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy.
•
Use filters with route maps with the route-map and the neighbor route-map commands.
•
New policy values are applied to all routes that are sent (outbound policy) or received
(inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
•
Use the no version to disassociate the access list from a neighbor.
•
See neighbor distribute-list.
neighbor prefix-list
•
Use to assign an inbound or outbound prefix list.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy.
84 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
neighbor prefix-tree
•
Example host1(config-router)#neighbor 192.168.1.158 prefix-list seoul19 in
•
New policy values are applied to all routes that are sent (outbound policy) or received
(inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
•
Use the no version to remove the prefix list.
•
See neighbor prefix-list.
•
Use to assign an inbound or outbound prefix tree.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy.
•
Example host1(config-router)#neighbor 192.168.1.158 prefix-tree newyork out
•
New policy values are applied to all routes that are sent (outbound policy) or received
(inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
•
IPv6 prefix trees are not supported, Therefore you can specify an IPv6 address with this command only within the IPv4 address family and when you want to advertise
IPv4 routes to IPv6 peers.
•
Use the no version to remove the prefix tree.
•
See neighbor prefix-tree.
Copyright © 2013, Juniper Networks, Inc.
85
JunosE 14.3.x BGP and MPLS Configuration Guide
Filtering AS Paths with a Filter List
You can use a filter list to filter incoming and outgoing routes based on the value of the
AS-path attribute. Whenever a BGP route passes through an AS, BGP prepends its AS number to the AS-path attribute. The AS-path attribute is the list of ASs that a route has passed through to reach a destination.
To filter routes based on the AS-path, define the access list with the ip as-path access-list command, and apply the list to routes received from or passed to a neighbor with the neighbor filter-list command. AS-path access lists use regular expressions to describe the AS path to be matched. A regular expression uses special characters—often referred to as metacharacters—to define a pattern that is compared with an input string. For a full discussion of regular expressions, with examples on how to use them, see JunosE IP
Services Configuration Guide.
The router compares each route’s AS path against the conditions in the access list one by one. If the first match is for a permit condition, the route is accepted or passed. If the first match is for a deny condition, the route is rejected or blocked. The order of conditions is critical because testing stops with the first match. If no conditions match, the router rejects or blocks the route; that is, the last action of any list is an implicit deny condition for all routes.
You cannot selectively place conditions in or remove conditions from an AS-path access list. You can insert a new condition only at the end of an AS-path access list.
Example 1 Consider the network structure in
.
Figure 23: Filtering with AS-Path Access Lists
86
Suppose you want router London to behave in the following way:
•
Accept routes originated in AS 621 only if they pass directly to router London
•
Accept routes originated in AS 11 only if they pass directly to router London
•
Forward routes from AS 282 to AS 435 only if they pass through either AS 621 or AS 11, but not both AS 621 and AS 11
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
The following commands configure router London to apply filters based on the AS path to routes received from router Berlin and router Paris and to routes forwarded to router
Madrid.
host1(config)#router bgp 47 host1(config-router)#neighbor 10.2.9.2 remote-as 621 host1(config-router)#neighbor 10.2.9.2 filter-list 1 in host1(config-router)#neighbor 10.2.8.2 remote-as 11 host1(config-router)#neighbor 10.2.8.2 filter-list 2 in host1(config-router)#neighbor 10.2.7.2 remote-as 435 host1(config-router)#neighbor 10.2.7.2 filter-list 3 out host1(config-router)#exit host1(config)#ip as-path access-list 1 deny ^621_11$ host1(config)#ip as-path access-list 1 permit .* host1(config)#ip as-path access-list 2 deny ^11_621$ host1(config)#ip as-path access-list 2 permit .* host1(config)#ip as-path access-list 3 deny ^11_621_282 host1(config)#ip as-path access-list 3 deny ^621_11_282 host1(config)#ip as-path access-list 3 permit .*
AS-path access list 1 is applied to routes that router London receives from router Paris.
Router London rejects routes with the AS path (621 11).
AS-path access list 2 is applied to routes that router London receives from router Berlin.
Router London rejects routes with the AS path (11 621) or (621 282 11).
Router London accepts routes with the AS path (11 282), (621 282), (621 11 282), or (11
621 282). However, it applies AS-path access list 3 to routes it forwards to router Madrid, and filters out routes with the AS path (621 11 282) or (11 621 282).
Example 2 Consider the following commands used to configure router Chicago in
: host1(config)#router bgp 293 host1(config-router)#neighbor 10.5.5.2 remote-as 32 host1(config-router)#neighbor 10.5.5.2 filter-list 1 in host1(config-router)#neighbor 10.2.2.4 remote-as 17 host1(config-router)#exit host1(config)#ip as-path access-list 1 deny ^32$
Figure 24: Assigning a Filter List
Copyright © 2013, Juniper Networks, Inc.
87
JunosE 14.3.x BGP and MPLS Configuration Guide
Access list 1 denies routes that originate in AS 32—and therefore routes originated by router NY—because the AS-path attribute for these routes begins with (and indeed consists only of) the value 32.
Routes originating anywhere else—such as in AS 837, AS 17, or AS 451—are permitted, because their AS-path attributes do not begin with 32.
ip as-path access-list
•
Use to define an AS-path access list to permit or deny routes based on the AS path.
•
Each access list is a set of permit or deny conditions for routes based on matching a route’s AS path with a regular expression. If the regular expression matches the representation of the AS path of the route as an ASCII string, then the permit or deny condition applies. The AS path does not contain the local AS number.
•
Use the neighbor filter-list command to apply the AS-path access list. You can apply access list filters to inbound and outbound BGP routes. You can assign weights to routes matching the AS-path access list.
•
Use the no version to remove a single access list entry if permit or deny and a path-expression are specified. Otherwise, the entire access list is removed.
•
See ip as-path access-list.
neighbor filter-list
•
Use to assign an AS-path access list to matching inbound or outbound routes with the in or out keywords.
•
You can specify an optional weight value with the weight keyword to assign a relative importance to incoming routes matching the AS-path access list.
•
The name of the access list is a string of up to 32 characters.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy.
•
New policy values are applied to all routes that are sent (outbound policy) or received
(inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
88 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
Use the no version to disassociate the access list from a neighbor.
•
See neighbor filter-list.
Filtering AS Paths with a Route Map
You can use a route map instead of the neighbor filter-list command to apply access lists for filtering routes. In
Figure 25 on page 89 , suppose router Chicago is configured as
follows: host1(config)#router bgp 293 host1(config-router)#network 192.168.5.0 mask 255.255.255.0
host1(config-router)#neighbor 10.2.2.4 remote-as 17 host1(config-router)#neighbor 10.2.2.4 weight 150 host1(config-router)#neighbor 10.5.5.2 remote-as 32 host1(config-router)#neighbor 10.5.5.2 weight 50
Figure 25: Route Map Filtering
Routes learned from router Boston have a weight of 150, whereas those learned from router NY have a weight of 50. Router Chicago therefore prefers all routes learned from router Boston to those learned from router NY. Based on this configuration, router Chicago prefers routes to prefixes originating in AS 837 or originating in AS 32 that pass through router Boston over routes to those same prefixes that pass through router NY.
This is a longer path than you might desire. You can avoid this result by configuring a route map to modify the weight of certain routes learned by router Chicago: host1(config-router)#neighbor 10.5.5.2 route-map alpha in host1(config-router)#exit host1(config)#route-map alpha permit 10 host1(config-route-map)#match as-path dog1 host1(config-route-map)#set weight 175 host1(config-route-map)#exit host1(config)#ip as-path access-list dog1 permit _32$ host1(config)#ip as-path access-list dog1 permit _837$ host1(config)#route-map alpha permit 20 host1(config-route-map)#match as-path dog2 host1(config-route-map)#exit host1(config)#ip as-path access-list dog2 permit .*
Copyright © 2013, Juniper Networks, Inc.
89
JunosE 14.3.x BGP and MPLS Configuration Guide
BGP applies route map alpha to all routes learned from 10.5.5.2 (router NY). Instance 10 of route map alpha matches routes with access list dog1. This access list permits any route whose AS-path attribute ends in 32 or 837—that is, routes that originate in AS 32 or AS 837. It sets their weight to 175, overriding the neighbor weight (50) set for updates received from 10.5.5.2. Then, instance 20 of route map alpha permits all other routes with no modification.
The result of this improved configuration is the following:
•
Router Chicago prefers routes learned from router Boston (weight 150) over routes learned from router NY (weight 50), except that
• Router Chicago prefers routes learned from router NY that originate in AS 837 or AS
32 (weight 175 as a result of route map alpha) over the same routes learned from router
Boston (weight 150).
Refer to the commands and guidelines in the section
“Types of BGP Route Maps” on page 70
for more information about configuring route maps.
Configuring the Community Attribute
A community is a logical group of prefixes that share some common attribute. Community members can be on different networks and in different autonomous systems. BGP allows you to define the community to which a prefix belongs. A prefix can belong to more than one community. The community attribute lists the communities to which a prefix belongs.
You can use communities to simplify routing policies by configuring which routing information a BGP speaker will accept, prefer, or distribute to other neighbors according to community membership. When a route is learned, advertised, or redistributed, a BGP speaker can set, append, or modify the community of a route. When routes are aggregated, the resulting BGP update contains a community attribute that contains all communities from all of the aggregated routes (if the aggregate is an AS-set aggregate).
Several well-known communities have been predefined.
describes how a BGP speaker handles a route based on the setting of its community attribute.
Table 19: Action Based on Well-Known Community Membership
Well-Known Community BGP Speaker Action no-export no-advertise local-as (also known as no-export-subconfed) internet
Does not advertise the route to any EBGP peers (does not advertise the route beyond the local AS)
Does not advertise the route to any peers, IBGP or EBGP
Advertises the route only to peers within the local confederation
Advertises this route to the Internet community; by default, all prefixes are members of the Internet community
In addition to the well-known communities, you can define local-use communities, also known as private communities or general communities. These communities serve as a
90 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing convenient way to categorize groups of routes to facilitate the use of routing policies.
The community attribute consists of four octets, but it is common practice to designate communities in the AA:NN format. The autonomous system number (AA) comprises the higher two octets, and the community number (NN) comprises the lower two octets.
Both are expressed as decimal numbers. For example, if a prefix in AS 23 belongs to community 411, the attribute can be expressed as 23:411. Use the ip bgp-community new-format command to specify that the show commands display communities in this format.
Use the set community command in route maps to configure the community attributes.
By default, the community attribute is not sent to BGP peers. To send the community attribute to a neighbor, use the neighbor send-community command.
Consider the network structure shown in
Figure 26 on page 91 . The following sample
configurations illustrate some of the capabilities of using the community attribute.
Figure 26: Communities
The following commands configure router NY to apply route map setcomm to routes going out to 10.72.4.3. If the community attribute of such a route matches instance 10 of the route map, router NY sets the community attribute to 31:15. All locally originated routes will match this instance of the route map.
host1(config)#router bgp 31 host1(config-router)#network 10.16.22.0 mask 255.255.254.0
host1(config-router)#neighbor 10.72.4.3 remote-as 425 host1(config-router)#neighbor 10.72.4.3 send-community host1(config-router)#neighbor 10.72.4.3 route-map setcomm out host1(config-router)#exit host1(config)#ip as-path access-list 1 permit ^$ host1(config)#route-map setcomm permit 10 host1(config-route-map)#match as-path 1 host1(config-route-map)#set community 31:15
The following commands configure router LA to apply route map matchcomm to routes coming in from 10.72.4.2. If the community attribute of such a route matches instance 10 of the route map, router LA sets the weight of the route to 25.
host2(config)#router bgp 425 host2(config-router)#network 172.24.160 mask 255.255.224.0
host2(config-router)#neighbor 10.72.4.2 remote-as 31 host2(config-router)#neighbor 10.72.4.2 send-community
Copyright © 2013, Juniper Networks, Inc.
91
JunosE 14.3.x BGP and MPLS Configuration Guide host2(config-router)#neighbor 10.72.4.2 route-map matchcomm in host2(config-router)#neighbor 10.5.5.1 remote-as 122 host2(config-router)#neighbor 10.5.5.1 send-community host2(config-router)#exit host2(config)#ip community-list 1 permit 31:15 host2(config)#route-map matchcomm permit 10 host2(config-route-map)#match community 1 host2(config-route-map)#set weight 25
The following commands configure router Boston to apply route map 5 to routes going out to 10.5.5.4. If the destination IP address of such a route matches instance 10 of the route map, router Boston sets the community attribute of the route to no-export.
host3(config)#router bgp 122 host3(config-router)#network 192.168.144.0 mask 255.255.240.0
host3(config-router)#neighbor 10.5.5.4 remote-as 425 host3(config-router)#neighbor 10.5.5.4 send-community host3(config-router)#neighbor 10.5.5.4 route-map 5 out host3(config-router)#exit host3(config)#route-map 5 permit 10 host3(config-route-map)#match ip address access5 host3(config-route-map)#set community no-export host3(config-route-map)#exit host3(config)#access-list access5 permit 10.16.22.112
Suppose router Boston forwards a route destined for 10.16.22.112 through router LA. Route map 5 matches and sets the community attribute to no-export. As a consequence router
LA does not export the route to router NY; the route does not reach its destination.
ip bgp-community new-format
•
Use to specify that communities must be displayed in AA:NN format, where AA is a number that identifies the autonomous system and NN is a number that identifies the community within the autonomous system.
•
Use the no version to restore the default display.
•
See ip bgp-community new-format.
neighbor send-community
•
Use to specify that a community attribute must be sent to a BGP neighbor.
•
You can specify that only standard communities, only extended communities, or both be sent.
•
When you create a neighbor in a VPNv4 address family, that neighbor automatically gets a neighbor send-community extended command; this command subsequently appears in a show configuration display because it is not the default.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override this inheritance for a peer group member.
•
Example host1(config-router)#neighbor send-community westcoast extended
92 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
set community
•
New policy values are applied to all routes that are sent (outbound policy) or received
(inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
•
Use the no version to send only standard communities to a BGP neighbor. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor send-community.
•
Use to set the community attribute in BGP updates.
•
You can specify a community list number in the range 1–4294967295, or in the new community format of AA:NN, or one of the following well-known communities:
• local-as—Prevents advertisement outside the local AS
• no-advertise—Prevents advertisement to any peer
• no-export—Prevents advertisement beyond the BGP confederation boundary
•
Alternatively, you can use the list keyword to specify the name of a community list that you previously created with the ip community-list command.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set community no-advertise
•
Use the none keyword to remove the community attribute from a route.
•
Use the no version to delete the set clause from a route map.
•
See set community.
Community Lists
A community list is a sequential collection of permit and deny conditions. Each condition describes the community number to be matched. If you issued the ip bgp-community new-format command, the community number is in AA:NN format; otherwise it is in decimal format.
The router tests the community attribute of a route against the conditions in a community list one by one. The first match determines whether the router accepts (the route is
Copyright © 2013, Juniper Networks, Inc.
93
JunosE 14.3.x BGP and MPLS Configuration Guide permitted) or rejects (the route is denied) a route having the specified community.
Because the router stops testing conditions after the first match, the order of the conditions is critical. If no conditions match, the router rejects the route.
Consider the network structure shown in
.
Figure 27: Community Lists
94
Suppose you want router Albany to set metrics for routes that it forwards to router Boston based on the communities to which the routes belong. You can create community lists and filter the routes with a route map that matches on the community list. The following commands demonstrate how to configure router Albany: host1(config)#router bgp 293 host1(config-router)#neighbor 10.5.5.2 remote-as 32 host1(config-router)#neighbor 10.2.2.1 remote-as 451 host1(config-router)#neighbor 10.2.2.4 remote-as 17 host1(config-router)#neighbor 10.2.2.4 route-map commtrc out host1(config-router)#exit host1(config)#route-map commtrc permit 1 host1(config-route-map)#match community 1 host1(config-route-map)#set metric 20 host1(config-route-map)#exit host1(config)#route-map commtrc permit 2 host1(config-route-map)#match community 2 host1(config-route-map)#set metric 75 host1(config-route-map)#exit host1(config)#route-map commtrc permit 3 host1(config-route-map)#match community 3 host1(config-route-map)#set metric 85 host1(config-route-map)#exit host1(config)#ip community-list 1 permit 25 host1(config)#ip community-list 2 permit 62 host1(config)#ip community-list 3 permit internet
Community list 1 comprises routes with a community of 25; their metric is set to 20.
Community list 2 comprises routes with a community of 62; their metric is set to 75.
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
ip community-list
Community 3 catches all remaining routes by matching the internet community; their metric is set to 85.
•
Use to create a standard or a regular expression community list for BGP and controls access to it.
•
A route can belong to any number of communities, so a community list can have many entries comprising many communities.
•
You can specify one or more community values when you create a community list. A clause in a route map that includes a list having more than one value only matches a route having all of the values; that is, the multiple values are logically joined by the
AND operator.
•
Example host1(config)#ip community-list 1 permit 100:2 100:3 100:4 host1(config)#route-map marengo permit 10 host1(config-route-map)#match community 1
A route matches this community list only if it belongs to at least all three communities in community list 1: Communities 100:2, 100:3, and 100:4.
•
Use the no version to remove a single community list entry if permit or deny and a path-expression are specified. Otherwise, the entire community list is removed.
•
See ip community-list.
The router supports the new BGP extended community attribute. This attribute enables the definition of a new type of IP extended community and extended community list unrelated to the community list that uses regular expressions. BGP speakers can use the new extended community attribute to control routes similarly to the way it uses the community attribute. The extended community attribute is currently defined in the Internet draft, BGP Extended Communities Attribute—draft-ietf-idr-bgp-ext-communities-07.txt
(February 2004 expiration).
NOTE: IETF drafts are valid for only 6 months from the date of issuance. They must be considered as works in progress. Please refer to the IETF Web site at http://www.ietf.org for the latest drafts.
ip extcommunity-list
•
Use to create an extended community list for BGP and control access to it.
•
A route can belong to any number of communities, so an extended community list can have many entries comprising many communities.
•
You can specify one or more community values when you create an extended community list. A clause in a route map that includes a list having more than one value only matches a route having all of the values; that is, the multiple values are logically joined by the AND operator.
Copyright © 2013, Juniper Networks, Inc.
95
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Example host1(config)#ip extcommunity-list boston1 permit 100:2 100:3 100:4 host1(config)#route-map marengo permit 10 host1(config-route-map)#match extcommunity boston1
A route matches this community list only if it belongs to at least all three communities in extended community list boston1: Communities 100:2, 100:3, and 100:4.
•
Use the no version to remove a single extended community list entry if permit or deny and a path-expression are specified. Otherwise, the entire community list is removed.
•
See ip extcommunity-list.
Resetting a BGP Connection
When a routing policy changes, use the clear ip bgp and clear bgp ipv6 commands to clear the current BGP session and implement the new policy.
Clearing a BGP session can create a major disruption in the network operation; this is known as a hard clear. For this reason, you can use the soft in and soft out options of the command (a soft clear) to activate policies without disrupting the BGP session.
The soft in option reapplies inbound policy to received routes; the soft out option resends routes to a neighbor after reapplying outbound policy. The soft in prefix-list option causes BGP to push any prefix list outbound route filters (ORFs) to the peer and then reapply inbound policy to received routes.
NOTE: Resetting the BGP connection is slightly different when you change outbound policies for peer groups for which you have enabled Adj-RIBs-Out.
You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group.
clear bgp ipv6 clear ip bgp
•
Use to clear the current BGP connection or to activate a new policy without clearing the BGP session.
•
You can specify the IP address of a BGP neighbor, the name of a BGP peer group, or an address family to be cleared.
•
Use the asterisk (*) to clear all BGP connections.
•
If you do not use the soft in or soft out options, the clear is known as a hard clear and clears the current BGP connection.
96 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
Use the soft in option to reapply inbound policy to all received routes without clearing the BGP session.
•
Use the soft in prefix-filter option to push an ORF to the peer and reapply inbound policy to all received routes without clearing the BGP session.
•
Use the soft out option to reapply outbound policy and resend routes without clearing the BGP session.
•
This command takes effect immediately.
•
There is no no version.
•
See clear bgp ipv6.
•
See clear ip bgp.
Changing Policies Without Disruption
Changing policies can cause major network disruptions when you bring down sessions to reapply the modified policies. You can use either of the methods in this section to minimize network disruptions.
Soft Reconfiguration
You can use soft reconfiguration to enable the nondisruptive reapplication of inbound policies. Issuing the command causes the router to store copies of the routes received from the specified peer or from all members of the specified peer group. The route copies are stored unmodified, before application of inbound policies.
If you then change your inbound policies, you can apply them to the stored routes without clearing your BGP sessions—and causing network disruptions—by issuing the clear ip bgp soft in command.
neighbor soft-reconfiguration inbound
•
Use to initiate the storage of copies of routes received from the specified IP address or from all members of the specified peer group.
•
Use with the clear ip bgp soft in command to reapply inbound policies to stored routes without clearing the BGP sessions.
•
Example host1(config)#router bgp 37 host1(config-router)#neighbor 192.168.1.1 remote-as 42 host1(config-router)#neighbor 192.168.1.1 soft-reconfiguration inbound
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
If the route-refresh capability was negotiated with the peer, BGP immediately sends a route-refresh message to the peer to populate the Adj-RIBs-In table.
Copyright © 2013, Juniper Networks, Inc.
97
JunosE 14.3.x BGP and MPLS Configuration Guide
clear ip bgp neighbor capability
If the route-refresh capability was not negotiated with the peer, BGP automatically bounces the session. The Adj-RIBs-In table is repopulated when routes are received from the peer after the session comes back up.
•
Use the no version to disable storage of the route copies. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor soft-reconfiguration inbound.
Route-Refresh Capability
The route-refresh capability provides a lower-cost alternative to soft reconfiguration as a means to change policies without major disruptions. The router advertises the route-refresh capability when it establishes a BGP session with a peer to indicate that it is capable of exchanging BGP route-refresh messages. If inbound soft reconfiguration is disabled (the default) and you issue the clear ip bgp soft in command, the router sends route-refresh messages to its peers that have advertised this capability. The messages contain a request for the peer to resend its routes to the router. The new inbound policy is then applied to the routes as they are received.
Our implementation conforms to RFC 2918—Route Refresh Capability for BGP-4
(September 2000), but it also supports nonstandard implementations.
Cooperative Route Filtering
If a BGP speaker negotiates the cooperative route filtering capability with a peer, then the speaker can transfer inbound route filters to the peer. The peer then installs the filter as an outbound route filter (ORF) on the remote end. The ORF is applied by the peer after application of its configured outbound policies. This cooperative filtering has the advantage of both reducing the amount of processing required for inbound BGP updates and reducing the amount of BGP control traffic generated by BGP updates.
•
Use to push an ORF to the peer and reapply inbound policy to all received routes without clearing the BGP session.
•
You can specify the IP address of a BGP neighbor, the name of a BGP peer group, or an address family to be cleared.
•
Use the asterisk (*) to clear all BGP connections.
•
If the ORF capability is not configured or received on the peer, then the prefix-filter keyword is ignored and the router performs a normal inbound soft reconfiguration.
•
This command takes effect immediately.
•
There is no no version.
•
See clear ip bgp.
98 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
neighbor maximum-orf-entries
•
Use to set the maximum number of ORF entries of any one type that will be accepted from the specified neighbor.
•
Example host1(config-router)#neighbor 192.168.1.158 maximum-orf-entries 125000
•
Use the no version to restore the default value of no limits.
•
See neighbor maximum-orf-entries.
neighbor prefix-list
•
Use to negotiate the exchange of inbound route filters and their installation as ORFs by specifying the orf keyword, an ORF type, and the direction of the capability.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
You cannot configure the receive direction for the orf capability for a peer that is a member of a peer group or for a peer.
•
When issued with the orf keyword, this command takes effect immediately and automatically bounces the BGP session.
•
Example host1(config-router)#neighbor 192.168.1.158 capability orf prefix-list both
•
Use the no version to prevent advertisement of the capability. Use the default version to restore the default, advertising the capability.
•
See neighbor capability.
•
Use to assign an inbound or outbound prefix list.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy.
•
Example host1(config-router)#neighbor 192.168.1.158 prefix-list seoul19 in
•
New policy values are applied to all routes that are sent (outbound policy) or received
(inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or
Copyright © 2013, Juniper Networks, Inc.
99
JunosE 14.3.x BGP and MPLS Configuration Guide outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
•
Use the no version to remove the prefix list.
•
See neighbor prefix-list.
Configuring Route Flap Dampening
Route flap dampening is a mechanism for minimizing instability caused by route flapping.
Route flapping occurs when a link is having a problem and is constantly going up and down. Every time the link goes down, the upstream peer withdraws the routes from all its neighbors. When the link comes back up again, the peer advertises those routes globally. When the link problem appears again, the peer withdraws the routes again. This process continues until the underlying problem is fixed.
The router stores a penalty value with each route. Each time the route flaps, the router increases the penalty by 1000. If the penalty for a route reaches a configured suppress value, the router suppresses the route. That is, the router does not include the route as a forwarding entry and does not advertise the route to BGP peers.
The penalty decrements by 50 percent for each half-life interval that passes. The half-life interval resets when the route flaps and the penalty increments. The route remains suppressed until the penalty falls below the configured reuse threshold, at which point the router once again advertises the route. You can specify a max-suppress-time for route suppression; after this interval passes, the router once again advertises the route.
BGP creates a dampening parameter block for each unique set of dampening parameters—such as suppress threshold and reuse threshold—used by BGP. For example, if you have a route map that sets the dampening parameters to one set of values for some routes and to another set of values for the remaining routes, BGP uses and stores two dampening parameter blocks, one for each set.
Global Route Flap Dampening
Use the bgp dampening command if you want to enable route flap dampening with the same values on all BGP routes, or on all routes matching the specified route map. If you specify a route map, the router dampens only routes that are permitted by the route map.
For example: host1(config-router)#bgp dampening 8 600 2500 30 route-map 1
bgp dampening
•
Use to enable BGP route flap dampening on all BGP routes or routes matching a specified route map.
•
You can specify a complete set of values that determine how routes are dampened.
If you choose to do so, you must specify the entire set:
100 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
half-life— When this period expires, the penalty assigned to a route is decreased by half
•
reuse— When the penalty for a flapping route falls below this limit, the route is unsuppressed (added back to the BGP table and used for forwarding)
•
suppress—When a route’s penalty exceeds this limit, the route is suppressed
•
max-suppress-time—When the period a route has been suppressed exceeds this limit, the route becomes unsuppressed
•
If you specify the preceding set of dampening values, you can optionally specify a
half-life-unreachable period to apply to unreachable routes. If you do not specify this value, the same half-life period is used for both reachable and unreachable routes.
•
Dampening applies only to routes learned by means of EBGP.
•
The new dampening parameters are applied in future flaps. Changing the dampening parameters does not affect the Figure of Merit that has been calculated for routes using the old dampening parameters. To reset the Figure-of-Merit for all routes, you must issue the clear ip bgp dampening command.
•
Use the no version to disable route flap dampening.
•
See bgp dampening.
clear bgp ipv6 dampening clear ip bgp dampening
•
Use to clear the BGP route flap dampening information and unsuppress the suppressed routes.
•
You can use the flap-statistics keyword as an alternative to the dampening keyword.
Both achieve the same results.
•
This command takes effect immediately.
•
Examples
To clear IPv6 dampening information for all routes in all routers: host1#clear bgp ipv6 dampening
To clear IPv6 dampening information for a specific route: host1#clear bgp ipv6 dampening 6000::/64
To clear IPv4 dampening information for all routes in all address families in all VRFs: host1#clear ip bgp dampening
To clear IPv4 dampening information for all routes in VRF dogwood: host1#clear ip bgp ipv4 dogwood dampening
To clear IPv4 dampening information for all non-VRF routes in the IPv4 unicast address family: host1#clear ip bgp vrf unicast dampening
To clear IPv4 dampening information for a specific route:
Copyright © 2013, Juniper Networks, Inc.
101
JunosE 14.3.x BGP and MPLS Configuration Guide host1#clear ip bgp dampening 192.168.5.0 255.255.255.0
To clear IPv4 dampening information for the most specific route matching an address: host1#clear ip bgp dampening 192.168.5.0
•
There is no no version.
•
See clear bgp ipv6 dampening.
•
See clear ip bgp dampening.
Policy-Based Route Flap Dampening
You can use policy-based route flap dampening to apply different dampening criteria to different routes. Establish one or more match clauses for an instance of a route map.
Then use the set dampening command to specify the dampening values that apply to routes that pass all the match clauses for that route map. Consider the following example: host1(config)#route-map 21 permit 5 host1(config-route-map)#match as-path 1 host1(config-route-map)#set dampening 5 1000 1500 45 15 host1(config-route-map)#exit host1(config)#ip as-path access-list 1 permit ^300_
Access list 1 permits routes that originate in AS 300. Instance 5 of route map 21 permits routes that match access list 1 and applies the set of dampening criteria to only those routes; in this case, routes that originate in AS 300.
You can restore the advertisement of routes suppressed as a result of policy-based route flap dampening by issuing the neighbor unsuppress-map command. You can unsuppress routes from a specified neighbor or peer group. You must specify a route map; only those routes that match the route map are unsuppressed.
neighbor unsuppress-map
•
Use to unsuppress routes that have been suppressed by a set dampening clause in a route map.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override this inheritance for a peer group member.
•
Routes previously suppressed by a route map that are unsuppressed by this command are not automatically advertised; you must use the clear ip bgp command to perform a hard clear or outbound soft clear.
•
Example host1(config-router)#neighbor berlin5 unsuppress-map inmap3
•
Use the no version to restore the default values.
•
See neighbor unsuppress-map.
set dampening
102 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
Use to enable BGP route flap dampening only on routes that pass the match clauses of, and are redistributed by, a particular route map.
•
BGP creates a dampening parameter block for each unique set of dampening parameters—such as suppress threshold and reuse threshold—used by BGP. For example, if you have a route map that sets the dampening parameters to one set of values for some routes and to another set of values for the remaining routes, BGP uses and stores two dampening parameter blocks, one for each set.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set dampening 5 1000 1500 45 15
•
Use the no version to delete the set clause from a route map.
•
See set dampening.
Policy Testing
You can analyze and check your BGP routing policies on your network before you implement the policies. Use the test ip bgp neighbor and test bgp ipv6 neighbor commands to test the outcome of a BGP policy. The commands output displays the routes that are advertised or accepted if the specified policy is implemented.
NOTE: You can use the standard redirect operators to redirect the test output to network or local files. See the section JunosE System Basics Configuration
Guide.
BGP routes must be present in the forwarding table for these commands to work properly.
If you run the policy test on incoming routes, soft reconfiguration (configured with the neighbor soft reconfiguration in command) must be in effect.
NOTE: The output of these commands is always speculative. It does not reflect the current state of the router.
test bgp ipv6 neighbor test ip bgp neighbor
•
Use to test the effect of BGP policies on a router without implementing the policy.
•
You can apply the test to routes advertised to peers or received from peers.
•
You can test the following kinds of policies: distribute lists, filter lists, prefix lists, prefix trees, or route maps. If you do not specify a policy, then the test uses whatever policies are currently in effect on the router.
Copyright © 2013, Juniper Networks, Inc.
103
JunosE 14.3.x BGP and MPLS Configuration Guide
NOTE: If you test the current policies, the results might vary for routes learned before the current policies were activated if you did not clear the forwarding table when the policies changed.
•
The following three items apply to the test ip bgp neighbor command only:
•
The address-family identifier for the route is the same as is used for identifying the neighbor.
•
If you do not specify a route, the test is performed for all routes associated with the
address-family identifier.
•
Specifying only an address and mask without a route distinguisher causes all routes sharing the address and mask to be considered. Specifying only an address causes a best match to be performed for the route.
•
If you completely specify a route with IP address, mask, and route distinguisher, the command displays detailed route information. Otherwise only summary information is shown. Use the fields option to select particular fields of interest.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
You can set a weight value for inbound routes filtered with a filter list.
•
Example host1#test ip bgp neighbor 10.12.54.21 advertised-routes distribute-list boston5 fields
•
There is no no version.
•
See test bgp ipv6 neighbor.
•
See test ip bgp neighbor.
Selecting the Best Path
BGP selects only one route to a destination as the best path. When multiple routes to a given destination exist, BGP must determine which of these routes is the best. BGP puts the best path in its routing table and advertises that path to its BGP neighbors.
If only one route exists to a particular destination, BGP installs that route. If multiple routes exist for a destination, BGP uses tie-breaking rules to decide which one of the routes to install in the BGP routing table.
BGP Path Decision Algorithm
BGP determines the best path to each destination for a BGP speaker by comparing path attributes according to the following selection sequence:
104 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
1.
Select a path with a reachable next hop.
2.
Select the path with the highest weight.
3.
If path weights are the same, select the path with the highest local preference value.
4.
Prefer locally originated routes (network routes, redistributed routes, or aggregated routes) over received routes.
5.
Select the route with the shortest AS-path length.
6.
If all paths have the same AS-path length, select the path based on origin: IGP is preferred over EGP; EGP is preferred over Incomplete.
7.
If the origins are the same, select the path with lowest MED value.
8.
If the paths have the same MED values, select the path learned by means of EBGP over one learned by means of IBGP.
9.
Select the path with the lowest IGP cost to the next hop.
10.
Select the path with the shortest route reflection cluster list. Routes without a cluster list are treated as having a cluster list of length 0.
11.
Select the path received from the peer with the lowest BGP router ID.
12.
Select the path that was learned from the neighbor with the lowest peer remote address.
The following sections discuss the attributes evaluated in the path decision process.
Examples show how you might configure these attributes to influence routing decisions.
Configuring Next-Hop Processing
Routes sent by BGP speakers include the next-hop attribute. The next hop is the IP address of a node on the network that is closer to the advertised prefix. Routers that have traffic destined for the advertised prefix send the traffic to the next hop. The next hop can be the address of the BGP speaker sending the update or of a third-party node.
The third-party node does not have to be a BGP speaker.
The next-hop attributes conform to the following rules:
• The next hop for EBGP sessions is the IP address of the peer that advertised the route.
• The next hop for IBGP sessions is one of the following:
•
If the route originated inside the AS, the next hop is the IP address of the peer that advertised the route.
• If the route originated outside the AS—that is, it was injected into the AS by means of an EBGP session—the next hop is the IP address of the external BGP speaker that advertised the route.
•
For routes advertised on multiaccess media—such as Frame Relay, ATM, or
Ethernet—the next hop is the IP address of the originating router’s interface that is connected to the medium.
Copyright © 2013, Juniper Networks, Inc.
105
JunosE 14.3.x BGP and MPLS Configuration Guide
Next Hops
If you use the neighbor remote-as command to configure the BGP neighbors, the next hop is passed according to the rules provided above when networks are advertised.
Consider the network configuration shown in
Figure 28 on page 106 . Router Jackson
advertises 192.168.22.0/23 internally to router Memphis with a next hop of 10.2.2.1. Router
Jackson advertises the same network externally to router Topeka with a next hop of
10.1.13.1.
Figure 28: Configuring Next-Hop Processing
106
Router Memphis advertises 172.24.160/19 with a next hop of 10.2.2.2 to router Jackson.
Router Jackson advertises this same network externally to router Topeka with a next hop of 10.1.13.1.
Router Topeka advertises network 192.168.32.0/19 with a next hop of 10.1.13.2 to router
Jackson. Because this network originates outside AS 604, router Jackson then internally advertises this network (192.168.32.0/19) to router Memphis with the same next hop,
10.1.13.2 (the IP address of the external BGP speaker that advertised the route).
When router Memphis has traffic destined for 192.168.32.0/19, it must be able to reach the next hop by means of an IGP, because it has no direct connection to 10.1.13.2.
Otherwise, router Memphis will drop packets destined for 192.168.32.0/19 because the next-hop address is not accessible. Router Memphis does a lookup in its IP routing table to determine how to reach 10.1.13.2:
Destination
10.1.13.0/24
Next Hop
10.2.2.1
The next hop is reachable through router Jackson, and the traffic can be forwarded.
The following commands configure the routers as shown in
:
To configure router Jackson:
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing host1(config)#router bgp 604 host1(config-router)#neighbor 10.1.13.2 remote-as 25 host1(config-router)#neighbor 10.2.2.2 remote-as 604 host1(config-router)#network 192.168.22.0 mask 255.255.254.0
To configure router Memphis: host2(config)#router bgp 604 host2(config-router)#neighbor 10.2.2.1 remote-as 604 host2(config-router)#network 172.24.160.0 mask 255.255.224.0
To configure router Topeka: host3(config)#router bgp 25 host3(config-router)#neighbor 10.1.13.1 remote-as 604 host3(config-router)#network 172.31.64.0 mask 255.255.192.0
Additional configuration is required for routers Biloxi, Memphis, and Jackson; the details depend on the IGP running in AS 604.
neighbor remote-as
•
Use to add an entry to the BGP neighbor table.
•
Specifying a neighbor with an AS number that matches the AS number specified in the router bgp command identifies the neighbor as internal to the local AS. Otherwise, the neighbor is treated as an external neighbor.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
This command takes effect immediately.
•
Use the no version to remove an entry from the table.
•
See neighbor remote-as.
Next-Hop-Self
In some circumstances, using a third-party next hop causes routing problems. These configurations typically involve nonbroadcast multiaccess (NBMA) media. To better understand this situation, first consider a broadcast multiaccess (BMA) media network, as shown in
.
Figure 29: Next-Hop Behavior for Broadcast Multiaccess Media
Routers Toledo, Madrid, and Barcelona are all on the same Ethernet network, which has a prefix of 10.19.7.0/24. When router Toledo advertises prefix 192.168.22.0/23 to router
Copyright © 2013, Juniper Networks, Inc.
107
JunosE 14.3.x BGP and MPLS Configuration Guide
Madrid, it sets the next-hop attribute to 10.19.7.5. Before router Madrid advertises this prefix to router Barcelona, it sees that its own IP address, 10.19.7.7, is on the same subnet as the next hop for the advertised prefix. If router Barcelona can reach router Madrid, then it should be able to reach router Toledo. Router Madrid therefore advertises
192.168.22.0/23 to router Barcelona with a next-hop attribute of 10.19.7.5.
Now consider
Figure 30 on page 108 , which shows the same routers on a Frame
Relay—NBMA—network.
Figure 30: Next-Hop Behavior for Nonbroadcast Multiaccess Media
neighbor next-hop-self
Routers Toledo and Madrid are EBGP peers, as are routers Madrid and Barcelona. When router Toledo advertises prefix 192.168.22.0/23 to router Madrid, router Madrid makes the same comparison as in the BMA example, and leaves the next-hop attribute intact when it advertises the prefix to router Barcelona. However, router Barcelona will not be able to forward traffic to 192.168.22.0/23, because it does not have a direct PVC connection to router Toledo and cannot reach the next hop of 10.19.7.5.
You can use the neighbor next-hop-self command to correct this routing problem. If you use this command to configure router Madrid, the third-party next hop advertised by router Toledo is not advertised to router Barcelona. Instead, router Madrid advertises
192.168.22.0/23 with the next-hop attribute set to its own IP address, 10.19.7.7. Router
Barcelona now forwards traffic destined for 192.168.22.0/23 to the next hop, 10.19.7.7.
Router Madrid then passes the traffic along to router Toledo.
To disable third-party next-hop processing, configure router Madrid as follows: host1(config)#router bgp 319 host1(config-router)#neighbor 10.19.7.8 remote-as 211 host1(config-router)#neighbor 10.19.7.8 next-hop-self
•
Use to prevent third-party next hops from being used on NBMA media such as Frame
Relay. This command is useful in nonmeshed networks such as Frame Relay or where
BGP neighbors may not have direct access to the same IP subnet.
•
Forces the BGP speaker to report itself as the next hop for an advertised route it learned from a neighbor.
108 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override the characteristic for a specific member of the peer group.
•
New policy values are applied to all routes that are sent (outbound policy) or received
(inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
•
Issuing this command automatically removes the neighbor next-hop-unchanged configuration (enabled or disabled) on the peer or peer group. Issuing the no or default version of this command has no effect on the neighbor next-hop-unchanged configuration.
•
Use the no version to disable this feature (and therefore enable next-hop processing of BGP updates). Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor next-hop-self.
Assigning a Weight to a Route
You can assign a weight to a route when more than one route exists to the same destination. A weight indicates a preference for that particular route over the other routes to that destination. The higher the assigned weight, the more preferred the route. By default, the route weight is 32768 for paths originated by the router, and 0 for other paths.
In the configuration shown in
, routers Boston and NY both learn about network 192.68.5.0/24 from AS 200. Routers Boston and NY both propagate the route to router LA. Router LA now has two routes for reaching 192.68.5.0/24 and must decide the appropriate route. If you prefer that router LA direct traffic through router
Boston, you can configure router LA so that the weight of routes coming from router
Boston are higher—more preferred—than the routes coming from router NY. Router LA subsequently prefers routes received from router Boston and therefore uses router Boston as the next hop to reach network 192.68.5.0/24.
Copyright © 2013, Juniper Networks, Inc.
109
JunosE 14.3.x BGP and MPLS Configuration Guide
Figure 31: Assigning a Weight to a Neighbor Connection
110
You can use any of the following three ways to set the weights in routes coming in from router Boston:
•
The neighbor weight command
•
The set weight command in route maps
• An AS-path access list
Using the neighbor weight Command
The following commands assign a weight of 1000 to all routes router LA receives from
AS 100 and assign a weight of 500 to all routes router LA receives from AS 300: host1(config)#router bgp 400 host1(config-router)#neighbor 10.5.5.1 remote-as 100 host1(config-router)#neighbor 10.5.5.1 weight 1000 host1(config-router)#neighbor 10.72.4.2 remote-as 300 host1(config-router)#neighbor 10.72.4.2 weight 500
Router LA sends traffic through router Boston in preference to router NY.
Using a Route Map
A route map instance is a set of conditions with an assigned number. The number after the permit keyword designates an instance of a route map. For example, instance 10 of route map 10 begins with the following: host1(config)#route-map 10 permit 10
In the following commands to configure router LA, instance 10 of route map 10 assigns a weight of 1000 to any routes from AS 100. Instance 20 assigns a weight of 500 to routes from any other AS.
host1(config)#router bgp 400 host1(config-router)#neighbor 10.5.5.1 remote-as 100 host1(config-router)#neighbor 10.5.5.1 route-map 10 in host1(config-router)#neighbor 10.72.4.2 remote-as 300 host1(config-router)#neighbor 10.72.4.2 route-map 20 in
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing host1(config-router)#exit host1(config)#route-map 10 host1(config-route-map)#set weight 1000 host1(config-route-map)#route-map 20 host1(config-route-map)#set weight 500
See JunosE IP Services Configuration Guide for more information about using route maps.
Using an AS-Path Access List
The following commands assign weights to routes filtered by AS-path access lists on router LA: host1(config)#router bgp 400 host1(config-router)#neighbor 10.5.5.1 remote-as 100 host1(config-router)#neighbor 10.5.5.1 filter-list 1 weight 1000 host1(config-router)#neighbor 10.72.4.2 remote-as 300 host1(config-router)#neighbor 10.72.4.2 filter-list 2 weight 500 host1(config-router)#exit host1(config)#ip as-path access-list 1 permit ^100_ host1(config)#ip as-path access-list 2 permit ^300_
Access list 1 permits any route whose AS-path attribute begins with 100 (specified by
^). This permits routes that pass through router Boston, whether they originate in AS 100
(AS path = 100) or AS 200 (AS path = 100 200) or AS 300 (AS path = 100 200 300).
Access list 2 permits any route whose AS-path attribute begins with 300. This permits routes that pass through router NY, whether they originate in AS 300 (AS path = 300) or AS 200 (AS path = 300 200) or AS 100 (AS path = 300 200 100).
The neighbor filter-list commands assign a weight attribute of 1000 to routes passing through router Boston and a weight attribute of 500 to routes passing through router
NY. Regardless of the origin of the route, routes learned through router Boston are preferred.
ip as-path access-list
•
Use to define a BGP access list; use the neighbor filter-list command to apply a specific access list.
•
You can apply access list filters on inbound or outbound BGP routes, or both.
•
You can permit or deny access for a route matching the condition(s) specified by the regular expression.
•
If the regular expression matches the representation of the AS path of the route as an
ASCII string, then the permit or deny condition applies.
•
The AS path allows substring matching. For example, the regular expression 20 matches
AS path = 20 and AS path = 100 200 300, because 20 is a substring of each path. To disable substring matching and constrain matching to only the specified attribute string, place the underscore (_) metacharacter on both sides of the string, for example
_20_.
•
The AS path does not contain the local AS number.
Copyright © 2013, Juniper Networks, Inc.
111
JunosE 14.3.x BGP and MPLS Configuration Guide
neighbor filter-list neighbor weight
•
Use the no version to remove a single access list entry if permit or deny and a path-expression are specified. Otherwise, the entire access list is removed.
•
See ip as-path access-list.
•
Use to apply an AS-path access list to advertisements inbound from or outbound to the specified neighbor, or to assign a weight to incoming routes that match the AS-path access list.
•
You can specify an optional weight value with the weight keyword to assign a relative importance to incoming routes matching the AS-path access list.
•
The name of the access list is a string of up to 32 characters.
•
You can apply the filter to incoming or outgoing advertisements with the in or out keywords.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy.
•
New policy values are applied to all routes that are sent (outbound policy) or received
(inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
•
Use the no version to remove the filter list.
•
See neighbor filter-list.
•
Use to assign a weight to a neighbor connection.
•
All routes learned from this neighbor will have the assigned weight initially.
•
The route with the highest weight will be chosen as the preferred route when multiple routes are available to a particular network.
•
The weights assigned with the set weight commands in a route map override the weights assigned with the neighbor weight and neighbor filter-list commands.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
112 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
New policy values are applied to all routes that are sent (outbound policy) or received
(inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
•
Use the no version to remove the weight assignment.
•
See neighbor weight.
See
for more information about using access lists.
Configuring the Local-Pref Attribute
The local-pref attribute specifies the preferred path among multiple paths to the same destination. The preferred path is the one with the higher preference value. Local preference is used only within an AS, to select an exit point.
To configure the local preference of a BGP path, you can do one of the following:
• Use the bgp default local-preference command to set the local-preference attribute.
• Use a route map to set the local-pref attribute.
Using the bgp default local-preference Command
In
Figure 32 on page 114 , AS 873 receives updates for network 192.168.5.0/24 from AS 32
and AS 17.
Copyright © 2013, Juniper Networks, Inc.
113
JunosE 14.3.x BGP and MPLS Configuration Guide
Figure 32: Configuring the Local-Preference Attribute
The following commands configure router LA: host1(config-router)#router bgp 873 host1(config-router)#neighbor 10.72.4.2 remote-as 32 host1(config-router)#neighbor 10.2.2.4 remote-as 873 host1(config-router)#bgp default local-preference 125
The following commands configure router SanJose: host2(config-router)#router bgp 873 host2(config-router)#neighbor 10.5.5.1 remote-as 17 host2(config-router)#neighbor 10.2.2.3 remote-as 873 host2(config-router)#bgp default local-preference 200
Router LA sets the local preference for all updates from AS 32 to 125. Router SanJose sets the local preference for all updates from AS 17 to 200. Because router LA and router
SanJose exchange local preference information within AS 873, they both recognize that routes to network 192.168.5.0/24 in AS 293 have a higher local preference when they come to AS 873 from AS 17 than when they come from AS 32. As a result, both router LA and router SanJose prefer to reach this network through router Boston in AS 17.
bgp default local-preference
•
Use to change the default local preference value.
•
Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix.
To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current
BGP session.
•
Use the no version to restore the default value, 100.
•
See bgp default local-preference.
114 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Using a Route Map to Set the Local Preference
When you use a route map to set the local preference you have more flexibility in selecting routes for which you can set a local preference based on many criteria, including AS. In the previous section, all updates received by router SanJose were set to a local preference of 200.
Using a route map, you can specifically assign a local preference for routes from AS 17 that pass through AS 293.
The following commands configure router SanJose.
host2(config-router)#router bgp 873 host2(config-router)#neighbor 10.2.2.3 remote-as 873 host2(config-router)#neighbor 10.5.5.1 remote-as 17 host2(config-router)#neighbor 10.5.5.1 route-map 10 in host2(config-router)#exit host2(config)#ip as-path access-list 1 permit ^17 293$ host2(config)#route-map 10 permit 10 host2(config-route-map)#match as-path 1 host2(config-route-map)#set local-preference 200 host2(config-route-map)#exit host2(config)#route-map 10 permit 20
Router SanJose sets the local-pref attributes to 200 for routes originating in AS 293 and passing last through AS 17. All other routes are accepted (as defined in instance 20 of the route map 10), but their local preference remains at the default value of 100, indicating a less-preferred path.
Understanding the Origin Attribute
BGP uses the origin attribute to describe how a route was learned at the origin—the point where the route was injected into BGP. The origin of the route can be one of three values:
•
IGP—Indicates that the route was learned by means of an IGP and, therefore, is internal to the originating AS. All routes advertised by the network command have an origin of
IGP.
•
EGP—Indicates that the route was learned by means of an EGP.
•
Incomplete—Indicates that the origin of the route is unknown—that is, learned from something other than IGP or EGP. All routes advertised by the redistribute command—such as static routes—have an origin of Incomplete. An origin of Incomplete occurs when a route is redistributed into BGP.
Copyright © 2013, Juniper Networks, Inc.
115
JunosE 14.3.x BGP and MPLS Configuration Guide
Figure 33: The Origin Attribute
116
Consider the sample topology shown in
Figure 33 on page 116 . Because routers Albany
and Boston are not directly connected, they learn the path to each other by means of an
IGP (not illustrated).
The following commands configure router Boston: host1(config)#ip route 172.31.125.100 255.255.255.252
host1(config)#router bgp 100 host1(config-router)#neighbor 10.2.25.1 remote-as 100 host1(config-router)#neighbor 10.4.4.1 remote-as 100 host1(config-router)#neighbor 10.3.3.1 remote-as 300 host1(config-router)#network 172.19.0.0
host1(config-router)#redistribute static
The following commands configure router NY: host2(config)#router bgp 100 host2(config-router)#neighbor 10.4.4.1 remote-as 100 host2(config-router)#neighbor 10.2.25.2 remote-as 100 host2(config-router)#network 172.28.8.0 mask 255.255.248.0
The following commands configure router Albany: host3(config)#router bgp 100 host3(config-router)#neighbor 10.4.4.2 remote-as 100 host3(config-router)#neighbor 10.2.25.2 remote-as 100 host3(config-router)#network 192.168.33.0 mask 255.255.255.0
The following commands configure router LA: host4(config)#router bgp 300 host4(config-router)#neighbor 10.3.3.2 remote-as 100 host4(config-router)#network 192.168.204.0 mask 255.255.252.0
host4(config-router)#redistribute isis
Consider how route 172.21.10.0/23 is passed along to the routers in
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
192.168.204.0/22
192.168.204.0/22
192.168.204.0/22
172.21.10.0/23
172.21.10.0/23
172.21.10.0/23
172.21.10.0/23
172.28.8.0/21
172.28.8.0/21
172.28.8.0/21
172.28.8.0/21
172.31.125.100
172.31.125.100
172.31.125.100
172.31.125.100
172.19.0.0/16
172.19.0.0/16
1.
IS-IS injects route 172.21.10.0/23 from router Chicago into BGP on router LA. BGP sets the origin attribute to Incomplete (because it is a redistributed route) to indicate how
BGP originally became aware of the route.
2.
Router Boston learns about route 172.21.10.0/23 by means of EBGP from router LA.
3.
Router NY learns about route 172.21.10.0/23 by means of IBGP from router Boston.
The value of the origin attribute for a given route remains the same, regardless of where you examine it.
shows this for all the routes known to routers NY and LA.
Table 20: Origin and AS Path for Routes Viewed on Different Routers
Route Router Origin AS Path
192.168.204.0/22 Albany IGP 300
NY
LA
Albany
Boston
NY
LA
Boston
NY
LA
Albany
Boston
Albany
Boston
NY
LA
Albany
Boston
IGP
IGP
IGP
Incomplete
Incomplete
Incomplete
Incomplete
IGP
IGP
IGP
IGP
Incomplete
Incomplete
Incomplete
Incomplete
IGP
IGP
300 empty empty empty empty
100
300
300 empty
300
300 empty empty empty
100 empty empty
Copyright © 2013, Juniper Networks, Inc.
117
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 20: Origin and AS Path for Routes Viewed on Different Routers
(continued)
Route Router Origin AS Path
172.19.0.0/16
172.19.0.0/16
192.168.330/24
192.168.330/24
NY
LA
Albany
Boston
IGP
IGP
IGP
IGP empty
100 empty empty
192.168.330/24
192.168.330/24
NY
LA
IGP
IGP empty
100
As a matter of routing policy, you can specify an origin for a route with a set origin clause in a redistribution route map. Changing the origin enables you to influence which of several routes for the same destination prefix is selected as the best route. In practice, changing the origin is rarely done.
Understanding the AS-Path Attribute
The AS-path attribute is a list of the ASs through which a route has passed. Whenever a route enters an AS, BGP prepends the AS number to the AS-path attribute. This feature enables network operators to track routes, but it also enables the detection and prevention of routing loops.
Consider the following sequence of events for the routers shown in
1.
Route 172.21.10.0/23 is injected into BGP by means of router London in AS 47.
2.
Suppose router London advertises that route to router Paris in AS 621. As received by router Paris, the AS-path attribute for route 172.21.10.0/23 is 47.
3.
Router Paris advertises the route to router Berlin in AS 11. As received by router Berlin, the AS-path attribute for route 172.21.10.0/23 is 621 47.
4.
Router Berlin advertises the route to router London in AS 47. As received by router
London, the AS-path attribute for route 172.21.10.0/23 is 11 621 47.
118 Copyright © 2013, Juniper Networks, Inc.
Figure 34: AS-Path Attributes
Chapter 1: Configuring BGP Routing
A routing loop exists if router London accepts the route from router Berlin. Router London can choose not to accept the route from router Berlin because it recognizes from the
AS-path attribute (11 621 47) that the route originated in its own AS 47.
As a matter of routing policy, you can prepend additional AS numbers to the AS-path attribute for a route with a set as-path prepend clause in an outbound route map.
Changing the AS path enables you to influence which of several routes for the same destination prefix is selected as the best route.
Configuring a Local AS
You can change the local AS of a BGP peer or peer group within the current address family with the neighbor local-as command. By using different local AS numbers for different peers, you can avoid or postpone AS renumbering in the event the ASs are merged.
neighbor local-as
•
Use to assign a local AS to the given BGP peer or peer group.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
This command takes effect immediately and automatically bounces the BGP session.
•
Use the no version for an individual peer to restore the value set for the peer group, if present, or set globally for BGP with the router bgp command. Use the no version for a peer group to restore the value set globally for BGP.
•
See neighbor local-as.
The following example commands change the local AS number for peer 104.4.2 from the global local AS of 100 to 32: host1(config)#router bgp 100 host1(config-router)#address-family ipv4 unicast vrf boston host1(config-router)#neighbor 10.4.4.2 remote-as 645 host1(config-router)#neighbor 10.4.4.2 local-as 32
Copyright © 2013, Juniper Networks, Inc.
119
JunosE 14.3.x BGP and MPLS Configuration Guide
Configuring the MED Attribute
If two ASs connect to each other in more than one place, one link or path might be a better choice to reach a particular prefix within or behind one of the ASs. The MED value is a metric expressing a degree of preference for a particular path. Lower MED values are preferred.
Whereas the Local Preference attribute is used only within an AS (to select an exit point), the MED attribute is exchanged between ASs. A router in one AS sends the MED to inform a router in another AS which path the second router should use to reach particular destinations. If you are the administrator of the second AS, you must therefore trust that the router in the first AS is providing information that is truly beneficial to your AS.
You configure the MED on the sending router by using the set metric command in an outbound route map. Unless configured otherwise, a receiving router compares MED attributes only for paths from external neighbors that are members of the same AS. If you want MED attributes from neighbors in different ASs to be compared, you must issue the bgp always-compare-med command.
In
Figure 35 on page 120 , router London in AS 303 can reach 192.168.33.0/24 in AS 73
through router Paris or through router Nice to router Paris.
Figure 35: Configuring the MED
120
The following commands configure router London: host1(config)#router bgp 303 host1(config-router)#neighbor 10.4.4.2 remote-as 73 host1(config-router)#neighbor 10.3.3.2 remote-as 73 host1(config-router)#neighbor 10.5.5.2 remote-as 4 host1(config-router)#network 122.28.8.0 mask 255.255.248.0
The following commands configure router Paris: host2(config)#router bgp 73 host2(config-router)#neighbor 10.4.4.1 remote-as 303 host2(config-router)#neighbor 10.4.4.1 route-map 10 out
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing host2(config-router)#neighbor 10.2.25.1 remote-as 73 host2(config-router)#neighbor 10.6.6.1 remote-as 4 host2(config-router)#neighbor 10.6.6.1 route-map 10 out host2(config-router)#network 192.168.33.0 mask 255.255.255.0
host2(config-router)#exit host2(config)#route-map 10 permit 10 host2(config-route-map)#set metric 50
The following commands configure router Nice: host3(config)#router bgp 73 host3(config-router)#neighbor 10.3.3.1 remote-as 303 host3(config-router)#neighbor 10.3.3.1 route-map 10 out host3(config-router)#neighbor 10.2.25.2 remote-as 73 host3(config-router)#network 172.19.0.0
host3(config-router)#exit host3(config)#route-map 10 permit 10 host3(config-route-map)#set metric 100
The following commands configure router Dublin: host4(config)#router bgp 4 host4(config-router)#neighbor 10.5.5.1 remote-as 303 host4(config-router)#neighbor 10.5.5.1 route-map 10 out host4(config-router)#neighbor 10.6.6.2 remote-as 73 host4(config-router)#network 172.14.27.0 mask 255.255.255.0
host4(config-router)#exit host4(config)#route-map 10 permit 10 host4(config-route-map)#set metric 25
Router London receives updates regarding route 192.168.33.0/24 from both router Nice and router Paris. Router London compares the MED values received from the two routers:
Router Nice advertises a MED of 100 for the route, whereas router Paris advertises a MED of 50. On this basis, router London prefers the path through router Paris.
Because BGP by default compares only MED attributes of routes coming from the same
AS, router London can compare only the MED attributes for route 192.168.33.0/24 that it received from routers Paris and Nice. It cannot compare the MED received from router
Dublin, because router Dublin is in a different AS than routers Paris and Nice.
However, you can use the bgp always-compare-med command to configure router
London to take into account the MED attribute from router Dublin as follows: host1(config)#router bgp 303 host1(config-router)#neighbor 10.4.4.2 remote-as 73 host1(config-router)#neighbor 10.3.3.2 remote-as 73 host1(config-router)#neighbor 10.5.5.2 remote-as 4 host1(config-router)#network 122.28.8.0 mask 255.255.248.0
host1(config-router)#bgp always-compare-med
Router Dublin advertises a MED of 25 for route 192.168.33.0/24, which is lower—more preferred—than the MED advertised by router Paris or router Nice. However, the AS path for the route through router Dublin is longer than that through router Paris. The AS path is the same length for router Paris and router Nice, but the MED advertised by router Paris is lower than that advertised by router Nice. Consequently, router London prefers the path through router Paris.
Copyright © 2013, Juniper Networks, Inc.
121
JunosE 14.3.x BGP and MPLS Configuration Guide
Suppose, however that router Dublin was not configured to set the MED for route
192.168.33.0/24 in its outbound route map 10. Would router London receive a MED of 50 passed along by router Paris through router Dublin? No, because the MED attribute is nontransitive. Router Dublin does not transmit any MED that it receives. A MED is only of value to a direct peer.
bgp always-compare-med
•
Use to enable the comparison of the MED for paths from neighbors in different ASs.
•
Unless you specify the bgp always-compare-med command, the router compares
MED attributes only for paths from external neighbors that are in the same AS.
•
The BGP path decision algorithm selects a lower MED value over a higher one.
•
Unlike local preferences, the MED attribute is exchanged between ASs, but does not leave the AS.
•
The value is used for decision making within the AS only.
•
When BGP propagates a route received from outside the AS to another AS, it removes the MED.
•
Example host1(config-router)#bgp always-compare-med
•
Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix.
To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current
BGP session.
•
Use the no version to disable the feature.
•
See bgp always-compare-med.
set metric
•
Use to set the metric value—for BGP, the MED—for a route.
•
Sets an absolute metric. You cannot use both an absolute metric and a relative metric within the same route map sequence. Setting either metric overrides any previously configured value.
•
Example host1(config)#route-map nyc1 permit 10 host1(config-route-map)#set metric 10
•
Use the no version to delete the set clause from a route map.
•
See set metric.
122 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Missing MED Values
By default, a route that arrives with no MED value is treated as if it had a MED of 0, the most preferred value. You can use the bgp bestpath missing-as-worst command to specify that a route with any MED value is always preferred to a route that is missing the
MED value.
bgp bestpath missing-as-worst
•
Use to set a missing MED value to infinity, the least preferred value.
•
After issuing this command, a route missing the MED is always preferred less than any route that has a MED configured.
•
Example host1(config-router)#bgp bestpath missing-as-worst
•
Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix.
To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current
BGP session.
•
Use the no version to restore the default condition, where a missing MED value is set to 0, the most preferred value.
•
See bgp bestpath missing-as-worst.
Comparing MED Values Within a Confederation
A BGP speaker within a confederation of sub-ASs might need to compare routes to determine the best path to a destination. By default, BGP does not use the MED value when comparing routes originated in different sub-ASs within the confederation to which the BGP speaker belongs. (Within the confederation, routes learned from different sub-ASs are treated as having originated in different places.) You can use the bgp bestpath med confed command to force MED values to be taken into account within a confederation.
bgp bestpath med confed
•
Use to specify that BGP take into account the MED when comparing routes originated in different sub-ASs within the confederation to which the BGP speaker belongs.
•
This command does not affect the comparison of routes that are originated in other
ASs and does not affect the comparison of routes that are originated in other confederations.
•
Example host1(config-router)#bgp bestpath med confed
Copyright © 2013, Juniper Networks, Inc.
123
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix.
To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current
BGP session.
•
Use the no version to restore the default, where the MED is not taken into account.
Suppose a BGP speaker has three routes to prefix 10.10.0.0/16:
•
Route 1 is originated by sub-AS 1 inside the confederation.
•
Route 2 is originated by sub-AS 2 inside the confederation.
•
Route 3 is originated by AS 3 outside the confederation.
•
See bgp bestpath med confed.
BGP compares these routes to each other to determine the best path to the prefix. If you have issued the bgp bestpath med confed command, BGP takes into account the MED when comparing Route 1 with Route 2. However, BGP does not take into account the
MED when comparing Route 3 with either Route 1 or Route 2, because Route 3 originates outside the confederation.
Capability Negotiation
The router accepts connections from peers that perform capability negotiation.
Capabilities are negotiated by means of the open messages that are exchanged when the session is established. The router supports the following capabilities:
• Cisco-proprietary route refresh—Capability code 128
•
Cooperative route filtering—Capability code 3
•
Deprecated dynamic capability negotiation—Capability code 66
• Dynamic capability negotiation—Capability code 67
• Four-octet AS numbers—Capability code 65
•
Graceful restart—Capability code 64
•
Multiprotocol extensions—Capability code 1
• address family IPv4 unicast—AFI 1 SAFI 1
• address family IPv4 multicast—AFI 1 SAFI 2
• address family IPv4 unicast and multicast—AFI 1 SAFI 3
• address family VPN-IPv4 unicast—AFI 1 SAFI 128
•
Route refresh—Capability code 2
The router advertises these capabilities—except for the cooperative route filtering capability—by default. You can prevent the advertisement of specific capabilities with
124 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing the no neighbor capability command. You can also use this command to prevent all capability negotiation with the specified peer.
NOTE: The graceful restart capability is controlled with the bgp graceful-restart and neighbor graceful-restart commands rather than the neighbor capability command. However, the no neighbor capability command will prevent negotiation of the graceful restart capability.
Cooperative Route Filtering
The cooperative route filtering capability—also referred to as outbound route filtering
(ORF)—enables a BGP speaker to send an inbound route filter to a peer and have the peer install it as an outbound filter on the remote end of the session.
You must specify both the type of inbound filter (ORF type) and the direction of ORF capability. The router currently supports prefix-lists as the inbound filter sent by the BGP speaker. The inbound filter sent by the BGP speaker can be a prefix list or a Cisco proprietary prefix list. The BGP speaker must indicate whether it will send inbound filters to peers, accept inbound filters from peers, or both. The router supports both standard and Cisco-proprietary orf messages.
Dynamic Capability Negotiation
If both peers acknowledge support of dynamic capability negotiation, then at any subsequent point after the session is established, either peer can send a capabilities message to the other indicating a desire to negotiate another capability or to remove a previously negotiated capability.
The data field of the capability message contains a list of all the capabilities that can be dynamically negotiated. In earlier versions, now deprecated, the data field did not carry this information. Use the dynamic-capability-negotiation keyword to include the list.
Use the deprecated-dynamic-capability-negotiation keyword to exclude sending the list.
Nondynamic capability negotiation is supported for the cooperative route filtering, four-octet AS numbers, deprecated dynamic capability negotiation, and dynamic capability negotiation capabilities. Dynamic capability negotiation of these capabilities is not supported.
If both sides of the connection advertise support for the new dynamic capability negotiation capability, then the peers negotiate which capabilities are dynamic and which are not.
If both sides of the connection advertise support only for the deprecated dynamic capability negotiation, then the BGP speaker uses dynamic capability negotiation for all capabilities that allow it without attempting to negotiate this with the peer.
Four-Octet AS Numbers
BGP speakers that support four-octet AS and sub-AS numbers are sometimes referred to as “ new” speakers. The four-octet AS numbers are employed by the AS-path and
Copyright © 2013, Juniper Networks, Inc.
125
JunosE 14.3.x BGP and MPLS Configuration Guide
126 aggregator attributes. “ Old” speakers are those that do not support the four-octet numbers.
Two new transitional optional attributes, new-as-path and new-aggregator, are used to carry the four-octet numbers across the old speakers. A new speaker communicating with an old speaker will send the new attributes with the four-octet numbers for locally-originated and propagated routes. The old speaker propagates the new attributes for received routes. The new speaker also sends the AS-path and aggregator attributes with two-octet numbers; any AS number greater than 65535 is replaced with a reserved
AS number, 23456.
Graceful Restarts
When BGP restarts on a router, all of the router’s BGP peers detect that the BGP session transitioned from up to down. The transition causes a routing flap throughout the network as the peers recalculate their best routes in light of the loss of routes from that peering session.
The BGP graceful restart capability reduces the network disruption that normally results from a peer session going down. If the session is with a peer that had previously advertised the graceful restart capability, the receiving BGP speaker marks all routes from that peer in the BGP routing table as stale. BGP keeps these stale routes for a limited time and continues to use these routes to forward traffic. Any existing stale routes from that peer are deleted to account for consecutive restarts.
When the restarting peer reestablishes the session, the receiving BGP speaker replaces the stale routes with the fresh routes it receives from the peer. The restarted peer sends an End-of-RIB marker to signal when it has finished sending all its routes to the BGP speaker. Until this point, BGP has still been using the stale routes to forward traffic. Upon receipt of the End-of-RIB marker, the BGP speaker flushes any remaining stale routes from the restarted peer.
The End-of-RIB marker is an update message that contains no advertised or withdrawn prefixes; it is sent only to BGP speakers that have previously advertised the graceful restart capability.
The receiving speaker also sends its own routes to the restarted speaker, and sends an
End-of-RIB marker when it completes the update. The restarted peer defers reinitiating the BGP best-path selection process until it has received this marker from all peers with which it had a session in the established state and from which it had received an
End-of-RIB marker before it restarted.
After running the selection process to pick the best route to all prefixes using the fresh routes, BGP then installs the best routes in the IP routing table on the restarted peer. Any of these that are best overall routes to a prefix are then pushed by the router to the forwarding tables on the line modules.
By waiting for all restarted peers to send the End-of-RIB marker, BGP risks delaying the initiation of the best path decision process indefinitely due to a single very slow peer. For a specific peer, you can avoid this delay by hard clearing the peer or issuing the clear ip bgp wait-end-of-rib command. Either method removes that peer from the set of peers for which BGP is awaiting an End-of-RIB marker. Alternatively, you can minimize this
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing effect by using the bgp graceful-restart path-selection-defer-time-limit command to specify a maximum period that the restarted peer waits for the marker from its peers.
Note that the receiving peer does not defer its best-path selection process while waiting for a restarted peer to reestablish a session. The receiving peer continues to use the stale routes from the restarted peer in the decision process. When it flushes stale routes, the receiving peer then uses the freshly updated routes.
A restarting peer must bring the session back up and refresh its routes within a limited period, or BGP on the receiving peer will flush all the stale routes. When a BGP speaker advertises the graceful restart capability, it also advertises how long it expects to take to reestablish a session if it restarts. If the session is not reestablished within this restart period, the speaker’s peers flush the stale routes from the speaker. You can use the bgp graceful-restart restart-time command to modify the restart period advertised to all peers; the neighbor graceful-restart restart-time command modifies the restart period advertised to specific peers or peer groups. A receiving peer starts the timer as soon as it recognizes that the session with the restarting peer has transitioned to down.
The receiving peer also has a configurable timer that starts when it recognizes that the session with the restarting peer has gone down. The bgp graceful-restart stalepaths-time command determines how long a receiving peer is willing to use stale paths from any restarted peer; the neighbor graceful-restart stalepaths-time command does the same for a specified restarted peer or peer group. If the receiving peer does not receive an
End-of-RIB marker from the restarted peer before the stalepaths timer expires, the receiving peer flushes all stale routes from the peer.
In this release, BGP supports the graceful restart capability to inform peers that the forwarding state for IPv6 address families, namely unicast, multicast, VPN unicast, and unicast labeled subsequent address family identifiers (SAFIs), can be preserved during a stateful SRP switchover. MPLS also provides high availability support for IPv6 by preserving the MPLS state for IPv6 interfaces during a stateful SRP switchover. This capability of MPLS enables BGP to support graceful restart for IPv6 labeled address families. During a restart, BGP acts as a restarting speaker for the IPv6 unlabeled and labeled address-families. The function of BGP as a graceful restart helper for both IPv4 and IPv6 address families had been available in lower-numbered releases, and there is no change to this functionality in this release.
NOTE: The function of BGP as a graceful restart helper for both IPv4 and
IPv6 address families had been available in lower-numbered releases, and there is no change to this functionality in this release.
bgp graceful-restart
•
Use to enable the BGP graceful restart capability.
•
Advertisement of the graceful restart capability is disabled by default.
•
The no neighbor capability negotiation command prevents the advertisement of all
BGP capabilities, including graceful restart, to the specified peers.
•
This command takes effect immediately and automatically bounces the session.
Copyright © 2013, Juniper Networks, Inc.
127
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Example host1(config-router)#bgp graceful-restart
•
Use the no version to disable advertisement of the graceful restart capability. Use the default version to restore the default condition, of not advertising this capability.
•
See bgp graceful-restart.
bgp graceful-restart path-selection-defer-time-limit
•
Use to set the maximum time a restarted BGP speaker defers reinitiating the best-path selection process.
•
This command takes effect immediately and automatically bounces the session.
•
Example host1(config-router)#bgp graceful-restart path-selection-defer-time-limit 180
•
Use the no version to restore the default value, 120 seconds.
•
See bgp graceful-restart path-selection-defer-time-limit.
bgp graceful-restart restart-time
•
Use to set the time BGP advertises to all peers within which it expects to reestablish a session after restarting. Peers flush stale routes from the speaker if the session is not restarted within this period.
•
Specify an interval shorter than the stalepaths time.
•
This command takes effect immediately and automatically bounces the session.
•
Example host1(config-router)#bgp graceful-restart restart-time 240
•
Use the no version to restore the default value, 120 seconds.
•
See bgp graceful-restart restart-time.
bgp graceful-restart stalepaths-time
•
Use to set the maximum time BGP waits to receive an End-of-RIB marker from any restarted peer before flushing all remaining stale routes from that peer. The timer begins when BGP recognizes that the peer session has gone down.
•
This command prevents an excessive delay in BGP reconvergence due to a peer that brings a session back up but is slow to send fresh routes.
•
Specify an interval longer than the restart time.
•
This command takes effect immediately and automatically bounces the session.
•
Example host1(config-router)#bgp graceful-restart stalepaths-time 480
•
Use the no version to restore the default value, 360 seconds.
•
See bgp graceful-restart stalepaths-time.
128 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
clear ip bgp wait-end-of-rib
•
Use to clear a peer or peer group from the set of peers for which BGP is waiting to receive an End-of-RIB marker after a peer restart.
•
Alternatively, performing a hard clear of a peer without this keyword has the same effect.
•
This command takes effect immediately.
•
Example host1#clear ip bgp 192.168.1.158 wait-end-of-rib
•
There is no no version.
•
See clear ip bgp wait-end-of-rib.
neighbor graceful-restart
•
Use to control the advertisement of the BGP graceful restart capability for specified peers or peer groups.
•
Advertisement of the graceful restart capability is disabled by default.
•
The no neighbor capability negotiation command prevents the advertisement of all
BGP capabilities, including graceful restart, to the specified peers, but does not affect global advertisement of the graceful restart capability.
•
This command takes effect immediately and automatically bounces the session.
•
Example host1(config-router)#no neighbor 10.21.3.5 graceful-restart
•
Use the no version to disable advertisement of the graceful restart capability for specified peers or peer groups. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the capability configuration.
•
See neighbor graceful-restart.
neighbor graceful-restart restart-time
•
Use to set the time BGP advertises to specified peers or peer groups within which it expects to reestablish a session after restarting. Peers flush stale routes from the speaker if the session is not restarted within this period.
•
Specify an interval shorter than the stalepaths time.
•
This command takes effect immediately and automatically bounces the session.
•
Example host1(config-router)#neighbor graceful-restart restart-time 240
•
Use the no version to restore the default value, 120 seconds.
•
See neighbor graceful-restart restart-time.
neighbor graceful-restart stalepaths-time
Copyright © 2013, Juniper Networks, Inc.
129
JunosE 14.3.x BGP and MPLS Configuration Guide
130
•
Use to set the maximum time BGP waits to receive an End-of-RIB marker from the specified restarted peer or peer group before flushing all remaining stale routes from that peer. The timer begins when BGP recognizes that the peer session has gone down.
•
This command prevents an excessive delay in BGP reconvergence due to a peer that brings a session back up but is slow to send fresh routes.
•
Specify an interval longer than the restart time.
•
This command takes effect immediately and automatically bounces the session.
•
Example host1(config-router)#neighbor graceful-restart stalepaths-time 480
•
Use the no version to restore the default value, 360 seconds.
•
See neighbor graceful-restart stalepaths-time.
Configuring Hold Timers for Successful Graceful Restart in Scaled Scenarios
In a scaled environment, we recommend that you increase the hold timers for the following protocols to appropriate values, based on the level of complexity of the network and scaling settings, so as to enable graceful restart to be completed successfully.
• BGP
•
IS-IS
•
LDP
• OSPF
• RSVP
Consider a scenario in which a provider edge router, PE1, at one side of the service provider core is connected to a provider core router, P, which is a label-switched router (LSR) that carries traffic for the VPN tunnel. The core router, P, is connected to another provider edge router, PE2, which provides egress from the VPN. Both PE1 and PE2 routers communicate with customer sites through a direct connection to a customer edge (CE) device that sits at the edge of the customer site.
PE1 is configured for graceful restart and PE2 functions as the helper node, and each PE router is configured with 1500 VRFs and 1500 adjacencies. In such an environment, you need to perform the following steps:
1.
On PE1, which is the restarting router, use the hello hold-time command in LDP Profile
Configuration mode to modify the period for which an LSR maintains link hello records before another link hello is sent as 90 seconds.
host1(config)#mpls ldp interface profile ldp1 host1(config-ldp)#hello hold-time 90
2.
On the interface that connects PE1 to the core router, P, use the isis hello-interval command in Interface Configuration mode to set the frequency at which the router sends hello packets on the specified interface as 30 seconds.
host1(config-if)#isis hello-interval 30
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
neighbor capability
3.
On PE2, which is the helper router, use the bgp graceful-restart stalepaths-time command in Router Configuration mode to set the maximum time BGP waits to receive an End-of-RIB marker from any restarted peer before flushing all remaining stale routes from that peer as 3600 seconds.
host1(config-router)#bgp graceful-restart stalepaths-time 3600
This condition can occur even in environments that are not scaled to the maximum limits and contain minimal subscriber connections or attribute definitions.
We recommend that you perform IS-IS graceful restart only with point-to-point adjacencies because of certain limitations that exist with graceful restart support for
LAN interfaces. IS-IS graceful restart (nonstop forwarding) does not work on the broadcast interface when the restarting router is the designated intermediate system (DIS). Graceful restart works properly when the restarting router is not the DIS.
Route Refresh
If the router detects that a peer supports both Cisco-proprietary and standard route refresh messages, it uses the standard route refresh messages.
•
Use to control the advertisement of BGP capabilities to peers. Capability negotiation and advertisement of all capabilities are enabled by default.
•
You can specify the deprecated-dynamic-capability-negotiation, dynamic-capability-negotiation, four-octet-as-numbers, orf, route-refresh, and route-refresh-cisco capabilities. The graceful restart capability is controlled by specific graceful-restart commands.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
You cannot configure the receive direction for the orf capability for a peer that is a member of a peer group or for a peer.
•
If you issue the route-refresh or route-refresh-cisco keywords, the command takes effect immediately. If dynamic capability negotiation was negotiated for the session, a capability message is sent to inform the peer of the new capability configuration. If dynamic capability negotiation was not negotiated for the session, the session is bounced automatically.
•
If you issue the deprecated-dynamic-capability-negotiation, dynamic-capability-negotiation, four-octet-as-numbers, negotiation, or orf keywords, the command takes effect immediately and bounces the session.
•
If the BGP speaker receives a capability message for a capability that BGP did not previously advertise in the dynamic capability negotiation capability, BGP sends a notification to the peer with the error code “ capability message error” and error subcode
“ unsupported capability code.”
Copyright © 2013, Juniper Networks, Inc.
131
JunosE 14.3.x BGP and MPLS Configuration Guide
•
IPv6 ORF prefix lists are not supported. Therefore you can specify an IPv6 address with the orf keyword only within the IPv4 address family and when you want to advertise
IPv4 routes to IPv6 peers.
•
Example host1(config-router)#neighbor 10.6.2.5 capability orf prefix-list both
•
Use the no version to prevent advertisement of the specified capability or use the negotiation keyword with the no version to prevent all capability negotiation with the specified peer. Use the default version to restore the default, advertising the capability.
•
See neighbor capability.
Interactions Between BGP and IGPs
Interactions between BGP and an interior gateway protocol are more likely to occur in an enterprise topology than in a service provider topology. You can also encounter interactions when configuring small test topologies. The main interaction factors are the following:
•
Synchronization between BGP and IGPs
•
Administrative distances for routes learned from various sources
Synchronizing BGP with IGPs
In
Figure 36 on page 133 , AS 100 provides transit service but does not run BGP on all of
the routers in the AS. In this situation, you must redistribute BGP into the IGP so that the non-BGP routers—for example, router Albany—learn how to forward traffic to customer prefixes. If BGP converges faster than the IGP, a prefix might be advertised to other ASs before that prefix can be forwarded.
For example, suppose router LA advertises a route to router Boston using EBGP, and router Boston propagates that route to router NY using IBGP. If router NY propagates the route to router Chicago before the IGP within AS 100 has converged—that is, before router Albany learns the route—then router Chicago might start sending traffic for that route before router Albany can forward that traffic.
132 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Figure 36: Synchronization
Synchronization solves this problem by preventing a BGP speaker from advertising a route over an EBGP session until all routers within the speaker’s AS have learned about the route. If the AS contains routers connected by means of an IGP, the BGP speaker cannot propagate a BGP route that it learned from a peer until an IGP route to the prefix has been installed in the BGP speaker’s IP routing table. The BGP speaker advertises the
BGP route externally even if the IGP route is better than the BGP route. By contrast, if synchronization is disabled, a BGP speaker propagates a BGP route learned from a peer only if it is the best route to the prefix in the IP routing table.
Synchronization is enabled by default. However, you must configure redistribution of external routes into the IGP, or the routing tables will not receive the IGP routes.
NOTE: When you create an address family for a VRF, synchronization is automatically disabled for that address family.
If synchronization is enabled and if redistribution is configured for the networks in
Figure 36 on page 133 , router NY checks its IGP routing table for a route to 192.56.0.0/16
when it learns about the prefix from the IBGP session with router Boston. If the route is not present, the prefix is not reachable through router Albany, so router NY does not advertise it as available. Router NY keeps checking its IGP routing table; if the route appears, router NY knows that it can pass traffic to the prefix and advertises the route by means of EBGP to router Chicago.
In practice, service providers rarely redistribute BGP into an IGP because existing IGPs cannot handle the full Internet routing table (about 100,00 routes). Instead, all routers in an AS typically run BGP; in these cases it is advisable to turn synchronization off everywhere.
Disabling Synchronization
Because the routes learned by means of EBGP are extensive, redistributing those routes into your IGP consumes processor and memory resources. You can disable synchronization if your AS does not pass traffic from one AS to another or if all the transit routers in your
AS run BGP.
shows the same configuration as in the previous
Copyright © 2013, Juniper Networks, Inc.
133
JunosE 14.3.x BGP and MPLS Configuration Guide example, except that all the routers in AS 100 now run IBGP. As a result, all the routers receive updates learned by the area border routers from external BGP speakers.
Figure 37: Disabling Synchronization
134
If synchronization is disabled, a BGP speaker propagates a BGP route learned from a peer only if it is the best route to the prefix in the IP routing table. However, the speaker does advertise the routes that it originates.
The following commands show how to configure routers Boston, NY, and Chicago (shown in
) with synchronization disabled for routers NY and Boston. The no synchronization command enables router NY to put the route to 192.56.0.0/16 in its
IP routing table and advertise it to router Chicago without learning about 192.56.00/16 from router Albany. The command also enables router Boston to put the route to
192.30.0.0/16 in its IP routing table and advertise it to router LA without learning about
192.30.00/16 from router Albany.
To configure router Boston: host1((config)#router bgp 100 host1(config-router)#neighbor 2.2.2.2 remote-as 100 host1(config-router)#neighbor 4.4.4.1 remote-as 100 host1(config-router)#neighbor 1.1.1.2 remote-as 300 host1(config-router)#no synchronization
To configure router NY: host2(config)#router bgp 100 host2(config-router)#neighbor 3.3.3.2 remote-as 200 host2(config-router)#neighbor 2.2.2.1 remote-as 100 host2(config-router)#neighbor 4.4.4.3 remote-as 100 host2(config-router)#no synchronization
To configure router Albany: host3(config)#router bgp 100 host3(config-router)#neighbor 4.4.4.4 remote-as 100 host3(config-router)#neighbor 4.4.4.2 remote-as 100 host3(config-router)#no synchronization
To configure router Chicago:
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing host4(config)#router bgp 200 host4(config-router)#neighbor 3.3.3.1 remote-as 100
To configure router LA: host5(config)#router bgp 300 host5(config-router)#neighbor 1.1.1.1 remote-as 100 host5(config-router)#network 192.56.0.0
synchronization
•
Use to enable and disable synchronization between BGP and an IGP.
•
Synchronization is enabled by default. However, creating an address family for a VRF automatically disables synchronization for that address family.
•
This command takes effect immediately.
•
Use the no version to advertise a route without waiting for the IGP to learn a route to the prefix.
•
See synchronization.
Setting the Administrative Distance for a Route
The administrative distance is an integer in the range 0–255 that is associated with each route known to a router. The distance represents how reliable the source of the route is considered to be. A lower value is preferred over a higher value. An administrative distance of 255 indicates no confidence in the source; routes with this distance are not installed in the routing table. As shown in
Table 21 on page 135 , default distances are provided for
each type of source from which a route can be learned.
Table 21: Default Administrative Distances for Route Sources
Route Source Default Distance
Connected interface
Static route
External BGP
OSPF
IS-IS
0
1
20
110
115
RIP
Internal BGP
Unknown
120
200
255
Copyright © 2013, Juniper Networks, Inc.
135
JunosE 14.3.x BGP and MPLS Configuration Guide
distance bgp
136
If the IP routing table contains several routes to the same prefix—for example, an OSPF route and an IBGP route—the route with the lowest administrative distance is used for forwarding.
By default, BGP propagates received BGP routes to EBGP routes only if the BGP route is used for forwarding traffic—that is, if it is the route with the lowest administrative distance in the IP forwarding table. However, you can modify this behavior by using the bgp advertise-inactive command. See
“Advertising Inactive Routes” on page 61
for more information.
You can use the distance bgp command to configure the administrative distance associated with routes. If you choose to set an administrative distance, you must specify a value for all three of the following types of routes:
• external—Administrative distance for BGP external routes. External routes are routes for which the best path is learned from a BGP peer external to the AS. Acceptable values are from 1 to 255. The default value is 20.
• internal—Administrative distance for BGP internal routes. Internal routes are those routes that are learned from a BGP peer within the same AS. Acceptable values are from 1 to 255. The default value is 200.
• local—Administrative distance for BGP local routes. Local routes are those routes locally originated by BGP. BGP can locally originate routes if you issue the network command, if you configure redistribution into BGP, or by means of a non-AS-set aggregate route. Acceptable values are from 1 to 255. The default value is 200.
CAUTION: Changing the administrative distance of BGP internal routes is considered dangerous and is not recommended. One problem that can arise is the accumulation of routing table inconsistencies, which can break routing.
You can use the distance bgp command to configure these preferences. The following commands leave the internal distance at 200, set the external distance to 150, and set the local distance to 80: host1(config)#router bgp 100 host1(config-router)#network 172.28.0.0
host1(config-router)#neighbor 156.128.5.5 remote-as 310 host1(config-router)#neighbor 142.132.1.1 remote-as 50 host1(config-router)#distance bgp 150 200 80
•
Use to set the administrative distance for all BGP routes.
•
You must specify the following:
•
external-distance—Administrative distance for routes external to the AS in the range
1–255. The default is 20.
•
internal-distance—Administrative distance for routes internal to the AS in the range
1–255. The default is 200.
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
local-distance—Administrative distance for local routes in the range 1–255. The default is 200.
•
The default value is 20 for external routes, 200 for internal route, and 200 for local routes.
•
The new distance is applied to all routes that are subsequently placed in the IP routing table. To apply the new distance to routes that are already present in the IP routing table, you must use the clear ip routes * command to reinstall BGP routes in the IP routing table.
•
Use the no version to return the distances to their default values, 20, 200, and 200.
•
See distance bgp.
Example 1 Routes learned from other sources can be preferred to routes learned by means of BGP.
Consider the network structure shown in
Figure 38: Administrative Distances
Suppose router KC originates 172.17.24.0/21 and advertises the route to router Chicago by means of EBGP. Both router KC and router Chicago are directly connected to the network represented by 172.17.24.0/21. If you issue the show ip route command on router
Chicago, the BGP route does not appear. Instead, only the connected route is displayed.
Both routes are in the IP routing table, but the show ip route command displays only the
best route. (Use the show ip route all command to display all best routes; in this case the BGP route and the connected route.) Connected routes have a default distance of
0. Routes learned by means of EBGP have a default value of 20. The connected route is a better route than the EBGP route and appears in the command display.
In practice, if two BGP peers are connected to the same network, both peers should originate the route.
Example 2 Consider the network structure shown in
. Router Chicago originates prefix 192.168.11.0/24 and advertises it by means of EBGP to router Albany. Router Albany advertises the route to router Boston by means of IBGP.
Router Albany also redistributes the route into the interior gateway protocol RIP, which informs router NY of the route. Router NY propagates the route to router Boston by means of RIP, from which it is injected into BGP.
In this example, both router Albany and router Boston have synchronization turned on.
When synchronization is on, BGP propagates a received route to EBGP peers, even if the
Copyright © 2013, Juniper Networks, Inc.
137
JunosE 14.3.x BGP and MPLS Configuration Guide
IP forwarding table contains a non-BGP route with a better administrative distance than the BGP route. This example demonstrates why synchronization is needed.
Figure 39: Administrative Distance and Synchronization
Router Boston does not advertise the route externally to router Philly. At first, this is because router Boston has not yet heard about the prefix from router NY, and therefore the IGP route does not appear in router Boston’s IP routing table.
BGP routes are not propagated until a route to the prefix by means of any IGP appears in the IP routing table. In other words, routers connected by means of an IGP must have a route to the prefix before a BGP speaker can advertise the route it learned from a peer.
When the RIP route appears on router Boston, the router has both an IBGP route and a
RIP route to the same prefix. Even though the RIP route has a better administrative distance, the IBGP route is propagated to router Philly because synchronization is turned on.
Configuring Backdoor Routes
In certain network topologies, a BGP speaker might learn routes to the same prefix from an external BGP peer and by means of an IGP protocol. Consider the network structure shown in
.
A company has established an OSPF link between routers NY and Boston. This private link between the two routers is known as a backdoor link. Router NY learns two routes to prefix 172.19.0.0/16; one by means of OSPF from router Boston, and one by means of
EBGP from router LA through router SanDiego. As was shown in
,
EBGP routes have an administrative distance of 20 and are preferred over IGP routes, which have much higher administrative distances. In this example, the longer path by means of EBGP is preferred over the OSPF backdoor path with its distance of 110.
138 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Figure 40: Backdoor Route
You can modify this behavior by issuing the network backdoor command on router NY: host1(config)#router bgp 300 host1(config-router)#neighbor 10.4.4.1 remote-as 400 host1(config-router)#network 172.19.0.0 backdoor
Unlike the typical network command, network backdoor does not cause the BGP speaker to advertise the specified prefix. Instead, it sets the administrative distance for the EBGP path to that prefix to the same value as a route learned by means of IBGP. That is, the
EBGP administrative distance is changed from the highly preferred value of 20 to the highly unpreferred value of 200. In
Figure 40 on page 139 , this change in value results in
the backdoor OSPF being more preferred as a way to reach prefix 172.19.0.0/16.
network backdoor
•
Use to cause a backdoor IGP route to be preferred over an EBGP route to the same prefix by setting the administrative distance of the EBGP route to that of an IBGP route,
200.
•
Issuing this command does not cause the BGP speaker to advertise the specified route.
•
This command takes effect immediately.
•
Example host1(config-router)#network 10.53.42.0 backdoor
•
Use the no version to restore the default distance to the EBGP route, 20.
•
See network.
Setting the Maximum Number of Equal-Cost Multipaths
You can use the maximum-paths command to specify the number of equal-cost paths to the same destination that BGP can submit to the IP routing table.
If you set the value to 1, the router installs the single best route in the IP routing table. If you set the value greater than 1, the router installs that number of parallel routes.
By default, for IBGP routes, unequal-cost multipaths are installed in the routing table.
You must use the equal-cost keyword with the maximum-paths ibgp command to enable equal-cost multipaths to be used in the routing table for traffic forwarding. IGP
Copyright © 2013, Juniper Networks, Inc.
139
JunosE 14.3.x BGP and MPLS Configuration Guide can use an asymmetric set of paths for a given destination. This functionality is called unequal-cost load balancing. Unequal-cost load balancing enables traffic to be distributed among multiple unequal-cost paths to ensure higher overall throughput and reliability.
maximum-paths
•
Use to set the maximum number of equal-cost multipaths.
•
Specify a value in the range 1–16; the default value is 1.
•
If you do not specify a keyword, the maximum number applies only to routes learned from external peers. If you specify the ibgp keyword, the maximum number applies only to routes received from internal peers. If you specify the eibgp keyword (valid only for VRF IPv4 unicast or IPv6 unicast address families), the maximum number applies to routes received from internal peers and external peers.
•
To prevent the possibility of routing loops from occurring, the IGP metric to the BGP next hop must be equal to the best-path IGP metric, unless you explicitly configure the router for unequal-cost IBGP multipath, in which case you need to manually configure settings to avoid the occurrence of routing loops. For example, a sufficient, but not necessary, condition to ensure that there is no routing loop for a given route, is that all of the IGP next hop routers have metrics that are less than or equal to the lowest local metric. The load-sharing algorithms based on hashing determines the packets that are looped. When you configure unequal-cost paths for IBGP using the maximum-paths ibgp command without specifying the equal-cost keyword, multiple IBGP routes to the same destination prefix might be installed in the routing table, although they all do not have equal IGP costs to the BGP next hop. This method of operation might cause routing loops.
•
This command takes effect immediately; it does not bounce the session.
•
You can specify the maximum number of equal-cost multipaths in the context of the virtual router, an IPv4 unicast or IPv6 unicast address family, or a VRF specified in the context of an IPv4 unicast or IPv6 unicast address family.
•
This command is not supported for VPNv4 or VPNv6 address families.
•
Example 1 host1(config-router)#maximum-paths 3
•
Example 2 host1:vr1(config-router-af)#maximum-paths ibgp 5
•
Use the no version to restore the default value, 1.
•
See maximum-paths.
Detecting Peer Reachability with BFD
You can configure a Bidirectional Forwarding Detection (BFD) session with a BGP neighbor or peer group to determine relatively quickly whether the neighbor or peer group is reachable. For more information on BFD, see JunosE IP Services Configuration Guide. BFD is supported only for single-hop IBGP and EBGP sessions with either IPv4 or IPv6 neighbors
140 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing in the core or within a VRF. BFD is not supported for multi-hop BGP sessions (IBGP multi-hop or EBGP multi-hop). BFD behavior is identical for IBGP and EBGP single-hop sessions, and for IPv4 and IPv6 neighbors.
When you configure BFD for a BGP session, the normal BGP keepalive mechanism is not disabled. Unless you configure BGP not to do so, BGP still sends keepalive messages and brings the BGP session down if the holdtimer expires.
When you configure this feature, BGP requests BFD to start a BFD protocol session as soon as the BGP session enters the established state. BGP allows the BFD protocol session to come up only when the source address of received BFD packets matches the destination address of the BGP neighbor. When the BFD protocol session comes up, BGP logs this event and reports the session in subsequent show commands. If the BFD protocol session goes down, BGP immediately brings down the BGP session and takes all associated actions.
Whenever a BGP session leaves the established state, BGP requests BFD to stop the
BFD protocol session. BGP also requests BFD to bring the BFD protocol session down and inform BGP if the local interface goes down.
To enable a BGP session to come up even if the remote peer does not support BFD or has not been configured to use BFD, the following behavior applies:
•
The BGP session can come up when the BFD protocol session is not yet up.
• The BGP session can stay up even when the BFD protocol session never comes up.
You can specify a desired rate for receiving BFD packets from the peer, transmitting them to the peer, or both, by setting a desired time interval between the packets. The actual timer values can be different as a result of other applications requesting BFD protocol sessions on the same interface with different timer values, as a result of timer value negotiation between the local and remote BFD speakers, or both.
In the following example, the router is configured to send BFD packets to peer 10.25.43.1
with a minimum interval of 450 milliseconds between the packets, and to accept BFD packets from the peer only with the same minimum interval: host1(config)#router bgp 100 host1(config-router)#neighbor 10.25.43.1 bfd-liveness-detection minimum-interval 450
neighbor bfd-liveness-detection
•
Use to enable BGP to detect whether a neighbor is unreachable by means of a BFD protocol session to the neighbor.
•
The peers in a BGP adjacency use the configured values to negotiate the actual transmit intervals for BFD packets.
•
You can use the minimum-transmit-interval keyword to specify the interval at which the local peer proposes to transmit BFD control packets to the remote peer. The default value is 300 milliseconds.
Copyright © 2013, Juniper Networks, Inc.
141
JunosE 14.3.x BGP and MPLS Configuration Guide
•
You can use the minimum-receive-interval keyword to specify the minimum interval at which the local peer must receive BFD control packets from the remote peer. The default value is 300 milliseconds.
•
You can use the minimum-interval keyword to specify the same value for both of those intervals. Configuring a minimum interval has the same effect as configuring the minimum receive interval and the minimum transmit interval to the same value.
The default value is 300 milliseconds.
•
You can use the multiplier keyword to specify the detection multiplier value. The calculated BFD liveness detection interval can be different on each peer. The multiplier value is roughly equivalent to the number of packets that can be missed before the
BFD session is declared to be down. The default value is 3.
•
For details on liveness detection negotiation, see JunosE IP Services Configuration Guide.
•
You can change the BFD liveness detection parameters at any time without stopping or restarting the existing session; BFD automatically adjusts to the new parameter value. However, no changes to BFD parameters take place until the values resynchronize with each peer.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
This command takes effect immediately.
•
The BGP session does not flap when you enable BFD for a session that is already up or change the BFD timer values for an established session.
•
If you remove the BFD configuration while the BGP sessions and the BFD protocol session are up, BFD moves to the Admin Down state and communicates the change to the peer to enable the client protocols to handle this in a seamless manner without going down. For the Admin Down state to work, the peer, which receives the Admin
Down state notification, must have the capability to distinguish between administratively down state and real link down.
NOTE: The BFD Admin Down state is used to bring down a BFD session administratively, to protect client applications from BFD configuration removal, license issues, and clearing of BFD sessions.
•
Use the no version to disable BFD liveness detection for the neighbor. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor bfd-liveness-detection.
BFD and BGP Graceful Restart
So that BFD can maintain its BFD protocol sessions across a BGP graceful restart, BGP requests that BFD set the C bit to 1 in transmitted BFD packets. When the C bit is set to
142 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
1, BFD can maintain its session in the forwarding plane in spite of disruptions in the control plane. Setting the bit to 1 gives BGP neighbors acting as a graceful restart helper the most accurate information about whether the forwarding plane is up.
When BGP is acting as a graceful restart helper and the BFD session to the BGP peer is lost, one of the following actions takes place:
• If the C bit received in the BFD packets was 1, BGP immediately flushes all routes, determining that the forwarding plane on the BGP peer has gone down.
•
If the C bit received in the BFD packets was 0, BGP marks all routes as stale but does not flush them because the forwarding plane on the BGP peer might be working and only the control plane has gone down.
Managing a Large-Scale AS
BGP requires that IBGP peers be fully meshed, creating significant routing overhead as the number of peers increases. The number of IBGP sessions increases rapidly with the number of routers:
For example, in an AS with 9 BGP peers, the peers can conduct 36 sessions:
BGP provides the following two alternative configuration strategies to reduce the number of fully meshed peers:
•
Configure confederations.
• Configure route reflectors.
Both of these strategies are complex and can create their own problems. Neither strategy is typically used unless the mesh of IBGP peers approaches 100 sessions per peer.
Configuring a Confederation
IBGP requires that BGP speakers within an AS be fully meshed. You can reduce the IBGP mesh inside an AS by subdividing the AS into a confederation of sub-ASs. Each sub-AS must be fully meshed internally, but the sub-ASs do not have to be fully meshed with each other. Confederations are most useful when the number of IBGP speakers within an AS increases to the point that each router has about 100 peering sessions.
shows a simpler topology. AS 29 consists of 10 fully meshed IBGP peers (for clarity, only the BGP sessions are shown). Border router Salem has an EBGP
Copyright © 2013, Juniper Networks, Inc.
143
JunosE 14.3.x BGP and MPLS Configuration Guide session with a neighbor in AS 325. Border router Boston has an EBGP session with a neighbor in AS 413.
Figure 41: A Fully Meshed Autonomous System
144
illustrates how you can create three sub-ASs within AS 29 to greatly reduce the number of peering sessions. According to common practice, use a number from the private range of AS numbers—from 64512 to 65535—to identify each sub-AS.
AS 29 is now a confederation of three sub-ASs: AS 64720, AS 64721, and AS 64722. Each sub-AS consists of fully meshed IBGP peers. A slightly modified version of EBGP runs between the sub-ASs: It acts like IBGP within an AS because the local-pref, MED, and next-hop attributes are preserved across the sub-AS boundaries. To the external neighbors, AS 29 appears the same as it ever was.
Copyright © 2013, Juniper Networks, Inc.
Figure 42: A Confederation of Subautonomous Systems
Chapter 1: Configuring BGP Routing
The following commands partially configure router Salem: host1(config)#router bgp 64720 host1(config-router)#bgp confederation identifier 29 host1(config-router)#bgp confederation peers 64721 64722 host1(config-router)#neighbor 10.2.25.4 remote-as 64720 host1(config-router)#neighbor 10.2.25.8 remote-as 64721 host1(config-router)#neighbor 10.2.25.2 remote-as 325
The bgp confederation identifier command establishes router Salem as a member of
Confederation 29. The bgp confederation peers command specifies that sub-AS 64721 and sub-AS 64722 are members of the same confederation as the sub-AS that includes router Salem. The neighbor remote-as commands specify the IBGP connection with a neighbor in sub-AS 64720 and the EBGP connections with neighbors in sub-AS 64721 and outside the confederation in AS 325.
Similarly, the following commands partially configure router Harvard: host2(config)#router bgp 64721 host2(config-router)#bgp confederation identifier 29 host2(config-router)#bgp confederation peers 64720 64722 host2(config-router)#neighbor 10.2.25.7 remote-as 64720
From router Newport’s perspective, router Salem is simply a member of AS 29: host3(config)#router bgp 325 host3(config-router)#neighbor 10.2.25.6 remote-as 29
Copyright © 2013, Juniper Networks, Inc.
145
JunosE 14.3.x BGP and MPLS Configuration Guide
From router Mason’s perspective, router Boston is simply a member of AS 29:
bgp confederation identifier
host4(config)#router bgp 413 host4(config-router)#neighbor 10.3.3.2 remote-as 29
•
Use to establish a router as a member of the specified BGP confederation.
•
To routers outside the confederation, the confederation appears as an autonomous system with an AS number the same as the confederation identifier.
•
The new confederation identifier is used in open messages and in the AS path in update messages that are sent after you issue the command.
To force sessions that are already up to use the new confederation identifier, you must use the clear ip bgp command to perform a hard clear.
•
Use the no version to remove the sub-AS from the confederation.
•
See bgp confederation identifier.
bgp confederation peers
•
Use to enable EBGP sessions with routers in the peer sub-ASs; the EBGP sessions preserve local-pref, MED, and next-hop attributes.
•
You can specify one or more individual sub-AS numbers, or you can issue the filter-list keyword and an AS-path access list (which is based on regular expressions) to specify a list of sub-AS numbers.
•
If the remote AS of a peer appears in the specified list of sub-ASs or is identified by the filter list, then the peer is treated as being in the same confederation.
•
This command takes effect immediately and bounces only those sessions whose peer type changed as a result of issuing the command.
•
Use the no version to remove individually specified sub-ASs, all sub-ASs specified by the filter list, or all sub-ASs from the confederation.
•
See bgp confederation peers.
ip bgp-confed-as-set new-format
•
Use to specify that AS-confed-sets are displayed enclosed within square brackets rather than parentheses, and that the AS paths in the set are delimited by commas rather than spaces.
•
Example host1(config)#ip bgp-confed-as-set new-format
•
Use the no version to restore the default display within parentheses and with space-delimited ASs.
•
See ip bgp-confed-as-set new-format.
146 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Configuring Route Reflectors
Router reflection is an alternative to confederations as a strategy to reduce IBGP meshing.
BGP specifies that a BGP speaker cannot advertise routes to an IBGP neighbor if the speaker learned the route from a different IBGP neighbor. A route reflector is a BGP speaker that advertises routes learned from each of its IBGP neighbors to its other IBGP neighbors; routes are reflected among IBGP routers that are not meshed. The route reflector’s neighbors are called route reflector clients. The clients are neighbors only to the route reflector, not to each other. Each route reflector client depends on the route reflector to advertise its routes within the AS; each client also depends on the route reflector to pass routes to the client.
A route reflector and its clients are collectively referred to as a cluster. Clients peer only with a route reflector and do not peer outside their cluster. Route reflectors peer with clients and other route reflectors within the cluster; outside the cluster they peer with other reflectors and other routers that are neither clients nor reflectors. Route reflectors and nonclient routers must be fully meshed.
Clients and nonclients have no knowledge of route reflection; they operate as standard
BGP peers and require no configuration. You simply configure the route reflectors.
Route reflectors advertise routes learned from:
• A nonclient peer only to clients
• A client peer to all nonclient peers and to all client peers except for the originator of the route
•
An EBGP peer to all nonclient peers and all client peers
illustrates a simple route reflection setup. Configured as a route reflector, Router Harvard reflects routes among its clients within Cluster 23: Routers
Plymouth, Westford, and Acton. These route reflector clients see router Harvard and each other simply as IBGP neighbors. Router Newport in AS 325 and router Mason in AS
413 see router Harvard simply as an EBGP neighbor in AS 29.
Figure 43: Simple Route Reflection
Copyright © 2013, Juniper Networks, Inc.
147
JunosE 14.3.x BGP and MPLS Configuration Guide
Route Reflection and Redundancy
Reliability and redundancy are important issues when using route reflection because the members of a cluster are not fully meshed. For example, if router Harvard in
goes down, all of its clients are isolated from networks outside the cluster. Having one or more redundant route reflectors in a cluster protects against such an occurrence.
However, you cannot rely on logical redundancy alone. Consider the cluster shown in
Figure 44 on page 148 . The operator has attempted to provide redundancy in Cluster 9
by configuring two route reflectors, router Acton and router Westford. Unfortunately, router Harvard is physically isolated if its link to router Acton goes down, or if router Acton itself goes down. Similarly, router Plymouth is isolated if any problems develop with router Westford.
Figure 44: Route Reflection: Logical Redundancy
In
Figure 45 on page 148 , the operator has added physical redundancy to the cluster
configuration. Now, loss of either one of the route reflectors does not isolate the reflector clients.
Figure 45: Route Reflection: Physical and Logical Redundancy
148
Route Reflection and Looping
BGP prevents looping between ASs by evaluating the AS-path attribute to determine a route’s origin. Border routers reject routes they receive from external neighbors if the AS path indicates that the route originated within the border router’s AS.
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
Route reflection creates the possibility of looping within an AS. Routes that originate within a cluster might be forwarded back to the cluster. Because this happens within a given AS, the AS-path attribute is of no use in detecting a loop.
Route reflectors add an originator ID to each route that identifies the originator of the route within the local AS by its router ID. If a router receives a route having the originator
ID set to its own router ID, it rejects the route.
You can also use a cluster list to prevent looping. Each cluster has an identifying number, the cluster ID. For clusters with a single route reflector, the cluster ID is the router ID of the route reflector; otherwise you configure the cluster ID. The cluster list records the cluster ID of each cluster traversed by a route. When a route reflector passes a route from a client to a nonclient router outside the cluster, the reflector appends the cluster ID to the list. When a route reflector receives a route from a nonclient, it rejects the route if the list contains the local cluster ID.
What about routes that a client forwards out of the cluster? No cluster ID is needed, because clients can forward routes only to EBGP peers, that is, to peers outside the AS.
Looping between ASs is prevented by the AS-path list.
The following commands configure the route reflectors for the network topology shown in
. You configure the other routers, whether nonclients or route reflector clients, as usual for IBGP and EBGP peers.
To configure router Salem as a route reflector: host1(config)#router bgp 29 host1(config-router)#neighbor 10.2.5.5 remote-as 29 host1(config-router)#neighbor 10.2.5.5 route-reflector-client host1(config-router)#neighbor 10.2.5.6 remote-as 29 host1(config-router)#neighbor 10.2.5.6 route-reflector-client host1(config-router)#neighbor 10.2.5.7 remote-as 29 host1(config-router)#neighbor 10.2.5.8 remote-as 29 host1(config-router)#neighbor 10.2.25.5 remote-as 325
You do not configure a cluster ID, because router Salem is the only route reflector in this cluster.
Copyright © 2013, Juniper Networks, Inc.
149
JunosE 14.3.x BGP and MPLS Configuration Guide
Figure 46: BGP Route Reflection
150
To configure router Concord as a route reflector: host2(config)#router bgp 29 host2(config-router)#neighbor 10.7.1.3 remote-as 29 host2(config-router)#neighbor 10.7.1.3 route-reflector-client host2(config-router)#neighbor 10.7.1.4 remote-as 29 host2(config-router)#neighbor 10.7.1.4 route-reflector-client host2(config-router)#neighbor 10.7.6.2 remote-as 29
You do not configure a cluster ID, because router Concord is the only route reflector in this cluster.
To configure router Acton as a route reflector: host3(config)#router bgp 29 host3(config)#bgp cluster-id 23 host3(config-router)#neighbor 10.3.1.1 remote-as 29 host3(config-router)#neighbor 10.3.1.1 route-reflector-client host3(config-router)#neighbor 10.1.2.3 remote-as 29 host3(config-router)#neighbor 10.1.2.3 route-reflector-client host3(config-router)#neighbor 10.3.3.4 remote-as 29 host3(config-router)#neighbor 10.2.5.1 remote-as 29
You must configure a cluster ID, because router Acton and router Harvard are both route reflectors in this cluster.
To configure router Harvard as a route reflector:
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing host4(config)#router bgp 29 host4(config)#bgp cluster-id 23 host4(config-router)#neighbor 10.3.1.2 remote-as 29 host4(config-router)#neighbor 10.3.1.2 route-reflector-client host4(config-router)#neighbor 10.1.2.1 remote-as 29 host4(config-router)#neighbor 10.1.2.1 route-reflector-client host4(config-router)#neighbor 10.3.3.2 remote-as 29 host4(config-router)#neighbor 10.2.5.2 remote-as 29
You must configure a cluster ID, because router Harvard and router Acton are both route reflectors in this cluster.
bgp client-to-client reflection
•
Use to reenable the reflector to reflect routes among all clients.
•
Client-to-client reflection is enabled by default. If the route reflector’s clients are fully meshed, you can disable reflection because it is not necessary.
•
If client-to-client reflection is enabled (the default), clients of a route reflector cannot be members of a peer group.
•
Example host1(config-router)#no bgp client-to-client reflection
•
Changes apply automatically to any routes received after you issue the command. To advertise or withdraw routes that are already present in the BGP routing table, you must use the clear ip bgp command to issue a hard clear or an outbound soft clear.
•
Use the no version to disable route reflection; use only if the route reflector’s clients are fully meshed.
•
See bgp client-to-client reflection.
bgp cluster-id
•
Use to configure a cluster ID on the route reflectors if the BGP cluster has more than one route reflector. For clusters with a single reflector, the cluster ID is the reflector’s router ID and does not have to be configured.
•
You specify a cluster ID number or an IP address of a router acting as a route reflector.
•
The new cluster ID is used in update messages sent after you issue the command. To force BGP to resend all routes with the new cluster ID, you must use the clear ip bgp command to perform a hard clear or a soft clear.
•
Use the no version to cause BGP to use the router ID as the cluster ID.
•
See bgp cluster-id.
neighbor route-reflector-client
•
Use to configure the local router as the route reflector and the specified neighbor as one of its clients. The reflector and its clients constitute a cluster. BGP neighbors that are not specified as clients are nonclients.
•
Route reflectors pass routes among the client routers.
Copyright © 2013, Juniper Networks, Inc.
151
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Route reflection eliminates the need for all IBPG peers to be fully meshed. The members of a cluster do not have to be fully meshed, but BGP speakers outside the cluster must be fully meshed.
•
If client-to-client reflection is enabled (the default), clients of a route reflector cannot be members of a peer group.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override this inheritance for a peer group member.
•
Changes apply automatically to any routes received after you issue the command. To advertise or withdraw routes that are already present in the BGP routing table, you must use the clear ip bgp command to issue a hard clear or an outbound soft clear.
•
Use the no version to indicate that the neighbor is no longer a client. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
•
See neighbor route-reflector-client.
Configuring BGP Multicasting
The BGP multiprotocol extensions (MP-BGP) enable BGP to carry IP multicast routes used by the Protocol Independent Multicast (PIM) to build data distribution trees. (See
JunosE Multicast Routing Configuration Guide for information about PIM.) You can configure a multicast routing topology different from your unicast topology to achieve greater control over network resources. This application of MP-BGP is often referred to as multicast BGP (MBGP).
The BGP multiprotocol extensions specify that BGP can exchange information within different types of address families:
• Unicast IPv4—If you do not explicitly specify the address family, the router is configured to exchange unicast IPv4 addresses by default.
•
Multicast IPv4—If you specify the multicast IPv4 address family, you can use BGP to exchange routing information about how to reach a multicast source instead of a unicast destination. For information about BGP multicasting commands, see
“Configuring BGP Routing” on page 3
. For a general description of multicasting, see
JunosE Multicast Routing Configuration Guide.
• VPN IPv4—If you specify the VPN-IPv4 (also known as VPNv4) address family, you can configure the router to provide IPv4 VPN services over an MPLS backbone. These
VPNs are often referred to as BGP/MPLS VPNs.
•
Unicast IPv6—If you specify the IPv6 unicast address family, you can configure the router to exchange unicast IPv6 routes. For a description of IPv6, see JunosE IP, IPv6,
and IGP Configuration Guide.
•
Multicast IPv6—If you specify the multicast IPv6 address family, you can use BGP to exchange routing information about how to reach an IPv6 multicast source instead of
152 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing an IPv6 unicast destination. For a general description of multicasting, see JunosE
Multicast Routing Configuration Guide.
• VPN IPv6—If you specify the VPN-IPv6 address family, you can configure the router to provide IPv6 VPN services over an MPLS backbone. These VPNs are often referred to as BGP/MPLS VPNs.
• L2VPN—If you specify the L2VPN address family, you can configure the PE router for
VPLS L2VPNs or VPWS L2VPNs to exchange layer 2 network layer reachability information (NLRI) for all VPLS or VPWS instances. Optionally, you can use the signaling keyword with the address-family command for the L2VPN address family to specify BGP signaling of L2VPN reachability information. Currently, you can omit the signaling keyword with no adverse effects. For a description of VPLS, see
“Configuring VPLS” on page 609
. For a description of VPWS, see
“Configuring VPWS” on page 673 .
• VPLS—If you specify the VPLS address family, you can configure the router to exchange layer 2 NLRI for a specified VPLS instance. For a description of VPLS, see
“Configuring VPLS” on page 609
.
•
VPWS—If you specify the VPWS address family, you can configure the PE router to exchange layer 2 NLRI for a specified VPWS instance. For a description of VPWS, see
“Configuring VPWS” on page 673 .
As discussed in
“Understanding BGP Command Scope” on page 18
, BGP configuration commands fall into five categories. If you specify the multicast address family, from within the Address Family Configuration mode you can issue the commands listed in
to configure parameters that affect the multicast address family globally. You can issue the commands listed in
to configure a peer or peer group that you have activated in the multicast address family without affecting those configuration parameters for any other address family within which the peer or peer group is activated.
If you issue any of the commands listed in
from within the default
IPv4 unicast address family to configure a peer or peer group, you can apply those configuration values to the same entity in the multicast address family by activating the peer or peer group in the multicast address family.
Example To add a peer to the multicast routing table, first add the peer to the unicast routing table, and then copy it to the multicast routing table.
host1(config)#router bgp 22 host1(config-router)#neighbor 192.168.55.122 remote-as 33 host1(config-router)#address-family ipv4 multicast host1(config-router-af)neighbor 192.168.55.122 activate
address-family
•
Use to configure the router to exchange IPv4 or IPv6 addresses by creating the specified address family.
•
IPv4 addresses can be exchanged in unicast, multicast, or VPN mode. IPv6 addresses can be exchanged in unicast mode.
Copyright © 2013, Juniper Networks, Inc.
153
JunosE 14.3.x BGP and MPLS Configuration Guide
exit-address-family
•
The default setting is to exchange IPv4 addresses in unicast mode from the default router.
•
This command takes effect immediately.
•
Examples host1:vr1(config-router)#address-family ipv4 multicast host1:vr1(config-router)#address-family vpnv4 host1:vr1(config-router)#address-family ipv4 unicast vrf vr2
•
Use the no version to disable the exchange of a type of prefix.
•
See address-family.
•
Use to exit Address Family Configuration mode and access Router Configuration mode.
•
Example host1:vr1(config-router-af)#exit-address-family
•
There is no no version.
•
See exit-address-family.
neighbor activate
•
Use to specify a peer with which routes of the current address family are exchanged.
•
A peer can be activated in more than one address family. By default, a peer is activated only for the IPv4 unicast address family.
•
The peer must be created in unicast IPv4 or VPN IPv4 before you can activate it in another address family.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
The address families that are actively exchanged over a BGP session are negotiated when the session is established.
•
This command takes effect immediately. If dynamic capability negotiation was not negotiated with the peer, the session is automatically bounced so that the exchanged address families can be renegotiated in the open messages when the session comes back up.
If dynamic capability negotiation was negotiated with the peer, BGP sends a capability message to the peer to advertise or withdraw the multiprotocol capability for the address family in which this command is issued. If a neighbor is activated, BGP also sends the full contents of the BGP routing table of the newly activated address family.
•
Example host1:vr1(config-router-af)#neighbor 192.168.1.158 activate
154 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
Use the no version to indicate that routes of the current address family must not be exchanged with the peer.
•
See neighbor activate.
Monitoring BGP Multicast Services
To display values from the BGP multicast routing table, use the show BGP commands with the ipv4 multicast keyword. For more information about displaying BGP parameters, see
.
Using BGP Routes for Other Protocols
You can use the ip route-type or ipv6 route-type command to specify whether BGP IPv4 or IPv6 unicast routes are available only for unicast routing protocols or for both unicast and multicast routing protocols to perform RPF checks. Routes available for unicast routing protocols appear in the unicast view of the routing table, whereas routes available for multicast routing protocols appear in the multicast view of the routing table.
Typically you use MP-BGP to learn the RPF routes for multicast protocols, especially if the topology for multicast networks differs from that for unicast networks. However, you might use this command if you do not want to run multicast MP-BGP, or if you are running
BGP between CE routers in a given BGP/MPLS VPN (the current specification does not provide a way to transmit multicast MP-BGP routes across a BGP/MPLS VPN core).
ip route-type ipv6 route-type
•
Use to specify whether BGP routes are available for other unicast protocols or both unicast and multicast protocols.
•
You cannot specify that BGP routes are available only for multicast protocols.
•
Use the show ip route or show ipv6 route command to view the routes available for unicast protocols.
•
Use the show ip rpf-route or show ipv6 rpf-route command to view the routes available for multicast protocols. It does not display routes available only to unicast protocols.
•
By default, BGP IPv4 and IPv6 unicast routes are available only for other unicast routing protocols.
•
Example 1 host1(config)#router bgp 100 host1(config-router)#ipv6 route-type both
•
Example 2 host1(config)#router bgp 100 host1(config-router)#address-family ipv4 unicast vrf v1 host1(config-router-af)#ip route-type both
•
Use the no version to restore the default value, unicast.
Copyright © 2013, Juniper Networks, Inc.
155
JunosE 14.3.x BGP and MPLS Configuration Guide
•
See ip route-type.
•
See ipv6 route-type.
Configuring BGP/MPLS VPNs
The BGP multiprotocol extensions enable the exchange of BGP information within different types of address families. The VPN IPv4 address family enables you to configure the router to provide IPv4 VPN services over an MPLS backbone. These VPNs are often referred to as BGP/MPLS VPNs. For detailed information, see
“Configuring BGP-MPLS Applications” on page 389 .
Testing BGP Policies
You can analyze and check your BGP routing policies on your network before you implement the policies. Use the test ip bgp neighbor and test bgp ipv6 neighbor commands to test the outcome of a BGP policy. The commands output display the routes that are advertised or accepted if the specified policy is implemented.
BGP routes must be present in the forwarding table for this command to work properly.
If you run the policy test on incoming routes, soft reconfiguration (configured with the neighbor soft reconfiguration in command) must be in effect.
NOTE: You can use the standard redirect operators to redirect the test output to network or local files. See JunosE System Basics Configuration Guide.
The output of these commands is always speculative. It does not reflect the current state of the router.
test bgp ipv6 neighbor test ip bgp neighbor
•
Use to test the effect of BGP policies on a router without implementing the policy.
•
You can apply the test to routes advertised to peers or received from peers.
•
You can test the following kinds of policies: distribute lists, filter lists, prefix lists, prefix trees, or route maps. If you do not specify a policy, then the test uses whatever policies are currently in effect on the router.
NOTE: If you test the current policies, the results might vary for routes learned before the current policies were activated if you did not clear the forwarding table when the policies changed.
•
The following three items apply to the test ip bgp neighbor command only:
•
The address-family identifier for the route is the same as is used for identifying the neighbor.
156 Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Configuring BGP Routing
•
If you do not specify a route, the test is performed for all routes associated with the
address-family identifier.
•
Specifying only an address and mask without a route distinguisher causes all routes sharing the address and mask to be taken into account. Specifying only an address causes a best match to be performed for the route.
•
If you completely specify a route with IP address, mask, and route distinguisher, the command displays detailed route information. Otherwise only summary information is shown. Use the fields option to select particular fields of interest.
•
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
•
You can set a weight value for inbound routes filtered with a filter list.
•
Example host1#test ip bgp neighbor 10.12.54.21 advertised-routes distribute-list boston5 fields all
•
There is no no version.
•
See test bgp ipv6 neighbor.
•
See test ip bgp neighbor.
Copyright © 2013, Juniper Networks, Inc.
157
JunosE 14.3.x BGP and MPLS Configuration Guide
158 Copyright © 2013, Juniper Networks, Inc.
CHAPTER 2
Monitoring BGP
This chapter describes the commands you can use to monitor and troubleshoot Border
Gateway Protocol (BGP) on E Series routers.
NOTE: The E120 router and E320 router output for monitor and show commands is identical to output from other E Series routers, except that the
E120 and E320 router output also includes information about the adapter identifier in the interface specifier (slot/adapter/port).
This chapter contains the following sections:
•
Setting a Baseline on All BGP Statistics on page 160
•
Enabling Display of BGP Logs on page 160
•
Setting the Default Output Fields While Displaying Summarized Status of BGP
•
Setting the Default BGP Routing Table Output Fields on page 161
•
Monitoring the AS-Path Access Lists for IP on page 164
•
Monitoring the BGP Routing Table on page 164
•
Monitoring Advertised BGP Routes on page 170
•
Monitoring BGP Aggregate Addresses on page 171
•
Monitoring BGP Routes with Nonnatural Network Masks on page 172
•
Monitoring BGP Routes in a Community on page 173
•
Monitoring BGP Community Routes in the Community List on page 175
•
Monitoring Dampened BGP Routes on page 176
•
Monitoring BGP Routes with Matching AS Paths and AS-Path Access Lists on page 178
•
Monitoring BGP Flap Statistics on page 180
•
Monitoring BGP Routes with Inconsistent AS Paths on page 181
•
Monitoring BGP Neighbors on page 182
•
Monitoring Dampened BGP Routes of Specified Neighbors on page 188
•
Monitoring BGP Paths of Neighbors on page 189
Copyright © 2013, Juniper Networks, Inc.
159
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Monitoring Prefix List Outbound Route Filters Received from the BGP
•
Monitoring Routes Originating from a BGP Neighbor Before Application of Inbound
•
Monitoring Routes Originating from a BGP Neighbor After Application of Inbound
•
Monitoring Networks in an Autonomous System on page 194
•
Monitoring BGP Next Hops on page 194
•
Monitoring BGP Paths on page 195
•
Monitoring BGP Peer Groups on page 196
•
Monitoring BGP Routes with Matching AS Paths and Regular Expressions for Single
Regular Expressions on page 199
•
Monitoring BGP Routes with Matching AS Paths and Regular Expressions for Multiple
Regular Expressions on page 201
•
Monitoring the Status of All BGP Neighbors on page 203
•
Monitoring the Routes Permitted by IP Community Lists on page 207
•
Disabling Display of BGP Logs on page 208
Setting a Baseline on All BGP Statistics
You can set a baseline for all BGP statistics.
The system implements the baseline by reading and storing the statistics at the time the baseline is set and then subtracting this baseline whenever baseline-relative statistics are retrieved.
To set a baseline for BGP statistics:
•
Issue the baseline ip bgp command: host1#baseline ip bgp
Related
Documentation
•
baseline ip bgp
Enabling Display of BGP Logs
To display information about BGP logs for inbound or outbound events, or both.
•
Issue the debug ip bgp command: host1#debug ip bgp
Related
Documentation
•
Disabling Display of BGP Logs on page 208
•
debug ip bgp
•
undebug ip bgp
160 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Setting the Default Output Fields While Displaying Summarized Status of BGP
Neighbors
Purpose Specify fields that are displayed by default by a subsequently issued show ip bgp summary command.
You can use the intro keyword to enable the display of introductory information about
BGP attributes. The order in which you specify the fields has no effect on the order in which they are displayed.
Action To specify the default output fields: host1:pe2(config-router)# default-fields peer remote-as state messages-received messages-sent up-down-time host1# show ip bgp summary
Messages Messages
Neighbor AS State Up/down time Sent Received
1.1.1.1 100 Established 00:07:55 94 92
Meaning
lists the show bgp summary command output fields.
Table 22: show bgp summary Output Fields
Field Name Field Description
Neighbor BGP neighbors
AS
State
Up/down time
Messages sent
Messages received
AS number of the peer
State of the connection
Time the connection has been up or down
Number of messages sent to peer
Number of messages received from peer
Related
Documentation
•
Monitoring the Status of All BGP Neighbors on page 203
•
default-fields peer
Setting the Default BGP Routing Table Output Fields
Purpose Specify fields that are displayed by default by any subsequently issued show ip bgp command that displays the BGP routing table.
You can use the intro keyword to enable the display of introductory information about
BGP attributes. The order in which you specify the fields has no effect on the order in which they are displayed.
Copyright © 2013, Juniper Networks, Inc.
161
JunosE 14.3.x BGP and MPLS Configuration Guide
Action To specify the default output fields while displaying the BGP routes: host1:pe2(config-router)# default-fields route intro next-hop med loc-pref weight as-path host1:pe2# show ip bgp vpnv4 all
Local BGP identifier 2.2.2.2, local AS 100
6 routes (388 bytes)
7 destinations (560 bytes) of which 0 have a route
0 routes selected for route table installation
6 path attribute entries (936 bytes)
Local-RIB version 74. FIB version 74.
Prefix Next-hop MED LocPrf Weight AS-path
99.99.99.11/32 1.1.1.1 1 100 0 65011
99.99.99.12/32 1.1.1.1 0 100 0 empty
99.99.99.13/32 1.1.1.1 2 100 0 empty
99.99.99.21/32 21.21.21.2 1 0 65021
99.99.99.22/32 22.22.22.2 0 32768 empty
99.99.99.23/32 23.23.23.2 2 32768 empty
Meaning
lists the show ip bgp command output fields.
Table 23: show ip bgp Output Fields
Field Name Field Description
Local BGP identifier local AS routes
BGP router ID of the local router
Local autonomous system number
Total number of routes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, all routes are included in this count.
destinations routes selected for route table installation path attribute entries
Local-RIB version
Number of routes to unique prefixes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table, plus prefixes for which there are currently no routes but which have had to be withdrawn from peers to which these prefixes may been previously advertised.
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Number that is increased by one each time a route in that RIB is added, removed or modified.
162 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 23: show ip bgp Output Fields (continued)
Field Name Field Description
FIB version
Prefix
Peer
Next hop IP address
Number that is increased by one each time BGP updates the routes in the IP routing table based on changes in the local RIB. The FIB version matches the local-RIB version when BGP has finished updating the routes in the IP route table. The FIB version is less than the local-RIB version when BGP is still in the process of updating the IP routing table.
Prefix for the routing table entry
Peer from which route was learned
IP address of the next router that is used when a packet is forwarded to the destination network
MED
LocPrf
Weight
Origin
AS path
Statistics baseline set
Multiexit discriminator for the route
Local preference for the route
Weight of the route
Origin of the route
AS path through which this route has been advertised
Communities
Stale unicast/multicast routes selected for route table installation unicast/multicast tunnel-usable routes selected for route table installation
Community number associated with the route
Routes that have gone stale due to peer restart
Number of unicast routes in the BGP routing table that have been inserted into the IP routing table that are also available for use in the multicast view of the IP routing table
Number of unicast and multicast routes in the BGP routing table that have been inserted into the IP routing table that are also available for use in the IP tunnel routing table tunnel-only routes selected for tunnel-route table installation
Number of routes in the BGP routing table that have been inserted into the IP tunnel routing table path attribute entries Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Timestamp indicating when the statistics baseline was last set
Copyright © 2013, Juniper Networks, Inc.
163
JunosE 14.3.x BGP and MPLS Configuration Guide
Related
Documentation
•
Monitoring the BGP Routing Table on page 164
•
default-fields route
Monitoring the AS-Path Access Lists for IP
Purpose Display information about AS-path access lists.
Action To display information about AS-path access lists: host1# show ip as-path-access-list
AS Path Access List 1:
permit .*
AS Path Access List 2:
deny .*
AS Path Access List 3:
permit _109_
deny .*
AS Path Access List 4:
permit _109$
deny .*
AS Path Access List 10:
deny _109$
permit ^108_
deny .*
Meaning
lists the show ip as-path-access-list command output fields.
Table 24: show ip as-path-access-list Output Fields
Field Name Field Description
As Path Access List permit, deny
Name of an AS-Path access list
Condition statement for routes matching the condition
Related
Documentation
•
show ip as-path-access-list
Monitoring the BGP Routing Table
Purpose Display the BGP IPv4 routing table or BGP IPv6 routing table.
The show ip bgp and show bgp ipv6 commands display similar information.
Action To display information about routes in the IPv6 multicast address family: host1# show bgp ipv6 multicast
Local BGP identifier 10.13.13.13, local AS 400
4 routes (160 bytes)
4 destinations (288 bytes) of which 4 have a route
4 routes selected for route table installation
3 path attribute entries (456 bytes)
Local-RIB version 31. FIB version 31.
164 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Status codes: > best, * invalid, s suppressed, d dampened, r rejected,
a auto-summarized
Prefix Peer Next-hop MED LocPrf Weight Origin
::103.103.103.0/120 103.103.103.3 ::103.103.103.3 0 0 inc.
> 3ffe:0:0:1::/64 11.11.11.11 ::101.101.101.1 0 100 0 inc.
> 3ffe:0:0:3::/64 103.103.103.3 ::103.103.103.3 0 0 inc.
> 3ffe:0:1:1::/64 12.12.12.12 ::102.102.102.2 0 100 0 inc.
To display information about routes for the specified IPv4 prefix: host1:pe1# show ip bgp 10.88.88.1
BGP route information for prefix 10.88.88.1/32
Network route (best route
Advertised to both internal and external peers
Address Family Identifier (AFI) is ip-v4
Subsequent Address Family Identifier (SAFI) is unicast
Next hop IP address is 0.0.0.0 (metric 2)
Multi-exit discriminator is 1
Local preference is not present
Weight is 32768
Origin is IGP
AS path is empty
Extended communities empty
To display information about routes for the specified IPv6 prefix: host1:pe1# show bgp ipv6 2001:0430::1/128
BGP route information for prefix 2001:1::1/128
Received route learned from internal peer 2.2.2.2 (best route)
Route placed in IP forwarding table
Best to advertise to external peers
Address Family Identifier (AFI) is ip-v6
Subsequent Address Family Identifier (SAFI) is unicast
MPLS in-label is none
MPLS out-label is 17
Next hop IP address is ::ffff:2.2.2.2 (metric 3)
Multi-exit discriminator is 0
Local preference is 100
Weight is 0
Origin is IGP
AS path is 65021
To display information about next hop routers for VRF PE 11 in the IPv4 VPN address family: host1:pe1# show ip bgp vpnv4 vrf pe11 next-hops
Indirect next-hop 11.11.11.2
Resolution in IP route table of VR pe11
Reachable (metric 0)
IP indirect next-hop index 35
Direct next-hop ATM2/0.11 (11.11.11.2)
Resolution in IP tunnel-route table of VR pe11
Not reachable
Reference count is 1
Indirect next-hop 2.2.2.2
Resolution in IP route table of VR pe1
IP indirect next-hop index 123
Reachable (metric 100)
Direct next-hop POS4/0 (10.10.10.1)
Copyright © 2013, Juniper Networks, Inc.
165
JunosE 14.3.x BGP and MPLS Configuration Guide
POS4/1 (12.12.12.1)
Resolution in IP tunnel-route table of VR pe1
MPLS indirect next-hop index 578
Reachable (metric 100)
Direct next-hop Push 23, POS4/0 (10.10.10.1)
Push 43, POS4/1 (12.12.12.1)
Reference count is 1
To display information about routes in the route-target address family: host1:pe1# show ip bgp route-target signaling
Local BGP identifier 13.13.13.13, local AS 100
4 routes (240 bytes)
3 destinations (228 bytes) of which 3 have a route
3 routes selected for route tables installation
0 unicast/multicast routes selected for route table installation
0 unicast/multicast tunnel-usable routes selected for route table installation
0 tunnel-only routes selected for tunnel-route table installation
10 path attribute entries (1520 bytes)
Local-RIB version 19. FIB version 19.
Status codes: > best, * invalid, s suppressed, d dampened, r rejected,
a auto-summarized
Prefix Peer Next-hop MED LocPrf Weight Origin
> 0:0:0/0 12.12.12.12 12.12.12.12 100 0 IGP
> 100:100:1/96 11.11.11.11 11.11.11.11 100 0 IGP
100:100:1/96 14.14.14.14 14.14.14.14 100 0 IGP
> 100:100:2/96 11.11.11.11 11.11.11.11 100 0 IGP
To display information about routes in the route-target address family corresponding to the specified RT-MEM-NLRI: host1:pe1# show ip bgp route-target signaling 100:100:1/96
BGP route information for prefix 100:100:1/96
Received route learned from internal peer 11.11.11.11 (best route)
Route not placed in IP forwarding table
Best to advertise to both internal and external peers
Address Family Identifier (AFI) is ip-v4
Subsequent Address Family Identifier (SAFI) is route-target-signaling
Next hop IP address is 11.11.11.11 (metric 0)
Multi-exit discriminator is not present
Local preference is 100
Weight is 0
Origin is IGP
AS path is empty
Received route learned from internal peer 14.14.14.14
Route not placed in IP forwarding table
Do not advertise to any peers
Address Family Identifier (AFI) is ip-v4
Subsequent Address Family Identifier (SAFI) is route-target-signaling
Next hop IP address is 14.14.14.14 (metric 0)
Multi-exit discriminator is not present
Local preference is 100
Weight is 0
Origin is IGP
AS path is empty
166 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
To display information about network routes in the route-target address family: host1:pe1# show ip bgp route-target signaling network
Prefix Weight Route-map Backdoor
102:111:34/96 No
1111111111:23:1/96 No
To display information about network routes in the route-target address family corresponding to the specified RT-MEM-NLRI: host1:pe1# show ip bgp route-target signaling network 102:111:34
Prefix Weight Route-map Backdoor
102:111:34/96 No
To display filtered information about all networks in the BGP routing table: host1:pe1# show ip bgp fields peer next-hop next-hop-cost
Prefix Peer Next-hop Next-hop-cost
11.11.11.11/32 3.3.3.3 3.3.3.3 Unreachable
11.11.11.11/32 4.4.4.4 4.4.4.4 Unreachable
22.22.22.22/32 3.3.3.3 3.3.3.3 Unreachable
22.22.22.22/32 4.4.4.4 4.4.4.4 Unreachable
33.33.33.33/32 3.3.3.3 3.3.3.3 Unreachable
44.44.44.44/32 4.4.4.4 4.4.4.4 Unreachable
55.55.55.55/32 0.0.0.0 0.0.0.0 0
66.66.66.66/32 6.6.6.6 6.6.6.6 Unreachable
77.77.77.77/32 57.57.57.7 57.57.57.7 1
88.88.88.88/32 57.57.57.7 57.57.57.7 1
To display filtered information about routes that are stale due to peer restart: host1:pe1# show ip bgp fields best peer next-hop stale
Prefix Stale Peer Next-hop
10.22.22.1/32 stale 10.12.12.2 10.12.12.2
10.22.22.2/32 stale 10.12.12.2 10.12.12.2
10.22.22.3/32 stale 10.12.12.2 10.12.12.2
10.33.33.1/32 10.13.13.3 10.13.13.3
10.33.33.2/32 10.13.13.3 10.13.13.3
10.33.33.3/32 10.13.13.3 10.13.13.3
To display introductory information about BGP attributes: host1:pe1# show ip bgp 0.0.0.0 /0 fields intro
Local BGP identifier 192.168.254.79, local AS 6730
201058 routes (12063492 bytes)
201540 destinations (15317040 bytes) of which 201058 have a route
193909 routes selected for route tables installation
0 unicast/multicast routes selected for route table installation
0 unicast/multicast tunnel-usable routes selected for route table installation
0 tunnel-only routes selected for tunnel-route table installation
35097 path attribute entries (5334744 bytes)
Local-RIB version 20969483. FIB version 20969483.
Statistics baseline set WED JUL 12 2006 10:31:53 METDST
...
To display all routes with a prefix that is equal to or more specific than the specified prefix: host1# show ip bgp 12.2.0.0 255.255.0.0 longer-prefixes
Local router ID 192.168.1.153, local AS 100
72074 paths, 72074 distinct prefixes (5189328 bytes used)
Copyright © 2013, Juniper Networks, Inc.
167
JunosE 14.3.x BGP and MPLS Configuration Guide
168
72074 paths selected for route table installation
21685 path attribute entries (2965327 bytes used)
Prefix Peer Next-hop MED CalPrf Weight Origin
> 12.2.6.0/24 10.5.0.48 10.5.0.48 100 100 IGP
> 12.2.7.0/24 10.5.0.48 10.5.0.48 100 100 IGP
> 12.2.76.0/24 10.5.0.48 10.5.0.48 100 100 IGP
> 12.2.88.0/22 10.5.0.48 10.5.0.48 100 100 IGP
> 12.2.97.0/24 10.5.0.48 10.5.0.48 100 100 IGP
> 12.2.99.0/24 10.5.0.48 10.5.0.48 100 100 IGP
> 12.2.109.0/24 10.5.0.48 10.5.0.48 100 100 IGP
> 12.2.169.0/24 10.5.0.48 10.5.0.48 100 100 IGP
Meaning
lists the show ip bgp command output fields.
Table 25: show ip bgp Output Fields
Field Name Field Description
Local BGP identifier local AS
BGP router ID of the local router
Local autonomous system number routes destinations routes selected for route table installation path attribute entries
Local-RIB version
FIB version
Prefix
Peer
Total number of routes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, all routes are included in this count.
Number of routes to unique prefixes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table, plus prefixes for which there are currently no routes but which have had to be withdrawn from peers to which these prefixes may been previously advertised.
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Number that is increased by one each time a route in that RIB is added, removed or modified.
Number that is increased by one each time BGP updates the routes in the IP routing table based on changes in the local RIB. The FIB version matches the local-RIB version when BGP has finished updating the routes in the IP route table. The FIB version is less than the local-RIB version when BGP is still in the process of updating the IP routing table.
Prefix for the routing table entry
Peer from which route was learned
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 25: show ip bgp Output Fields (continued)
Field Name Field Description
Next hop IP address
MED
LocPrf
Weight
IP address of the next router that is used when a packet is forwarded to the destination network
Multiexit discriminator for the route
Local preference for the route
Weight of the route
Origin
AS path
Communities
Stale unicast/multicast routes selected for route table installation
CalPrf
Origin of the route
AS path through which this route has been advertised
Community number associated with the route
Routes that have gone stale due to peer restart
Number of unicast routes in the BGP routing table that have been inserted into the IP routing table that are also available for use in the multicast view of the IP routing table unicast/multicast tunnel-usable routes selected for route table installation
Number of unicast and multicast routes in the BGP routing table that have been inserted into the IP routing table that are also available for use in the IP tunnel routing table tunnel-only routes selected for tunnel-route table installation
Number of routes in the BGP routing table that have been inserted into the IP tunnel routing table path attribute entries Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Statistics baseline set
Route-map
Timestamp indicating when the statistics baseline was last set
Indicates whether network-route filtering is enabled
Backdoor Indicates whether an IGP backdoor route is favored over an EBGP route
Calculated preference
Related
Documentation
•
show bgp ipv6
•
show ip bgp
Copyright © 2013, Juniper Networks, Inc.
169
JunosE 14.3.x BGP and MPLS Configuration Guide
Monitoring Advertised BGP Routes
Purpose Display the routes in the specified neighbor’s or peer group’s Adj-RIBs-Out table for IPv4 or IPv6.
For peers, display the attributes associated with the route before the application of any outbound policy. For peer groups, display the attributes associated with the route after the application of any outbound policy; that is, the actual advertised attributes. Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop.
The show ip bgp advertised-routes and show bgp ipv6 advertised-routes commands displays similar information.
NOTE: You must first enable storage of routes to the Adj-RIBs-Out tables with the no rib-out disable command or the no neighbor rib-out disable command. Otherwise, this command returns an error message.
Action To display routes in the specified neighbor’s or peer group’s Adj-RIBs-Out table for IPv4: host1# show ip bgp neighbors 5.72.116.1 advertised-routes
Local BGP identifier 2.2.2.2, local AS 2222
0 routes (0 bytes used), 0 distinct destinations (0 bytes used)
0 routes selected for route table installation
0 path attribute entries (0 bytes used)
Status codes: > best, * invalid, s suppressed, d dampened, r rejected
Prefix Peer Next-hop MED LocPrf Weight Origin
> 0.0.0.0/0 5.72.116.1 5.72.1.1 0 IGP
> 10.10.0.87/32 5.72.116.1 5.72.1.1 0 inc.
> 13.13.13.13/32 5.72.116.1 5.72.1.1 0 IGP
> 33.0.0.0/16 0.0.0.0 5.72.1.1 1 32768 inc.
> 33.0.0.0/24 0.0.0.0 5.72.1.1 1 32768 inc.
> 44.44.0.0/16 5.72.116.1 5.72.1.1 0 inc.
Meaning
lists the show ip bgp advertised-routes command output fields.
Table 26: show ip bgp advertised-routes Output Fields
Field Name Field Description
Local BGP identifier BGP router ID of the local router local AS routes
Local autonomous system number
Total number of routes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, all routes are included in this count.
170 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 26: show ip bgp advertised-routes Output Fields (continued)
Field Name Field Description distinct destinations routes selected for route table installation path attribute entries
Prefix
Number of routes to unique prefixes stored in the BGP routing table.
If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Prefix for the routing table entry
Peer
Next hop IP address
MED
LocPrf
Weight
Origin
IP address of BGP peer
IP address of the next hop
Multiexit discriminator for the route
Local preference for the route
Assigned path weight
Origin of the route
Related
Documentation
•
show bgp ipv6 advertised-routes
•
show ip bgp advertised-routes
Monitoring BGP Aggregate Addresses
Purpose Display information about aggregate addresses.
The show ip bgp aggregate-address and show bgp ipv6 aggregate-address commands display similar information.
Action To display information about aggregate addresses: host1# show bgp ipv6 aggregate-address
Prefix AS set Summ only Attribute map Advertise map Suppress map
3ffe::/48 No No None None None
Meaning
lists the show bgp ipv6 aggregate-address command output fields.
Copyright © 2013, Juniper Networks, Inc.
171
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 27: show bgp ipv6 aggregate-address Output Fields
Field Name Field Description
Prefix
AS set
Summary only
Attribute map
Prefix of the aggregate address
ASs in the AS-set path
Displays a summary of aggregate address information
Displays the attribute maps for aggregate addresses
Advertise map
Suppress map
Displays the advertise maps for aggregate addresses
Displays the suppressed maps for the aggregate addresses
Related
Documentation
•
show bgp ipv6 aggregate-address
•
show ip bgp aggregate-address
Monitoring BGP Routes with Nonnatural Network Masks
Purpose Display information about routes that have nonnatural network masks. Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop.
Action To display information about routes that have nonnatural network masks: host1# show ip bgp cidr-only
Local BGP identifier 111.111.111.111, local AS 444
0 routes (0 bytes used), 0 distinct destinations (0 bytes used)
0 routes selected for route table installation
0 path attribute entries (0 bytes used)
Status codes: > best, * invalid, s suppressed, d dampened, r rejected
Prefix Peer Next-hop MED LocPrf Weight Origin
33.0.0.0/24 5.72.1.1 5.72.1.1 1 0 inc.
> 44.44.0.0/24 0.0.0.0 192.168.1.1 1 32768 inc.
Meaning
lists the show ip bgp cidr-only command output fields.
Table 28: show ip bgp cidr-only Output Fields
Field Name Field Description
Local BGP identifier BGP router ID of the local router local AS Local autonomous system number
172 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 28: show ip bgp cidr-only Output Fields (continued)
Field Name Field Description routes distinct destinations routes selected for route table installation path attribute entries
Total number of routes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, all routes are included in this count.
Number of routes to unique prefixes stored in the BGP routing table.
If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Prefix
Peer
Next hop IP address
MED
LocPrf
Weight
Origin
Prefix for the routing table entry
IP address of BGP peer
IP address of the next hop
Multiexit discriminator for the route
Local preference for the route
Assigned path weight
Origin of the route
Related
Documentation
•
show ip bgp cidr-only
Monitoring BGP Routes in a Community
Purpose Display all routes that are members of the specified BGP community. Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop. Does not accept regular expressions.
The show ip bgp community and show bgp ipv6 community commands display similar information.
Action To display all routes that are members of the specified BGP community:
Copyright © 2013, Juniper Networks, Inc.
173
JunosE 14.3.x BGP and MPLS Configuration Guide
174
NOTE:
Specify the community number in AA:NN format:
•
AA—Number that identifies the autonomous system
•
NN—Number that identifies the community within the autonomous system host1# show ip bgp community 999:999
Local router ID 192.168.1.153, local AS 100
40845 paths, 40845 distinct prefixes (2940840 bytes used)
40845 paths selected for route table installation
13651 path attribute entries (1864908 bytes used)
Prefix Peer Next-hop MED CalPrf Weight Origin
> 24.0.0.0/12 10.5.0.48 10.5.0.48 100 100 IGP
> 24.4.252.0/22 10.5.0.48 10.5.0.48 100 100 IGP
> 24.6.0.0/23 10.5.0.48 10.5.0.48 100 100 IGP
> 24.6.11.0/24 10.5.0.48 10.5.0.48 100 100 IGP
Meaning
lists the show ip bgp community command output fields.
Table 29: show ip bgp community Output Fields
Field Name Field Description
Local router ID local AS
BGP router ID of the local router
Local autonomous system number routes paths distinct prefixes routes selected for route table installation path attribute entries
Prefix
Total number of routes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, all routes are included in this count.
Total number of routes stored in the BGP routing table. If several peers have advertised a route to the same prefix, all routes are included in this count.
Number of routes to unique prefixes stored in the BGP routing table.
If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Prefix for the routing table entry
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 29: show ip bgp community Output Fields (continued)
Field Name Field Description
Peer
Next hop IP address
MED
CalPrf
IP address of BGP peer
IP address of the next hop
Multiexit discriminator for the route
Calculated preference for the route
Weight
Origin
Assigned path weight
Origin of the route
Related
Documentation
•
show bgp ipv6 community
•
show ip bgp community
Monitoring BGP Community Routes in the Community List
Purpose Display all routes that are members of communities on the specified BGP community list. Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop. Accepts regular expressions.
The show ip bgp community-list and show bgp ipv6 community-list commands display similar information.
Action To display all routes that are members of communities in the specified BGP community list: host1# show ip bgp community-list 1 fields peer communities
Local router ID 192.168.1.153, local AS 100
72077 paths, 72077 distinct prefixes (5189544 bytes used)
72077 paths selected for route table installation
21627 path attribute entries (2957324 bytes used)
Prefix Peer Communities
3.0.0.0/8 10.5.0.48 777:777 888:888
4.0.0.0/8 10.5.0.48 777:777 888:888
4.17.106.0/24 10.5.0.48 777:777 888:888
4.17.115.0/24 10.5.0.48 777:777 888:888
6.0.0.0/8 10.5.0.48 777:777 888:888
9.2.0.0/16 10.5.0.48 777:777 888:888
9.20.0.0/17 10.5.0.48 777:777 888:888
12.0.0.0/8 10.5.0.48 777:777 888:888
Meaning
lists the show ip bgp community-list command output fields.
Copyright © 2013, Juniper Networks, Inc.
175
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 30: show ip bgp community-list Output Fields
Field Name Field Description
Local router ID local AS routes paths
BGP router ID of the local router
Local autonomous system number
Total number of routes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, all routes are included in this count.
Total number of routes stored in the BGP routing table. If several peers have advertised a route to the same prefix, all routes are included in this count.
distinct prefixes paths selected for route table installation path attribute entries
Prefix
Peer
Communities
Number of routes to unique prefixes stored in the BGP routing table.
If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Prefix for the routing table entry
IP address of BGP peer
Community number in AA:NN format:
•
•
AA—Number that identifies the autonomous system
NN—Number that identifies the community within the autonomous system
Related
Documentation
•
show bgp ipv6 community-list
•
show ip bgp community-list
Monitoring Dampened BGP Routes
Purpose Display information about dampened routes. Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop.
The show ip bgp dampened-paths and show bgp ipv6 dampened-paths commands display similar information.
176 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Action To display information about dampened routes: host1# show ip bgp dampened-paths
Local router ID 192.168.1.218, local AS 100
Route flap dampening is enabled
Decay half-life is 10 minutes while reachable, 20 minutes while unreachable
Cuttoff threshold is 2000, reuse threshold is 750
Maximum hold-down time is 20 minutes
60 paths have active route flap histories (4560 bytes used)
11 paths are suppressed
Figure Time until
Prefix Peer Status of Merit Reuse/Remove
24.31.128.0/19 10.2.1.48 Suppressed/Reachable 2681 00:17:00
24.93.128.0/19 10.2.1.48 Suppressed/Reachable 2681 00:17:00
24.95.0.0/19 10.2.1.48 Suppressed/Reachable 2681 00:17:00
128.192.0.0/16 10.2.1.48 Available 1997 00:15:08
148.161.0.0/16 10.2.1.48 Available 1997 00:15:10
164.81.0.0/16 10.2.1.48 Available 1997 00:15:11
192.29.60.0/24 10.2.1.48 Available 1997 00:15:12
192.58.228.0/24 10.2.1.48 Available 1997 00:15:15
192.88.8.0/24 10.2.1.48 Available 1997 00:15:17
192.107.253.0/24 10.2.1.48 Suppressed/Unreachable 4331 00:19:42
192.195.44.0/24 10.2.1.48 Suppressed/Reachable 2923 00:19:15
192.195.49.0/24 10.2.1.48 Suppressed/Reachable 2923 00:19:15
192.195.50.0/24 10.2.1.48 Suppressed/Reachable 2923 00:19:15
192.197.150.0/24 10.2.1.48 Available 1997 00:15:25
192.222.89.0/24 10.2.1.48 Suppressed/Unreachable 2788 00:19:42
204.17.195.0/24 10.2.1.48 Suppressed/Reachable 2923 00:17:20
204.52.186.0/24 10.2.1.48 Available 1997 00:15:26
204.68.178.0/24 10.2.1.48 Available 1000 00:19:38
204.101.0.0/16 10.2.1.48 Available 1997 00:15:29
204.128.227.0/24 10.2.1.48 Suppressed/Reachable 2923 00:17:16
204.146.24.0/22 10.2.1.48 Available 1997 00:15:30
204.146.24.0/24 10.2.1.48 Available 1997 00:15:30
Meaning
lists the show ip bgp dampened-paths command output fields.
Table 31: show ip bgp dampened-paths Output Fields
Field Name Field Description
Local router ID local AS
BGP router ID of the local router
Number of the local AS
Route flap dampening
Decay half-life
Cutoff threshold
Reuse threshold
Status of route flap dampening (enabled or disabled)
Time (in minutes) after which a penalty is decreased. After the route has been assigned a penalty, the penalty is decreased by half after the half-life period (which is 15 minutes by default).
Value of the penalty for a flapping route below which the route is unsuppressed
Time (in hours:minutes:seconds) after which the path will be made available
Copyright © 2013, Juniper Networks, Inc.
177
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 31: show ip bgp dampened-paths Output Fields (continued)
Field Name Field Description
Maximum hold-down time Interval, in seconds, after not receiving a keepalive message that the software declares a peer dead route flap history
Prefix
Peer
Status of route flap history for route paths
Prefix for the IP address
IP address of BGP peer
Status
Figure of Merit
Status of route dampening of the route path
A measure of the route's stability. Higher values indicate more recent route flap activity or less stability.
Time until Reuse/Remove Time until the route is either reused (if currently suppressed) or its history entry is removed (if currently available)
Related
Documentation
•
show bgp ipv6 dampened-paths
•
show ip bgp dampened-paths
Monitoring BGP Routes with Matching AS Paths and AS-Path Access Lists
Purpose Display all routes whose AS path matches the specified AS-path access list. Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop.
The show ip bgp filter-list and show bgp ipv6 filter-list commands display similar information.
Action To display all routes whose AS path matches the specified AS-path access list: host1# show ip bgp filter-list 1
Local router ID 192.168.1.153, local AS 100
72080 paths, 72080 distinct prefixes (5189760 bytes used)
72080 paths selected for route table installation
21667 path attribute entries (2962828 bytes used)
Prefix Next-hop MED CalPrf Weight AS-path
> 6.0.0.0/8 10.5.0.48 100 100 11488 701 7018 7170
> 12.0.0.0/8 10.5.0.48 100 100 11488 701 1740 7018
> 12.1.248.0/24 10.5.0.48 100 100 11488 701 7018 13391
> 12.2.6.0/24 10.5.0.48 100 100 11488 701 7018 11101
> 12.2.7.0/24 10.5.0.48 100 100 11488 701 7018 11101
> 12.2.76.0/24 10.5.0.48 100 100 11488 701 7018 11812
> 12.2.99.0/24 10.5.0.48 100 100 11488 701 7018 10656
> 12.2.109.0/24 10.5.0.48 100 100 11488 701 7018 10656
> 12.2.169.0/24 10.5.0.48 100 100 11488 701 7018 11806
> 12.4.114.0/24 10.5.0.48 100 100 11488 701 7018 14065
178 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
> 12.4.119.0/24 10.5.0.48 100 100 11488 701 7018 14065
> 12.4.175.0/24 10.5.0.48 100 100 11488 701 7018 11895
> 12.4.196.0/22 10.5.0.48 100 100 11488 701 7018 12163
> 12.5.48.0/21 10.5.0.48 100 100 11488 701 7018 12163
> 12.5.164.0/24 10.5.0.48 100 100 11488 701 7018 11134
> 12.6.42.0/23 10.5.0.48 100 100 11488 701 7018 11090
Meaning
lists the show ip bgp filter-list command output fields.
Table 32: show ip bgp filter-list Output Fields
Field Name Field Description
Local router ID local AS
BGP router ID of the local router
Local autonomous system number paths distinct prefixes paths selected for route table installation path attribute entries
Prefix
Next hop IP address
MED
CalPrf
Weight
AS path
Total number of routes stored in the BGP routing table. If several peers have advertised a route to the same prefix, all routes are included in this count.
Number of routes to unique prefixes stored in the BGP routing table.
If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Prefix for the routing table entry
IP address of the next router that is used when a packet is forwarded to the destination network
Multiexit discriminator for the route
Calculated preference for the route
Weight of the route
Autonomous system path
Related
Documentation
•
show bgp ipv6 filter-list
•
show ip bgp filter-list
Copyright © 2013, Juniper Networks, Inc.
179
JunosE 14.3.x BGP and MPLS Configuration Guide
Monitoring BGP Flap Statistics
Purpose Display information about BGP flap statistics
The show ip bgp flap-statistics and show bgp ipv6 flap-statistics commands display similar information.
Action To display information about flap statistics: host1# show ip bgp flap-statistics
Local BGP identifier 192.168.1.232, local AS 100
Route flap dampening is enabled
Default decay half-life is 15 minutes
Default cutoff threshold is 2000, default reuse threshold is 750
Default maximum hold-down time is 60 minutes
307 paths have active route flap histories (27016 bytes used)
5 paths are suppressed
Figure Time until
Prefix Peer Status of Merit Reuse/Remove
24.201.0.0/18 192.168.1.158 Available 925 00:58:23
24.201.64.0/18 192.168.1.158 Available 925 00:58:23
52.128.224.0/19 192.168.1.158 Available 750 00:54:12
61.8.0.0/19 192.168.1.158 Available 993 00:59:53
61.8.30.0/24 192.168.1.158 Available 993 00:59:53
62.229.73.0/24 192.168.1.158 Unreachable 925 00:58:23
63.69.150.0/24 192.168.1.158 Available 750 00:54:12
Meaning
lists the show ip bgp flap-statistics command output fields.
Table 33: show ip bgp flap-statistics Output Fields
Field Name Field Description
Local BGP identifier BGP router ID of the local router local AS
Route flap dampening
Default decay half-life
Default cutoff threshold
Default reuse threshold
Default maximum hold-down time route flap history
Local autonomous system number
Status of route flap dampening (enabled or disabled)
Time (in minutes) after which a penalty is decreased. After the route has been assigned a penalty, the penalty is decreased by half after the half-life period (which is 15 minutes by default).
Value of the penalty for a flapping route below which the route is unsuppressed
Time (in hours:minutes:seconds) after which the path will be made available
Interval, in seconds, after not receiving a keepalive message that the software declares a peer dead
Status of route flap history for route paths
180 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 33: show ip bgp flap-statistics Output Fields (continued)
Field Name Field Description
Prefix
Peer
Status
Figure of Merit
Prefix for the routing table entry
IP address of BGP peer
Status of route dampening of the route path
A measure of the route's stability. Higher values indicate more recent route flap activity or less stability.
Time until Reuse/Remove Time until the route is either reused (if currently suppressed) or its history entry is removed (if currently available)
Related
Documentation
•
show bgp ipv6 flap-statistics
•
show ip bgp flap-statistics
Monitoring BGP Routes with Inconsistent AS Paths
Purpose Display information about routes that have inconsistent AS paths. Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop.
The show ip bgp inconsistent-as and show bgp ipv6 inconsistent-as commands display similar information.
Action To display information about routes that have inconsistent AS paths: host1# show ip bgp inconsistent-as
Local BGP identifier 192.168.1.10, local AS 123
0 routes (0 bytes used), 0 distinct destinations (0 bytes used)
0 routes selected for route table installation
0 path attribute entries (0 bytes used)
Status codes: > best, * invalid, s suppressed, d dampened, r rejected
Prefix Next-hop MED LocPrf Weight AS-path
> 4.0.0.0/8 0.0.0.0 1 32768 empty
4.0.0.0/8 192.168.1.1 0 11488 701 1
Meaning
lists the show ip bgp inconsistent-as command output fields.
Table 34: show ip bgp inconsistent-as Output Fields
Field Name Field Description
Local BGP identifier local AS
BGP router ID of the local router
Local autonomous system number
Copyright © 2013, Juniper Networks, Inc.
181
JunosE 14.3.x BGP and MPLS Configuration Guide
Prefix
Next hop
MED
LocPrf
Weight
Origin
AS-path
Table 34: show ip bgp inconsistent-as Output Fields (continued)
Field Name Field Description routes distinct destinations routes selected for route table installation path attribute entries
Total number of routes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, all routes are included in this count.
Number of routes to unique prefixes stored in the BGP routing table.
If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Prefix for the routing table entry
IP address of the next hop
Multiexit discriminator for the route
Local preference for the route
Assigned path weight
Origin of the route
AS path through which this route bas been advertised
Related
Documentation
•
show bgp ipv6 inconsistent-as
•
show ip bgp inconsistent-as
Monitoring BGP Neighbors
Purpose Display information about BGP neighbors.
The show ip bgp neighbors and show bgp ipv6 neighbors commands display similar information.
Action To display information about BGP neighbors:
• host1# show ip bgp neighbors
BGP neighbor ID 10.2.1.48, remote AS 11488 (external peer)
Remote router ID is 172.31.1.48, negotiated BGP version is 4
Administrative status is Start, connection state is Established
182 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Reason for last reset was tcp connection error
TCP error code 60 (Connection timed out)
Connection has been established 1 time, up for 0 17:42:31
Options:
Default originate is disabled
EBGP multi-hop is enabled
IBGP single-hop is disabled
Next hop self is disabled
seconds
Policy:
Neighbor weight is 100
Timers:
Connect retry interval is 120 seconds
Minimum route advertisement interval is 30 seconds
Minimum AS origination interval is 10 seconds
Configured keep-alive interval is 30 seconds, negotiated 30
seconds
Configured hold time is 90 seconds, negotiated 90
TCP connection:
Local IP address is 192.168.1.218, local port is 1024
Remote IP address is 10.2.1.48, remote port is 179
Statistics:
Total of 4100 messages sent, 44913 messages received
2053 update messages sent, 42785 update messages received
0 00:00:17 since last update message was received
•
Fields relevant to multiprotocol extensions:
Multi-protocol extensions negotiation:
ip-v4 unicast: sent, received, used
ip-v6 unicast-labeled: sent, received, used
•
For the graceful restart capability, additional information is presented.
•
Fields concerning graceful restart attributes that apply to peers as a whole (for all address families):
Graceful restart negotiation:
Sent restart time is 120 seconds
Sent restart state bit is zero (we are not restarting)
Received restart time is 120 seconds
Received restart state bit is zero (peer is not restarting)
Maximum time for keeping stale paths is 360 seconds
•
Fields concerning attributes that apply to peers a particular address family:
Peer is capable of preserving forwarding stat(3)
Peer preserved forwarding state during last restart
We have received an end-of-rib marker from the peer
We have sent an end-of-rib marker to the peer
•
Fields relevant if the peer is currently restarting:
Graceful restart waiting for the session to come back up
Restart-time advertised by the peer is 120 seconds
Remaining time for the peer to come back up is 117 seconds
Remaining time for keeping stale routes from the peer is 357 seconds
•
Fields relevant during reconvergence after the peer has restarted:
Graceful restart negotiation:
Sent restart time is 120 seconds
Sent restart state bit is zero (we are not restarting)
Received restart time is 120 seconds
Copyright © 2013, Juniper Networks, Inc.
183
JunosE 14.3.x BGP and MPLS Configuration Guide
Received restart state bit is zero (peer is not restarting)
Maximum time for keeping stale paths is 300 seconds
Remaining time for keeping stale routes from the peer is 297 seconds
•
For BFD, additional information is presented.
•
Fields relevant to BFD when BFD is not configured:
BFD is disabled
•
Fields relevant to BFD when BFD is configured for an IBGP peer:
BFD is enabled but not supported (IBGP neighbor)
•
Fields relevant to BFD when BFD is configured for a multihop EBGP peer:
BFD is enabled but not supported (multi-hop EBGP neighbor)
•
Fields relevant to BFD when BFD is configured but the BGP session is not established:
BFD is enabled:
Single-hop IPv4 BFD session to 1.2.3.4
Minimum transmit interval is 300 ms
Minimum receive interval is 300 ms
Multiplier is 3
Waiting for BGP to become established before initiating BFD session
•
Fields relevant to BFD when BFD is configured, the BGP session is established, but the BFD protocol session is not up:
BFD is enabled:
Single-hop IPv4 BFD session to 1.2.3.4
Minimum transmit interval is 300 ms
Minimum receive interval is 300 ms
Multiplier is 3
BFD session is down
•
Fields relevant to BFD when BFD is configured, the BGP session is established, and the BFD protocol session is up:
BFD is enabled:
Single-hop IPv4 BFD session to 1.2.3.4
Minimum transmit interval is 300 ms
Minimum receive interval is 300 ms
Multiplier is 3
BFD session is up for 00:00:50
Negotiated detection time is 900 ms
•
Fields relevant to conditional advertisement:
Advertise-map is advertisetoR1
Condition-map: trigger1
Sequence: 5
Status: Withdraw
Advertise-map is alternatetoR1
Condition-map: trigger2
Sequence: 10
Status: Advertise
Meaning
lists the show ip bgp neighbors command output fields.
184 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 35: show ip bgp neighbors Output Fields
Field Name Field Description
BGP neighbor ID remote AS
Description
Member of peer group
BGP identifier of the BGP neighbor
Remote AS of the BGP neighbor
Textual description of the BGP neighbor
Name of the peer group of which this BGP neighbor is a member
Remote router ID negotiated BGP version
Administrative status
Connection state
Connection has been established
Reason for last reset
TCP error code
Default originate
EBGP multi-hop
IBGP single-hop
Router ID of the remote router
BGP version being used to communicate with the neighbor
Desired state of the peer connection
Current state of the BGP connection
Time that TCP connection was established
Reason for last reset of the BGP session
TCP connection error type
Status of default originate (enabled or disabled)
Status of EBGP multihop (enabled or disabled)
Status of IBGP single hop (enabled or disabled)
Next hop self
Route reflector status
Status of next-hop self (enabled or disabled)
Identifies the neighbor as a route-reflector client
Neighbor weight Weight of routes from the BGP neighbor
Incoming update distribute list
Distribute list for incoming routes, if configured
Outgoing update distribute list
Distribute list for outgoing routes, if configured
Incoming update filter list Update filter list for incoming routes, if configured
Outgoing update filter list Update filter list for outgoing route, if configured
Weight filter list
Incoming route map
Weight filter list for routes, if configured
Incoming route map, if configured
Copyright © 2013, Juniper Networks, Inc.
185
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 35: show ip bgp neighbors Output Fields (continued)
Field Name Field Description
Outgoing route map
Connect retry interval
Outgoing route map, if configured
Time between a BGP peer’s attempts to reestablish a connection to the neighbor
Minimum time between route advertisements Minimum route advertisement interval
Minimum AS origination interval
Minimum time between advertisement of changes within the speaker’s AS
Configured keep-alive interval
Negotiated keepalive interval
Frequency of keep-alive messages generated
Negotiated frequency of keep-alive messages generated
Configured hold time
Negotiated hold time
Configured maximum time allowed between received messages
Negotiated maximum time allowed between received messages
Configured update source
IP address
IP address used when sending update messages
Local IP address
Local port
Remote IP address
Remote port
Total messages sent
Local IP address used for TCP communication to this peer
Local TCP port number used for TCP communication to this peer
Remote IP address used for TCP communication to this peer
Remote IP address used for TCP communication to this peer
Total BGP messages sent to this neighbor
Total messages received
Total update messages sent
Total BGP messages received from this neighbor
Total BGP update messages sent to this neighbor
Total update messages received
Time since last update message was received
Total BGP update messages received from this neighbor
Time since last BGP update message was received from this neighbor
Address Family dependent capabilities
Lists type of ORF send and receive capability per address family and whether it is advertised (configured) or received
186 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 35: show ip bgp neighbors Output Fields (continued)
Field Name Field Description
Maximum number of ORF entries
Limit of ORF entries that will be accepted from the neighbor
Capability advertisement Lists whether the specific capability (capabilities option, deprecated dynamic capability negotiation, dynamic capability negotiation, multiprotocol extensions, route refresh, route refresh (Cisco proprietary), four octet AS numbers, and graceful restart) has been sent, received, or both
Multi-protocol extensions negotiation
Lists the relevant address family and whether it has been sent, received, or used
BFD Status of BFD configuration, enabled, enabled but not supported because the peer is an IBGP neighbor a multihop EBGP neighbor, or disabled
BFD session Type and address of peer to which BFD session is established
Minimum transmit interval Desired interval between BFD packets transmitted to members of peer group
Minimum receive interval
Multiplier
Desired interval between BFD packets received from members of peer group
Number of BFD packets that can be missed before declaring BFD session down
Negotiated detection time Interval between BFD packets negotiated by peers
Advertise-map
Condition-map
Sequence
Status
Name of route map that specifies routes to be advertised when routes in conditional route maps are matched
Name of route map that specifies routes to be matched by routes in the BGP routing table
Position of the specified advertise route map in a list of advertise route maps configured for a particular peer within the same address-family. A lower sequence number has a higher priority; that route map is processed before one with a higher sequence number.
Status of the routes specified by the route map, advertise (route map condition has been met) or withdraw (route map condition has not been met; regardless of this status, the specified routes might be governed by another route map with a lower sequence number and actually advertised or not according to that map
Related
Documentation
•
show bgp ipv6 neighbors
•
show ip bgp neighbors
Copyright © 2013, Juniper Networks, Inc.
187
JunosE 14.3.x BGP and MPLS Configuration Guide
Monitoring Dampened BGP Routes of Specified Neighbors
Purpose Display information about routes with a dampening history for the specified BGP neighbor.
Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop.
The show ip bgp neighbors dampened-routes and show bgp ipv6 neighbors dampened-routes commands display similar information.
Action To display information about routes with a dampening history for the specified BGP neighbor: host1# show ip bgp neighbors 192.168.1.158 dampened-routes
Local BGP identifier 192.168.1.232, local AS 100
120 routes (5760 bytes used), 94 distinct destinations (9024 bytes used)
67 routes selected for route table installation
23 path attribute entries (3450 bytes used)
Status codes: > best, * invalid, s suppressed, d dampened, r rejected
Prefix Peer Next-hop MED LocPrf Weight Origin
d12.8.12.0/24 192.168.1.158 192.168.1.1 0 IGP
d24.48.12.0/24 192.168.1.158 192.168.1.1 0 IGP
d24.72.12.0/24 192.168.1.158 192.168.1.1 0 inc.
d24.116.12.0/23 192.168.1.158 192.168.1.1 0 IGP
d24.143.12.0/24 192.168.1.158 192.168.1.1 0 IGP
d24.154.12.0/24 192.168.1.158 192.168.1.1 0 inc.
d24.216.12.0/24 192.168.1.158 192.168.1.1 0 IGP
d24.240.12.0/24 192.168.1.158 192.168.1.1 0 IGP
d24.244.12.0/22 192.168.1.158 192.168.1.1 0 IGP
d24.246.12.0/22 192.168.1.158 192.168.1.1 0 IGP
d61.0.12.0/24 192.168.1.158 192.168.1.1 0 IGP
d61.11.12.0/24 192.168.1.158 192.168.1.1 0 IGP
d62.74.12.0/22 192.168.1.158 192.168.1.1 0 IGP
d62.76.12.0/22 192.168.1.158 192.168.1.1 0 IGP
d63.65.12.0/24 192.168.1.158 192.168.1.1 0 inc.
d63.73.12.0/24 192.168.1.158 192.168.1.1 0 IGP
Meaning
lists the show ip bgp neighbors dampened-routes command output fields.
Table 36: show ip bgp neighbors dampened-routes Output Fields
Field Name Field Description
Local BGP identifier BGP router ID of the local router local AS routes
Local autonomous system number
Total number of routes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, all routes are included in this count.
188 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 36: show ip bgp neighbors dampened-routes Output Fields
(continued)
Field Name Field Description distinct destinations routes selected for route table installation path attribute entries
Prefix
Number of routes to unique prefixes stored in the BGP routing table.
If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Prefix for the routing table entry
Peer
Next hop IP address
MED
LocPrf
Weight
Origin
IP address of BGP peer
IP address of the next hop
Multiexit discriminator for the route
Local preference for the route
Assigned path weight
Origin of the route
Related
Documentation
•
show bgp ipv6 neighbors dampened-routes
•
show ip bgp neighbors dampened-routes
Monitoring BGP Paths of Neighbors
Purpose Display path information for the specified BGP neighbor.
The show ip bgp neighbors paths and show bgp ipv6 neighbors paths commands display similar information.
Action To display path information for the specified BGP neighbor.
host1# show ip bgp neighbors 1.02.3.4 paths
Address Refcount Origin Next-hop AS-path
0xC384BD0 1 IGP 192.168.1.1 11488 701 2853 5515 764
0xC384C40 1 IGP 192.168.1.1 11488 701 4183
0xC384CB0 1 IGP 192.168.1.1 11488 701 1239 1833 1833 1833 1299
8308
0xC384D20 1 IGP 192.168.1.1 11488 701 6453 786
0xC384D90 1 IGP 192.168.1.1 11488 701 6453 1103 1103
Copyright © 2013, Juniper Networks, Inc.
189
JunosE 14.3.x BGP and MPLS Configuration Guide
0xC384E00 1 IGP 192.168.1.1 11488 701 6762 9116 9116 9116 6888
6888
0xC384E70 1 IGP 192.168.1.1 11488 701 6453 8297 6758
0xC384EE0 1 IGP 192.168.1.1 11488 701 5511 3215
0xC384F50 1 IGP 192.168.1.1 11488 701 3561 5683 5551
0xC384FC0 1 IGP 192.168.1.1 11488 701 1239 1755 1273 8793 8793
8793
0xC385030 1 IGP 192.168.1.1 11488 701 5705 5693
Meaning
lists the show ip bgp neighbors paths command output fields.
Table 37: show ip bgp neighbors paths Output Fields
Field Name Field Description
Address
Refcount
Hexadecimal number that uniquely identifies the path attributes
Number of routes that share the path attributes
Origin
Next-hop
AS-path
Value of the origin path attribute
Value of the next-hop path attribute
Value of the AS-path attribute
Related
Documentation
•
show bgp ipv6 neighbors paths
•
show ip bgp neighbors paths
Monitoring Prefix List Outbound Route Filters Received from the BGP Neighbor
Purpose Display prefix-list outbound route filters received from the BGP neighbor.
Action To display prefix-list outbound route filters received from the specified neighbor: host1# show ip bgp neighbors 192.168.1.158 received prefix-filter ip prefix-list filter 192.168.1.158 for address family ipv4:unicast
seq 5 permit 10.1.1.1/32
seq 10 permit 10.1.1.2/32
seq 15 permit 10.1.1.3/32
Meaning
lists the show ip bgp neighbors received prefix-filter command output fields.
Table 38: show ip bgp neighbors received prefix-filter
Field Name Field Description seq Sequence number of the entry in the prefix list permit, deny Condition statement for addresses matching the listed address
190 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Related
Documentation
•
show ip bgp neighbors
Monitoring Routes Originating from a BGP Neighbor Before Application of Inbound
Policy
Purpose Display routes originating from the specified BGP neighbor before inbound policy is applied. Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop.
The show ip bgp neighbors received-routes and show bgp ipv6 neighbors received-routes commands display similar information.
Action To display routes originating from the specified BGP neighbor before inbound policy is applied: host1# show ip bgp neighbors 192.168.1.158 received-routes
Local BGP identifier 111.111.111.111, local AS 444
0 routes (0 bytes used), 0 distinct destinations (0 bytes used)
0 routes selected for route table installation
0 path attribute entries (0 bytes used)
Status codes: > best, * invalid, s suppressed, d dampened, r rejected
Prefix Peer Next-hop MED LocPrf Weight Origin
>0.0.0.0/0 192.168.1.158 192.168.1.158 0 IGP
>13.13.13.13/32 192.168.1.158 192.168.1.158 0 0 IGP
Meaning
lists the show ip bgp neighbors received-routes command output fields.
Table 39: show ip bgp neighbors received-routes Output Fields
Field Name Field Description
Local BGP identifier local AS routes distinct destinations routes selected for route table installation
BGP router ID of the local router
Local autonomous system number
Total number of routes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, all routes are included in this count.
Number of routes to unique prefixes stored in the BGP routing table.
If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table path attribute entries Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Copyright © 2013, Juniper Networks, Inc.
191
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 39: show ip bgp neighbors received-routes Output Fields
(continued)
Field Name Field Description
Prefix
Peer
Next hop
MED
Prefix for the routing table entry
IP address of BGP peer
IP address of the next hop
Multiexit discriminator for the route
LocPrf
Weight
Origin
Local preference for the route
Assigned path weight
Origin of the route
Related
Documentation
•
show bgp ipv6 neighbors received-routes
•
show ip bgp neighbors received-routes
Monitoring Routes Originating from a BGP Neighbor After Application of Inbound Policy
Purpose Display all routes that originate from the specified BGP neighbor after inbound policy is applied. Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop.
The show ip bgp neighbors routes and show bgp ipv6 neighbors routes commands display similar information.
Action To all routes that originate from the specified BGP neighbor after inbound policy is applied: host1# show bgp ipv6 neighbors 12.12.12.12 routes
Local BGP identifier 11.11.11.11, local AS 400
5 routes (200 bytes)
5 destinations (360 bytes) of which 5 have a route
5 routes selected for route table installation
4 path attribute entries (608 bytes)
Local-RIB version 33. FIB version 33.
Status codes: > best, * invalid, s suppressed, d dampened, r rejected,
a auto-summarized
Prefix Peer Next-hop MED LocPrf Weight Origin
> 3ffe:0:1:1::/64 12.12.12.12 ::102.102.102.2 0 100 0 inc.
Meaning
lists the show bgp ipv6 neighbors routes command output fields.
192 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Prefix
Peer
Next hop
MED
LocPrf
Weight
Origin
Table 40: show bgp ipv6 neighbors routes Output Fields
Field Name Field Description
Local BGP identifier local AS routes destinations
BGP router ID of the local router
Local autonomous system number
Total number of routes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, all routes are included in this count.
Number of routes to unique prefixes stored in the BGP routing table and amount of memory consumed by routes. If several peers have advertised a route to the same prefix, only the best route is included in this count.
routes selected for route table installation path attribute entries
Local-RIB version
FIB version
Number of routes in the BGP routing table that have been inserted into the IP routing table, plus prefixes for which there are currently no routes but which have had to be withdrawn from peers to which these prefixes may been previously advertised.
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Number that is increased by one each time a route in that RIB is added, removed or modified.
Number that is increased by one each time BGP updates the routes in the IP routing table based on changes in the local RIB. The FIB version matches the local-RIB version when BGP has finished updating the routes in the IP route table. The FIB version is less than the local-RIB version when BGP is still in the process of updating the IP routing table.
Prefix for the routing table entry
IP address of BGP peer
IP address of the next hop
Multiexit discriminator for the route
Local preference for the route
Assigned path weight
Origin of the route
Copyright © 2013, Juniper Networks, Inc.
193
JunosE 14.3.x BGP and MPLS Configuration Guide
Related
Documentation
•
show bgp ipv6 neighbors routes
•
show ip bgp neighbors routes
Monitoring Networks in an Autonomous System
Purpose Display information about networks in an AS.
The show ip bgp network and show bgp ipv6 network commands display similar information.
Action To display information about networks in an AS: host1# show bgp ipv6 network
Prefix Weight Route-map Backdoor
3ffe:0:0:2::/64 No
Meaning
lists the show bgp ipv6 network command output fields.
Table 41: show bgp ipv6 network Output Fields
Field Name Field Description
Prefix
Weight
Route-map
Backdoor
Prefix for the routing table entry
Assigned path weight
Indicates whether network-route filtering is enabled
Indicates whether an IGP backdoor route is favored over an EBGP route
Related
Documentation
•
show bgp ipv6 network
•
show ip bgp network
Monitoring BGP Next Hops
Purpose Display information about all indirect next hops or a particular next hop..
The show ip bgp next-hops and show bgp ipv6 next-hops commands display similar information.
Action To display information about all indirect next hops or a particular indirect next hop: host1# show ip bgp next-hops
Indirect next-hop 4.4.4.4
Reachable (metric 2)
Direct next-hop atm2/0.34 (34.34.34.4)
Reference count is 3
Indirect next-hop ::ffff:2.2.2.2
MPLS stacked label 17
194 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Reachable (metric 3)
Direct next-hop tun mpls:vpnInL17-23
Reference count is 1
Indirect next-hop 5.5.5.5
Reachable (metric 2)
Direct next-hop atm2/0.35 (35.35.35.5)
Reference count is 3
Indirect next-hop 6.6.6.6
Reachable (metric 3)
Direct next-hop atm2/0.34 (34.34.34.4)
atm2/0.35 (35.35.35.5)
Reference count is 3
Indirect next-hop 13.13.13.1
Not reachable
Reference count is 2
Meaning
lists the show ip bgp next-hops command output fields.
Table 42: show ip bgp next-hops Output Fields
Field Name Field Description
Indirect next-hop
Reachable
BGP next-hop attribute as received in the BGP update message
Indicates whether or not the indirect next hop is reachable.
Metric
Direct next-hop
Reference count
Metric of the BGP indirect next hop
IP interface and next-hop IP address that resolve the BGP indirect next hop; the direct next hop can also be an IP indirect next hop or an MPLS indirect next hop when chains of next hops are in use
Number of label mappings of BGP routes that use this next hop
Related
Documentation
•
show bgp ipv6 next-hops
•
show ip bgp next-hops
Monitoring BGP Paths
Purpose Display information about the most common BGP path attributes.
The show ip bgp paths and show bgp ipv6 paths commands display similar information.
Action To display information about BGP paths: host1# show bgp ipv6 paths
Address Refcount Metric AS-path
0x4B311118 1 100
0x4C548224 1 0 100
0x4C548530 1 0 200
0x4C548704 2 0 300
Copyright © 2013, Juniper Networks, Inc.
195
JunosE 14.3.x BGP and MPLS Configuration Guide
BGP internally maintains additional attributes that are not displayed—for example, the
MED, local preference, and communities attributes.
Meaning
lists the show bgp ipv6 paths command output fields.
Table 43: show bgp ipv6 paths Output Fields
Field Name Field Description
Address
Refcount
Hexadecimal number that uniquely identifies the path attributes
Number of routes that share the path attributes
Origin
Next hop
AS-path
Value of the origin path attribute
Value of the next-hop path attribute
Value of the AS-path attribute
Related
Documentation
•
show bgp ipv6 paths
•
show ip bgp paths
Monitoring BGP Peer Groups
Purpose Display information about BGP peer groups.
The show ip bgp peer-group and show bgp ipv6 peer-group commands display similar information.
Action To display information about BGP peer groups: host1# show ip bgp peer-group
BGP peer-group leftcoast, remote AS 200
Peer-group members are external peers
Local AS 100
Administrative status is Start
EBGP multi-hop is disabled
IBGP single-hop is disabled
BFD is enabled:
Single-hop IPv4 BFD session
Minimum transmit interval is 300 ms
Minimum receive interval is 300 ms
Multiplier is 3
Maximum update message size is 1024 octets
Neighbor weight is 0
Connect retry interval is 10 seconds initially
Configured keep-alive interval is 30 seconds
Configured hold time is 90 seconds
Minimum route advertisement interval is 30 seconds
Minimum AS origination interval is 10 seconds
Graceful restart negotiation:
Restart time is 120 seconds
Stale paths time is 360 seconds
196 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Configuration for address family ipv4:unicast
RIB-out is disabled
Default originate is disabled
Next hop self is disabled
Next hop unchanged is disabled
Don't send communities
Inbound soft reconfiguration is disabled
Private AS number stripping is disabled
Override site AS with provider AS is disabled
No loops in the received AS-path are allowed
Members: 10.2.2.2 10.3.3.3
•
Fields relevant to conditional advertisement:
Advertise-map is advertisetoR1
Condition-map: trigger1
Sequence: 5
Status: Withdraw
Advertise-map is alternatetoR1
Condition-map: trigger2
Sequence: 10
Status: Advertise
Meaning
lists the show ip bgp peer-group command output fields.
Table 44: show ip bgp peer-group Output Fields
Field Name Field Description
BGP peer group remote AS local AS
Administrative status
Name of a BGP peer group
Remote AS of the BGP neighbor
Local autonomous system number
Desired state of the peer connection
EBGP multi-hop
IBGP single-hop
BFD
BFD session
Description
Status of EBGP multihop for the peer group (enabled or disabled)
Status of IBGP single hop for the peer group (enabled or disabled)
Status of BFD configuration for the peer group (enabled or disabled)
Type and address of peer to which BFD session is established
Textual description of the BGP neighbor
Members
Default originate
Name of the peer group of which this BGP neighbor is a member
IP addresses of the members of the BGP peer group
Minimum transmit interval Desired time interval between BFD packets transmitted to members of peer group
Copyright © 2013, Juniper Networks, Inc.
197
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 44: show ip bgp peer-group Output Fields (continued)
Field Name Field Description
Minimum receive interval
Multiplier
Next hop self
Peers are route reflector clients
Desired time interval between BFD packets received from members of peer group
Number of BFD packets that can be missed before declaring BFD session down
Status of next-hop self information for the peer group (enabled or disabled)
BGP peer group is configured as a route reflector. This field does not appear when route reflectors are not configured.
weight Neighbor weights assigned to BGP peer groups
Incoming update distribute list
Distribute list for incoming routes, if configured
Outgoing update distribute list
Distribute list for outgoing routes, if configured
Incoming update filter list Update filter list for incoming routes, if configured
Outgoing update filter list Update filter list for outgoing route, if configured
Weight filter list
Incoming route map
Outgoing route map
Minimum route advertisement interval
Weight filter list for routes, if configured
Incoming route map, if configured
Outgoing route map, if configured
Minimum time between route advertisements
Configured update source
IP address
IP address used when sending update messages
Advertise-map
Condition-map
Sequence
Name of route map that specifies routes to be advertised when routes in conditional route maps are matched
Name of route map that specifies routes to be matched by routes in the BGP routing table
Position of the specified advertise route map in a list of advertise route maps configured for a particular peer within the same address-family. A lower sequence number has a higher priority; that route map is processed before one with a higher sequence number.
198 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 44: show ip bgp peer-group Output Fields (continued)
Field Name Field Description
Status Status of the routes specified by the route map, advertise (route map condition has been met) or withdraw (route map condition has not been met; regardless of this status, the specified routes might be governed by another route map with a lower sequence number and actually advertised or not according to that map
Related
Documentation
•
show bgp ipv6 peer-group
•
show ip bgp peer-group
Monitoring BGP Routes with Matching AS Paths and Regular Expressions for Single
Regular Expressions
Purpose Display information about BGP routes whose AS path matches the specified regular expression. Accepts a single regular expression element. Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop.
Regular expressions match numbers for which the specified path is a substring—for example, if you specify 20, 200 matches because 20 is a substring of 200. You can disallow substring matching by using the underscore (_) metacharacter to constrain matching to the specified pattern, for example, _20_.
The show ip bgp quote-regexp and show bgp ipv6 quote-regexp commands display similar information.
Action To display information about routes whose AS path matches the specified regular expression: host1# show ip bgp quote-regexp ^200
Local router ID 192.168.1.232, local AS 100
6 paths, 3 distinct prefixes (324 bytes used)
3 paths selected for route table installation
7 path attribute entries (872 bytes used)
Prefix Next-hop MED CalPrf Weight AS-path
10.99.1.2/32 10.1.1.2 100 100 200
10.99.1.3/32 10.1.1.2 100 100 200 10
10.99.1.4/32 10.1.1.2 100 100 200 10 20
NOTE: For single regular expressions without any spaces in them, you can use either show ip bgp regexp or show ip bgp quote-regexp with the same results.
You must enclose all regular expression elements within quotation marks (“ element” ) when the regular expressions contain one or more spaces. To display information about
Copyright © 2013, Juniper Networks, Inc.
199
JunosE 14.3.x BGP and MPLS Configuration Guide
200 routes whose AS path matches the specified regular expression and also has spaces within the regular expression element: host1# show ip bgp quote-regexp “ 10 20"
Local router ID 192.168.1.232, local AS 100
6 paths, 3 distinct prefixes (324 bytes used)
3 paths selected for route table installation
7 path attribute entries (872 bytes used)
Prefix Next-hop MED CalPrf Weight AS-path
10.99.1.4/32 10.1.1.2 100 100 200 10 20
Because the show ip bgp quote-regexp command accepts only one string as an argument to the regular expression, output filtering is possible. To display information about routes whose AS path matches the specified regular expression with output filtering: host1# show ip bgp quote-regexp ^200 | begin Prefix
Prefix Next-hop MED CalPrf Weight AS-path
10.99.1.2/32 10.1.1.2 100 100 200
10.99.1.3/32 10.1.1.2 100 100 200 10
10.99.1.4/32 10.1.1.2 100 100 200 10 20
Meaning
lists the show ip bgp quote-regexp command output fields.
Table 45: show ip bgp quote-regexp Output Fields
Field Name Field Description
Local router ID local AS paths
BGP router ID of the local router
Local autonomous system number
Total number of routes stored in the BGP routing table. If several peers have advertised a route to the same prefix, all routes are included in this count.
distinct prefixes paths selected for route table installation path attribute entries
Prefix
Next hop IP address
MED
Number of routes to unique prefixes stored in the BGP routing table.
If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Prefix for the routing table entry
IP address of the next router that is used when a packet is forwarded to the destination network
Multiexit discriminator for the route
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 45: show ip bgp quote-regexp Output Fields (continued)
Field Name Field Description
CalPrf
Weight
AS path
Calculated preference for the route
Weight of the route
Autonomous system path
Related
Documentation
•
Monitoring BGP Routes with Matching AS Paths and Regular Expressions for Multiple
Regular Expressions on page 201
•
show bgp ipv6 quote-regexp
•
show ip bgp quote-regexp
Monitoring BGP Routes with Matching AS Paths and Regular Expressions for Multiple
Regular Expressions
Purpose Display information about BGP routes whose AS path matches the specified regular expression elements. Accepts one or more regular expression elements. Report whether the indirect next hop of a route is unreachable; if not, display the IGP cost to the indirect next hop.
Regular expressions match numbers for which the specified path is a substring—for example, if you specify 20, 200 matches because 20 is a substring of 200. You can disallow substring matching by using the underscore (_) metacharacter to constrain matching to the specified pattern, for example, _20_.
The show ip bgp regexp and show bgp ipv6 regexp commands display similar information.
Action To display information about routes whose AS path matches the specified regular expression element: host1# show ip bgp regexp ^200
Local router ID 192.168.1.232, local AS 100
6 paths, 3 distinct prefixes (324 bytes used)
3 paths selected for route table installation
7 path attribute entries (872 bytes used)
Prefix Next-hop MED CalPrf Weight AS-path
10.99.1.2/32 10.1.1.2 100 100 200
10.99.1.3/32 10.1.1.2 100 100 200 10
10.99.1.4/32 10.1.1.2 100 100 200 10 20
NOTE: For single regular expressions without any spaces in them, you can use either show ip bgp regexp or show ip bgp quote-regexp with the same results.
Copyright © 2013, Juniper Networks, Inc.
201
JunosE 14.3.x BGP and MPLS Configuration Guide
202
To display information about routes whose AS path matches the specified regular expression and also has spaces within the regular expression element: host1# show ip bgp regexp 10 20
Local router ID 192.168.1.232, local AS 100
6 paths, 3 distinct prefixes (324 bytes used)
3 paths selected for route table installation
7 path attribute entries (872 bytes used)
Prefix Next-hop MED CalPrf Weight AS-path
10.99.1.4/32 10.1.1.2 100 100 200 10 20
The show ip bgp regexp command accepts multiple strings as arguments. If you try to apply output filtering, the command interprets the filter information as a regular expression and fails. To display information about routes whose AS path matches the specified regular expression with output filtering: host1#s how ip bgp regexp ^200 | begin Prefix
% invalid regular expression
Meaning
lists the show ip bgp regexp command output fields.
Table 46: show ip bgp regexp Output Fields
Field Name Field Description
Local router ID BGP router ID of the local router local AS paths distinct prefixes paths selected for route table installation path attribute entries
Prefix
Next hop IP address
MED
CalPrf
Local autonomous system number
Total number of routes stored in the BGP routing table. If several peers have advertised a route to the same prefix, all routes are included in this count.
Number of routes to unique prefixes stored in the BGP routing table.
If several peers have advertised a route to the same prefix, only the best route is included in this count.
Number of routes in the BGP routing table that have been inserted into the IP routing table
Number of distinct path attributes stored in BGP's internal path attributes table. If BGP receives two routes for different prefixes but with identical path attributes, BGP will create only one entry in its internal path attribute table and share it between the two routes to conserve memory.
Prefix for the routing table entry
IP address of the next router that is used when a packet is forwarded to the destination network
Multiexit discriminator for the route
Calculated preference for the route
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 46: show ip bgp regexp Output Fields (continued)
Field Name Field Description
Weight
AS path
Weight of the route
Autonomous system path
Related
Documentation
•
Monitoring BGP Routes with Matching AS Paths and Regular Expressions for Single
Regular Expressions on page 199
•
show bgp ipv6 regexp
•
show ip bgp regexp
Monitoring the Status of All BGP Neighbors
Purpose Display summarized status of all BGP neighbors.
The show ip bgp summary and show bgp ipv6 summary commands display similar information.
Action To display summarized status of all BGP neighbors: host1# show bgp ipv6 summary
Local router ID 10.13.13.13, local AS 400
Administrative state is Start
BGP Operational state is Up
Shutdown in overload state is disabled
Default local preference is 100
IGP synchronization is disabled
Default originate is disabled
Always compare MED is disabled
Compare MED within confederation is disabled
Advertise inactive routes is disabled
Advertise best external route to internal peers is disabled
Enforce first AS is disabled
Missing MED as worst is disabled
Route flap dampening is disabled
Maximum number of equal-cost EBGP paths is 2
Maximum number of equal-cost IBGP paths is 2
Log neighbor changes is disabled
Fast External Fallover is disabled
No maximum received AS-path length
BGP administrative distances are 20 (ext), 200 (int), and 200 (local)
Client-to-client reflection is enabled
Cluster ID is 10.13.13.13
Route-target filter is enabled
Default IPv4-unicast is enabled
Redistribution of iBGP routes is disabled
Graceful restart is globally disabled
Global graceful-restart restart time is 120 seconds
Global graceful-restart stale paths time is 360 seconds
Graceful-restart path selection defer time is 360 seconds
This platform supports only the receiver role of graceful restart
Route Distinguisher: 100:11
Copyright © 2013, Juniper Networks, Inc.
203
JunosE 14.3.x BGP and MPLS Configuration Guide
204
Import route map: test2-import-map
Export route map: test1-export-map (cannot filter routes)
Global import route map: test3-global-import-map
103 routes imported from global table (max 5000 routes allowed)
Global export route map: test4-global-export-map
Local-RIB version 7. FIB version 7.
Messages Messages Prefixes
Neighbor AS State Up/down time Sent Received Received
11.11.11.11 400 Established 00:36:19 78 81 2
12.12.12.12 400 Established 00:36:21 78 78 1
103.103.103.3 300 Established 00:36:34 85 80 2
To display the status of next hop reachability checking by specifying vpnv4: host1# show ip bgp vpnv4 all summary
Local router ID 10.13.5.19, local AS 100
Administrative state is Start
BGP Operational state is Up
...
Default IPv4-unicast is enabled
Redistribution of iBGP routes is disabled
Check reachability of next-hops for VPN routes is enabled
...
To display the status of fields related to enabling local AS numbers to be received in routes: host1# show ip bgp summary fields remote-as state rib-version send-queue-length more-in-queue
Send More
Neighbor AS State RIB Ver Q InQ
2.2.2.2 100 Established 2 0 no
Meaning
lists the show bgp ipv6 summary command output fields.
Table 47: show bgp ipv6 summary Output Fields
Field Name Field Description
Local router ID local AS
Administrative state
BGP Operational state
Router ID of the local router
Local autonomous system number
BGP administrative state, start or stop
Operational state, up, down, or overload
Shutdown in overload state Status, enabled or disabled
Default local preference
IGP synchronization
Default originate
Auto-summary
Default value for local preference
Synchronization status, enabled or disabled
Whether network 0.0.0.0 is redistributed into BGP (enabled) or not
(disabled)
Status of auto summarization of routes redistributed into BGP
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 47: show bgp ipv6 summary Output Fields (continued)
Field Name Field Description
Always compare MED
Compare MED within confederation
Advertise inactive routes
Advertise best external route to internal peer
Status, enabled or disabled
Status, enabled or disabled
Status, enabled or disabled
Status, enabled or disabled
Enforce first AS
Missing MED as worst
Route flap dampening
Maximum number of equal-cost EBGP paths
Maximum number of equal-cost IBGP paths
Status, enabled or disabled
Status, enabled or disabled
Status, enabled or disabled
Number of paths
Number of paths
Log neighbor changes
Fast External Fallover
No maximum received
AS-path length
BGP administrative distances
Status, enabled or disabled
Status, enabled or disabled
Indicates whether limit is set for AS-path length and, if set, the limit
Distances for external, internal, and local BGP routes
Router is a route reflector Indicates whether the router has been configured as a route reflector
Client-to-client reflection Whether client-to-client reflection is configured (enabled) or not
(disabled)
Cluster ID
Route-target filter
Identifying number for cluster ID
Status, enabled or disabled
Default IPv4-unicast
Redistribution of iBGP routes
Status, enabled or disabled
Status, enabled or disabled
Check reachability of next-hops for VPN routes
Status, enabled or disabled
Copyright © 2013, Juniper Networks, Inc.
205
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 47: show bgp ipv6 summary Output Fields (continued)
Field Name Field Description
Graceful restart
Global graceful-restart restart time
Global graceful-restart stale paths time
Graceful-restart path selection defer time
Status, enabled or disabled
Time in seconds
Time in seconds
Time in seconds
Route Distinguisher
Confederation ID
Confederation peers
Import route map
Export route map
Global import route map routes imported from global table
Global export route map
Local-RIB version
RD assigned to the VRF
Confederation ID
Confederation peers
Route map associated with the VRF that filters and modifies routes imported to the VRF from the global BGP VPN RIB. The map applies to both IPv4 and IPv6 routes, unless the field name is preceded by
IPv4 (applies the map to only IPv4 routes) or IPv6 (applies the map to only IPv6 routes).
Route map associated with the VRF that modifies and filters routes exported by the VRF to the global BGP VPN RIB. The map applies to both IPv4 and IPv6 routes, unless the field name is preceded by
IPv4 (applies the map to only IPv4 routes) or IPv6 (applies the map to only IPv6 routes). The can filter routes text appears only if the filter keyword was issued for export map.
Route map associated with the VRF that modifies routes imported to the VRF from the global BGP non-VPN RIB. The map applies to both IPv4 and IPv6 routes, unless the field name is preceded by
IPv4 (applies the map to only IPv4 routes) or IPv6 (applies the map to only IPv6 routes).
Number of routes imported from the global BGP non-VPN RIB; also lists the maximum number of routes that can be imported
Route map associated with the VRF that modifies routes exported by the VRF to the global BGP non-VPN RIB. The map applies to both IPv4 and IPv6 routes, unless the field name is preceded by
IPv4 (applies the map to only IPv4 routes) or IPv6 (applies the map to only IPv6 routes).
Number that is increased by one each time a route in that RIB is added, removed or modified.
206 Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Monitoring BGP
Table 47: show bgp ipv6 summary Output Fields (continued)
Field Name Field Description
FIB version
Neighbor
AS
Ver
Number that is increased by one each time BGP updates the routes in the IP routing table based on changes in the local RIB. The FIB version matches the local-RIB version when BGP has finished updating the routes in the IP route table. The FIB version is less than the local-RIB version when BGP is still in the process of updating the IP routing table.
BGP neighbors
AS number of the peer
Negotiated BGP version number
State
Up/down time
Messages sent
Messages received
Prefixes received
Rib Ver
Send Q
More InQ
State of the connection
Time the connection has been up or down
Number of messages sent to peer
Number of messages received from peer
Number of prefixes received from peer
Last RIB version queued to be sent to peer
Number of messages queued to be sent to peer
Status indicating whether any messages are waiting to be sent to peer
Related
Documentation
•
show bgp ipv6 summary
•
show ip bgp summary
Monitoring the Routes Permitted by IP Community Lists
Purpose Display community list information.
The display varies if you issue the ip bgp community new-format command.
Action To display community list information without issuing the ip bgp community new-format command: host1# show ip community-list
Community List 1:
permit 81200109
permit 81200110
permit 81200108
Copyright © 2013, Juniper Networks, Inc.
207
JunosE 14.3.x BGP and MPLS Configuration Guide
Community List 2:
deny 81200109
permit 81200110
permit 81200108
Community List 4:
permit local-as
Community List 5:
permit no-advertise
Community List 6:
permit no-export
Community List 7:
permit internet
To display the community list information by issuing the ip bgp community new-format command: host1# show ip community-list
Community List 1:
permit 1239:1005
permit 1239:1006
permit 1239:1004
Community List 2:
deny 1239:1005
permit 1239:1006
permit 1239:1004
Community List 4:
permit local-as
Community List 5:
permit no-advertise
Community List 6:
permit no-export
Community List 7:
permit internet
Meaning
lists the show ip community-list command output fields.
Table 48: show ip community-list Output Fields
Field Name Field Description
Community List 1 permit, deny
Name of the community list
Condition statement for routes matching the condition
Related
Documentation
•
show ip community-list
Disabling Display of BGP Logs
To disable the display of information about BGP logs that was previously enabled with the debug ip bgp command.
• Issue the undebug ip bgp command: host1#undebug ip bgp
208 Copyright © 2013, Juniper Networks, Inc.
Related
Documentation
•
Enabling Display of BGP Logs on page 160
•
debug ip bgp
•
undebug ip bgp
Chapter 2: Monitoring BGP
Copyright © 2013, Juniper Networks, Inc.
209
JunosE 14.3.x BGP and MPLS Configuration Guide
210 Copyright © 2013, Juniper Networks, Inc.
PART 2
Multiprotocol Layer Switching
•
•
•
•
Configuring BGP-MPLS Applications on page 389
•
Monitoring BGP/MPLS VPNs on page 505
Copyright © 2013, Juniper Networks, Inc.
211
JunosE 14.3.x BGP and MPLS Configuration Guide
212 Copyright © 2013, Juniper Networks, Inc.
CHAPTER 3
MPLS Overview
This chapter describes Multiprotocol Label Switching (MPLS) and contains the following sections:
•
•
Terminology for MPLS Topics on page 214
•
MPLS Terms and Acronyms on page 216
•
•
MPLS Platform Considerations on page 219
•
•
MPLS Label Switching and Packet Forwarding Overview on page 222
•
TTL Processing in the Platform Label Space Overview on page 226
•
MPLS Label Distribution Methodology on page 231
•
IP Data Packet Mapping onto MPLS LSPs Overview on page 233
•
Statistics for IP Packets Moving On or Off MPLS LSPs on page 235
•
MPLS Forwarding and Next-Hop Tables Overview on page 237
•
MPLS Packet Spoof Checking Overview on page 238
•
IP and IPv6 Tunnel Routing Tables and MPLS Tunnels Overview on page 238
•
Explicit Routing for MPLS Overview on page 239
•
MPLS Interfaces and Interface Stacking Overview on page 240
•
MPLS Label Distribution Protocols Overview on page 242
•
ECMP Labels for MPLS Overview on page 246
•
MPLS Connectivity Verification and Troubleshooting Methods on page 249
•
Point-to-Multipoint LSPs Connectivity Verification at Egress Nodes Overview on page 250
•
Ping Extensions for Point-to-Multipoint LSPs Connectivity Verification at Egress
•
•
LDP Discovery Mechanisms on page 255
•
MPLS Traffic Engineering Overview on page 256
Copyright © 2013, Juniper Networks, Inc.
213
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Tracking Resources for MPLS Traffic Engineering Overview on page 258
•
Topology-Driven LSPs Overview on page 259
•
LDP Graceful Restart Overview on page 260
•
LDP-IGP Synchronization Overview on page 262
•
Use of RSVP-TE Hello Messages to Determine Peer Reachability on page 264
•
RSVP-TE Graceful Restart Overview on page 267
•
RSVP-TE Hellos Based on Node IDs Overview on page 269
•
BFD Protocol and RSVP-TE Overview on page 270
•
Tunneling Model for Differentiated Services Overview on page 271
•
EXP Bits for Differentiated Services Overview on page 272
•
Point-to-Multipoint LSPs Overview on page 275
MPLS Overview
In conventional IP routing, as a packet traverses from one router to the next through a network, each router analyzes the packet’s header and performs a network layer routing table lookup to choose the next hop for the packet. In conventional IP forwarding, the router looks for the address in its forwarding table with the longest match (best match) for the packet’s destination address. All packets forwarded to this longest match are considered to be in the same forwarding equivalence class (FEC).
MPLS is a hybrid protocol that integrates network layer routing with label switching to provide a layer 3 network with traffic management capability. MPLS provides traffic-engineering capabilities that make effective use of network resources while maintaining high bandwidth and stability. MPLS enables service providers to provide their customers with the best service available given the provider’s resources, with or without traffic engineering. MPLS is the foundation for layer 3 and layer 2 VPNs.
The two basic components of MPLS are label distribution and data mapping.
• Label distribution is the set of actions MPLS performs to establish and maintain a label-switched path (LSP), also known as an MPLS tunnel.
•
Data mapping is the process of getting data packets onto an established LSP.
Related
Documentation
•
MPLS Terms and Acronyms on page 216
•
Terminology for MPLS Topics on page 214
Terminology for MPLS Topics
Certain terms used with MPLS, such as the names of messages, are often expressed in the RFCs and other sources either with initial uppercase letters or all uppercase letters.
For improved readability, those terms are represented in lowercase in this chapter.
lists the terms and some of their variant spellings.
214 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview keepalive label mapping label release label request label request abort label withdrawal message ack message ID srfresh path patherr pathtear resv resvconf resverr resvtear targeted hello
Table 49: Conventions for MPLS Terms
In This Chapter In RFCs and Other Sources ack bundle hello initialization
Ack
Bundle
Hello
Initialization
ACK
–
HELLO
INITIALIZATION
Keepalive
Label Mapping
Label Release
Label Request
Label Request Abort
Label Withdrawal message_Ack message_ID
Srefresh
Path
PathErr
PathTear
Resv
ResvConf
ResvErr
ResvTear
Targeted Hello
KEEPALIVE
LABEL_MAPPING
LABEL_RELEASE
LABEL_REQUEST
LABEL_REQUEST_ABORT
LABEL_WITHDRAWAL
MESSAGE_ACK
MESSAGE_ID
–
PATH
PATHERR
PATHTEAR
RESV
RESVCONF
RESVERR
RESVTEAR
TARGETED_HELLO
Related
Documentation
•
MPLS Terms and Acronyms on page 216
•
Copyright © 2013, Juniper Networks, Inc.
215
JunosE 14.3.x BGP and MPLS Configuration Guide
MPLS Terms and Acronyms
defines terms and acronyms that are used in this discussion of
MPLS.
Table 50: MPLS Terms and Acronyms
Term Definition
Admission control
BGP
Branch node
Accounting mechanism that tracks resource information. Prevents requests from being accepted if sufficient resources are not available.
Border Gateway Protocol, which provides loop-free interdomain routing between autonomous systems (ASs) and can act as a label distribution protocol for MPLS.
An LSR in a point-to-multipoint LSP that is not an ingress node or an egress node. A branch node can be connected to other branch nodes, an ingress node, or an egress node.
Constraint-based routing A mechanism to establish paths based on certain criteria (explicit route, QoS parameters). The standard routing protocols can be enhanced to carry additional information to be used when running the route calculation.
E-LSP
Explicit routing
EXP-inferred-PSC LSP. The EXP field of the MPLS Shim Header is used to determine the per-hop behavior applied to the packet.
A subset of constraint-based routing where the constraint is an explicit route
FEC
Label Distribution
Protocol
Leaf
Forwarding equivalence class—Group of IP packets forwarded over the same path with the same path attributes applied
•
•
A particular label distribution protocol used for label distribution among the routers in an MPLS domain; represented by the acronym LDP
In lowercase—label distribution protocol—a generic term for any of several protocols that distribute labels among the routers in an
MPLS domain, including BGP, LDP, and RSVP-TE. This usage is not represented in this text by the acronym, LDP.
Egress LSRs in a point-to-multipoint LSP. It is also referred as a leaf node.
LDP
LER
Label Distribution Protocol—A particular protocol used for label distribution among the routers in an MPLS domain
This text does not use LDP to refer to the generic class of label distribution protocols.
Label edge router—A label-switching router serving as an ingress or egress nodes
216 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
Table 50: MPLS Terms and Acronyms (continued)
Term Definition
LSP
LSP priority level
L-LSP
LSR
Label-switched path—The path traversed by a packet that is routed by MPLS. Some LSPs act as tunnels.
A priority that indicates the importance of one LSP relative to another
LSP. LSPs having higher priorities can preempt LSPs having lower priorities. Priorities range from 0 through 7 in order of decreasing priority.
Label-only-inferred-PSC LSP. The label value, and possibly the
EXP-bits, are used to determine the per-hop behavior applied to the packet.
Label-switching router—An MPLS node that can forward layer 3 packets based on their labels
MPLS
MPLS edge node
MPLS egress node
MPLS ingress node
MPLS label
Multiprotocol Label Switching—Set of techniques enabling forwarding of traffic using layer 2 and layer 3 information
MPLS node that connects an MPLS domain with a node outside the domain that either does not run MPLS or is in a different domain
MPLS edge node in the role of handling traffic as it leaves an MPLS domain
MPLS edge node in the role of handling traffic as it enters an MPLS domain
Label carried in a packet header that represents a packet’s forwarding equivalence class
MPLS node
Point-to-multipoint tunnel
A router running MPLS. An MPLS node is aware of MPLS control protocols, operates one or more L3 routing protocols, and is capable of forwarding packets based on labels. Optionally, an MPLS node can be capable of forwarding native L3 packets.
The series of LSRs and links that form the path from an ingress LSR to all of its egress LSRs. Each tunnel is uniquely identified by a session object.
Point-to-multipoint LSP An RSVP-TE LSP with a single ingress LSR and one or more egress
LSRs. Incoming data is replicated at the branch nodes.
Provider edge router
Provider core router
PE—An LER at the edge of a service provider core that provides ingress to or egress from a VPN
P—An LSR within a service provider core that carries traffic for a VPN
RSVP Resource Reservation Protocol; E Series routers do not support RSVP
Copyright © 2013, Juniper Networks, Inc.
217
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 50: MPLS Terms and Acronyms (continued)
Term Definition
RSVP-TE
Sub-LSP
Traffic engineering
Tunnel
Resource Reservation Protocol enhanced to support MPLS traffic engineering; E Series routers support RSVP-TE
The portion of the LSP from one LSR to another LSR in a point-to-multipoint tunnel.
The ability to control the path taken through a network or portion of a network based on a set of traffic parameters (bandwidth, QoS parameters, and so on). Traffic engineering (TE) enables performance optimization of operational networks and their resources.
LSP that is used by an IGP to reach a destination, or an LSP that uses traffic engineering
Related
Documentation
•
•
Terminology for MPLS Topics on page 214
MPLS Features
The following major features are currently supported by MPLS:
•
BFD fast failure detection for RSVP-TE adjacencies
•
Differentiated services
• Interface support
• ATM AAL5 (RSVP-TE only)
•
ATM1483 (point-to-point AAL5SNAP only)
•
Ethernet/VLAN
• GRE
• Multilink PPP
•
POS (PPP over HDLC)
•
PPP
• SLEP (Cisco HDLC)
• Label stacking
• Virtual Private Networks (VR-based and BGP-based)
•
Layer 2 Services over MPLS
•
LER functionality
•
LSR functionality
218 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
•
Spoof checking
• LDP graceful restart
• ECMP
•
Topology-driven LSPs (LDP) including support of LDP over RSVP tunnels
•
Traffic engineering (RSVP-TE)
• Constraint-based explicit routing
• Statically configured explicit routing
•
Hop-by-hop routing
•
Admission control and bandwidth enforcement
• Tunnels used by IGP as next hops in SPF calculation
• Tunnel ingress controlled failure recovery
•
Facility back-up-style fast-route
•
Traffic support
•
Layer 2 frames: ATM, Ethernet, Frame Relay, HDLC, PPP, VLAN
• Layer 3 datagrams: IPv4, IPv6
• Point-to-multipoint LSP support
• Data replication at branch nodes
•
E Series routers as egress LSRs
Related
Documentation
•
•
Terminology for MPLS Topics on page 214
•
MPLS Terms and Acronyms on page 216
MPLS Platform Considerations
For information about modules that support MPLS on the ERX7xx models, ERX14xx models, and the ERX310 Broadband Services Router:
• See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
• See ERX Module Guide, Appendix A, Module Protocol Support for information about the modules that support BGP.
For information about modules that support MPLS on E120 and E320 Broadband Services
Routers:
•
See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module specifications.
Copyright © 2013, Juniper Networks, Inc.
219
JunosE 14.3.x BGP and MPLS Configuration Guide
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information about the modules that support MPLS.
Related
Documentation
•
Interface Types and Specifiers
MPLS References
For more information about the MPLS protocol, consult the following resources:
• JunosE Release Notes, Appendix A, System Maximums—Refer to the Release Notes corresponding to your software release for information about maximum values.
•
Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)—draft-ietf-mpls-in-ip-or-gre-03.txt (September 2003 expiration)
• LDP IGP Synchronization—draft-jork-ldp-igp-sync-01.txt (August 2005 expiration)
•
Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching
(MPLS) - Extensions to LSP Ping—draft-ietf-mpls-p2mp-lsp-ping-08.txt (February
2010 expiration)
• RFC 2104—HMAC: Keyed-Hashing for Message Authentication (February 1997)5.2
•
RFC 2205—Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification
(September 1997)
• RFC 2209—Resource ReSerVation Protocol (RSVP) -- Version 1, Message Processing
Rules (September 1997)
•
RFC 2210—The Use of RSVP with IETF Integrated Services (September 1997)
•
RFC 2211—Specification of the Controlled-Load Network Element Service (September
1997)
• RFC 2474—Definition of the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers (December 1998)
•
RFC 2475—An Architecture for Differentiated Services (December 1998)
• RFC 2597—Assured Forwarding PHB Group (June 1999)
• RFC 2685—Virtual Private Networks Identifier (September 1999)
•
RFC 2702—Requirements for Traffic Engineering over MPLS (September 1999)
•
RFC 2747—RSVP Cryptographic Authentication (January 2000)
• RFC 2836—Per Hop Behavior Identification Codes (May 2000)
• RFC 4760—Multiprotocol Extensions for BGP-4 (January 2007)
•
RFC 2961—RSVP Refresh Overhead Reduction Extensions (April 2001)
•
RFC 3031—Multiprotocol Label Switching Architecture (January 2001)
• RFC 3032—MPLS Label Stack Encoding (January 2001)
• RFC 3035—MPLS using LDP and ATM VC Switching (January 2001)
220 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
•
RFC 3036—LDP Specification (January 2001)
• RFC 3037—LDP Applicability (January 2001)
• RFC 3097—RSVP Cryptographic Authentication -- Updated Message Type Value (April
2001)
•
RFC 3107—Carrying Label Information in BGP-4 (May 2001)
• RFC 3140—Per Hop Behavior Identification Codes (June 2001)
• RFC 3209—RSVP-TE: Extensions to RSVP for LSP Tunnels (December 2001)
•
RFC 3210—Applicability Statement for Extensions to RSVP for LSP-Tunnels (December
2001)
• RFC 3246—An Expedited Forwarding PHB (Per-Hop Behavior) (March 2002)
• RFC 3270—Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
(May 2002)
•
RFC 3443—Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS)
Networks (January 2003)
• RFC 3471—Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional
Description (January 2003)
•
RFC 3473—Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions (January 2003)
• RFC 3478—Graceful Restart Mechanism for Label Distribution Protocol (February
2003)
•
RFC 3479—Fault Tolerance for the Label Distribution Protocol (LDP) (February 2003)
• RFC 3564—Requirements for support of Differentiated Services-aware MPLS Traffic
Engineering (July 2003)
•
RFC 4090—Fast Reroute Extensions to RSVP-TE for LSP Tunnels (May 2005)
•
RFC 4364—BGP/MPLS IP Virtual Private Networks (VPNs) (February 2006)
• RFC 4379—Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
(February 2006)
•
RFC 4661—Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS
Label Switched Paths (LSPs) (April 2006)
• RFC 4875—Extensions to Resource Reservation Protocol - Traffic Engineering
(RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) (May 2007)
NOTE: IETF drafts are valid for only 6 months from the date of issuance.
They must be considered as works in progress. Please refer to the IETF
Web site at http://www.ietf.org for the latest drafts.
Related
Documentation
•
Copyright © 2013, Juniper Networks, Inc.
221
JunosE 14.3.x BGP and MPLS Configuration Guide
MPLS Label Switching and Packet Forwarding Overview
MPLS is not a routing protocol; it works with layer 3 routing protocols (BGP, IS-IS, OSPF) to integrate network layer routing with label switching. An MPLS FEC consists of a set of packets that are all forwarded in the same manner by a given label-switching router
(LSR). For example, all packets received on a particular interface might be assigned to a FEC. MPLS assigns each packet to a FEC only at the LSR that serves as the ingress node to the MPLS domain. A label distribution protocol binds a label to the FEC. Each
LSR uses the label distribution protocol to signal its forwarding peers and distribute its labels to establish an LSP. The label distribution protocol enables negotiation with the downstream LSRs to determine what labels are used on the LSP and how they are employed.
Labels represent the FEC along the LSP from the ingress node to the egress node. The label is prepended to the packet when the packet is forwarded to the next hop. Each label is valid only between a pair of LSRs. A downstream LSR reached by a packet uses the label as an index into a table that contains both the next hop and a different label to prepend to the packet before forwarding. This table is usually referred to as a label information base (LIB).
The LSR that serves as the egress MPLS node uses the label as an index into a table that has the information necessary to forward the packet from the MPLS domain. The forwarding actions at the egress LSR can be any of the following:
•
Forward the packet based on the inner header exposed after popping the label. This can be accomplished either by doing a routing table lookup or forwarding based on the exposed inner MPLS label.
•
Forward the packet to a particular neighbor as directed by the table entry, for example in a Martini layer 2 transport case.
NOTE: Forwarding of traffic for labeled IPv6 unicast routes with native IPv6 next-hop addresses does not work.
shows a simple MPLS domain, consisting of multiple LSRs. The
LSRs serving as ingress and egress nodes are also referred to as label edge routers (LERs).
The ingress router is sometimes referred to as the tunnel head end, or the head-end router.
The egress router is sometimes referred to as the tunnel tail end, or the tail-end router.
LSPs are unidirectional, carrying traffic only in the downstream direction from the ingress node to the egress node.
222 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
Figure 47: Simple MPLS Domain
MPLS LSRs
Each LSR, also known as an MPLS node, must have the following:
•
At least one layer 3 routing protocol
•
A label distribution protocol
• The ability to forward packets based on their labels
The router can use BGP, IS-IS, or OSPF as its layer 3 routing protocol, and BGP, LDP, or
RSVP-TE as its label distribution protocol.
MPLS Label Switching: Push, Look Up, and Pop
MPLS can label packets by using the existing layer 2 header or an encapsulation header that carries the MPLS label. During LSP negotiation, the LSRs in an MPLS domain agree on a labeling method. Labels have only local meaning; that is, meaning for two LSR peers.
Each pair of LSRs—consisting of a label originator and a label acceptor—must use a label distribution protocol to agree on the label-to-FEC binding.
Because of the local label assignment, packet labels typically change at each segment in the LSP path, as shown in
. The ingress node, LSR 1, receives an unlabeled data packet and prepends label d to the packet. LSR 2 receives the packet, removes label d and uses it as an index in its forwarding table to find the next label. LSR
2 prepends label e to the packet. LSR 3 does the same thing, removing label e and prepending label u. Finally, the egress node, LSR 4, removes label u and determines where to forward the packet outside the MPLS domain.
Figure 48: Label Switching
Copyright © 2013, Juniper Networks, Inc.
223
JunosE 14.3.x BGP and MPLS Configuration Guide
Any packet can carry multiple labels. The labels are stacked in a last-in-first-out order.
Each LSR forwards packets based on the outermost (top) label in the stack. An LSR
pushes a label onto the stack when it prepends the label to a packet header. It pops the label when it pulls the label off the stack and compares it with the forwarding table. On determining the label for the next segment of the LSP, the LSR pushes the new label on the stack. A label swap consists of a pop, lookup, and push.
When the egress router, such as LSR 4 in
, receives a packet, it may perform two lookups: it looks up the label and determines that the label must be popped, then it does another lookup based on the exposed header to determine where to forward the packet. This behavior is known as ultimate hop popping, and was the only possible action for the JunosE implementation before Release 7.3.0.
Beginning with JunosE Release 7.3.0, an alternative behavior, known as penultimate hop
popping (PHP), is the default when RSVP-TE is the signaling protocol. Beginning with
JunosE Release 8.1.0, PHP is also the default when LDP is the signaling protocol. PHP reduces the number of lookups performed by the LER. In PHP, the LER requests its upstream neighbor (the penultimate hop) to pop the outermost label and send just the packet to the LER. The LER then performs only the lookup for the packet. The request to perform PHP is signaled by the LER when it includes an implicit null label in the label mapping message that it sends to its upstream neighbor. The implicit null label never appears in the encapsulation.
You can still achieve ultimate hop popping by configuring the egress router to advertise an explicit null label to its upstream neighbor. This advertisement, performed by LDP or
RSVP-TE, ensures that all MPLS packets traversing the LSP to the egress router include a label. Alternatively, you can configure the egress router to advertise real (non-null) labels, and achieve the same result.
Regardless of whether the LSR advertises the implicit null label to achieve PHP on an upstream neighbor, if the LSR receives a PHP request from a downstream neighbor, then the LSR does perform the PHP for its neighbor.
MPLS Label Stacking
shows an LSP that uses label stacking. The ingress node, LSR 1, receives an unlabeled data packet and prepends label d to the packet. LSR 2 receives the packet, removes label d and uses it as an index in its forwarding table to find the next label, prepending label e to the packet. LSR 3 removes label e and prepends label s
(negotiated with LSR 5) to the packet. LSR 3 pushes label x on top of label s. LSR 4 pops the top (outermost) label, x, and pushes label r on top of label s. LSR 5 pops label r, determines that it must pop label s, and pushes label z on the empty stack. Finally, the egress node, LSR 6, removes label z and determines where to forward the packet outside the MPLS domain.
224 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
Figure 49: Label Stacking
The configuration shown in
is an example of an LSP within an LSP
(a tunnel within a tunnel). The first LSP consists of LSR 1, LSR 2, LSR 3, LSR 5, and LSR
6. The second LSP consists of LSR 3, LSR 4, and LSR 5. The two LSPs have different ingress and egress points. LSR 1 and LSR 6 are LERs. Less obviously, LSR 3 and LSR 5 are also LERs, but for the internal LSP.
NOTE: Label stacking is typically employed for LSR peers that are not directly connected.
is a simplified example to illustrate the concept of label stacking.
MPLS Labels and Label Spaces
MPLS uses labels from either the platform label space or the interface label space. ATM
AAL5 interfaces always use labels from only the interface label space. For every interface using the interface label space, you must define the range available to the router for labels in the interface label space. All other interface types always use labels from only the platform label space. You cannot configure the range for the platform label space.
The platform label space is a large, single, unconfigurable pool of labels that can be shared by the platform—all MPLS interfaces on a given virtual router. By contrast, interface labels enable you to effectively create multiple smaller pools of labels, each used only by a particular interface. When you configure interface labels, you restrict only a given interface to a particular range of labels. Other interfaces in that VR can still use labels from that space unless you restrict them in turn to a different range of interface labels.
In the interface label space, MPLS selects labels from interface resources, a VPI/VCI combination. You configure a VPI range and a VCI range available to the labels. When an upstream LSR requests a label, the downstream LSR allocates a VPI/VCI combination for use as a label between these two peers. Allocating labels on a per interface basis is necessary because the VPI/VCI ranges are limited. This enables you to use the same label on different interfaces without conflict.
When you use the platform label space, the MPLS ingress node places labels in shim
headers between the link-layer header and the payload. The shim header includes the
following bits ( Figure 50 on page 226
):
Copyright © 2013, Juniper Networks, Inc.
225
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Label bits—Twenty bits
• EXP bits—Three bits for class of service information; these bits are variously called the experimental bits, class of service (CoS) bits, or type of service (ToS) bits. The EXP bits are mapped from the IP packet at the ingress node and are mapped back into the
IP packet at the egress node.
• S bit—One bit to indicate whether the label is on the bottom of the label stack.
• TTL bits—Eight bits for a time-to-live indicator. The TTL bits are mapped from the IP packet at the ingress node. The TTL bits in the shim header are decremented at each hop. The bits are mapped back into the IP packet at the egress node. See
Processing in the Platform Label Space Overview” on page 226
for more information.
Figure 50: Shim Header
If you configure an MPLS interface to use the interface label space, the VPI/VCI combinations are used as labels, so there is no need to place them within a shim header.
As the data travels along the LSP, the LSRs examine only the VPI/VCI combination. The shim header is used only to carry the TTL bits to the egress, and is not visible to intermediate LSRs. The ingress node learns the total hop count from signaling and then uses that count to decrement the TTL to the correct final value. The TTL is then carried in the shim header to the egress node without modification, arriving with the correct count.
Related
Documentation
•
MPLS Label Distribution Methodology on page 231
•
IP Data Packet Mapping onto MPLS LSPs Overview on page 233
•
MPLS Forwarding and Next-Hop Tables Overview on page 237
•
MPLS Interfaces and Interface Stacking Overview on page 240
•
TTL Processing in the Platform Label Space Overview on page 226
•
Topology-Driven LSPs Overview on page 259
TTL Processing in the Platform Label Space Overview
JunosE MPLS TTL processing is compliant with RFC 3443. The details of TTL processing vary with the tunnel model that is configured for TTL processing, pipe or uniform.
To keep backward compatibility with earlier JunosE releases, you do not use the mpls tunnel-model command to configure the tunnel model for TTL processing, That command is used instead to configure the tunnel model for EXP bits processing. The default tunnel model varies between TTL and EXP processing; for EXP processing, the default tunnel model is pipe, while for TTL processing the default tunnel model is uniform.
You can issue the no mpls ip propagate-ttl command to change the TTL processing tunnel model from the default uniform model to the pipe model. Issue the no mpls ip
226 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview propagate-ttl local command to set the tunnel model to pipe for locally originated packets. Issue the no mpls ip propagate-ttl forwarded command to set the tunnel model to pipe for forwarded packets.
TTL Processing on Incoming MPLS Packets
The flow chart on
illustrates TTL processing on incoming MPLS packets. On a transit LSR or an egress LER, MPLS pops one or more labels and can push one or more labels. The incoming TTL of the packet is determined by the configured TTL processing tunnel model.
When all of the following conditions are met, the incoming TTL is set to the TTL value found in the immediate inner header:
• The outer label is popped as opposed to being swapped
• The TTL processing model is configured to pipe
•
The inner header is MPLS or IP
If any of those conditions is not met, then the incoming TTL is set to the TTL value found in the outermost label. In all cases, the TTL values of any further inner labels are ignored.
When an IP packet is exposed after MPLS pops all the labels that should be popped,
MPLS passes the packet to IP for further processing, including TTL checking. When the uniform tunnel model for TTL processing is in effect, MPLS sets the TTL value of the IP packet to the incoming TTL value that was just set. In other words, the TTL value is copied from the outermost label to the IP packet. When the pipe model for TTL processing is in effect, the TTL value in the IP header is left unchanged.
If an IP packet is not exposed by the label popping, then MPLS performs the TTL validation.
If the incoming TTL is less than 2, the packet is dropped. If innermost packet is IP, an
ICMP packet is built and sent. If the TTL does not expire and the packet needs to be sent out, the outgoing TTL is determined by the rules for outgoing MPLS packets.
Copyright © 2013, Juniper Networks, Inc.
227
JunosE 14.3.x BGP and MPLS Configuration Guide
Figure 51: TTL Processing on Incoming MPLS Packets
TTL Processing on Outgoing MPLS Packets
The flow chart on
illustrates TTL processing on outgoing MPLS packets.
Rules for Processing on an LSR
On an LSR—where an MPLS packet is label-switched after processing on the line module—the TTL value in the swapped-to label is decremented by 1 from the incoming
TTL value when the swapped-to label is not implicit-null. When the swapped-to label is implicit-null (for example, in a PHP configuration), the inner or exposed header's TTL is either left unchanged (when the forwarded option for the mpls ip propagate-ttl
228 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview command has been configured) or is decremented by 1 from the incoming TTL value. If
MPLS needs to push more labels, it sets the TTL for each label according to the following
LER rules, because for those labels the router effectively is an ingress LER.
Rules for Processing on an LER
On an LER, when the packet is a locally originated IP packet, MPLS copies the TTL of all pushed MPLS labels from the IP header when the local option for the mpls ip propagate-ttl command has been configured. When the no mpls ip propagate-ttl local command has been configured, MPLS sets the TTL to 255.
When the packet is a forwarded IP or MPLS packet, MPLS copies the TTL of all pushed labels from the inner IP or MPLS header when the forwarded option for the mpls ip propagate-ttl command has been configured. When the no mpls ip propagate-ttl forwarded command has been configured, MPLS sets the TTL for these pushed labels to 255.
When the packet is neither IP nor MPLS, such as a Martini packet, MPLS sets the TTL of all pushed labels to 255.
Copyright © 2013, Juniper Networks, Inc.
229
JunosE 14.3.x BGP and MPLS Configuration Guide
Figure 52: TTL Processing on Outgoing MPLS Packets
MPLS Rules for TTL Expiration
MPLS takes the following actions when the TTL in a MPLS label of a received MPLS packet expires:
1.
A TTL-expired ICMP packet is constructed.
2.
The destination address of ICMP packet is set to the source address of the IP packet that was encapsulated in the MPLS packet.
230 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
3.
The source address of ICMP packet is set to the router ID of the router on which the
TTL expired.
4.
The first 128 bytes of the MPLS packet including the IP payload encapsulated in the
MPLS packet are copied into the payload of the ICMP packet, followed by the entire label stack of the original packet.
The ICMP packet is label-switched to the end of the LSP. From that location, the packet is forwarded back to the source of the IP packet. This behavior enables IP trace-route to work even when the LSR in the middle of the LSP does not have an IP route to the source address of the IP packet.
Related
Documentation
•
MPLS Label Distribution Methodology on page 231
•
IP Data Packet Mapping onto MPLS LSPs Overview on page 233
•
MPLS Label Switching and Packet Forwarding Overview on page 222
•
MPLS Forwarding and Next-Hop Tables Overview on page 237
•
MPLS Interfaces and Interface Stacking Overview on page 240
•
Topology-Driven LSPs Overview on page 259
MPLS Label Distribution Methodology
The JunosE implementation of MPLS supports the following methods of label distribution:
• Downstream-on-demand, ordered control with RSVP-TE
• Downstream-unsolicited, independent control or ordered control with LDP; ordered control is the default. BGP accepts only downstream-unsolicited, ordered control
Downstream-on-demand means that MPLS devices do not signal a FEC-to-label binding until requested to do so by an upstream device. Upstream is the direction toward a packet’s source; the ingress node in an MPLS domain is the farthest possible upstream node. Downstream is the direction toward a packet’s destination; the egress node in an
MPLS domain is the farthest possible downstream node. The egress node is sometime referred to as the tunnel endpoint.
Downstream-on-demand conserves labels in that they are not bound until they are needed and the LSR receives label mappings (also known as label bindings) from a neighbor that is the next hop to a destination; it is used when RSVP is the signaling protocol.
Ordered control means that an LSR does not advertise a label for a FEC unless it is the egress LSR for the FEC or until it has received a label for the FEC from its downstream peer. In this manner the entire LSP is established before MPLS begins to map data onto the LSP, preventing inappropriate (early) data mapping from occurring on the first LSR in the path.
An LSR is an egress LSR for a FEC when the FEC is its directly attached interface or when
MPLS is not configured on the next-hop interface.
Copyright © 2013, Juniper Networks, Inc.
231
JunosE 14.3.x BGP and MPLS Configuration Guide
In
Figure 53 on page 232 , LSR A sends a label request to LSR C. Before LSR C responds, it
sends its own request to LSR D. LSR D in turn makes a request for a label to LSR F. When
LSR F returns an acceptable label to LSR D, that label is for use only between LSRs D and F. LSR D sends a label back to LSR C that this pair of LSRs will use. Finally, LSR C sends back to LSR A the label that they will use. This completes the establishment of the LSP.
Downstream-unsolicited means that MPLS devices do not wait for a request from an upstream device before signaling FEC-to-label bindings. As soon as the LSR learns a route, it sends a binding for that route to all peer LSRs, both upstream and downstream.
Downstream-unsolicited does not conserve labels, because an LSR receives label mappings from neighbors that might not be the next hop for the destination; it is used by BGP or LDP when adjacent peers are configured to use the platform label space.
Figure 53: LSP Creation, Downstream-on-Demand, Ordered Control
232
Independent control means that the LSR sending the label acts independently of its downstream peer. It does not wait for a label from the downstream LSR before it sends a label to its peers. When an LSR advertises a label to an upstream neighbor before it has received a label for the FEC from the next-hop neighbor, the LSP is terminated at the LSR. Traffic for the destination cannot be label-switched all the way to the egress
LSR. If no inner label is present, then the traffic is routed instead of switched.
In
Figure 54 on page 233 , LSR D learns a route to some prefix. LSR D immediately maps a
label for this destination and sends the label to its peers, LSR B, LSR C, LSR E, and LSR
F. In the topology-driven network, the LSPs are created automatically with each peer
LSR.
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
Figure 54: LSP Creation, Downstream-Unsolicited, Independent Control
1 1
1
1
Related
Documentation
•
TTL Processing in the Platform Label Space Overview on page 226
•
IP Data Packet Mapping onto MPLS LSPs Overview on page 233
•
MPLS Label Switching and Packet Forwarding Overview on page 222
•
MPLS Forwarding and Next-Hop Tables Overview on page 237
•
MPLS Interfaces and Interface Stacking Overview on page 240
•
Topology-Driven LSPs Overview on page 259
IP Data Packet Mapping onto MPLS LSPs Overview
IP packets are mapped onto LSPs by one of the following methods:
• RSVP-TE tunnels can be referenced directly by static routes that you configure. You can determine which routes (routes destined for which subnets) to direct through the
LSP and issue the appropriate ip route commands, as shown in the following example: host1(config-if)#ip route 10.15.21.16 tunnel mpls:1
You cannot create any static routes until the tunnel interface has been created.
However, the tunnel does not have to be active before you create the static routes.
• RSVP-TE tunnels are announced to IS-IS and OSPF; the IGP then uses the tunnels as next hop interfaces for its SPF calculations. For this method, you must issue the tunnel mpls autoroute announce command. When the LSP is established, the ingress LSR announces the LSP endpoint to the IGP. This is also referred to as registering the LSP.
The IGP then recalculates the shortest path for all routes destined for or beyond that endpoint. You can choose to register endpoints with both IS-IS and OSPF. The following is an example registration command: host1(config-if)#tunnel mpls autoroute announce isis
• For topology-driven LSPs, LDP can modify the IP routing table to use MPLS next hops in the routing table, replacing the regular IP next hops for the corresponding routes.
•
For labeled BGP routes, BGP adds routes with MPLS next hops to the appropriate VR or VRF routing table.
Copyright © 2013, Juniper Networks, Inc.
233
JunosE 14.3.x BGP and MPLS Configuration Guide
234
When IP packets arrive at the ingress LER, they are looked up in the relevant IP forwarding table and then are forwarded into an LSP. Every IP route eventually points to an IP interface. The IP interface contains IP attributes that affect how the IP packet is forwarded.
IPv4 routes point only to IPv4 interfaces and IPv6 routes point only to IPv6 interfaces.
Because IP routes cannot point directly to MPLS major interfaces, MPLS automatically creates up to four dynamic IP shared interfaces that are stacked on each MPLS major interface. When you issue the mpls command in Interface Configuration mode, the interfaces are created dynamically and provide the interfaces an IP route needs to point to. You can specify a profile (created with the profile command) to configure attributes for these interfaces with the mpls create-dynamic-interfaces command. You can use the same command to enable or disable the creation of specific interface types or all types.
Each dynamic interface is one of the following types:
•
By default, MPLS creates one dynamic IPv4 interface per MPLS major interface for non-VPN traffic. This interface is used by default for VPN traffic as well.
• By default, but only if IPv6 is enabled in the virtual router, MPLS creates one dynamic
IPv6 interface per MPLS major interface for non-VPN traffic. This interface is used by default for VPN traffic as well.
•
If you configure it to do so, MPLS creates one dynamic IPv4 interface per MPLS major interface for VPN traffic. If this interface is not created, then the VPN traffic uses the default IPv4 interface for non-VPN traffic.
Typically, you request the creation of separate IPv4 interfaces for VPN traffic only when you want the IPv4 interface for VPN traffic to have different attributes, such as a different IP policy, from the IPv4 interface for non-VPN traffic. When it is acceptable for the VPN traffic and the non-VPN traffic to receive the same IP treatment, then you do not need to create separate IPv4 interfaces for the VPN traffic.
•
If you configure it to do so, but only if IPv6 is enabled in the virtual router, MPLS creates one dynamic IPv6 interface per MPLS major interface for VPN traffic. If this interface is not created, then the VPN traffic uses the default IPv6 interface for non-VPN traffic.
Typically, you request the creation of separate IPv6 interfaces for VPN traffic only when you want the IPv6 interface for VPN traffic to have different attributes, such as a different IP policy, from the IPv6 interface for non-VPN traffic. When it is acceptable for the VPN traffic and the non-VPN traffic to receive the same IP treatment, then you do not need to create separate IPv6 interfaces for the VPN traffic.
IPv6 must be enabled in the parent virtual router so that IPv6 dynamic interfaces can be created over MPLS interfaces. Otherwise, IPv6 VPNs do not work correctly,
All VPN traffic sent onto or received from the same layer 2 interface uses the same IPv4
VPN or IPv6 VPN interface. Consequently, any policy attached to the interface applies to all that VPN traffic.
Related
Documentation
•
TTL Processing in the Platform Label Space Overview on page 226
•
MPLS Label Switching and Packet Forwarding Overview on page 222
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
•
MPLS Forwarding and Next-Hop Tables Overview on page 237
•
MPLS Interfaces and Interface Stacking Overview on page 240
•
Topology-Driven LSPs Overview on page 259
•
MPLS Packet Spoof Checking Overview on page 238
•
Statistics for IP Packets Moving On or Off MPLS LSPs on page 235
Statistics for IP Packets Moving On or Off MPLS LSPs
In the earlier architecture, the statistics for IP packets moving onto or off an LSP applied to the IP interface that was stacked on top of the LSP. Because IP interfaces are no longer stacked on LSPs in the current architecture, these statistics apply to one of the dynamic
IP interfaces that is established on the same major interface the LSP is stacked on.
However, even though the IP traffic leaving the LSP as MPLS packets is associated with a dynamic IP interface, it does not use the queue associated with that dynamic IP interface.
Instead, the IP traffic uses the queues at the layer 2 interface; the MPLS major interface on which the dynamic IP interface is created does not have its own queue. As a result, queue-related statistics do not increase with the IP traffic flow on the dynamic IP interfaces. This behavior can create some confusion when you examine the output from commands such as show egress-queue rate interface ip.
In the following sample output, the statistics of interest are those for the layer 2 interface, atm-vc ATM9/0.10. Traffic is present as indicated by the forwarded rate value for the layer 2 interface. If no IP traffic is present, the forwarded rate for the layer 2 interface has a value of 0.
host1:pe1# show egress-queue rates interface atm9/0.10
traffic forwarded aggregate minimum maximum
interface class rate drop rate rate rate
--------------------------- ----------- --------- --------- ------- --------atm-vc ATM9/0.10 best-effort 116032 0 4680000 149760000 ip ATM9/0.10 best-effort 0 0 4680000 149760000 ip ip19000001.mpls.ip best-effort 0 0 4680000 149760000 ipv6 ipv619000001.mpls.ipv6 best-effort 0 0 4680000 149760000
Queues reported: 4
Queues filtered (under threshold): 0
* Queues disabled (no rate period): 0
**Queues disabled (no resources): 0
Total queues: 4
You can use the show mpls interface brief command to display the MPLS major interfaces. You can then view the statistics for the major interface displayed by the show ip interface command, as show in the following display excerpt: host1:pe1# show ip interface null0 line protocol is up, ip is up
...
loopback0 line protocol is up, ip is up
...
ATM9/0.10 line protocol Atm1483 is up, ip is up
...
In Received Packets 78, Bytes 5991
Copyright © 2013, Juniper Networks, Inc.
235
JunosE 14.3.x BGP and MPLS Configuration Guide
236
Unicast Packets 29, Bytes 2469
Multicast Packets 49, Bytes 3522
In Policed Packets 0, Bytes 0
In Error Packets 0
In Invalid Source Address Packets 0
In Discarded Packets 0
Out Forwarded Packets 78, Bytes 5786
Unicast Packets 78, Bytes 5786
Multicast Routed Packets 0, Bytes 0
Out Scheduler Dropped Packets 0, Bytes 0
Out Policed Packets 0, Bytes 0
Out Discarded Packets 0
queue 0: traffic class best-effort, bound to ip ATM9/0.10
Queue length 0 bytes
Forwarded packets 1, bytes 52
Dropped committed packets 0, bytes 0
Dropped conformed packets 0, bytes 0
Dropped exceeded packets 0, bytes 0 ip19000001.mpls.ip line protocol MplsMajor is up, ip is up
...
The show mpls interface command displays the queue associated with the MPLS major interface, but indicates it is bound to the layer 2 interface.
host1:pe1# show mpls interface
MPLS major interface ATM9/0.10
ATM circuit type is 1483 LLC encapsulation
Administrative state is enabled
Operational state is up
Operational MTU is 9180
Received:
1 packet
136 bytes
0 errors
0 discards
0 failed label lookups
Sent:
1 packet
136 bytes
0 errors
0 discards
LDP information:
10.10.10.1/24
enabled with profile 'default'
133 hello recv, 136 hello sent, 0 hello rej
2 adj setup, 1 adj deleted,
Session to 10.10.10.2 is operational (passive)
Session statistics:
4 label alloc, 4 label learned,
4 accum label alloc, 4 accum label learned,
last restart time = 00:01:49
Rcvd: 0 notf, 8 msg, 4 mapping, 0 request
0 abort, 0 release, 0 withdraw, 1 addr
0 addr withdraw, 8 msgId
0 bad mapping, 0 bad request, 0 bad abort, 0 bad release
0 bad withdraw, 0 bad addr, 0 bad addr withdraw
0 unknown msg type err
last info err code = 0x00000000, 0 loop detected
Sent: 0 notf, 8 msg, 4 mapping, 0 request
0 abort, 0 release, 0 withdraw, 1 addr
0 addr withdraw, 8 msgId
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
Adjacency statistics:
30 hello recv, 29 hello sent, 0 bad hello recv
adj setup time = 00:02:19
last hello recv time = 00:00:00, last hello sent time = 00:00:00
queue 0: traffic class best-effort, bound to atm-vc ATM9/0.10
Queue length 0 bytes
Forwarded packets 1, bytes 148
Dropped committed packets 0, bytes 0
Dropped conformed packets 0, bytes 0
Dropped exceeded packets 0, bytes 0
Related
Documentation
•
MPLS Label Switching and Packet Forwarding Overview on page 222
•
MPLS Forwarding and Next-Hop Tables Overview on page 237
•
MPLS Interfaces and Interface Stacking Overview on page 240
•
Topology-Driven LSPs Overview on page 259
•
MPLS Packet Spoof Checking Overview on page 238
MPLS Forwarding and Next-Hop Tables Overview
An MPLS forwarding table determines how MPLS handles received MPLS packets. When an MPLS packet arrives on an MPLS major interface, MPLS looks up the outermost MPLS label of the received packet in the relevant MPLS forwarding table.
The entries in the MPLS forwarding table map labels to next hops. Each entry in the MPLS forwarding table points to an entry in the MPLS next-hop table. Each MPLS next hop points to either an interface or another MPLS next hop. The chain of MPLS next hops, which ends at an interface, informs MPLS which labels to push and where to send the
MPLS packet.
For RSVP-TE tunnels, minor interfaces are created in addition to the forwarding table and next-hop table entries. One minor interface is created of each in/out segment of a tunnel. the purpose of these minor interfaces is to attach QoS and policy to an LSP.
MPLS forwarding tables consist of the following:
•
One forwarding table for each MPLS virtual router. This table contains labels from the platform label space. When an MPLS packet arrives on an MPLS major interface that uses the platform label space, MPLS looks up the label in the MPLS forwarding table of the virtual router in which the major interface exists.
•
One forwarding table for each MPLS major interface that uses the interface label space.
This table contains labels from the interface label space of that major interface. When an MPLS packet arrives on an MPLS major interface that uses the interface label space,
MPLS looks up the label in the MPLS forwarding table for that particular major interface.
The signaling protocols add entries to the MPLS forwarding tables. You cannot manually create an MPLS forwarding entry. The signaling protocols set the following attributes for each entry placed in the forwarding table:
Copyright © 2013, Juniper Networks, Inc.
237
JunosE 14.3.x BGP and MPLS Configuration Guide
•
An MPLS in label that is matched against the outermost label of the received MPLS packet.
• The MPLS next hop, which specifies the actions to be performed on the MPLS packet.
MPLS next hops can be chained together to create complex actions.
•
A spoof check field that specifies the type of spoof checking is performed to determine whether the MPLS packet arrived from a legitimate source. See
Checking Overview” on page 238
for more information.
See
, for information about enabling statistics collection for MPLS forwarding table entries.
Related
Documentation
•
MPLS Label Distribution Methodology on page 231
•
MPLS Label Switching and Packet Forwarding Overview on page 222
•
MPLS Packet Spoof Checking Overview on page 238
•
IP and IPv6 Tunnel Routing Tables and MPLS Tunnels Overview on page 238
MPLS Packet Spoof Checking Overview
The MPLS forwarding table enables MPLS to determine whether an MPLS packet received from an upstream neighbor contains an MPLS label that was advertised to that neighbor.
If not, the packet is dropped. Each entry in the forwarding table has a spoof check field that specifies the type of checking that must be performed for the associated in label.
The signaling protocol (BGP, LDP, or RSVP) that populates the entry in the MPLS forwarding table sets the spoof check field.
MPLS supports the following types of spoof checking:
•
Router spoof checking—MPLS packets are accepted only if they arrive on an MPLS major interface that is in the same virtual router as the MPLS forwarding table.
• Interface spoof checking—MPLS packets are accepted only if they arrive on the particular MPLS major interface identified in the spoof check field.
You can use the show mpls forwarding command to view the spoof check field for an
MPLS forwarding table entry.
Related
Documentation
•
MPLS Forwarding and Next-Hop Tables Overview on page 237
IP and IPv6 Tunnel Routing Tables and MPLS Tunnels Overview
The IP and IPv6 tunnel routing tables contain routes that point only to tunnels, such as
MPLS tunnels. The tunnel routing table is not used for forwarding. Instead, protocols resolve MPLS next hops by looking up the routes in the table. For example, BGP uses the table to resolve indirect next hops for labeled routes.
BGP, LDP, and RSVP-TE can contribute routes to the table. LDP adds all destinations that can be reached by means of labels learned from downstream LDP neighbors.
238 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
RSVP-TE adds only MPLS tunnel endpoints. BGP also adds routes to the tunnel table in certain cases. Routes added by any of these protocols include the effective metric.
For example, in a BGP/MPLS VPN topology, LDP or RSVP-TE adds routes to the tunnel routing table for all available tunnels. BGP performs a lookup in the tunnel routing table so that it can resolve indirect next hops.
You can clear the routes from the tunnel routing table. You might do this, for example, to reapply routing policies when the policies are changed.
Related
Documentation
•
MPLS Forwarding and Next-Hop Tables Overview on page 237
•
Clearing and Refreshing IPv4 Dynamic Routes in the Tunnel Routing Table on page 329
•
Clearing and Refreshing IPv6 Dynamic Routes in the Tunnel Routing Table on page 329
•
Explicit Routing for MPLS Overview on page 239
Explicit Routing for MPLS Overview
MPLS offers two options for selecting routing paths:
• Hop-by-hop routing
• Explicit routing
In explicit routing, the route the LSP takes is defined by the ingress node. The path consists of a series of hops defined by the ingress LSR. Each hop can be a traditional interface, an autonomous system, or an LSP. A hop can be strict or loose.
A strict hop must be directly connected (that is, adjacent) to the previous node in the path. A loose hop is not necessarily directly connected to the previous node; whether it is directly connected is unknown.
The sequence of hops comprising an explicit routing LSP may be chosen in either of the following ways:
• Through a user-defined configuration, resulting in configured explicit paths. When you create the explicit route, you must manually configure each hop in the path.
•
Through a routing protocol–defined configuration, resulting in dynamic explicit paths.
When the routing protocol (IS-IS or OSPF) creates the explicit path, it makes use of the topological information learned from a link-state database in order to compute the entire path, beginning at the ingress node and ending at the egress node.
Consider the MPLS domain shown in
Figure 55 on page 240 . Without explicit path routing,
the tunnel is created hop by hop along the following path:
LSR 1 –> LSR 3 –> LSR 4 –> LSR 7
Suppose LSR 5 and LSR 6 are underused and LSR 4 is overused. In this case you might choose to configure the following explicit path because it forwards the data better than the hop-by-hop path:
Copyright © 2013, Juniper Networks, Inc.
239
JunosE 14.3.x BGP and MPLS Configuration Guide
LSR 1 –> LSR 3 –> LSR 5 –> LSR 6 –> LSR 7
Figure 55: Explicit Routing in an MPLS Domain
Related
Documentation
•
Configuring Explicit Routing for MPLS on page 290
MPLS Interfaces and Interface Stacking Overview
The JunosE implementation of MPLS employs MPLS major, minor, and shim interfaces.
MPLS Major Interfaces
An MPLS major interface must be stacked on a layer 2 interface to send or receive MPLS packets on that interface. Each MPLS major interface exists in a particular virtual router.
MPLS major interfaces can use the platform label space or the interface label space.
Which type of label space is used by the major interface is determined by the layer 2 interface on which the major interface is stacked. If the layer 2 interface is an ATM AAL5 interface, the major interface uses the interface label space. For all other layer 2 interface types, the major interface uses the platform label space.
When an MPLS packet arrives on the MPLS major interface, MPLS looks up the label of the received MPLS packet, the in label, in the MPLS forwarding table that is associated with the major interface. For major interfaces using the platform label space, the lookup is in the MPLS forwarding table of the VR. For major interfaces using the interface label space, the lookup is in the MPLS forwarding table of the major interface.
You use the mpls command in Interface Configuration mode to create or remove MPLS major interfaces. Some other commands create an MPLS major interface if it does not already exist.
You can configure the following attributes for each MPLS major interface:
• The administrative state, enabled or disabled, configured with the mpls disable command.
•
The range of ATM VPIs used as interface labels for major interfaces stacked on ATM
AAL5 interfaces, configured with the mpls atm vpi range command.
240 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
•
The range of ATM VCIs used as interface labels for major interfaces stacked on ATM
AAL5 interfaces, configured with the mpls atm vci range command.
MPLS Minor Interfaces
When you configure an LSP with the interface tunnel mpls command, RSVP-TE creates an MPLS minor interface to represent the head of the LSP. MPLS minor interfaces are also created by RSVP-TE on the transit and tail LSRs when the LSP is signaled. Only
RSVP-TE creates MPLS minor interfaces. Neither BGP nor LDP create them.
These minor interfaces are used to associate policy or a QoS profile with an LSP (either on an LSR or an LER). This minor interface is created automatically by the signaling protocol. Minor interfaces are not saved in NVS. Use the show mpls interface minor command to view the minor interfaces.
The following attributes of the minor interface are set by RSVP-TE:
• The UID of the minor interface, assigned automatically when the interface is created.
• The operational state of the interface, up or down.
•
Whether the interface is an ingress MPLS minor interface used to receive traffic or an egress MPLS minor interface used to transmit traffic.
MPLS Shim Interfaces
MPLS shim interfaces are stacked on layer 2 interfaces to provide layer 2 services over
MPLS or to create local cross-connects by cross-connecting the layer 2 interface to another layer 2 interface. For more information about MPLS shim interfaces, see
Configuring Layer 2 Services over MPLS.
Interface Stacking
MPLS interface stacking differs depending on whether the platform label space
) or the interface label space (
Figure 57 on page 242 ) is used.
Figure 56: MPLS Interface Stacking for the Platform Label Space
Copyright © 2013, Juniper Networks, Inc.
241
JunosE 14.3.x BGP and MPLS Configuration Guide
Figure 57: MPLS Interface Stacking for the Interface Label Space
Related
Documentation
•
MPLS Label Distribution Methodology on page 231
•
MPLS Label Switching and Packet Forwarding Overview on page 222
•
MPLS Label Distribution Protocols Overview on page 242
MPLS Label Distribution Protocols Overview
Label distribution protocols create and maintain the label-to-FEC bindings along an LSP from MPLS domain ingress to MPLS domain egress. A label distribution protocol is a set of procedures by which one LSR informs a peer LSR of the meaning of the labels used to forward traffic between them. It enables each peer to learn about the other peer’s label mappings. The label distribution protocol provides the information MPLS uses to create the forwarding tables in each LSR in the MPLS domain.
NOTE: Label distribution protocols are sometimes referred to as signaling protocols. However, label distribution is a more accurate description of their function and is preferred in this text.
The following protocols are currently used for label distribution:
•
BGP—Border Gateway Protocol
• LDP—Label Distribution Protocol
• RSVP-TE—Resource Reservation Protocol with traffic-engineering extensions that enable label binding and explicit route capability
NOTE: To reduce confusion, this text uses the lowercase term, label distribution protocol, to refer to the generic class of protocols. The acronym,
LDP, refers only to the particular protocol named Label Distribution
Protocol.
BGP and LDP have no traffic-engineering capability and support only best-effort LSPs.
LDP supports topology-driven MPLS networks in best-effort, hop-by-hop implementations. RSVP-TE is used primarily for MPLS applications that require traffic
242 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview engineering (TE) or quality of service (QoS) capabilities, but they also support best-effort
LSPs.
LDP Messages and Sessions
LDP creates reliable sessions by running over TCP. You do not have to explicitly configure
LDP peers, because each LSR actively discovers all other LSRs to which it is directly connected. LDP is a hard-state protocol, meaning that after the LSP is established, it is assumed to remain in place until it has been explicitly torn down. This is in contrast to
RSVP-TE, which is a soft-state protocol. See
“RSVP-TE Messages and Sessions” on page 244
.
LDP uses many messages to create LSPs, classified in the following four types:
• Discovery—To identify other LSRs
• Adjacency—To create, maintain, and end sessions between LSRs
•
Label advertisement—To request, map, withdraw, and release labels
•
Notification—To provide advisory and error information
Unlike the other LDP messages, the discovery process runs over UDP. Each LSR periodically broadcasts a link hello message to the well-known UDP port, 646. Each LSR listens on this port for link hello messages from other LSRs. In this manner, each LSR learns about all other LSRs to which it is directly connected, creating link hello adjacencies.
When an LSR learns about another LSR, it establishes a TCP connection to the peer on well-known TCP port 646 and creates an LDP session on top of the TCP connection.
A transport address for the local peer is advertised in LDP discovery hello messages.
Interfaces that use the platform label space default to the LSR router ID for the transport address. You can use the mpls ldp discovery transport-address command to specify an arbitrary IP address as the transport address.
LDP can also discover peers that are not directly connected if you provide the LSR with the IP address of one or more peers by means of an access list. The LSR sends targeted hello messages to UDP port 646 on each remote peer. If the targeted peer responds with a targeted hello message to the initiator, a targeted hello adjacency is created and session establishment can proceed.
In certain cases, a targeted hello adjacency to directly connected peers might be useful.
If an LSR receives both a link hello message and a targeted hello message from the same initiator, only a single LDP session is established between the LSRs.
By default, because all LSRs listen on the well-known port, they all attempt to create a session with the originator. You can use the mpls ldp link-hello disable command to suppress the transmission of link hello messages. Thereafter, sessions are formed only with peers contacted with targeted hello messages.
The LDP peers exchange session initialization messages that include timer values and graceful-restart parameters. An LSR responds with a keepalive message if the values in the initialization message are acceptable. If any value is not acceptable, the LSR responds instead with an error notification message, terminating the session. After a session is
Copyright © 2013, Juniper Networks, Inc.
243
JunosE 14.3.x BGP and MPLS Configuration Guide established, LDP peers exchange keepalive messages that verify continued functioning of the LSR. Failure to receive an expected keepalive message causes an LSR to terminate the LDP session.
Label mapping and distribution use downstream-unsolicited, independent control.
With downstream-unsolicited, independent control, an LSR creates a label binding whenever it learns a new IGP route; the LSR sends a label mapping message immediately to all of its peer LSRs—upstream and downstream—without having received a label request message from any peer. The LSR sends the label mapping message regardless of whether it has received a label mapping message from a downstream LSR. This is the label distribution method employed in a topology-driven MPLS network.
A downstream LSR can send a label withdrawal message to recall a label that it previously mapped. If an LSR that has received a label mapping subsequently determines that it no longer needs that label, it can send a label release message that frees the label for use.
NOTE: The LDP database can maintain up to 250 neighbors if you configure the hello and dead intervals (or hold timers) for IGP, such as OSPF or IS-IS, to be higher than their default values. If you set the hello and dead intervals
(or hold timers) at their default values, the LDP neighbors start flapping
(constantly go up and down) when more than 200 LDP neighbors are present.
RSVP-TE Messages and Sessions
RSVP is described in RFC 2205. Multiple RFCs enable extensions to RSVP for traffic engineering. The router supports the extended version of RSVP, referred to as RSVP-TE.
RSVP-TE is “ unreliable” because it does not use TCP to exchange messages. In contrast to LDP—a hard-state protocol—RSVP-TE is a soft-state protocol, meaning that much of the session information is embedded in a state machine on each LSR. The state machine must be refreshed periodically to avoid session termination. LSRs send path messages to downstream peers to create and refresh local path states. LSRs send resv messages to upstream peers in response to path messages to create and refresh local resv states. A session is ended if the state machine is not refreshed within the RSVP tunnel timeout period, which is determined as follows:
For example, for the default values,
RSVP-TE messages carry objects consisting of type-length-values (TLVs). The label
request object instructs the endpoint LSR to return an resv message to establish the LSP.
The resv message contains the label object, the label used for the FEC. Both the path
244 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview and resv messages carry the record route object, which records the route traversed by the message.
An upstream LSR sends a pathtear message when its path state times out as a result of not being refreshed. The pathtear message removes the path and resv states in each
LSR as it proceeds downstream. Downstream LSRs similarly send the resvtear message when their resv state times out to remove the resv states in upstream LSRs.
If a downstream LSR determines that it received an erroneous path message, it sends a patherr message to the sender. If a reservation (label) request fails, the request initiator sends a resverr message to the downstream LSRs. Both of these messages are advisory and do not alter path or resv state.
RSVP-TE State Refresh and Reliability
RSVP-TE employs refresh messages to synchronize state between neighbors and to recover from lost RSVP-TE messages of other types. RSVP-TE by default does not provide for reliable transmission. Each node is responsible for the transmission of RSVP-TE messages to its neighbors and relies on periodic state refreshes to recover from lost messages.
RSVP-TE refresh reduction provides a means to increase reliability while reducing message handling and synchronization overhead. Issuing the mpls rsvp refresh-reduction command enables the following features:
• The message ID object is included in RSVP-TE messages to provide a unique message
ID on a per-hop basis. In refresh messages, it indicates to the receiving node that the message is a refresh message, eliminating the need for the node to completely analyze the message and thus reducing the processing overhead at the receiver.
• RSVP-TE uses a message acknowledgment mechanism to support reliable message delivery on a per-hop basis. Messages that include the message ID object also include a request for acknowledgment. Upon receipt, the receiving node returns a message ack object, enabling the sending node to determine whether a message was lost and triggering a retransmission as necessary.
•
Summary refresh (srefresh) messages refresh the state previously advertised in path or resv messages that included message ID objects. The srefresh message carries the unique message ID as state identifier, eliminating the need to send whole refresh messages and reducing the overhead needed to maintain RSVP-TE state synchronization. This method maintains RSVP-TE's ability to indicate when the state is lost and to adjust to changes in routing. The srefresh message can carry message
IDs for multiple RSVP-TE sessions.
Issuing the mpls rsvp message-bundling command enables RSVP-TE to use bundle messages, each of which includes multiple standard RSVP-TE messages, to reduce the overall message processing overhead.
BGP Signaling
You can use BGP as a label distribution protocol both for IP routes and for VPN routes.
Copyright © 2013, Juniper Networks, Inc.
245
JunosE 14.3.x BGP and MPLS Configuration Guide
When BGP distributes a particular IP route, it can also distribute an MPLS label that has been mapped to that route, as described in RFC 3107. The MP-BGP extensions (RFC
4760) enable the BGP update message to carry both the route and the label mapping information for the route. The label is encoded into the NLRI field of the attribute, and the SAFI field is set to 4 to indicate that the NLRI contains a label. A BGP speaker can use BGP to send labels to a particular BGP peer only if that peer advertised the capability to process update messages with SAFI 4. BGP speakers advertise this capability only to peers for which the neighbor send-label command has been configured.
When BGP advertises labeled routes, it adds a label-to-next-hop mapping
(cross-connect) to the MPLS forwarding table. This mapping consists of the in label that
BGP allocates from the platform label space plus the MPLS next hop information related to the labeled route's next hop.
BGP can also distribute labels for VPN routes in BGP/MPLS VPNs. In a BGP/MPLS VPN network, BGP is used to exchange the routes of a particular VPN among the provider edge routers attached to the VPN. To ensure that routes from different VPNS remain distinct even if the VPNs use overlapping address spaces, an MPLS label is assigned to each route within the VPN. BGP distributes both the VPN routes and the associated MPLS label for each route.
The label mapping information for a particular VPN route is included in the same BGP update message that distributes the route. The label is encoded into the NLRI field of the attribute, and the SAFI field has a value of 128 to indicate that the NLRI contains both an RD (route distinguisher) and a label.
For more information on BGP capabilities, see Configuring BGP Routing. For more information on MP-BGP extensions, NLRIs, and BGP/MPLS VPNs, see Configuring
BGP-MPLS Applications.
Related
Documentation
•
MPLS Label Distribution Methodology on page 231
•
MPLS Label Switching and Packet Forwarding Overview on page 222
•
MPLS Interfaces and Interface Stacking Overview on page 240
•
Topology-Driven LSPs Overview on page 259
ECMP Labels for MPLS Overview
MPLS supports equal-cost multipath (ECMP) labels. A maximum of 16 MPLS paths is supported; 4 paths are available by default. On LERs, MPLS ECMP next hops can be used in the IP routing table for non-VPN and VPN routes. On LSRs, an incoming label can point to either an MPLS ECMP next hop or an IP ECMP.
The signaling protocol determines whether ECMP next hops are used. For example, LDP can learn multiple labels for a route from different downstream peers (or one label from a downstream peer that has parallel connections to the router). LDP then creates an
MPLS ECMP next hop that can be used in the IP routing table. If LDP also advertises a label, then a forwarding entry is added to the MPLS forwarding table with the ECMP next hop.
246 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
MPLS Connectivity and ECMP
When an MPLS ECMP is part of the tunnel being explored by an MPLS echo request, the request packet takes one of the available ECMP paths. Probing FECs with different label stacks can yield different ECMP paths. However, you cannot guarantee complete coverage of all the ECMP paths.
You can use MPLS trace to determine which paths are present on an MPLS LSR. When the TTL expires on an MPLS LSR, the echo reply that is returned includes a downstream mapping TLV. This TLV contains all the downstream mappings of the LSR on which the
TTL expired, if that feature is supported by the LSR. You can use the detail version of the trace mpls commands to display these downstream mappings.
Supported TLVs
lists the TLVs supported by the MPLS LSP ping feature.
lists the sub-TLVs supported for the Target FEC Stack TLV.
Table 51: TLVs Supported by MPLS LSP ping
Type Number Value Comments
1 Target FEC Stack
2 Downstream Mapping
Multiple FEC stack sub-TLVs are not supported.
A single LSP ping message cannot have more than one target FEC stack TLV.
Only the IPv4 (numbered or unnumbered) downstream address type is supported.
Flag I for the Interface and Label Stack object is supported. Flag N, to treat the packet as a non-IP packet, is not supported.
An MPLS LSP trace echo request includes this TLV.
This TLV contains the downstream address all-routers-multicast; that is the well-known IP address 224.0.0.2. Validation of the downstream address is not performed.
Verification of the downstream address is not performed on receipt of an MPLS echo request that contains this TLV.
In an MPLS echo reply, multipath information is not supported in this TLV; the multipath type is always set to 0 in the reply. However, the reply includes one downstream mapping TLV for each downstream path.
3
7
Pad This TLV is included in the MPLS echo request packet. The TLV can specify either “ Do not reply” or “ Reply via an IPv4/IPv6 UDP packet.”
Interface and Label Stack This TLV is generated if requested by the received downstream mapping TLV.
Copyright © 2013, Juniper Networks, Inc.
247
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 51: TLVs Supported by MPLS LSP ping (continued)
Type Number Value Comments
9
10
11
12
Errored TLVs This TLV is generated if an error is encountered while parsing one of the received TLVs.
– Reply TOS Byte
P2MP Responder Identifier This TLV is included in the MPLS echo request packet to validate whether the IP address specified in the TLV is an IP address of one of the interfaces in the router. Four sub-TLVs are defined for inclusion in the P2MP Responder Identifier TLV in the echo request message.
Echo Jitter This TLV is included in the LSP ping message
(echo request) to enable the egress node of a point-to-multipoint LSP to delay the transmission of the response by a time interval that is limited by the value specified in this TLV. In JunosE
Software, the delay is set to a maximum of 30 seconds.
7
8
3
6
10
17
Table 52: Sub-TLVs Supported for the Target FEC Stack TLV
Subtype Number Value Comments
1
2
LDP IPv4 prefix
LDP IPv6 prefix
–
–
RSVP IPv4 LSP
VPN IPv4 prefix
VPN IPv6 prefix
L2 VPN endpoint
–
–
–
For VPLS and VPWS
FEC 128 pseudowire For Martini encapsulation
RSVP P2MP IPv4 Session For identification of the point-to-multipoint LSP for which you want to verify the data plane
Related
Documentation
•
MPLS Label Switching and Packet Forwarding Overview on page 222
248 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
MPLS Connectivity Verification and Troubleshooting Methods
In IP networks, the ping and traceroute commands enable you to verify network connectivity and find broken links or loops. In MPLS-enabled networks, you can use the ping command to determine whether IP connectivity exists to a destination even when the ping packets must traverse multiple LSPs. You can use the traceroute command to determine the labels that data packets use when traversing LSPs to the destination.
In an MPLS-enabled network, however, you cannot use these IP commands to determine
MPLS connectivity to a destination.
You can use the MPLS ping and trace features to detect data plane failures in LSPs.
Specific mpls ping and trace mpls commands enable you to target different types of
MPLS applications and network topologies. The various ping mpls and trace mpls commands send UDP packets, known as MPLS echo requests, to the egress LSR of MPLS packets in a given FEC. Each echo request is forwarded along the same data path as the
MPLS packets in that FEC.
The echo request packets use a destination address in the 127.0.0.0/8 range and port
3503. The default address is 127.0.0.1. This address range prevents IP from forwarding the packet, so that the echo request must follow the MPLS data path. This behavior is different from that of the IP ping and traceroute commands, which send ICMP packets to the actual destination.
Each MPLS echo request packet contains information about the FEC stack that is being validated. LSRs that receive an MPLS echo request respond with MPLS echo reply packets.
(Even when MPLS is not enabled on that router, echo reply packets are sent by E Series routers that receive an echo request packet. This situation is a transient condition when the router is receiving labeled packets. A return code in the echo replies indicates to the sending router that no label mapping exists on the receiving router.)
The ping mpls commands perform a basic connectivity check. When the echo request exits the tunnel at the egress LSR, the LSR sends the packet to the control plane. The egress router validates the FEC stack to determine whether that LSR is the actual egress for the FEC. The egress router sends an echo reply packet back to the source address of the echo request packet. The egress router can send the packet back by means of either the IP path or the MPLS path.
The trace mpls commands isolate faults in the LSP. For these commands, successive echo request packets are sent along the path. The first packet has a TTL of one; the TTL value is incremented by one for each successive packet. The first packet therefore reaches only the next hop on the path; the second packet reaches the next router after that. Echo request packets are sent until either an echo reply is received from the egress router for the FEC or a TTL of 32 is reached.
When a TTL expires on an LSR, that LSR sends an echo reply packet back to the source.
For transit routers, the echo reply indicates that downstream mapping exists for the FEC, meaning that the packet would have been forwarded if the TTL had not expired. The egress router sends an echo reply packet verifying that it is the egress.
Copyright © 2013, Juniper Networks, Inc.
249
JunosE 14.3.x BGP and MPLS Configuration Guide
Although you cannot send IPv6 UDP packets for MPLS ping, you can use the ping mpls l3vpn command with an IPv6 prefix to investigate IPv6 VPNs.
Related
Documentation
•
ECMP Labels for MPLS Overview on page 246
•
Verifying and Troubleshooting MPLS Connectivity on page 377
•
Packet Flow Examples for Verifying MPLS Connectivity on page 379
•
ping mpls ip
•
ping mpls l2transport
•
ping mpls l3vpn
•
ping mpls rsvp tunnel
•
ping mpls vpls
•
trace mpls ip
•
trace mpls l2transport
•
trace mpls l3vpn
•
trace mpls rsvp tunnel
•
trace mpls vpls
Point-to-Multipoint LSPs Connectivity Verification at Egress Nodes Overview
JunosE Software enables you to use the MPLS ping feature to detect data plane failures in point-to-multipoint MPLS LSPs. The implementation of the RSVP-TE protocol in
JunosE Software was previously enhanced to enable you to configure E Series routers as tunnel-tail or egress nodes for point-to-multipoint MPLS LSPs. You can use the point-to-multipoint LSP ping functionality, which is available in routers other than E Series routers, to send echo request packets and receive echo reply packets to test network connectivity of point-to-multipoint RSVP-TE MPLS LSPs that contain E Series routers as egress nodes. You cannot use the ping commands for other point-to-multipoint MPLS applications, such as LDP LSPs because E Series routers do not support such functionality.
In addition, because E Series routers do not support ingress, transit, or branch label-switched routers (LSR) roles for point-to-multipoint LSPs, they do not support the point-to-multipoint MPLS ping feature for ingress, transit, or branch nodes.
Related
Documentation
•
•
Ping Extensions for Point-to-Multipoint LSPs Connectivity Verification at Egress Nodes on page 251
•
Verifying and Troubleshooting MPLS Connectivity on page 377
250 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
Ping Extensions for Point-to-Multipoint LSPs Connectivity Verification at Egress Nodes
To enable detection of data plane failures at egress nodes in point-to-multipoint LSPs, the MPLS ping extensions in point-to-multipoint LSPs define the following new sub-type-length-values (TLVs) for the Target FEC Stack TLV and new TLVs:
•
RSVP P2MP IPv4 Session sub-TLV
• P2MP Responder Identifier TLV
• Echo Jitter TLV
RSVP P2MP IPv4 Session Sub-TLV Overview
The RSVP P2MP IPv4 Session TLV identifies the point-to-multipoint LSP for which you are verifying the data plane. This TLV has a type number of 17. To identify the point-to-multipoint LSP for which you are running diagnostic connectivity checks, the echo request message must carry a Target FEC Stack TLV that contains an RSVP P2MP
IPv4 Session sub-TLV. The point-to-multipoint LSP ping functionality performs necessary validation with RSVP-TE before sending the response to the source. For other sub-TLVs defined for identifying point-to-multipoint LDP MPLS LSP, the ping feature sends an error response.
P2MP Responder Identifier TLV Overview
The point-to-multipoint MPLS LSP ping extensions enable a specific egress node of the point-to-multipoint MPLS LSP to be selected to verify that the data plane of the path to the particular egress node does not possess any failures. Use the new P2MP Responder
Identifier TLV and associated rules for processing the LSP ping message (echo request) that contain this new TLV to validate whether the IP address specified in the TLV is an
IP address of one of the interfaces in the router.
•
If the IP address in the TLV matches the IP address assigned to one of the interfaces, the point-to-multipoint MPLS LSP ping feature sends the success response to the originator.
• If the IP address specified in the TLV does not match any of the IP addresses assigned to the interfaces, no response is sent to the originator.
If errors exist in the syntax of TLVs in the message received or if the router to which echo request packets are sent is not an egress node for the point-to-multipoint MPLS LSP, the echo response is sent to the originator, regardless of the presence of the P2MP
Responder Identifier TLV in the request packet.
IETF draft, Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label
Switching (MPLS) - Extensions to LSP Ping (draft-ietf-mpls-p2mp-lsp-ping-08.txt)
(February 2010 expiration), recommends a particular type value for the P2MP Responder
Identifier TLV.
The type value used by point-to-multipoint LSPs in Junos OS differs from the type value specified in the IETF draft. To enable interoperability with routers running Junos OS (which are often employed as the ingress, transit, or branch nodes in point-to-multipoint LSPs),
Copyright © 2013, Juniper Networks, Inc.
251
JunosE 14.3.x BGP and MPLS Configuration Guide the point-to-multipoint MPLS LSP ping feature in JunosE Software interprets both type values to identify the TLV (P2MP Responder Identifier).
Echo Jitter TLV Overview
The point-to-multipoint MPLS LSP ping extensions enable the initiator or ingress of the ping operation to request the egress nodes not to send responses immediately after the echo request message is received, but delay the response by a certain period of time.
Use the new Echo Jitter TLV and associated rules for processing the LSP ping message
(echo request) that contains this the Echo Jitter TLV to delay the transmission of the response by a time interval that is limited by the value specified in the Echo Jitter TLV.
The point-to-multipoint MPLS LSP ping functionality in JunosE Software supports a delay of up to 30 seconds. If the value specified in the Echo Jitter TLV is not within the supported range, the egress node uses a value within the range as the time to wait to send the echo response.
IETF draft, Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label
Switching (MPLS) - Extensions to LSP Ping, uses a particular type value for the Echo
Jitter TLV. The point-to-multipoint MPLS LSP ping functionality in JunosE Software interprets the suggested type value in the draft to denote the new TLV (Echo Jitter).
Traceroute Overview
The point-to-multipoint LSP ping feature enables the egress node to respond to the traceroute requests that the ingress node initiates in the same manner as the egress node responds to a ping request. No additional or separate configuration is needed to enable the path to the egress nodes to be traced by ingress nodes in point-to-multipoint
LSPs.
Related
Documentation
•
•
Point-to-Multipoint LSPs Connectivity Verification at Egress Nodes Overview on page 250
•
Verifying and Troubleshooting MPLS Connectivity on page 377
TLVs and Sub-TLVs Supported for Point-to-Multipoint LSPs Connectivity Verification at Egress Nodes
To enable detection of data plane failures using the ping mpls and trace mpls commands at egress nodes of point-to-multipoint LSPs, JunosE Software supports two new TLVs,
Echo Jitter and P2MP Responder Identifier. Also, a sub-TLV, RSVP P2MP IPv4 Session, is supported in the Target FEC Stack TLV to verify MPLS connectivity to egress nodes of point-to-multipoint LSPs.
Echo Jitter TLV Operations
The initiator (ingress) of a ping request might require the responding egress to introduce a random delay (or jitter) before forwarding the response. The delay period enables the responses from multiple egresses to be spread over a time period. This mechanism is very useful in situations when the entire LSP tree is being pinged because it helps the
252 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview ingress (and nearby routers) node from being flooded with a number of responses, or from discarding responses if any rate limits are applied on the incoming traffic.
In JunosE Software, the delay is set to a maximum of 30 seconds. The ingress node informs the egresses of this time interval limitation by supplying a value in the Echo Jitter
TLV in the echo request message. If this TLV is present in the echo request packet, the responding egress node delays sending a response for a random amount of time between zero milliseconds and 30 seconds that is predefined for this TLV. If the TLV is not contained in the echo request packet, the responding egress node does not create any additional delay in responding to the echo request. The Echo Jitter TLV is valid only in an echo request message. If this TLV is included in an echo response message, it is ignored.
The Echo Jitter TLV is assigned the TLV type value of 12.
P2MP Responder Identifier TLV Operations
You can select the egress node in a point-to-multipoint LSP for which you want to trace the path from an ingress node and detect network failures by including a P2MP Responder
Identifier TLV in the echo request packet sent to the egress node. The initiator can determine whether only the node identified in the TLV must respond or any node on the path to the selected egress node in the TLV needs to respond. If you do not include the
P2MP Responder Identifier TLV in an echo request packet, all egress nodes in the path to the ingress node respond to echo request packets.
If the node is an egress of the P2MP LSP, the node checks whether it has received a P2MP
Responder Identifier TLV in an echo request. If a P2MP Responder Identifier TLV is contained in the received echo request, the node uses the sub-TLVs contained in this
TLV to determine whether it must respond to the request. If the P2MP Responder Identifier
TLV is not present (or does not contain any sub-TLVs), the egress node responds to the echo request depending on the setting of the Response Type field in the echo message.
The P2MP Responder Identifier TLV is assigned a type number of 11. The P2MP Responder
Identifier TLV is valid only in an echo request message.
• If this TLV is included in an echo response message, it is ignored.
•
If no sub-TLVs are present, this TLV is processed as though it were not included.
•
If more than one sub-TLV is present in this TLV, they are processed based on their subtype numbers and subsequent sub-TLVs are ignored.
Four sub-TLVs are defined for inclusion in the P2MP Responder Identifier TLV in the echo request message.
lists the sub-TLVs supported for the P2MP
Responder Identifier TLV.
Table 53: Sub-TLVs Supported for the P2MP Responder Identifier TLV
Subtype Number Value Comments
1 IPv4 Egress Address P2MP
Responder Identifier
The IPv4 address in this sub-TLV is the IPv4 address of the egress node and does not specify the IPv4 address of a branch or intermediate node.
Copyright © 2013, Juniper Networks, Inc.
253
JunosE 14.3.x BGP and MPLS Configuration Guide
254
Table 53: Sub-TLVs Supported for the P2MP Responder Identifier TLV
(continued)
Subtype Number Value Comments
2 IPv4 Node Address P2MP
Responder Identifier
3
4
IPv6 Egress Address P2MP
Responder Identifier
IPv6 Node Address P2MP
Responder Identifier
The IPv6 address in this sub-TLV is the IPv6 address of the egress node and does not specify the IPv6 address of a branch or intermediate node.
The IPv4 address in the sub-TLV might be of any physical interface or the router ID of the node itself.
The IPv6 address in the sub-TLV might be of any physical interface or the router ID of the node itself.
The echo response is always controlled by the Response Type field in the echo message and also depends on whether the responding node is part of the point-to-multipoint LSP that is denoted in the Target FEC Stack TLV. The following sections describe the sub-TLVs of the P2MP Responder Identifier TLV, which are additional influencing factors to those requirements and are not a replacement for those requirements:
•
Egress Address P2MP Responder Identifier Sub-TLVs on page 254
•
Node Address P2MP Responder Identifier Sub-TLVs on page 254
Egress Address P2MP Responder Identifier Sub-TLVs
You can use the IPv4 or IPv6 Egress Address P2MP Responder Identifier sub-TLVs in an echo request that contains the RSVP P2MP Session or Multicast LDP FEC Stack sub-TLV.
An egress node that receives an echo request with this sub-TLV present responds only if the node lies on the path to the address in the sub-TLV. The address in this sub-TLV is the address of the egress node and does not specify the address of a branch or intermediate node. This address is made available to the nodes upstream of the target node, using signaling protocols, such as RSVP. This sub-TLV may be used to trace a specific egress node in a point-to-multipoint LSP.
Node Address P2MP Responder Identifier Sub-TLVs
You can use the IPv4 or IPv6 Node Address P2MP Responder Identifier sub-TLVs in an echo request that contains the RSVP P2MP Session or Multicast LDP FEC Stack sub-TLV.
A node that receives an echo request with this sub-TLV present responds only if the address in the sub-TLV corresponds to any address that is local to the node. This address in the sub-TLV might be of any physical interface or the router ID of the node itself. The address in this sub-TLV can be the address of any transit, branch, or egress node for that point-to-multipoint LSP.
Related
Documentation
•
Troubleshooting MTU Problems in Point-to-Point LSPs on page 386
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
•
Ping Extensions for Point-to-Multipoint LSPs Connectivity Verification at Egress Nodes on page 251
•
Point-to-Multipoint LSPs Connectivity Verification at Egress Nodes Overview on page 250
•
Verifying and Troubleshooting MPLS Connectivity on page 377
LDP Discovery Mechanisms
LDP uses two different mechanisms for peer discovery. Peer discovery removes the need to explicitly configure the label-switching peers for an LSR.
•
LDP uses the basic discovery mechanism to discover directly connected LDP peers.
•
LDP uses the extended discovery mechanism to discover peers that are not directly connected.
LDP Basic Discovery Mechanism
To discover directly connected peers, LSRs periodically send out LDP link hellos on the interface. The link hellos are contained in UDP packets that are addressed to the well-known LDP discovery port, 646. The destination address for the ports is 224.0.0.2.
Using this port and address ensures that the hellos are sent to all routers on the interface’s subnet.
The link hello includes the LDP identifier for the label space that the LSR intends to use for the interface. In the JunosE implementation, this is always the platform label space, so the LDP identifier specifies the LSR ID and a value of 0 for the label space. The link hello also includes other information, such as the hello hold time configured on the interface. The hello hold time specifies how long an LSR maintains a record of hellos received from potential peers.
When an LSR receives a link hello, it identifies the sending LSR as a potential LDP peer on that interface. The LSRs form a hello adjacency to keep track of each other.
The basic discovery mechanism is enabled by default when you enable LDP on an interface. You can configure the link hellos in the LDP profile with the hello hold-time and hello interval commands. You can configure a transport IP address to be globally included in link hellos with the mpls ldp discovery transport-address command.
LDP Extended Discovery Mechanism
To discover LDP peers that are not directly connected, LSRs periodically send out LDP targeted hellos to potential peers. The targeted hellos are contained in UDP packets that are addressed to the well-known LDP discovery port, 646. The destination address for the ports is a specific targeted address. LDP sends targeted hellos when you configure one or more IP addresses in a targeted-hello send list. In a layer 2 Martini circuit, targeted hellos are automatically sent to the remote PE neighbor (the base tunnel endpoint). See
Configuring Layer 2 Services over MPLS for information about layer 2 circuits.
Copyright © 2013, Juniper Networks, Inc.
255
JunosE 14.3.x BGP and MPLS Configuration Guide
The targeted hello includes the LDP identifier for the label space that the LSR intends to use. In the JunosE implementation, this is always the platform label space, so the LDP identifier specifies the LSR ID and a value of 0 for the label space. The targeted hello also includes other information, such as the targeted-hello hold time, which is configured globally. The targeted-hello hold time configures how long an LSR waits for another targeted hello from its peer before declaring the adjacency to be down.
Unlike basic discovery, where hellos are sent by all LSRs, extended discovery is initiated by one LSR that targets a specific LSR. The initiating LSR periodically sends targeted hellos to the targeted LSR. The targeted LSR then determines whether to respond to the targeted hello or to ignore it. If the targeted LSR responds to the sender, it does so by periodically sending targeted hellos to the initiating LSR. The exchange of targeted hellos constitutes a hello adjacency for the two LSRs.
Targeted hello values are configured globally with the mpls ldp targeted-hello holdtime, mpls ldp targeted-hello interval, mpls ldp targeted-hello receive list, and mpls ldp targeted hello send list commands.
Related
Documentation
•
MPLS Label Switching and Packet Forwarding Overview on page 222
•
MPLS Label Distribution Protocols Overview on page 242
MPLS Traffic Engineering Overview
MPLS traffic engineering (TE) is the ability to establish LSPs according to particular criteria (constraints) in order to meet specific traffic requirements rather than relying on the path chosen by the conventional IGP. The constraint-based IGP examines the available network resources and calculates the shortest path for a particular tunnel that has the resources required by that tunnel. Traffic engineering enables you to make the best use of your network resources by reducing overuse and underuse of certain links.
Constraint-based routing (CR) makes traffic engineering possible by considering resource requirements and resource availability rather than merely the shortest path calculations.
Constraints are determined at the edge of the network and include criteria such as required values for bandwidth or required explicit paths. You can use RSVP-TE as the label distribution protocol for traffic engineering. The IGP propagates resource information throughout its network. RSVP-TE employs downstream-on-demand, ordered control for label mapping and distribution.
Explicit routing specifies a list or group of nodes (hops) that must be used in setting up the tunnels. CR explicit paths can be strict or loose. Strict paths specify an exact physical path, including every physical node. Loose paths include hops that have local flexibility; the hop can be a traditional interface, an autonomous system, or an LSP.
LSP Backup
You can configure multiple LSPs to the same destination. By configuring different tunnel metrics for these LSPs, you can force a ranking or priority of use for the LSPs. In this scenario, all the configured LSPs are up and active. If the LSP in use develops problems and goes down, traffic is diverted to the LSP having the next best metric.
256 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
Path Option
You can configure multiple paths for an LSP with the tunnel mpls path-option command.
Each path option has an identifying number; the lower the number the higher the preference for that path option. In this scenario, only a single LSP is up and active at a time. If the path option currently in use by an LSP goes down, MPLS tries to reroute the tunnel using the path option with the next highest preference. In certain circumstances—for example, when a tunnel is preempted by another—MPLS first attempts to reroute the tunnel with the current path option.
Reoptimization
You can use the traffic-engineering reoptimization capability to ensure that the best path is being used. Suppose the current path goes down and MPLS switches to an alternate path that is not as good as the failed path. You can have MPLS periodically search—according to a specified schedule—for a path better than the alternate by configuring the reoptimization timer. For example, you might configure MPLS to search for a better path every 10 minutes; if it finds a better path, it switches.
On the other hand, you might be concerned about route flapping. If a path goes down and then comes back up, perhaps it will continue to do so. In this case, you might not ever want to go back to a path that goes down. To accomplish this, you can configure reoptimization to never occur.
When you do not want the initial path to change—that is, when you want to pin the route—you can disable reoptimization globally by setting the timer to 0. Alternatively, you can disable reoptimization on a per-tunnel basis by using the lockdown option with the tunnel mpls path-option command. LSP paths are always pinned until the next reoptimization.
Finally, you can manually force an immediate reoptimization. See MPLS Global
Configuration Tasks in Configuring MPLS in the JunosE BGP and MPLS Configuration Guide for information about configuring reoptimization.
Methods for Configuring RSVP-TE Tunnels
You can use either of the following methods to configure RSVP-TE tunnels:
• Configure individual tunnels with the interface tunnel mpls: tunnelName command.
•
Configure multiple tunnels with the same set of parameters with the mpls tunnels profile command.
Related
Documentation
•
Tracking Resources for MPLS Traffic Engineering Overview on page 258
•
LDP and RSVP-TE Interface Profile Configuration Tasks on page 284
Copyright © 2013, Juniper Networks, Inc.
257
JunosE 14.3.x BGP and MPLS Configuration Guide
Tracking Resources for MPLS Traffic Engineering Overview
MPLS traffic engineering uses admission control to keep track of resource information.
Admission control has an accounting feature that ensures that requests are not accepted when the router does not have sufficient resources to accommodate them.
Currently, bandwidth (BW) and bandwidth-related information are the only resources tracked and used for traffic engineering. Admission control determines whether a setup request can be honored for an MPLS LSP with traffic parameters.
Admission control provides bandwidth information to the IGP protocols, ISIS and OSPF.
As new LSPs are created, the available bandwidth decreases. The IGPs can subsequently advertise this information and use it for SPF calculations to determine paths that satisfy the traffic requirements. You can configure readvertisement to occur periodically or when the change crosses some threshold.
Starting Admission Control
Admission control operates on a router-wide basis rather than a per-virtual-router basis.
Admission control of resources begins when either of the following occurs:
• You configure resource-related information about an interface, including bandwidth
(either total bandwidth or MPLS reservable bandwidth), flooding frequency, flooding threshold, administrative weight, or attribute flags.
• MPLS begins to use admission control services; for example, by attempting to set up a constraint-based LSP.
Admission Control Interface Table
Configuring bandwidth on an interface creates an entry for the interface in the admission control interface table. Each entry in the table stores the following information per interface:
•
Maximum (physical or line-rate) bandwidth
• Maximum reservable bandwidth
• The following information per IP class (currently a single, default class)
•
Total available (unreserved) bandwidth
•
Available bandwidth at each MPLS priority level
•
Resource flooding threshold and period
The resource flooding threshold and period together control the flooding of the resource information by the IGP protocols, IS-IS and OSPF.
Configuring Traffic-Engineering Resources
You can configure the following resource-related information about an MPLS interface
(at either the major interface or subinterface level):
258 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
•
Bandwidth—Total bandwidth that can be reserved on the interface
• Flooding thresholds—Sets of absolute percentages of total reservable bandwidth that trigger the new bandwidth value to be flooded throughout the network; flooding is triggered when bandwidth increases past any up threshold value or decreases past any down threshold value
• Flooding frequency—Periodicity with which the bandwidth value is flooded, apart from any flooding due to value changes
•
Administrative weight—Weight assigned to the interface that supersedes any assigned by the IGP
• Attribute flags—32-bit value that assigns the interface to a resource class and enables a tunnel to discriminate among interfaces by matching against tunnel affinity bits
LSP Preemption
You can develop a preemption strategy whereby a new LSP can claim resources from an existing LSP. Each tunnel can be configured with a setup priority and a hold priority.
Priority levels range from 0 (highest priority) through 7 (lowest priority).
If traffic engineering admission control determines that there are insufficient resources to accept a request to set up a new LSP, the setup priority is evaluated against the hold priority of existing LSPs. An LSP with a hold priority lower than the setup priority of the new LSP can be preempted. The existing LSP is terminated to make room (free resources) for the new LSP. You must assign priorities according to network policies to prevent resource poaching and LSP thrashing.
Related
Documentation
•
LDP and RSVP-TE Interface Profile Configuration Tasks on page 284
•
MPLS Traffic Engineering Overview on page 256
Topology-Driven LSPs Overview
Topology-driven LSPs are implemented for best-effort, hop-by-hop routing. In topology-driven LSP mode, LDP automatically sets up LSPs for IGP, direct, and static routes, subject to filtering by access-lists. JunosE supports downstream-unsolicited LDP using the platform label space.
If you use the topology-driven LSP mode to forward plain IP packets, use the ldp ip-forwarding command to place LSPs into the IP routing table for forwarding plain IP traffic.
You can use the mpls ldp advertise-labels command to limit the number of routes for which labels are advertised. In most cases, you can issue mpls ldp advertise-labels host-only.
LDP over RSVP-TE
If you are running RSVP-TE in the core, LDP can tunnel through the core by stacking an
LDP LSP over an RSVP-TE LSP, as shown in
. With LDP over RSVP-TE,
Copyright © 2013, Juniper Networks, Inc.
259
JunosE 14.3.x BGP and MPLS Configuration Guide
LDP establishes targeted sessions among the LDP routers at the edge of the RSVP core.
From the perspective of the LDP LSP, the RSVP-TE core is a single hop.
Figure 58: LDP Tunneled Through an RSVP-TE Core
In the network topology illustrated in
, the RSVP-TE LSP consists of LSR 2, LSR 3, LSR 4, and LSR 5. The LDP LSP consists of LER 1, LSR 2, LSR 5, and LER
6. The RSVP-TE tunnel appears to LDP as a single hop.
The initial LDP label 19 is switched with label 24 at LSR 2. Because this is the entrance to the RSVP-TE tunnel, label 21 is pushed onto the stack. Label 21 is switched with label
43 at LSR 3. Label 43 is switched with label 56 at LSR 4. LSR 5 pops both labels, pushes label 17, and forwards the packet to LER 6.
On the LDP routers that are on the edge of the core, you must configure a list of peer addresses. The LDP router sends targeted hello messages to those addresses in order to establish targeted sessions across the RSVP-TE domain. The list includes other LDP routers on the edge of the core; for example, in
Figure 58 on page 260 , you include the
address of LSR 5 in the list configured on LSR 2.
Related
Documentation
•
MPLS Label Distribution Methodology on page 231
•
MPLS Label Switching and Packet Forwarding Overview on page 222
•
MPLS Label Distribution Protocols Overview on page 242
•
IP Data Packet Mapping onto MPLS LSPs Overview on page 233
LDP Graceful Restart Overview
The graceful restart mechanism minimizes the negative effect on MPLS forwarding across an LSR restart. You can configure the neighbors of the LSR to wait for the LSR to restart
(helper mode). When the LSR restarts, the neighbors mark their current label mapping entries from the LSR as stale. If the LSR recovers within the proper interval, the entries are no longer marked as stale and are used as they were before the LDP connection failed. If the LSR does not recover in time, the entries are deleted.
260 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
LDP graceful restart supports only the downstream-unsolicited mode of label distribution.
Successful operation of LDP graceful restart requires that stateful SRP switchover (high availability) be configured on the router. Although you can configure LDP graceful restart if stateful SRP switchover is not configured on the router, the graceful restart capability will not function.
You can configure an LSR to restart itself gracefully and to support graceful restart in its neighbors (helper mode), or helper mode alone. In either case, the LSR includes the fault tolerant (FT) session TLV in the LDP initialization messages it sends at session startup.
The TLV includes values for the reconnect timeout and the recovery time. When both graceful restart and the helper mode are disabled, the LSR does not include the TLV in its LDP initialization messages.
The configurable reconnect time specifies how long you want the LSR’s neighbors to wait for the LSR to resume exchanging LDP messages with the neighbors after the connection failure. The reconnect timeout value is nonzero when graceful restart is enabled.
When you disable graceful restart but enable helper mode, the reconnect timeout is set to zero to announce to the neighbors that the LSR does not preserve MPLS forwarding state across the restart. The presence of the TLV indicates to the neighbors that the LSR supports them if they gracefully restart. That is, the LSR in this case waits for a gracefully restarting neighbor to resume sending messages.
summarizes the states possible for LDP graceful restart.
Table 54: Summary of LDP Graceful Restart States
Graceful restart enabled?
Helper mode enabled?
FT TLV sent to neighbor?
Reconnect timeout value sent in TLV
Yes
No
No
Yes
Yes
No
Yes
Yes
No
Nonzero
Zero
–
The recovery time specifies how long the LSR retains its MPLS forwarding state across the restart. When the LSR restarts, it marks the forwarding state entries as stale. The forwarding state holding timer begins counting down from the configured recovery time value. If the timer expires before the restart completes, the LSR deletes all stale entries.
When the LSR sends new LDP initialization messages to its neighbors, the messages contain the current value of the timer.
NOTE: An LDP router processes LDP initialization messages received from peers with protocol data units (PDU) lengths in the range of 2095 to 4096.
The router responds to the initialization message with the same PDU length that it received from the peer, causing the peer to accept the LDP session.
Copyright © 2013, Juniper Networks, Inc.
261
JunosE 14.3.x BGP and MPLS Configuration Guide
When the LSR restarts, if a neighbor of the LSR has previously received the FT session
TLV from the LSR with a nonzero reconnect timeout value, the neighbor retains the label mapping information that it has previously received from the LSR and marks that information as stale. Alternatively, if the neighbor received an FT session TLV with a timeout value of zero (indicating that only helper mode is enabled) or no TLV at all
(indicating that both graceful restart and helper mode are disabled), it deletes the label mapping information.
Also when the LSR restarts, the neighbor sets its neighbor liveness timer to the lesser of the two values, the reconnect timeout value and its own configurable neighbor liveness timer value. If the neighbor liveness timer expires, the neighbor deletes all the stale mappings from the LSR. The configurable value represents the maximum time that the neighbor waits for the restarting LSR to reestablish the LDP session. This enables the neighbor to avoid having to wait an unreasonably long time set by the reconnect timeout value from the restarting LSR.
If the recovery time value in the FT session TLV is zero when a neighbor receives the new
LDP initialization message, the neighbor deletes all the stale mappings from the LSR.
If the recovery time value is nonzero, the neighbor starts a neighbor recovery timer set to the lesser of the two values, the recovery time value and its own configurable maximum recovery timeout value. The neighbor also cancels its neighbor liveness timer because the LDP session has been reestablished; it is now waiting on the successful completion of the restart.
The restarting LSR and its neighbors then exchange label mapping information. When a neighbor receives a label–to–FEC binding that matches a stale entry, it removes the staleness marker from the entry. If instead the neighbor receives a new label for the same
FEC that is in a stale entry, the neighbor updates the entry with the new label and removes the staleness marker from the entry.
The neighbor deletes any stale entries that remain when the neighbor recovery timer expires.
Dynamic exchange of the graceful restart capability is not supported. In some circumstances, such as when a standby SRP module is removed, an LSR that has communicated to neighbors that it supports graceful restart might subsequently be unable to do so. In such cases, the neighbors receive no indication of that change in support unless you bounce the LDP sessions, for example by issuing the clear mpls ldp neighbor command.
Related
Documentation
•
Configuring LDP Graceful Restart on page 294
LDP-IGP Synchronization Overview
LDP is often used to establish MPLS LSPs throughout a complete network domain using an IGP such as OSPFv2 or IS-IS. In such a network, all links in the domain have IGP adjacencies as well as LDP adjacencies. LDP establishes the LSPs on the shortest path to a destination as determined by IP forwarding.
262 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
MPLS data packets can be discarded in these networks when the network IGP is operational on a link for which LDP is not fully operational, because there is no coupling between the LDP operational state and the IGP. When LDP is not fully operational, LDP is considered to not be synchronized with the IGP.
This issue is especially significant for applications such as a core network that does not employ BGP. Another example is an MPLS VPN where each given PE router depends on the availability of a complete MPLS forwarding path to the other PE routers for each VPN that it serves. This means that along the shortest path between the PE routers, each link must have an operational hello adjacency and an operational LDP session, and MPLS label bindings must have been exchanged over each session.
When LDP has not completed exchanging label bindings with an IGP next hop, traffic is discarded if the head end of the LSP forwards traffic because the LSP is assumed to be in place. The following are some examples of when this can happen.
•
When an LDP hello adjacency or an LDP session with a peer is lost due to some error while the IGP still points to that peer. IP forwarding of traffic continues on the IGP link associated with the LDP peer rather than being shifted to another IGP link with which
LDP is synchronized.
•
When a new IGP link comes up, causing the next hop to a certain destination to change in the IGP’s SPF calculations. Although the IGP might be up on the new link, LDP might not have completed label exchange for all the routes. This condition might be transient or due to a misconfiguration.
The LDP protocol is unable to indicate to a dependent service the availability of an uninterrupted LSP to the desired destination. LDP-IGP synchronization minimizes this disruption due to LDP not being operational on a link for which the IGP is operational.
When synchronization is in effect, the IGP advertises the maximum possible cost or metric for that link. If an alternative next hop exists for traffic, the IGP can choose that next hop for forwarding. If LDP is operational for that next hop, then no traffic is discarded.
The IGP does not advertise the original cost or metric for the link until either LDP label exchange has been completed with the peer on the link or a configured amount of time has passed (the holddown period).
With synchronization configured, LDP notifies the IGP to advertise the maximum cost for the link when one of the following triggering events takes place:
•
The LDP hello adjacency goes down.
• The LDP session goes down.
• LDP is configured on an interface.
If the holddown timer has been configured, the timer starts when the triggering event takes place. When the timer expires, LDP notifies the IGP to resume advertising the original cost.
If the holddown timer has not been configured, the IGP waits (endlessly) until bindings have been received from downstream routers for all the FECs that have a next hop on
Copyright © 2013, Juniper Networks, Inc.
263
JunosE 14.3.x BGP and MPLS Configuration Guide that interface. Only after that takes place does LDP notify the IGP to bring down the cost on the interface.
LDP-IGP synchronization is supported only for directly connected peers and links with the platform label space.
Synchronization Behavior During Graceful Restart
LDP-IGP synchronization does not take place while the IGP is in the process of a graceful restart. When the graceful restart completes, links for which synchronization has been configured are advertised with maximum metrics in either of the following cases:
•
LDP is not yet operational on the link and no holddown timer has been configured.
•
The configured holddown timer has not expired.
During LDP graceful restart, no synchronization operations are done. If the LDP graceful restart is terminated, LDP notifies the IGPs to advertise the links with the maximum metric.
Synchronization Behavior on LAN Interfaces
LDP-IGP synchronization does not take place on LAN interfaces unless the IGP has a point-to-point connection over the LAN configured on the interface. The reason for this is that multiple LDP peers might be connected on such an interface unless a point-to-point connection to a single peer has been configured. Because synchronization raises the cost on the interface high enough to prevent traffic being forwarded to that link, if multiple peers are connected, the cost is raised on all the peers even though LDP might be unsynchronized with only one of the peers. Consequently, traffic is diverted away from all the peers, an undesirable situation.
Synchronization Behavior on IGP Passive Interfaces
On IGP passive interfaces, the link cost is not raised when LDP-IGP synchronization is configured and a triggering event occurs.
Synchronization and TE Metrics
When traffic engineering is configured for an IGP, LDP-IGP synchronization does not affect the traffic engineering metric advertised for the link, regardless of whether the TE metric is explicitly configured or the default value.
Related
Documentation
•
Configuring LDP-IGP Synchronization on page 295
Use of RSVP-TE Hello Messages to Determine Peer Reachability
RSVP-TE hello messages enable the router to detect when an RSVP-TE peer is no longer reachable. When the router makes this determination, all LSPs that traverse that neighbor are torn down. Hello messages are optional and can be ignored safely by peers that are not configured to use the feature.
264 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
When you enable the hello feature on a virtual router or interface configured with
RSVP-TE, that RSVP-TE node periodically sends a unicast hello message to each neighbor with which the node has established an LSP. The exchange of hello messages between the peers establishes a hello adjacency. You can configure the hello interval to establish how frequently the node sends hello messages. Hello messages are exchanged when an LSP is set up and are stopped when the last LSP between the two peers goes away.
You can use the hello feature to reduce the impact of RSVP-TE on system resources.
Because a hello timeout is treated as a link failure, RSVP-TE can use the hello timeout instead of path and resv timeouts to determine when to bring down an LSP. High RSVP-TE refresh values reduce the amount of control traffic (and CPU cycles) needed by RSVP-TE to refresh LSP state across the network, thus reducing the impact of RSVP-TE on system resources.
Hello Message Objects
Hello messages can contain a hello request object or a hello ack object. These objects provide a way to request an instance value from a peer and to provide an instance value to a peer. Hello requests are sent to establish and confirm an adjacency with a peer. Hello acks are sent in response to hello requests. However, a hello adjacency peer can treat a hello request as an implicit response to its own request, thus reducing the amount of polling that needs to be done for efficient failure detection.
Hello Message Instances
Each object includes a source instance and a destination instance. The sender generates the source instance for its relationship with the receiver. The value of the source instance is unique for each peer. A given source instance value does not change while the two peers are successfully exchanging hello messages.
The destination instance is simply the source instance value that an RSVP-TE node has most recently received from its peer. If the node has never received a hello message from that peer, then it sets the destination instance value to zero.
Hello adjacency peers monitor the source instance sent by their neighbors. When a peer detects that the value has changed or that its neighbor does not properly report the source instance that the peer transmitted, then the peer treats that neighbor as if it has reset. In these cases, the local peer changes the instance value that it advertises to the neighbor.
Sequence of Hello Message Exchange
When a peer receives a hello message with a hello request object, the receiver generates a hello message with a hello ack object. If the receiver has never received a hello from the sender and the source instance is nonzero, then the receiver updates the destination instance that it sends in response with this new value. When the original sender first receives a hello ack from the peer in response to the hello request, the sender updates the destination instance that it sends in the subsequent hello request with the nonzero source instance it receives in the hello ack.
Consider the following example. An LSP has been established between peers A and B.
These adjacent peers have not yet exchanged hello messages.
Copyright © 2013, Juniper Networks, Inc.
265
JunosE 14.3.x BGP and MPLS Configuration Guide
1.
Peer A sends a hello request to Peer B. The request object contains the following:
• Source instance = 5 (generated by Peer A for this adjacency)
• Destination instance = 0 (because it has never exchanged messages with Peer B)
2.
Peer B receives the hello request and sends a hello ack to Peer A. The ack object contains the following:
•
Source instance = 8 (generated by Peer B for this adjacency)
• Destination instance = 5 (because that is what Peer B detected in the source instance from peer A)
3.
Peer A receives the hello ack and sends another hello request to peer B. The request object contains the following:
•
Source instance = 5 (generated by Peer A for this adjacency)
• Destination instance = 8 (the source instance generated by Peer B for this adjacency)
The two peers continue exchanging hello messages until the LSP is torn down. The following is true for these message exchanges unless a peer resets:
• Peer A always sends source instance= 5 and destination instance= 8 to Peer B.
• Peer B always sends instance= 8 and destination instance= 5 to Peer A.
Determination That a Peer Has Reset
After the initial exchange of hello messages, both peers perform checks on the messages they receive to determine whether the peer has reset.
Behavior of the Requesting Peer
The requesting peer examines the ack messages it receives. It compares the source instance in each subsequent ack message with the previous value. If the value differs or is set to zero, then the requesting peer treats the acknowledging peer as if communication has been lost.
The requesting peer also determines whether the acknowledging peer is reflecting back the requesting peer’s source instance. If the acknowledging peer advertises a wrong value in the destination instance field of the ack message, then the requesting peer treats the acknowledging peer as if communication has been lost.
Behavior of the Acknowledging Peer
The acknowledging peer examines the request messages it receives. It compares the source instance in each subsequent request message with the previous value. If the value differs or is set to zero, then the acknowledging peer treats the requesting peer as if communication has been lost.
The acknowledging peer also determines whether the requesting peer is reflecting back the acknowledging peer’s source instance. It compares the destination instance value in each request message with the source instance value that it most recently advertised
266 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview to the requesting peer. If the requesting peer advertises a wrong value in the destination instance field of the request message, then the acknowledging peer treats the requesting peer as if communication has been lost.
Behavior of Both Peers
When no hello messages are received from a peer within the configured hello interval, the peer is treated as if communication has been lost.
When a peer determines that communication has been lost, it can reinitiate the sending of hello messages. In this case, the peer generates a new source instance different than the one it previously used for communication with its peer.
Related
Documentation
•
Configuring RSVP-TE Hello Messages to Determine Peer Reachability on page 302
RSVP-TE Graceful Restart Overview
RSVP-TE graceful restart enables routers to maintain MPLS forwarding state when a link or node failure occurs. In a link failure, control communication is lost between two nodes, but the nodes do not lose their control or forwarding state.
A node failure occurs when the LSR has a failure in the RSVP-TE control plane, but not in the data plane. The LSR maintains its data forwarding state. Traffic can continue to be forwarded while RSVP-TE restarts and recovers. The graceful restart feature supports the restoration and resynchronization of RSVP-TE states and MPLS forwarding state between the restarting router and its RSVP-TE peers during the graceful restart recovery period.
The RSVP-TE graceful restart feature enables an LSR to gracefully restart, to act as a graceful restart helper node for a neighboring router that is restarting, or both.
Announcement of the Graceful Restart Capability
LSRs use the RSVP-TE hello mechanism to announce their graceful restart capabilities to their peer RSVP-TE routers. Both restarting LSRs and helper LSRs include the restart_cap object in hello requests and hello acks. The restart_cap object specifies both the graceful restart time and the graceful restart recovery time:
• restart time—The sum of how long it takes the sender to restart RSVP-TE after a control plane failure plus how long it takes to reestablish hello communication with the neighboring RSVP-TE routers.
• recovery time—The period within which you want neighboring routers to resynchronize with the sending router’s RSVP-TE state and MPLS forwarding state after the peers have re-established hello communication. The restarting LSR advertises the configured or default recovery time only while the graceful restart is in progress. When the LSR is not currently restarting or when it is incapable of preserving its MPLS forwarding state during the restart, the LSR advertises a recovery time of zero.
Both the restarting router and neighboring GR helper routers save the restart and recovery times that they receive from their peers.
Copyright © 2013, Juniper Networks, Inc.
267
JunosE 14.3.x BGP and MPLS Configuration Guide
Restarting Behavior
When the control plane fails, the LSR stops sending hello messages to its RSVP-TE neighbors. However, as a restarting router the LSR can continue to forward MPLS traffic because it preserves its MPLS forwarding state during the restart. When RSVP-TE comes back up, the restarted router sends the first hello message to its neighbors with a new source instance value to indicate that it had a control plane failure. The destination instance value in the hello message is set to zero. The recovery time included in this hello message is set to zero only if the router was unable to preserve the MPLS forwarding state or to support control state recovery.
When a neighboring router that has been configured as a graceful restart helper determines that the number of continuous missing hellos has reached the configured hello miss limit, it declares the router to be down. The helper router then waits for a period equal to the restart time that it received from the router and stored before the failure.
During this period, the helper router preserves the restarting router's RSVP-TE state and
MPLS forwarding state for the established LSPs and keeps forwarding MPLS traffic.
However, the helper router suspends the refreshing of path and resv state to the restarting router. The helper router keeps sending hello messages to the restarting router with an unchanged source instance value and a destination instance value set to zero. The helper router removes the RSVP-TE state for any LSP that was in the process of being established when the neighbor was declared to be down.
If the helper router does not receive a hello message from the restarting router during the restart period, the helper router immediately exits the recovery procedure and cleans up the states associated with the restarting router. The helper router determines that the failed neighbor has restarted when it finds a new source instance in the neighbor's hello message. When a nonzero recovery time is received in that hello message, the helper router determines that the restarted neighbor supports state recovery. The helper router then starts the recovery procedures. However, if the recovery time specified in the hello message is zero, then the helper router exits the recovery procedure and cleans up the states associated with the restarting router.
Recovery Behavior
In the recovery period, neighboring helper routers and the restarting router resynchronize the RSVP-TE state and MPLS forwarding state. During this period, MPLS traffic continues to be forwarded.
The helper router starts the recovery procedure by marking as stale the RSVP-TE state associated with the restarting router. The upstream helper router then refreshes all the path messages shared with the downstream restarting router. The upstream helper router includes the recovery_label object in the path message to the downstream restarting router for the label binding information that the restarting router specified before the restart. The downstream helper router does not refresh the reservation state control block (RSB) shared with the restarting router until a corresponding path message is received from the restarting router.
During the recovery period, the restarting router checks for the state associated with an incoming path message. If the RSVP-TE state already exists, the restarting router handles
268 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview the path message as usual. Otherwise, the restarting router examines the path message for the recovery_label object. If the recovery_label object is not found, the restarting router treats the path message as a setup request for a new LSP and handles the path message as usual.
If the recovery_label object is found, the restarting router searches for the outgoing label based on the incoming interface and incoming label that are specified in the recovery_label object. If the restarting router does not find a match for the forwarding entry, the restarting router treats the path message as a setup request for a new LSP. If the restarting router finds a match, it conveys to the downstream neighbors the outgoing label associated with the forwarding entry in the suggested_label object in the path message and it continues normal operations.
The helper router removes the stale flag for the RSVP-TE state when it receives the corresponding state in path or resv messages sent by the restarting router. When the recovery period expires, the helper router deletes any RSVP-TE states that still have a stale flag. Graceful restart is considered to be complete when the recovery period expires or when the last LSP needing recovery is recovered.
Preservation of an Established LSP Label
Labels used for an established LSP are preserved through the graceful restart by means of the recovery_label object and the suggested_label object in the path messages. The recovery_label object conveys the incoming label of the restarting LSR that the restarting
LSR passed to the upstream helper before the restart. The suggested_label object includes the outgoing label that the restarting LSR used before the restart. The suggested_label object conveys the outgoing label from the restarting LSR to its downstream neighbor.
Related
Documentation
•
Configuring RSVP-TE Graceful Restart on page 303
RSVP-TE Hellos Based on Node IDs Overview
For interoperability with routers that cannot support RSVP-TE graceful restart with link-based hellos, you can use the mpls rsvp signaling node-hello command to configure the exchange of node-ID–based RSVP-TE hellos (node hellos). E Series routers use node hellos only to support their graceful restart capabilities.
NOTE: Node hellos are not required for RSVP-TE graceful restart support between routers running JunosE Software or for interoperability with routers running Junos OS.
Graceful restart must be enabled for node hellos to advertise graceful restart. Link-based hellos are not required for graceful restart when you have configured node hellos. However, you might still use link-based hellos to monitor RSVP-TE links and detect link failures.
The node hello sessions are established by the exchange of hello messages in which node IDs are used for the source and destination addresses in the hello packets. The
Copyright © 2013, Juniper Networks, Inc.
269
JunosE 14.3.x BGP and MPLS Configuration Guide sending router uses its local node ID as the source address and the remote node ID of the receiving router as the destination address.
RSVP-TE uses the configured IGP, IS-IS or OSPF, to learn the local and remote node IDs.
In IS-IS, the node ID is the TE router ID as defined in the traffic engineering router ID TLV for IPv4 addresses and in the IPv6 TE Router_ID for IPv6 addresses. In OSPF, the node
ID is the TE router ID as defined in the router address TLV for IPv4 addresses and in the
Router_IPv6_Address for IPv6 addresses. Only one node-based RSVP-TE hello session can be established for each instance of an IGP adjacency with a peer.
When a router receives a hello message where the destination address is set to the receiving router’s local node ID, the router verifies that the node ID is the ID that the IGP advertises. This router must then use its local node ID as the source address when it replies to the sending router.
Node-based hellos are an attractive alternative to link-based hellos for graceful restart when you use bidirectional forwarding detection (BFD) for link monitoring and you have configured node-based hellos on all RSVP-TE peers.
Link-based RSVP-TE hellos are used for monitoring RSVP-TE adjacencies with neighboring routers and for providing RSVP-TE graceful restart. However, the BFD protocol is more effective at monitoring RSVP-TE adjacencies than are link-based hellos.
Link-based RSVP-TE hellos for graceful restart are more resource-intensive option than node-based RSVP-TE hellos when your configuration has several interfaces enabled with MPLS RSVP-TE and carrying RSVP-TE data traffic. Link-based hellos generate a volume of network traffic and processing overhead that is directly proportional to the number of interfaces that are carrying active RSVP-TE tunnels.
Node-based hellos require less messaging and processing overhead in these circumstances. Node hellos require only a single hello session between the two node IDs, compared to link-based hellos that have hello sessions between all interface pairs. Less traffic and overhead result in a lesser impact on scaling.
Node-based hellos can therefore be advantageous even when you are interoperating with routers that are running JunosE Software or Junos OS, if you are using BFD to monitor your RSVP-TE links. If you are not using BFD, then you must use link-based hellos for link monitoring, and link-based hellos then become more practical for graceful restart.
Related
Documentation
•
Configuring RSVP-TE Hellos Based on Node IDs on page 304
BFD Protocol and RSVP-TE Overview
The Bidirectional Forwarding Detection (BFD) protocol uses control packets and shorter detection time limits to more rapidly detect failures in a network. Also, because they are adjustable, you can modify the BFD timers for more or less aggressive failure detection.
Without BFD, RSVP-TE can learn about adjacency failures by either of two methods. If
RSVP-TE hellos are configured, then hello message timeouts indicate a failure. If hellos are not configured, then RSVP-TE learns about failures from resv and path messages.
270 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
When a BFD session exists between RSVP-TE peers, a peer that goes down is detected quickly, enabling faster rerouting of traffic. Adjacency failure detection by means of hello messages takes place on the order of seconds, whereas BFD fast failure detection can take place on the order of hundreds of milliseconds.
When you issue the mpls rsvp bfd-liveness-detection command on an RSVP-TE major interface, BFD liveness detection is established with all BFD-enabled RSVP-TE peers associated with that interface.
When an RSVP-TE session is established with the remote peer—if BFD is enabled and if the BFD session is not already present—then the local peer attempts to create a BFD session to the remote peer. The BFD session is established only if when both of the following are true:
• At least one RSVP-TE LSP exists between (passes through) a pair of directly connected
RSVP-TE major interfaces.
•
Both interfaces are BFD-enabled.
Consequently, when the last LSP is torn down between the interfaces, the BFD session is no longer required and is brought down as well.
Each adjacent pair of peers negotiates an acceptable transmit interval for BFD packets.
The negotiated value can be different on each peer. Each peer then calculates a BFD liveness detection interval. When a peer does not receive a BFD packet within the detection interval, it declares the BFD session to be down and purges all routes learned from the remote peer.
For general information about configuring and monitoring the BFD protocol, see JunosE
IP Services Configuration Guide.
Related
Documentation
•
Configuring the BFD Protocol for RSVP-TE on page 304
Tunneling Model for Differentiated Services Overview
The JunosE Software supports both the pipe model and the uniform model for tunneling with the mpls tunnel-model command. The router also provides a way to implement the functionality of the short pipe model for IP packets.
Pipe and Short Pipe Models
In the pipe and short pipe models, any traffic conditioning (that is, in a pure JunosE environment, a change in traffic class/color combination) that is applied when traffic goes through the tunnel has no effect on the EXP bits coding in the inner header. In other words, when traffic exits an LSP (when a label is popped) or when traffic enters an LSP, the inner header’s EXP bits coding is not changed.
The pipe and short pipe models differ in the header that the tunnel egress uses when it determines the PHB of an incoming packet. With the short pipe model, the tunnel egress uses an inner header that is used for forwarding. With the pipe model, the outermost label is always used. Because of this, you cannot use PHP with the pipe model.
Copyright © 2013, Juniper Networks, Inc.
271
JunosE 14.3.x BGP and MPLS Configuration Guide
The pipe model is the default JunosE behavior, which you can configure with the mpls tunnel-model command. You cannot configure the short pipe model with this command.
In fact, on ingress line modules the traffic class/color combination is always determined from the outermost label, so fabric queuing is also based on the outermost label. However, on the egress line module you can achieve the queuing behavior expected with the short pipe model by attaching IP policies to egress interfaces to reset the traffic class/color combinations based on the IP header. However, this method requires that the outgoing packets to be IP. If the outgoing packets are MPLS, then this short pipe model of queuing is not supported.
Uniform Model
The uniform model of tunneling renders MPLS transparent to the differentiated services operation. From the diff-serv perspective, it is as if MPLS is not used. In the uniform model, if traffic conditioning is applied somewhere along the LSP, the EXP bits of the inner header must be changed at the egress when the inner header becomes the outer header (because of the pop of the outer label).
To specify whether MPLS uses the pipe or uniform model of tunneling for differentiated services:
•
Issue the mpls tunnel-model command.
host1(config)#mpls tunnel-model uniform
For detailed information about QoS, see the JunosE Quality of Service Configuration Guide.
Related
Documentation
•
Configuring MPLS and Differentiated Services on page 308
•
Configuring the Tunneling Model for Differentiated Services on page 309
•
mpls tunnel-model
EXP Bits for Differentiated Services Overview
MPLS matches on the EXP bits for incoming traffic to set the traffic class/color combination, and sets the EXP bits for outgoing traffic based on the traffic class/color combination.
Incoming Traffic
For incoming MPLS traffic, the traffic class/color combination is set according to the EXP bits in the outermost label, either per the policy attached to the label or per the per-VR rules. The policy has precedence over the per-VR rules. Therefore, fabric queuing is always based on the outer label's EXP bits.
If the traffic is label-switched through the router, the EXP bits value associated with the incoming label that is used for switching—which can be either an outermost label or an inner label after popping one or more outer labels—is passed onto the egress line module.
This behavior enables the EXP bits value to be copied to outgoing labels, used to reset the traffic class/color combination on the egress module, or both.
272 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
Outgoing Traffic
Outgoing traffic is queued according to traffic class/color combinations. The applied combination can be the same as was set on the ingress line module, or it can be reset on the egress line module by egress IP policy.
illustrates how the initial value of the EXP bits is set for the first label pushed.
illustrates how the EXP bits can be changed for all labels, including the first label, by attached policies or per-VR EXP rules. The following section describes in detail how the EXP bits value is set for outgoing traffic.
Setting the EXP Bits for Outgoing Traffic
Different types of packets distributed into LSPs by the router have different default settings for the EXP bits. For IP packets, the EXP bits value is set to match the IP precedence value from the TOS field of the packet header. For non-IP packets, such as
Martini or VPLS packets, the EXP bits value is set to 000. You can use the mpls copy-upc-to-exp command to free the EXP bits value in IP packets from being tied to the IP precedence value. Instead, this command sets the EXP bits value to match the user packet class (UPC) value.
The IP precedence value can be copied back into the IP precedence field of the IP packet header at the LSP endpoint on the ingress line module. This action takes place only if the IP header is exposed after popping the MPLS labels and if the uniform tunnel model is employed. The remaining bits of the TOS field are not touched.
In contrast, when you issue mpls copy-upc-to-exp command, the EXP bits value is not copied to the UPC field at the LSP endpoint, because the UPC value might have been set by a lower layer policy for a different purpose.
NOTE: For control traffic originated from this router, if an attached per-LSP policy has rules to modify the EXP bits, or if per-VR EXP rules are configured, the EXP bits value copied from the IP precedence value might be overwritten incorrectly because the default traffic class/color combination for control traffic is best-effort/green. You can avoid this situation by establishing an outgoing IP policy that sets the traffic class/color combination for control traffic so that the policy or rules have the correct traffic class/color to work with.
If per-LSP policies are used or per-VR rules are configured, by default all labels pushed by the router for the same packet have the same EXP bits value. That value is determined by the policies or rules.
You can use the mpls preserve-vpn-exp command to specify that the EXP bits value for the VPN or Martini or VPLS label pushed by the router cannot be modified by either policy for outer labels or by per-VR rules. This capability is useful if you want the inner labels to have a different value for the EXP bits than do the outer labels. For example, in a VPN you might want the inner label’s EXP bits value to be the copied IP precedence
Copyright © 2013, Juniper Networks, Inc.
273
JunosE 14.3.x BGP and MPLS Configuration Guide value. You might want the base label’s EXP bits value set according to the mapping of
EXP bits to traffic class/color combination that is defined in your network.
Figure 59: Flow for Initial Setting of EXP Bits for the First Label Pushed
274
shows how packet type and configuration determine how the EXP bits are set for the first label pushed.
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview
Figure 60: Flow for Setting EXP Bits for All Pushed Labels
Related
Documentation
•
Configuring EXP Bits for Differentiated Services on page 309
•
Configuring MPLS and Differentiated Services on page 308
Point-to-Multipoint LSPs Overview
A point-to-multipoint MPLS LSP is an RSVP-TE LSP with a single ingress LSR and one or more egress LSRs. You can use point-to-multipoint LSPs to avoid unnecessary duplication of packets at the ingress router by allowing non-ingress LSRs to replicate the incoming data on one or more outgoing interfaces. Point-to-multipoint LSPs for multicast
VPNs are supported for intra-autonomous system (AS) environments (within an AS), but are not supported for inter-AS environments (between ASs).
Although you can use point-to-point LSPs to provide point-to-multipoint services, this type of configuration can cause data replication at the ingress LSR or duplicate traffic
Copyright © 2013, Juniper Networks, Inc.
275
JunosE 14.3.x BGP and MPLS Configuration Guide within the network. You can use the traffic engineering (TE) capability of LSPs to achieve consistent QoS control and efficient use of network resources, and create point-to-multipoint LSPs to deliver data from one ingress LSR to multiple egress LSRs.
The flow of traffic in a point-to-multipoint LSP is not restricted to the paths that are followed for multicast or shortest path routing; instead, you can explicitly configure the values to determine the path. Packet replication takes place only when packets are forwarded to two or more different destinations requiring different network paths.
A point-to-multipoint TE tunnel is composed of multiple point-to-multipoint LSPs. To scale to a large number of nodes or branches in a point-to-multipoint LSP, each LSP is uniquely identified by a point-to-multipoint ID, which is unique for the entire LSP, regardless of the number of branches or leaves it contains. A point-to-multipoint LSP is composed of multiple source-to-leaf sub-LSPs. These sub-LSPs are formed between the ingress and egress LSRs to form the point-to-multipoint LSP.
Point-to-multipoint LSPs can be signaled using one or more path messages. If a path message signals only one sub-LSP, it targets only one leaf in the point-to-multipoint tunnel. Because a single path message might not be large enough to contain all the sub-LSPs in the tunnel and also because you can create path messages specific to a sub-LSP in the tunnel, you can use multiple path messages. However, if you want to minimize the number of control messages required to configure a point-to-multipoint tunnel, you need to use a single path message to signal multiple sub-LSPs.
The following are some of the benefits of using point-to-multipoint LSPs:
• A point-to-multipoint LSP allows you to use MPLS TE for point-to-multipoint data distribution. This functionality provides better control over the path chosen to transmit traffic than that provided by IP multicast.
•
You can add and remove branch LSPs from a main point-to-multipoint LSP without disrupting traffic. The unaffected parts of the point-to-multipoint LSP continue to function normally.
•
You can enable link protection on a point-to-multipoint LSP. Link protection can provide a bypass LSP for each of the branch LSPs that make up the point-to-multipoint LSP.
If any of the primary paths fail, traffic can be quickly switched to the bypass path.
• You can configure branch LSPs statically, dynamically, or as a combination of static and dynamic LSPs.
•
You can enable graceful restart on point-to-multipoint LSPs.
Using E Series Routers as Egress LSRs
You can use E Series routers as egress LSRs in a point-to-multipoint LSP. To create a point-to-multipoint LSP and to use E Series routers as egress LSRs, no special configuration is required. The configuration that you made for point-to-point LSPs, which enables MPLS RSVP-TE on the interface that must signal an LSP in that virtual router context, is sufficient.
shows a point-to-multipoint LSP with multiple egress LSRs. The multicast source sends a packet to the ingress router, LSR 1, which in turn sends the
276 Copyright © 2013, Juniper Networks, Inc.
Chapter 3: MPLS Overview packet on the point-to-multipoint LSP to the branch router, LSR 2. The branch router,
LSR 2, is connected to another branch router, LSR 3. Here, LSR 3 is not directly connected to the ingress router, LSR 1, but only to the branch router, LSR 2. These branch routers, in turn, replicate the packet and forward it to E Series routers, LSRs 4 through 7, configured as egress LSRs.
The configuration shown in
is an example of an LSP that contains segments that run from ingress LSR to one or more branch and egress LSRs. For example, sub-LSPs exist between LSR 1 and LSR 2, and between LSR 2 and LSR 4. The sub-LSP between LSR 2 and LSR 4 is an egress sub-LSP that transmits the replicated packet from branch router, LSR 2, to egress E Series router, LSR 4. Egress LSRs can also be directly connected to the ingress LSR. In this figure, the connection between LSR 8 and LSR 1 is an example of this type.
NOTE: You cannot use E Series routers as core or ingress LSRs. You need to use Juniper Networks routers running Junos OS to function as core or ingress
LSRs in the point-to-multipoint LSP.
Figure 61: Simple MPLS Domain
Multicast source
Ingress router
LSR 1
Egress routers
Branch routers
Sub-LSP
LSR 4
LSR 2
LSR 5
LSR 6
LSR 3
LSR 7
LSR 8
Use the show mpls rsvp tunnels p2mp role tail command to view the status and configuration information for point-to-multipoint egress tunnels.
Related
Documentation
•
Monitoring Status and Configuration for MPLS Tunnels on page 375
•
Configuring Point-to-Multipoint LSPs on page 322
•
show mpls tunnels
Copyright © 2013, Juniper Networks, Inc.
277
JunosE 14.3.x BGP and MPLS Configuration Guide
278 Copyright © 2013, Juniper Networks, Inc.
CHAPTER 4
Configuring MPLS
This chapter describes how to configure Multiprotocol Label Switching (MPLS) on the router, and contains the following sections:
•
Basic MPLS Configuration Tasks on page 280
•
MPLS Global Configuration Tasks on page 281
•
LDP and RSVP-TE Interface Profile Configuration Tasks on page 284
•
MPLS Interface Configuration Tasks on page 285
•
MPLS Tunnel Configuration Tasks on page 287
•
MPLS Tunnel Profile Configuration Tasks on page 289
•
Configuring Explicit Routing for MPLS on page 290
•
Additional LDP Configuration Tasks on page 292
•
Configuring LDP FEC Deaggregation on page 292
•
Configuring LDP Graceful Restart on page 294
•
Configuring LDP Autoconfiguration on page 295
•
Configuring LDP-IGP Synchronization on page 295
•
Configuring LDP MD5 Authentication on page 296
•
Controlling LDP Label Distribution on page 297
•
Additional RSVP-TE Configuration Tasks on page 298
•
Configuring RSVP MD5 Authentication on page 298
•
Configuring RSVP-TE Fast Rerouting with RSVP-TE Bypass Tunnels on page 299
•
Configuring RSVP-TE Hello Messages to Determine Peer Reachability on page 302
•
Configuring RSVP-TE Graceful Restart on page 303
•
Configuring RSVP-TE Hellos Based on Node IDs on page 304
•
Configuring the BFD Protocol for RSVP-TE on page 304
•
Configuring IGPs and MPLS on page 306
•
Configuring MPLS and Differentiated Services on page 308
•
Configuring the Tunneling Model for Differentiated Services on page 309
•
Configuring EXP Bits for Differentiated Services on page 309
•
Example Differentiated Services Application and Configuration on page 310
Copyright © 2013, Juniper Networks, Inc.
279
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Classifying Traffic for Differentiated Services on page 313
•
Example Traffic Class Configuration for Differentiated Services on page 318
•
Configuring Point-to-Multipoint LSPs on page 322
Basic MPLS Configuration Tasks
Configuring an MPLS network includes a number of tasks:
To configure an MPLS network:
•
Configure settings common to all MPLS usage on a given LSR.
See
“MPLS Global Configuration Tasks” on page 281 .
• (Optional) Configure LDP or RSVP-TE interface profiles.
See
“LDP and RSVP-TE Interface Profile Configuration Tasks” on page 284 .
•
Configure each interface on an LSR that uses MPLS.
See
“MPLS Interface Configuration Tasks” on page 285
.
• Configure MPLS tunnels or topology-driven LSPs.
See
“MPLS Tunnel Configuration Tasks” on page 287
.
•
(Optional) Configure a profile that contains settings to be used by multiple MPLS tunnels.
See
“MPLS Tunnel Profile Configuration Tasks” on page 289
.
Many users find it convenient to configure MPLS by completing the tasks in each set of tasks before moving to the next set. However, you do not have to complete the tasks in the listed order. For example, you might perform all the pure MPLS tasks relevant to your network and then perform all the relevant LDP or RSVP-TE tasks.
The type of network you want to implement determines which sets of tasks you must complete, as indicated in
Table 55: Configuration Tasks by Type of Network
Task Set
Traffic Engineering
Network
Topology-Driven Network
(Best-Effort, Hop-by-Hop, LDP)
Global
Interface Profile
Yes
Optional
Yes
Optional
Interface
Tunnel
Tunnel Profile
Yes
Yes
Yes
Yes
No
No
280 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
In addition to the basic configuration tasks, you might need to perform other LDP or
RSVP-TE configuration tasks.
To configure LDP and RSVP-TE, depending on your network topology and needs:
•
Configure LDP features depending on your network design.
See
“Additional LDP Configuration Tasks” on page 292 .
• Configure RSVP-TE features depending on your network design.
See
“Additional RSVP-TE Configuration Tasks” on page 298
.
MPLS Global Configuration Tasks
Complete these tasks to configure a virtual router as an LSR. You perform these commands in Global Configuration mode. The following sequence is arbitrary; you can perform these tasks in any order.
Your choice of label distribution protocol determines whether the LDP or RSVP-TE global tasks are appropriate for your network design.
MPLS global configuration tasks include the following sets of tasks:
•
•
•
RSVP-TE Global Tasks on page 283
MPLS Global Tasks
In a typical network, you perform only the first task. You might also perform the optional configuration tasks, but typically do not need to do so.
1.
Enable MPLS on a virtual router.
host1(config)#mpls
2.
(Optional) Configure the time-to-live field placed in the MPLS header when a label is first added to an IP packet.
host1(config)#mpls ip propagate-ttl forwarded
3.
(Optional) Configure the tunneling model for differentiated services. See
MPLS and Differentiated Services” on page 308
for more information and command descriptions. host1(config)#mpls tunnel-model uniform
4.
(Optional) Specify whether to use the TOS value (the default condition) or the UPC value of the packet as the value of the EXP bits when the router acts as an LER.
host1(config)#mpls copy-upc-to-exp
5.
(Optional) Specify whether the EXP bits for VPN MPLS labels can be modified by EXP bit mapping or by policy for differentiated services.
host1(config)#mpls preserve-vpn-exp
Copyright © 2013, Juniper Networks, Inc.
281
JunosE 14.3.x BGP and MPLS Configuration Guide
6.
(Optional) Specify whether to create dynamic IP interfaces on top of MPLS major interfaces and optionally what profile to use for them. host1(config)#mpls create-dynamic-interfaces ip on-major-interfaces profile v4intf
LDP Global Tasks
Typically, you do not configure anything for LDP at the global level, but you can perform the following optional tasks.
1.
(Optional) Enable LDP and topology-driven LSP. Any LDP-related command creates
LDP implicitly, negating the need to issue this command.
host1(config)#mpls ldp
2.
(Optional) Configure the redistribution of IGP routes to LDP.
host1(config)#mpls ldp redistribute ospf route-map boston5
3.
(Optional) Configure a global LDP profile that specifies how long an LSR maintains link hello records before another link hello is sent, the interval between link hellos, or both.
host1(config)#mpls ldp interface profile ldp1 host1(config-ldp)#hello hold-time 55 host1(config-ldp)#hello interval 10
4.
(Optional) Configure lists of peer addresses that targeted hello messages are sent to or accepted from.
host1(config)#mpls ldp targeted-hello send list 10.21.5.87
host1(config)#mpls ldp targeted-hello receive list 192.168.45.25
NOTE: The mpls ldp targeted-hello receive list command is unnecessary if you configure the mpls ldp targeted-hello send list command.
5.
(Optional) Configure the hold time and interval values for targeted hello messages used in LDP extended discovery.
host1(config)#mpls ldp targeted-hello holdtime 90 host1(config)#mpls ldp targeted-hello interval 30
6.
(Optional) Configure LDP session retry values.
host1(config)#mpls ldp session retry-time 2 host1(config)#mpls ldp session retries 1800
7.
(Optional) Configure the period that LDP negotiates with its peer for which the LDP session is maintained in the absence of any LDP messages.
host1(config)#mpls ldp session holdtime 1800
8.
(Optional) Configure the interval at which LDP sends session keepalive messages.
host1(config)#mpls ldp session keepalive-time 180
9.
(Optional) Specify an IP address to be advertised to peers as the transport address in discovery hello messages.
282 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS host1(config)#mpls ldp discovery transport-address 192.168.34.2
10.
(Optional) Configure independent control as the method of label distribution that
LDP uses.
host1(config)#mpls ldp independent-control
11.
(Optional) Configure LDP to advertise the explicit null label or a non-null label for the egress router to achieve ultimate hop popping.
host1(config)#mpls ldp egress-label explicit-null
For topology-driven LSPs, perform the following LDP configuration tasks.
1.
(Optional) Configure the LSR to create topology-driven LSPs. Enabling LDP automatically creates topology-driven LSPs.
host1(config)#mpls topology-driven-lsp
2.
(Optional) Specify filters for the routes and peers to which the labels are advertised.
host1(config)#mpls ldp advertise-labels host-only
3.
(Optional) Specify the LSPs to be put into the IP routing table for forwarding plain IP traffic.
NOTE: This step is not optional if you are using a topology-driven network to forward plain IP packets.
host1(config)#ldp ip-forwarding host-only
4.
(Optional) Establish a policy governing the distribution of incoming LDP labels.
host1(config)#mpls ldp advertise-labels for boston1
5.
(Optional) Remove and then reestablish existing LDP LSPs and to restart topology-driven LDP. Use this command when you have modified or created policies or access lists (with the mpls ldp-ip-forwarding and mpls ldp advertise-labels commands) and want them to be applied to LDP LSPs that are already in an up state.
host1#clear mpls ldp
RSVP-TE Global Tasks
Typically, you do not configure anything for RSVP-TE at the global level, but you can perform the following optional tasks.
1.
(Optional) Enable RSVP-TE. Any RSVP-TE–related command creates RSVP-TE implicitly, negating the need to issue this command.
host1(config)#mpls rsvp
2.
(Optional) Configure a global RSVP-TE profile that specifies the timeout period in milliseconds between generation of RSVP refresh messages, the number of refresh messages that can be lost before the PATH or RESV state is ended, or both.
host1(config)#mpls rsvp interface profile rsvp4 host1(config-rsvp)#refresh-period 60000
Copyright © 2013, Juniper Networks, Inc.
283
JunosE 14.3.x BGP and MPLS Configuration Guide host1(config-rsvp)#cleanup-timeout-factor 9
3.
(Optional) Configure retry timer options globally (to apply to all tunnels) to set up an
LSP after a setup failure (a failure other than one due to no available route). Specify the number of attempts to be made to set up an RSVP-TE tunnel or the interval in seconds between attempts.
host1(config)#mpls lsp retries 35 host1(config)#mpls lsp retry-time 55
4.
(Optional) Configure retry timer options globally (to apply to all tunnels) to set up an
LSP after a failure due to no available route. Specify the number of attempts to be made to set up an RSVP-TE tunnel or the interval in seconds between attempts.
host1(config)#mpls lsp no-route retries 3200 host1(config)#mpls lsp no-route retry-time 45
5.
(Optional) Configure the interval at which the bandwidth values are flooded.
host1(config)#mpls traffic-eng link-management timers periodic-flooding 10
6.
(Optional) Configure reoptimization—the frequency at which MPLS searches for better paths for existing tunnels.
NOTE: Low timer values lead to frequent reoptimization of LSPs, which is undesirable for the following reasons:
•
Frequent changes to the LSPs increases packet loss.
•
Frequent reoptimization increases the load on the router, especially when the router acts as the LSP head end. The load is particularly noticeable in a scaled network, resulting in high CPU utilization on the router.
host1(config)#mpls reoptimize timers frequency 180
You can also force an immediate search for better paths for all existing LSPs.
host1#mpls reoptimize
7.
(Optional) Enable refresh reduction and message bundling.
host1(config)#mpls rsvp refresh-reduction host1(config)#mpls rsvp message-bundling
8.
(Optional) Configure the egress router to advertise the explicit null label.
host1(config)#mpls rsvp egress-label explicit-null
LDP and RSVP-TE Interface Profile Configuration Tasks
The interface profile configuration tasks are optional tasks you may need to perform to configure your network’s label distribution options.
284 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
LDP and RSVP-TE interface profile configuration tasks include the following sets of tasks:
•
LDP Interface Profile Configuration Tasks and Commands on page 285
•
RSVP-TE Interface Profile Configuration Tasks and Commands on page 285
LDP Interface Profile Configuration Tasks and Commands
Creating or accessing an LDP interface profile places the CLI in LDP Configuration mode.
1.
Access LDP profile configuration mode.
host1(config)#mpls ldp interface profile ldp5
2.
Configure LDP interface profile settings, changing the values from the implicit default values.
host1(config-ldp)#hello hold-time 30 host1(config-ldp)#hello interval 10
RSVP-TE Interface Profile Configuration Tasks and Commands
Creating or accessing an RSVP-TE interface profile places the CLI in RSVP Configuration mode. When you have completed the interface profile configuration tasks, you may want to proceed to the section
“MPLS Interface Configuration Tasks” on page 285
.
1.
Access the desired profile configuration mode.
host1(config)#mpls rsvp interface profile rsvp4
2.
Configure interface profile settings to define the RSVP tunnel timeout period by specifying the timeout period in milliseconds between generation of RSVP refresh messages, the number of refresh messages that can be lost before the PATH or RESV state is ended, or both.
host1(config-rsvp)#refresh-period 60000 host1(config-rsvp)#cleanup-timeout-factor 9
See
,
“RSVP-TE Messages and Sessions” on page 244
for more information about the RSVP tunnel timeout period.
MPLS Interface Configuration Tasks
These tasks are performed at the major interface over which you want to run MPLS.
Creating or accessing an interface places the CLI in Interface Configuration mode. You can then configure MPLS options on that interface. The following sequence is arbitrary; you can perform these tasks in any order.
NOTE: Loop detection is always enabled in the JunosE MPLS implementation.
Your choice of label distribution protocol determines whether the LDP or RSVP-TE interface configuration tasks are appropriate for your network design.
Copyright © 2013, Juniper Networks, Inc.
285
JunosE 14.3.x BGP and MPLS Configuration Guide
MPLS interface configuration tasks include the following sets of tasks:
•
MPLS Interface Tasks on page 286
•
LDP Interface Tasks on page 286
•
RSVP-TE Interface Tasks on page 286
MPLS Interface Tasks
To configure MPLS on the interface:
1.
Enable MPLS on the interface.
or host1(config-if)#mpls host1(config-if)#no mpls disable
2.
(Optional) Configure the interface label space with the VPI and VCI ranges.
host1(config-if)#mpls atm vpi range 10 200 host1(config-if)#mpls atm vci range 33 4000
Only ATM AAL5 interfaces support the interface label space. For MPLS interfaces using the interface label space, you must configure the both the VPI and VCI range. If you do not, the interface will remain operationally down.
3.
(Optional) Specify an interface for signaling for an MPLS major interface in the interface label space.
host1(config-if)#mpls signaling-interface atm 4/0.5
LDP Interface Tasks
To configure LDP on the interface:
1.
Start LDP on the interface.
•
Using the default values (an implicit default profile): host1(config-if)#mpls ldp
• Using a previously created profile: host1(config-if)#mpls ldp profile ldp5
2.
(Optional) Suppress transmission of link hello messages to all LSRs.
host1(config-if)#mpls ldp link-hello disable
RSVP-TE Interface Tasks
To configure RSVP-TE on the interface:
1.
Start RSVP-TE on the interface.
•
Using the default values (an implicit default profile): host1(config-if)#mpls rsvp
286 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
•
Using a previously created profile: host1(config-if)#mpls rsvp profile rsvp4
To disable RSVP-TE on the interface: host1(config-if)#mpls rsvp disable
2.
(Optional) Configure total bandwidth available on the interface.
host1(config-if)#bandwidth 262144
3.
(Optional) Configure total bandwidth reservable for MPLS on the interface.
host1(config-if)#mpls bandwidth 4096
4.
(Optional) Specify thresholds that trigger bandwidth flooding when crossed by an increase or decrease in the total reservable bandwidth.
host1(config-if)#mpls traffic-eng flood thresholds up 15 host1(config-if)#mpls traffic-eng flood thresholds down 15
5.
(Optional) Specify the resource attributes for the interface so that tunnels can discriminate among interfaces.
host1(config-if)#mpls traffic-eng attribute-flags 0x000001f9
6.
(Optional) Configure an administrative weight for the interface that overrides the weight assigned by the IGP.
host1(config-if)#mpls traffic-eng administrative-weight 25
MPLS Tunnel Configuration Tasks
Complete the following tasks to configure a tunnel interface. Configure the tunnel endpoint last; anything configured after the tunnel endpoint does not take effect until the tunnel is brought up the next time. You can perform all other tasks in any order.
NOTE: Tunnel configuration tasks are relevant only for traffic engineering networks.
1.
Create the MPLS tunnel interface.
host1(config)#interface tunnel mpls:boston
2.
(Optional) Configure the LSP to announce its endpoint to an IGP (sometimes referred to as registering the endpoint).
host1(config-if)#tunnel mpls autoroute announce isis
3.
(Optional) Specify a tunnel metric to be used by an IGP in its SPF calculation.
host1(config-if)#tunnel mpls autoroute metric absolute 100
4.
(Optional) Configure the path options used for the tunnel.
host1(config-if)#tunnel mpls path-option 3 dynamic isis
5.
(Optional) Configure the bandwidth required for the tunnel.
Copyright © 2013, Juniper Networks, Inc.
287
JunosE 14.3.x BGP and MPLS Configuration Guide
288 host1(config-if)#tunnel mpls bandwidth 1240
6.
(Optional) Configure preemption hold or setup priority.
host1(config-if)#tunnel mpls traffic-eng priority 4 4
7.
(Optional) Configure resource class affinity.
host1(config-if)#tunnel mpls traffic-eng affinity 0x000C3000 0xFFFFFFFC
This example of a masked affinity matches only links configured with attribute flags from 0x000C3000 to 0x000C3003.
8.
(Optional) Configure retry timer options to apply to a specific tunnel to set up an LSP after a route or setup failure.
host1(config-if)#tunnel mpls no-route retries 100 host1(config-if)#tunnel mpls no-route retry-time 45 host1(config-if)#tunnel mpls retries 250 host1(config-if)#tunnel mpls retry-time 65
9.
(Optional) Associate a text description with the tunnel.
host1(config-if)#tunnel mpls description southshore
10.
Configure the tunnel endpoint.
host1(config-if)#tunnel destination 10.12.21.5
Related
Documentation
•
MPLS Global Configuration Tasks on page 281
•
MPLS Interface Configuration Tasks on page 285
•
MPLS Tunnel Profile Configuration Tasks on page 289
•
Additional LDP Configuration Tasks on page 292
•
Additional RSVP-TE Configuration Tasks on page 298
•
interface tunnel
•
tunnel destination
•
tunnel mpls affinity
•
tunnel mpls autoroute announce
•
tunnel mpls autoroute metric
•
tunnel mpls bandwidth
•
tunnel mpls description
•
tunnel mpls no-route retries
•
tunnel mpls no-route retry-time
•
tunnel mpls path-option
•
tunnel mpls priority
•
tunnel mpls retries
•
tunnel mpls retry-time
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
MPLS Tunnel Profile Configuration Tasks
If you anticipate having multiple tunnels to share the same configuration, you can reduce your configuration time by using tunnel profiles to configure your tunnels.
In the profile, configure the tunnel endpoint last; anything configured after the tunnel endpoint does not take effect until the tunnel is brought up the next time. You can perform all other tasks in any order.
NOTE: Tunnel profile configuration tasks are relevant only for traffic engineering networks.
To configure a tunnel profile:
1.
Create an MPLS tunnel profile and enter Tunnel Profile Configuration mode.
host1(config)#mpls tunnels profile Lisbon
2.
(Optional) Configure the LSP to announce its endpoint to an IGP.
host1(config-tunnelprofile)#tunnel mpls autoroute announce isis
3.
(Optional) Specify a tunnel metric to be used by an IGP in its SPF calculation.
host1(config-tunnelprofile)#tunnel mpls autoroute metric absolute 100
4.
(Optional) Configure the path options used for the tunnel.
host1(config-tunnelprofile)#tunnel mpls path-option 3 dynamic isis
5.
(Optional) Configure the bandwidth required for the tunnel.
host1(config-tunnelprofile)#tunnel mpls bandwidth 1240
6.
(Optional) Configure preemption hold or setup priority.
host1(config-tunnelprofile)#tunnel mpls priority 4 4
7.
(Optional) Configure resource class affinity..
host1(config-tunnelprofile)#tunnel mpls affinity 0x1100 mask 0xFFFF
8.
(Optional) Configure retry timers options to apply to a specific tunnel to set up an
LSP after a route or setup failure.
host1(config-tunnelprofile)#tunnel mpls no-route retries 100 host1(config-tunnelprofile)#tunnel mpls no-route retry-time 45 host1(config-tunnelprofile)#tunnel mpls retries 250 host1(config-tunnelprofile)#tunnel mpls retry-time 65
9.
(Optional) Associate a text description with the tunnel.
host1(config-tunnelprofile)#tunnel mpls description southshore
10.
Configure the tunnel endpoint.
• For static tunnels host1(config-tunnelprofile)#tunnel destination 10.1.2.5 10.1.2.6
Copyright © 2013, Juniper Networks, Inc.
289
JunosE 14.3.x BGP and MPLS Configuration Guide
All tunnels to the specified destination(s) are configured with the profile settings.
• For dynamic tunnels host1(config-tunnelprofile)#tunnel destination isis-level-2 access-list madrid3
When an endpoint is dynamically learned from the specified routing protocol, MPLS searches its tunnel profiles for a match. The dynamic tunnel is established using the settings from the first matching profile.
Related
Documentation
•
MPLS Global Configuration Tasks on page 281
•
MPLS Interface Configuration Tasks on page 285
•
MPLS Tunnel Configuration Tasks on page 287
•
Additional LDP Configuration Tasks on page 292
•
Additional RSVP-TE Configuration Tasks on page 298
•
mpls tunnels profile
•
tunnel destination
•
tunnel mpls affinity
•
tunnel mpls autoroute announce
•
tunnel mpls autoroute metric
•
tunnel mpls bandwidth
•
tunnel mpls description
•
tunnel mpls no-route retries
•
tunnel mpls no-route retry-time
•
tunnel mpls path-option
•
tunnel mpls priority
•
tunnel mpls retries
•
tunnel mpls retry-time
Configuring Explicit Routing for MPLS
When you configure explicit routing rather than hop-by-hop routing for MPLS, the route the LSP takes is defined by the ingress node. The path consists of a series of hops defined by the ingress LSR. Each hop can be a traditional interface, an autonomous system, or an LSP.
MPLS explicit routing configuration tasks include the following sets of tasks:
•
Defining Configured Explicit Paths on page 291
•
Specifying Configured Explicit Paths on a Tunnel on page 291
•
Configuring Dynamic Explicit Paths on a Tunnel on page 291
290 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
Defining Configured Explicit Paths
You can create explicit routing paths manually by configuring an explicit path with a name and a series of addresses (hops) from ingress to egress.
To manually configure explicit routing:
1.
Define an explicit path and access Explicit Path Configuration mode.
host1(config)#mpls explicit-path name xyz host1(config-expl-path)#
2.
Do one of the following to configure the hops in the LSP:
• Set the next hop (if need be) at a particular index in the explicit path.
host1(config-expl-path)#index 5 next-address 172.18.100.5
•
Add the next hop (if need be) after a particular index in the explicit path.
host1(config-expl-path)#append-after 5 next-address 192.168.47.22
3.
Configure a next hop at the end of the MPLS explicit path.
host1(config-expl-path)#next-address 10.10.9.2
4.
Enable the explicit path.
host1(config)#mpls explicit-path name xyz
NOTE: To prevent a partially configured explicit path from being used, do not enable it until you have finished configuring or modifying the path.
5.
(Optional) List the currently configured explicit path.
host1(config-expl-path)#list 5
Specifying Configured Explicit Paths on a Tunnel
After you have defined a configured explicit path, you can configure the path on a tunnel.
To configure explicit routing on a tunnel:
1.
Create an MPLS tunnel.
host1(config)#interface tunnel mpls:1
2.
Set the path option.
host1(config-if)#tunnel mpls path-option 1 explicit name xyz
Configuring Dynamic Explicit Paths on a Tunnel
You can create explicit routing paths dynamically with a routing protocol. IS-IS and OSPF both currently support explicit routing.
To configure dynamic explicit routing:
Copyright © 2013, Juniper Networks, Inc.
291
JunosE 14.3.x BGP and MPLS Configuration Guide
1.
Create an MPLS tunnel.
host1(config)#interface tunnel mpls:bilbao5
2.
Set the path option.
host1(config-if)#tunnel mpls path-option 2 dynamic isis
NOTE: If you configure the MPLS RSVP-TE tunnels to dynamically calculate the explicit path for the tunnels and if a router link-state advertisement (LSA) sends a metric of 65535 for one of the neighbors that is being considered while the Constrained Shortest Path First (CSPF) computation is performed, the metric that is sent in the router LSA is used in the CSPF calculation.
Processing the router LSA by the CSPF algorithm ensures that the MPLS
RSVP-TE tunnels are not retained in the down state and the tunnels come up properly.
Additional LDP Configuration Tasks
Several of the LDP configuration tasks are optional, and depend on your network topology and needs.
Tasks to configure LDP settings include:
• Configure LDP FEC deaggregation depending on your network design.
See
“Configuring LDP FEC Deaggregation” on page 292 .
•
Configure the LDP graceful restart mechanism depending on your network design.
See
“Configuring LDP Graceful Restart” on page 294
.
• Configure LDP autoconfiguration depending on your network design.
See
“Configuring LDP Autoconfiguration” on page 295
.
•
Configure LDP-IGP synchronization depending on your network design.
See
“Configuring LDP-IGP Synchronization” on page 295
.
• Configure LDP MD5 authentication depending on your network design.
See
“Configuring LDP MD5 Authentication” on page 296 .
•
Create a filter that determines whether and where LDP labels are distributed depending on your network design.
See
“Controlling LDP Label Distribution” on page 297
.
Configuring LDP FEC Deaggregation
Beginning with JunosE Release 8.1.0, LDP routers running JunosE Software employ LDP
FEC aggregation by default. FEC aggregation means that when an LDP egress router advertises multiple prefixes, all the prefixes are members of the same FEC. Only a single
292 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS label is advertised for this FEC. LDP maintains this aggregation as the advertisement traverses the network, if possible.
Consider the topology shown in
Figure 62: FEC Aggregation and Equal-Cost Paths
In this example, LSR 2 uses FEC aggregation, but LSR 3 does not. Consequently, LSR 2 advertises the single label e, mapped to a FEC that includes both prefixes, 10.10.22.0/24 and 10.43.12.0/24.
In contrast, LSR 3 has two FECs, one for 10.10.22.0/24 and one for 10.43.12.0/24. A separate label is bound to each FEC. LSR 3 advertises label h for one FEC and label w for the other FEC.
LSR 2 and LSR 3 are downstream routers for LSR 1. LSR 1 does not aggregate. Instead,
LSR 1 advertises label d for 10.10.22.0/24 and label x for 10.43.12.0/24.
To configure MPLS LDP FEC deaggregation to bind each prefix on the current virtual router to a separate label:
• Issue the mpls ldp deaggregate command: host1(config)#mpls ldp deaggregate
If you configure MPLS LDP FEC deaggregation to bind a separate label to each prefix on a virtual router, the default behavior is for the LDP egress router to advertise the implicit null label in the label mapping message that it sends to its upstream neighbor. If multiple labels are configured for the LDP egress router and FEC aggregation is configured, when you modify the label advertisement method to be FEC deaggregation, the egress router advertises the implicit null label and does not use separate labels with each prefix. With
FEC deaggregation configured, the egress router's upstream neighbor performs a penultimate hop pop (PHP) and the implicit null label never appears in the encapsulation.
If you configure MPLS LDP FEC deaggregation, the default advertised label is label 3
(implicit null label). In such a scenario, the penultimate-hop router removes the label and sends the packet to the egress router.
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional LDP Configuration Tasks on page 292
•
mpls ldp deaggregate
Copyright © 2013, Juniper Networks, Inc.
293
JunosE 14.3.x BGP and MPLS Configuration Guide
Configuring LDP Graceful Restart
The graceful restart mechanism minimizes the negative effect on MPLS forwarding across an LSR restart by enabling neighbors to wait for the LSR to restart and causing the LSR itself to restart gracefully.
NOTE: Successful operation of LDP graceful restart requires that stateful
SRP switchover (high availability) be configured on the router. Although you can configure LDP graceful restart if stateful SRP switchover is not configured on the router, the graceful restart capability will not function.
To configure LDP graceful restart:
1.
Enable LDP graceful restart and graceful restart helper mode.
host1(config)#mpls ldp graceful-restart
2.
(Optional) Specify the length of time you want the neighbors to wait for the gracefully restarting router to resume sending LDP messages to neighbors after the LDP connection between them fails.
host1(config)#mpls ldp graceful-restart reconnect-time 130
3.
(Optional) Specify the length of time the router retains its MPLS forwarding state across a restart.
host1(config)#mpls ldp graceful-restart recovery-time 150
4.
(Optional) Specify the maximum length of time that the router waits for a neighbor to complete a graceful LDP restart after the LDP session is reestablished.
host1(config)#mpls ldp graceful-restart timers max-recovery 150
5.
(Optional) Specify the length of time the router waits for a neighbor to reestablish the LDP session.
host1(config)#mpls ldp graceful-restart timers neighbor-liveness 150
NOTE: For information about configuring hold timers for LDP graceful restart in scaled environments, see the Configuring Hold Timers for Successful Graceful
Restart in Scaled Scenarios section in the JunosE BGP and MPLS Configuration
Guide
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional LDP Configuration Tasks on page 292
•
mpls ldp graceful-restart
•
mpls ldp graceful-restart reconnect-time
•
mpls ldp graceful-restart recovery-time
294 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
•
mpls ldp graceful-restart timers max-recovery
•
mpls ldp graceful-restart timers neighbor-liveness
Configuring LDP Autoconfiguration
LDP autoconfiguration enables you to ensure that LDP is configured on all interfaces running the IGP (IS-IS or OSPFv2). Using this command prevents you from having to configure LDP individually on each interface in the IGP. You can prevent LDP from being enabled on selected interfaces by issuing the no mpls ldp autoconfig command on the interface.
When autoconfiguration is enabled for IS-IS, you can specify whether LDP is automatically configured on all IS-IS interfaces in the virtual router or just the interfaces in a particular
IS-IS level. When autoconfiguration is enabled for OSPF, you can specify whether LDP is automatically configured on all OSPF interfaces in the virtual router or just the interfaces in a particular OSPF area.
To configure LDP autoconfiguration to ensure that LDP is configured on all interfaces running the IGP:
•
Specify whether LDP is created automatically on the current interface or all interfaces:
•
Create LDP on all interfaces in the IGP router context host1(config)#router ospf 1 host1(config-router)#mpls ldp autoconfig area 1
• Create LDP on the current interface host1(config)#interface atm 2/0 host1(config-if)#mpls ldp isis autoconfig
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional LDP Configuration Tasks on page 292
•
mpls ldp autoconfig
Configuring LDP-IGP Synchronization
MPLS data packets can be discarded in a network when the network IGP is operational on a link for which LDP is not fully operational, because there is no coupling between the
LDP operational state and the IGP. When LDP is not fully operational, LDP is considered to not be synchronized with the IGP.
To configure LDP-IGP synchronization:
1.
Specify whether LDP is synchronized with the IGP on the current interface or all interfaces.
•
Synchronize LDP with the IGP on the current interface:
Copyright © 2013, Juniper Networks, Inc.
295
JunosE 14.3.x BGP and MPLS Configuration Guide host1(config)#interface atm 2/0 host1(config-if)#mpls ldp isis sync
•
Synchronize LDP with the IGP on all interfaces in the IGP router context: host1(config)#router ospf 1 host1(config-router)#mpls ldp ospf sync
2.
Specify how long the IGP waits to synchronize with LDP.
host1(config)#mpls ldp igp sync holddown 15
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional LDP Configuration Tasks on page 292
•
mpls ldp igp sync holddown
•
mpls ldp sync
Configuring LDP MD5 Authentication
LDP MD5 authentication provides protection against spoofed TCP segments that can be introduced into the connection streams for LDP sessions. Authentication is configurable for both directly connected and targeted peers.
You configure a shared secret (password) on potential LDP peers. Any given pair of peers must share the same password. When a peer sends a TCP segment to an LSR, it uses the password and the segment to compute an MD5 digest that it sends along with the segment.
When the LSR receives the segment, the LSR calculates its own version of the digest using its instance of the password and the segment. The LSR validates the segment if the local digest matches the received digest. If the comparison fails—for example, if the password is not configured the same on both peers—the LSR drops the segment and does not send a response to the peer.
You can optionally enable a strict authentication mode that allows only peers configured with passwords to establish sessions. In this mode, LDP hello messages from peers that have no password are ignored. If you do not configure strict authentication, then peers that do not have configured passwords can establish connections with each other.
If you configure LDP MD5 authentication or change the authentication password for a peer while it is in an established LDP session, MPLS restarts that session.
To configure LDP MD5 authentication:
1.
Set the password for an LDP peer.
host1(config)#mpls ldp neighbor 10.3.5.1 password rop23ers
2.
(Optional) Set strict LDP authentication mode so that only peers with passwords can establish LDP sessions.
host1(config)#mpls ldp strict-security
296 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional LDP Configuration Tasks on page 292
•
mpls ldp neighbor password
•
mpls ldp strict-security
Controlling LDP Label Distribution
By default, LDP advertises label mappings for all IGP prefixes to all LDP peers. In this case, mappings are not advertised for interface addresses. You can alternatively specify that LDP labels be distributed for a particular interface itself, in addition to the subnet that the interface is on. This behavior enables LSPs to be set up to the LSR configured with the interface address.
When the LSR learns an IGP route and tries to decide whether to advertise a label for the destination to a particular LDP neighbor, it attempts to match the destination against a route access list specified by the mpls ldp advertise-labels command, in the order in which the commands were issued. The first match determines the action taken, and no further matching is attempted for that destination. If the destination matches, labels are advertised to peers subject to any specified neighbor address list. If either access list is not matched, the labels are not advertised.
To create a filter that determines whether and where incoming (locally assigned) labels are distributed:
•
Issue the mpls ldp advertise-labels command one or more times: host1(config)#mpls ldp advertise-labels for net25 to euro3
When you do not specify a toAccessList, the action is taken for all peers.
Consider the following example configuration.
host1(config)#mpls ldp advertise-labels for net25 to euro3 host1(config)#mpls ldp advertise-labels for boston1
In this example, suppose the LSR receives a label for destination 10.10.11.12. If net25 specifies 10.10.11.12, then the access list action—permit or deny—is taken with the destination. If the action is permit, the peer that the label is advertised to is subject to the access list euro3. If net25 does not include 10.10.11.12, the LSR attempts to match it against boston1. If 10.10.11.12 is present in that access list, the specified action is taken for all peers. If boston1 does not include the destination, the label is not advertised to any peer.
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional LDP Configuration Tasks on page 292
•
mpls ldp advertise-labels
Copyright © 2013, Juniper Networks, Inc.
297
JunosE 14.3.x BGP and MPLS Configuration Guide
Additional RSVP-TE Configuration Tasks
All of the following RSVP-TE configuration tasks are optional, depending on your network topology and needs.
Tasks to configure RSVP-TE settings based on your network topology include:
• Configure RSVP MD5 authentication to provide hop-by-hop security.
See
“Configuring RSVP MD5 Authentication” on page 298
.
•
Configure fast reroute extensions to RSVP-TE to create a bypass tunnel.
See
“Configuring RSVP-TE Fast Rerouting with RSVP-TE Bypass Tunnels” on page 299 .
• Configure RSVP-TE peers to exchange hello messages and establish a hello adjacency.
See
“Configuring RSVP-TE Hello Messages to Determine Peer Reachability” on page 302
.
•
Configure RSVP-TE graceful restart to enable routers to maintain MPLS forwarding state when a link or node failure occurs.
See
“Configuring RSVP-TE Graceful Restart” on page 303
.
•
Configure the exchange of RSVP-TE node hellos on all RSVP-TE interfaces.
See
“Configuring RSVP-TE Hellos Based on Node IDs” on page 304
.
• Configure the BFD Protocol for RSVP-TE.
See
“Configuring the BFD Protocol for RSVP-TE” on page 304
.
Configuring RSVP MD5 Authentication
RSVP MD5 authentication provides hop-by-hop security against message spoofing and replay attacks. When authentication is configured, RSVP embeds an integrity object within secure cleartext RSVP messages sent between peers. The integrity object includes a key ID unique to the sender, a message sequence number, and keyed message digest.
These attributes enable verification of both packet content and sender.
For all potential RSVP peers, you configure the same key on the MPLS neighbor major interfaces, and then enable RSVP authentication on each of these interfaces. When you enable RSVP authentication on an interface, RSVP creates a security association that includes the key, key ID, hash algorithm, and other associated attributes. Each sender and receiver pair maintains the security association for their shared key.
NOTE: You must enable authentication on both ends of an RSVP interface to protect the link. Failure to do so can prevent tunnels through the interface from coming up.
Thereafter, RSVP messages sent by a router through the secured interface include an integrity object that contains a key ID for the security association and an MD5 message digest of the message contents. To protect against message replay attacks, the sending
298 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS interface also places a sequence number in the integrity object. Each sequence number is a unique, monotonically increasing number.
The secured interface expects each received RSVP message to include an integrity object.
The interface drops all RSVP messages that do not contain the object.
The receiver uses the key ID and the sender’s address to determine the relevant security association. The key ID is extracted from the received integrity object. The address of the sending interface is extracted from the rsvp_hop object, if present, or from the packet header if the message does not include the rsvp_hop object. The receiver then recomputes the message digest using the association key and algorithm and compares it to the digest received from the peer.
If the digests match, RSVP checks the received sequence number. Every message received from a sender after the first authenticated message must have a sequence number greater than the number from a previously authenticated message from that sender.
Messages with invalid sequence numbers are discarded.
If the sequence number is valid, then the RSVP message is authenticated and forwarded for normal RSVP processing. Unauthenticated messages are discarded.
To configure RSVP-TE MD5 authentication:
1.
Assign a key to the interface for MD5 authentication between RSVP peers.
host1(config-if)#mpls rsvp authentication key 34udR973j
2.
Enable MD5 authentication on the RSVP-TE interface.
host1(config-if)#mpls rsvp authentication
To clear the security association on a receiving peer for the specified sending peer:
• Issue the clear mpls rsvp authentication command: host1#clear mpls rsvp authentication 10.3.5.1
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional RSVP-TE Configuration Tasks on page 298
•
clear rsvp authentication
•
mpls rsvp authentication
•
mpls rsvp authentication key
Configuring RSVP-TE Fast Rerouting with RSVP-TE Bypass Tunnels
The fast reroute extensions to RSVP-TE enable you to create a single LSP, known as a bypass tunnel, to back up a set of LSPs by bypassing specific links in the LSP. In the event of a failure in any link of the protected RSVP-TE LSP (the primary LSP), MPLS redirects traffic to the associated bypass tunnel in tens of milliseconds.
Copyright © 2013, Juniper Networks, Inc.
299
JunosE 14.3.x BGP and MPLS Configuration Guide
You must statically configure the bypass tunnel for each link that you want to protect on each router in the LSP. The bypass tunnel must intersect the protected LSP at two locations. The start of the bypass tunnels is the point of local repair (PLR), which is the head end of the protected link. The bypass tunnel terminates downstream of the PLR on the node that represents the end of the bypassed link on the primary LSP.
Each bypass tunnel provides 1:N local protection; that is, each bypass tunnel can protect one or more links depending on where you have configured it. The protected primary
LSPs are stacked over the bypass tunnel to redirect their traffic around the failure.
The bypass tunnel naturally protects all LSPs that share the bypassed link (the LSP segment from the PLR to the downstream node) and that have requested protection.
Consider the network shown in
.
Figure 63: Bypass Tunnel
300
Suppose you have configured both LER 1 and LER 2 to request bypass protection, and have configured the following two bypass tunnels:
LSR 5 –> LSR 8 –> LSR 6
LSR 6 –> LSR 9 –> LSR 7
If link LSR 5 –> LSR 6 fails, RSVP-TE redirects traffic through LSR 5 –> LSR 8 –> LSR 6.
If link LSR 6 –> LSR 7 fails, RSVP-TE redirects traffic through LSR 6 –> LSR 9 –> LSR 7.
These two bypass tunnels therefore protect all LSPs routed from LER 1 or LER 2 through
LSRs 5, 6, and 7. Notice in
that if both protected links fail, traffic is still safely redirected through LSR 5 –> LSR 8 –> LSR 6 –> LSR 9 –> LSR 7.
If you want to protect an LSP that traverses N nodes against a failure in any link, then you must configure N-1 bypass tunnels. As shown in
Figure 63 on page 300 , each of those
bypass tunnels in turn can protect multiple tunnels.
On detecting the link failure, the PLR redirects traffic arriving on all of the protected primary tunnels to the bypass tunnel that protects the failed link. An additional label representing the bypass tunnel is stacked on the redirected packets. This label is popped either at the router that is the remote end of the protected link or at the penultimate hop.
The merge point therefore sees traffic with the original label representing the primary tunnel.
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
When the ingress router learns by RSVP-TE signaling that local protection (a bypass tunnel) is in use, it attempts to find a new optimal path for the tunnel, based on the configured path options. The ingress router sets up the new tunnel before it tears down the old tunnel with the failed link, and switches its traffic to the new tunnel.
You can use the tunnel mpls path-option command to configure path options on the bypass tunnel. However, the link being protected by the bypass tunnel must not be in the path if you specify an explicit path.
Configuration Example
The following steps show a partial configuration using the topology in
1.
On LSR 5, create a bypass tunnel to protect the link between LSR 5 and LSR 6. If you configure path options, you can specify the explicit path for the bypass tunnel either statically or to be dynamically calculated by the IGP traffic engineering mechanism.
host1(config)#interface tunnel mpls:bypass56 host1(config-if)#tunnel mpls path-option 1 explicit name bypass host1(config-if)#tunnel destination 172.20.1.1
host1(config-if)#exit
2.
On LSR 5, enable the explicit path, if configured.
host1(config)#mpls explicit-path name bypass enable host1(config-expl-path)#next-address 10.10.9.2
host1(config-expl-path)#exit
3.
On LSR 5, assign the bypass tunnel to the interface being protected.
host1(config)#interface atm 4/0.1
host1(config-if)#mpls backup-path bypass56
4.
On LER 1 (the tunnel ingress), specify that local protection is required for the primary tunnel.
host1(config)#interface tunnel mpls:primary1 host1(config-if)#tunnel mpls fast-reroute
Fast Reroute over SONET/SDH
If you are using MPLS fast reroute over a SONET/SDH interface, reduce the times that the router uses to convert a defect to an alarm. Use the path trigger delay command to reduce the time for the path layer and the trigger delay command to reduce the time for the section and line layers. Use the following guidelines to set the times:
•
Specify a value of 0 milliseconds if the interface does not use APS/MSP or if you want
MPLS to have priority over APS/MSP.
• Specify a value of at least 100 milliseconds if this interface uses APS/MSP and if you want APS/MSP to have priority over MPLS.
For more information about these commands, see JunosE Physical Layer Configuration
Guide.
Copyright © 2013, Juniper Networks, Inc.
301
JunosE 14.3.x BGP and MPLS Configuration Guide
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional RSVP-TE Configuration Tasks on page 298
•
mpls backup-path
•
tunnel mpls fast-reroute
Configuring RSVP-TE Hello Messages to Determine Peer Reachability
The RSVP-TE hello feature enables RSVP-TE peers to exchange hello messages and establish a hello adjacency. The peers use the adjacency to verify reachability. When a peer is no longer reachable, the LSPs that traverse the neighbor are torn down.
High refresh values reduce the amount of control traffic (and CPU cycles) needed by
RSVP-TE to refresh LSP state across the network, reducing the impact of RSVP-TE on system resources:
• A hello refresh interval of 1000 milliseconds (a rate of one hello every second) is appropriate for a small configuration—tens of interfaces—without causing performance degradation.
•
For larger configurations, the default hello refresh interval of 10,000 milliseconds (a rate of one hello every 10 seconds) is more appropriate and typically does not cause performance degradation.
To configure the RSVP-TE hello feature on all RSVP-TE interfaces in the VR:
1.
Issue the mpls rsvp signaling hello command.
host1:vr5(config)#mpls rsvp signaling hello
2.
(Optional) Configure the refresh interval.
host1(config-if)#mpls rsvp signaling hello refresh interval 5000
3.
(Optional) Configure the refresh misses.
host1(config-if)#mpls rsvp signaling hello refresh misses 5
To configure the RSVP-TE hello feature on a RSVP-TE specific interface:
1.
Access the interface.
host1(config)#interface fastEthernet 4/3
2.
Issue the mpls rsvp signaling hello command.
host1(config-if)#mpls rsvp signaling hello
3.
(Optional) Configure the refresh interval.
host1(config-if)#mpls rsvp signaling hello refresh interval 5000
4.
(Optional) Configure the refresh misses.
host1(config-if)#mpls rsvp signaling hello refresh misses 5
302 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
NOTE: Issuing the refresh interval or the refresh misses keywords only configures the refresh values; this action has no effect on enabling or disabling hellos.
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional RSVP-TE Configuration Tasks on page 298
•
mpls rsvp signaling hello
Configuring RSVP-TE Graceful Restart
Configure RSVP-TE graceful restart to enable routers to maintain MPLS forwarding state when a link or node failure occurs. Because forwarding state is maintained, traffic can continue to be forwarded while RSVP-TE restarts and recovers. The RSVP-TE graceful restart feature enables an LSR to gracefully restart, to act as a graceful restart helper node for a neighboring router that is restarting, or both.
To configure RSVP-TE graceful restart on the current VR so that the LSR acts as both a graceful restart restarting node and a graceful restart helper node:
1.
Enable RSVP-TE graceful restart on the current virtual router.
host1(config)#mpls rsvp signaling hello graceful-restart
2.
(Optional) Configure the recovery time—the time within which you want neighboring routers to resynchronize RSVP-TE state and MPLS forwarding state after a graceful restart.
host1(config)#mpls rsvp signaling hello graceful-restart recovery-time 140000
3.
(Optional) Configure the restart time—the time within which the sender gracefully restarts RSVP-TE and reestablishes hello communication with RSVP-TE neighbors.
host1(config)#mpls rsvp signaling hello graceful-restart refresh restart-time 150000
To configure RSVP-TE graceful restart on the current VR so that the LSR acts as only a graceful restart helper node for neighbors that support RSVP-TE graceful restart:
• Issue the mpls rsvp signaling hello graceful-restart mode help-neighbor command: host1(config)#mpls rsvp signaling hello graceful-restart mode help-neighbor
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional RSVP-TE Configuration Tasks on page 298
•
mpls rsvp signaling hello graceful-restart
•
mpls rsvp signaling hello graceful-restart recovery-time
•
mpls rsvp signaling hello graceful-restart restart-time
Copyright © 2013, Juniper Networks, Inc.
303
JunosE 14.3.x BGP and MPLS Configuration Guide
Configuring RSVP-TE Hellos Based on Node IDs
You can configure the exchange of node-ID–based RSVP-TE hellos (node hellos) for interoperability with routers that cannot support RSVP-TE graceful restart with link-based hellos. E Series routers use node hellos only to support their graceful restart capabilities.
NOTE: Graceful restart must be enabled on the VR so that the node hellos can advertise the graceful restart capabilities. Link-based hellos are not required for graceful restart when you have configured node hellos. However, you might still use link-based hellos to monitor RSVP-TE links and detect link failures.
To configure the exchange of RSVP-TE node hellos on all RSVP-TE interfaces in the VR:
1.
Enable RSVP-TE graceful restart.
host1:vr5(config)#mpls rsvp signaling hello graceful-restart
2.
Enable node hellos.
host1:vr5(config)#mpls rsvp signaling node-hello
3.
(Optional) Configure the refresh interval.
host1(config-if)#mpls rsvp signaling node-hello refresh interval 12000
4.
(Optional) Configure the refresh misses.
host1(config-if)#mpls rsvp signaling node-hello refresh misses 5
NOTE: Issuing the refresh interval or the refresh misses keywords only configures the refresh values; this action has no effect on enabling or disabling RSVP-TE node hellos.
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional RSVP-TE Configuration Tasks on page 298
•
mpls rsvp signaling node-hello
Configuring the BFD Protocol for RSVP-TE
Configure the Bidirectional Forwarding Detection (BFD) protocol for RSVP-TE to more rapidly detect failures in a network and enable faster rerouting around the failures. You can modify the BFD timers for more or less aggressive failure detection.
When configured, BFD liveness detection is established with all BFD-enabled RSVP-TE peers associated with that RSVP-TE major interface.
304 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
NOTE: Before the router can use the mpls rsvp bfd-liveness-detection command, you must specify a BFD license key. To view an already configured license, use the show license bfd command.
To enable BFD (bidirectional forwarding detection) on an RSVP-TE major interface:
1.
Access the interface.
host1(config)#interface fastEthernet 4/3
2.
Enable BFD liveness detection.
host1(config-if)#mpls rsvp bfd-liveness-detection
The peers in an RSVP-TE adjacency use the BFD timer values to negotiate the actual transmit intervals for BFD packets.
• Use the minimum-transmit-interval keyword to specify the interval at which the local peer proposes to transmit BFD control packets to the remote peer.
host1(config-if)#mpls rsvp bfd-liveness-detection minimum-transmit-interval 400
• Use the minimum-receive-interval keyword to specify the minimum interval at which the local peer must receive BFD control packets from the remote peer.
host1(config-if)#mpls rsvp bfd-liveness-detection minimum-receive-interval 400
• Use the minimum-interval keyword to specify the same value for both the transmit and receive intervals. Configuring a minimum interval has the same effect as configuring the minimum receive interval and the minimum transmit interval to the same value.
host1(config-if)#mpls rsvp bfd-liveness-detection minimum-interval 400
• Use the multiplier keyword to specify the detection multiplier value, which roughly equivalent to the number of packets that can be missed before the BFD session is declared to be down. The calculated BFD liveness detection interval can be different on each peer.
host1(config-if)#mpls rsvp bfd-liveness-detection multiplier 15
NOTE: You can change the BFD liveness detection parameters at any time without stopping or restarting the existing session; BFD automatically adjusts to the new parameter value. However, no changes to BFD parameters take place until the values resynchronize with each peer.
For details on liveness detection negotiation, see Negotiation of the BFD Liveness Detection
Interval in the JunosE IP Services Configuration Guide.
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
Additional RSVP-TE Configuration Tasks on page 298
•
mpls rsvp bfd-liveness-detection
Copyright © 2013, Juniper Networks, Inc.
305
JunosE 14.3.x BGP and MPLS Configuration Guide
Configuring IGPs and MPLS
You can use the tunnel mpls autoroute announce command to configure a tunnel to announce its endpoint to IS-IS or OSPF so that the IGP can then use the LSP as a shortcut to a destination based on the LSP’s metric.
If no tunnels are registered, the IGP calculates the shortest path to a destination by using the shortest path first (SPF) algorithm. The results are represented by the destination node, next-hop address, and output interface, where the output interface is a physical interface.
If you configure an LSP to be announced to the IGP with a certain metric, the LSP appears as a logical interface directly connected to the LSP endpoint. The IGP can consider the
LSP as a potential output interface for the LSP endpoint and for destinations beyond the endpoint. In this case, the SPF computation results are represented by the destination node and the output LSP, effectively using the LSP as a shortcut through the network to the destination.
By default, IS-IS and OSPF always use the MPLS tunnel to reach the tunnel endpoint.
Best paths determined by SPF calculations are not considered. You can enable the consideration of best paths by issuing the IS-IS or OSPF mpls spf-use-any-best-path command. This command causes the IGP to evaluate the LSP as it does any other path.
The IGP then either forwards traffic along the best path (which might be the MPLS tunnel), or load-balances between the MPLS tunnel and another path.
The default behavior applies only to reaching the tunnel endpoint itself. For prefixes downstream of the tunnel endpoint, the value of the tunnel metric always determines whether the IGP uses the LSP or the native path, or load-balances between the native path and one or more LSPs.
The tunnel metric can be absolute or relative. An absolute metric indicates there is no relationship to the underlying IGP cost. A relative metric is added to or subtracted from the underlying IGP shortest path cost.
Example 1 The following commands announce the tunnel to OSPF and specify a relative metric of
-2: host1(config-if)#tunnel mpls autoroute announce ospf host1(config-if)#tunnel mpls autoroute metric relative -2
By default, the LSP is preferred to reach the tunnel endpoint. OSPF will treat this LSP as having a metric of 2 less than the shortest path metric it has calculated. The LSP is therefore also preferred over other paths to prefixes beyond the tunnel endpoint.
Example 2 The following commands announce the tunnel to OSPF, specify an absolute metric of
25, and configure OSPF to enable the consideration of SPF best paths: host1(config-if)#tunnel mpls autoroute announce ospf host1(config-if)#tunnel mpls autoroute metric absolute 25
...
host1(config)#router ospf 1 host1(config-router)#mpls spf-use-any-best-path
306 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
OSPF uses this metric in its SPF calculations for traffic to the tunnel endpoint as well as beyond the endpoint. Traffic is routed through this LSP only when the other calculated paths have higher metrics.
Configuring the IGPs for Traffic Engineering
For both IGPs, you must issue two commands to enable the IGP to support traffic engineering.
• IS-IS—Enable the flooding of MPLS traffic-engineering link information into the specified
IS-IS level with the mpls traffic-eng command. You must also specify a stable router interface with the mpls traffic-eng router-id command.
MPLS traffic engineering also requires that IS-IS generate the new-style TLVs that enable wider metrics. Use the metric-style wide command to generate the new-style
TLVs. If you are using some IS-IS routers that still cannot interpret the new-style TLVs, use the metric-style transition command.
•
OSPF—Enable OSPF areas for traffic engineering with the mpls traffic-eng area command. OSPF generates opaque LSAs—also known as type-10 opaque link area link states—to flood the traffic-engineering information to the specified area. OSPF builds a traffic-engineering database that it uses in the calculation of shortest path to destinations that satisfy specified traffic-engineering constraints. As with IS-IS, you must also specify a stable router interface with the mpls traffic-eng router-id command.
To enable a multicast network and MPLS traffic engineering (TE) network to interoperate on a router running OSPF, use the mpls traffic-eng multicast-intact command.
When you configure a node as the downstream endpoint of an LSP, you must provide a stable interface as the router ID for the endpoint. Typically you select a loopback interface because of its inherent stability. Use the mpls traffic-eng router-id command to designate the router as traffic engineering capable and to specify the router ID. For all tunnels that end at this node, set the tunnel destination to the destination node's traffic-engineering router identifier, because the traffic-engineering topology database at the tunnel ingress uses that for its path calculation.
You can use the show isis mpls and show isis database commands to display information about IS-IS traffic engineering:
For OSPF, you can use the show ip ospf database opaque-area command to display information about traffic-engineering opaque LSAs.
See JunosE IP, IPv6, and IGP Configuration Guide for more information about enabling
IS-IS and OSPF to support traffic engineering and monitoring IS-IS and OSPF traffic engineering.
For information about BGP and MPLS, see
“Configuring BGP-MPLS Applications” on page 389
Copyright © 2013, Juniper Networks, Inc.
307
JunosE 14.3.x BGP and MPLS Configuration Guide
Related
Documentation
•
Basic MPLS Configuration Tasks on page 280
•
metric-style narrow
•
metric-style transition
•
metric-style wide
•
mpls spf-use-any-best-path
•
mpls traffic-eng
•
mpls traffic-eng area
•
mpls traffic-eng router-id
•
show ip ospf database
•
show isis database
•
show isis mpls adjacency-log
•
show isis mpls advertisements
•
show isis mpls tunnel
•
tunnel mpls autoroute announce
•
tunnel mpls autoroute metric
Configuring MPLS and Differentiated Services
TIP: Before you read this section, we recommend you be thoroughly familiar with the concepts of the JunosE QoS application.
MPLS employs several strategies to manage different kinds of data streams based on service plans and priority:
• Different conceptual models of diff-serv tunneling that either conceal intermediate
LSP nodes from diff-serv operations or render the MPLS network transparent to the diff-serv operations
•
Different strategies to set the EXP bits in the shim header to modify or maintain the traffic class/color combination of traffic
• Mapping of traffic behavior aggregates to corresponding per-hop behaviors so that traffic can be differentially switched to the appropriate LSPs to meet your network objectives
To configure MPLS for differentiated services:
•
Configure MPLS to use the pipe or uniform model of tunneling for differentiated services.
See
“Configuring the Tunneling Model for Differentiated Services” on page 309 .
• Configure EXP bits for differentiated services.
308 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
See
“Configuring EXP Bits for Differentiated Services” on page 309 .
• Configure differentiated services in a sample topology.
See
“Example Differentiated Services Application and Configuration” on page 310
.
•
Classify traffic In a differentiated services domain.
See
“Classifying Traffic for Differentiated Services” on page 313
.
Configuring the Tunneling Model for Differentiated Services
The JunosE Software supports both the pipe model and the uniform model for tunneling with the mpls tunnel-model command. The router also provides a way to implement the functionality of the short pipe model for IP packets.
To specify whether MPLS uses the pipe or uniform model of tunneling for differentiated services:
• Issue the mpls tunnel-model command.
host1(config)#mpls tunnel-model uniform
Related
Documentation
•
Configuring MPLS and Differentiated Services on page 308
•
Example Differentiated Services Application and Configuration on page 310
•
mpls tunnel-model
Configuring EXP Bits for Differentiated Services
To set the initial value of the EXP bits to the UPC value associated with the packets:
• Issue the mpls copy-upc-to-exp command.
host1(config)#mpls copy-upc-to-exp
To prevent the value of the EXP bits for a VPN/VC label from being modified by a per-LSP policy applied for the outer labels or by per-VR traffic class/color rules:
• Issue the mpls preserve-vpn-exp command.
host1(config)#mpls preserve-vpn-exp
Related
Documentation
•
EXP Bits for Differentiated Services Overview on page 272
•
Configuring MPLS and Differentiated Services on page 308
•
Example Differentiated Services Application and Configuration on page 310
•
mpls copy-upc-to-exp
•
mpls preserve-vpn-exp
Copyright © 2013, Juniper Networks, Inc.
309
JunosE 14.3.x BGP and MPLS Configuration Guide
Example Differentiated Services Application and Configuration
shows an example topology where a service provider offers the following differentiated services to its customers over its MPLS network:
•
QoS Internet service—The CE router is managed by the provider and sets the IP precedence to predefined values. IP policy on the PE router sets the traffic-class/color combination according to the incoming well-defined IP precedence value. The policy also sets the UPC value to the incoming well-defined IP precedence value.
•
Plain Internet service—IP policy on the PE router leaves the traffic-class/color combination as the default value, best-effort/green. The policy sets the UPC to 0.
• QoS VPN service—For CE-to-PE traffic, the VPN EXP is copied from the IP precedence value when the PE router pushes VPN stacked labels.
For PE-to-CE traffic, IP policy on the PE router resets the traffic-class/color combination according to the received, well-defined IP precedence value, so that egress queuing is based on the IP precedence value. This action takes place on the egress line module.
• Plain VPN service—For CE-to-PE traffic, the VPN EXP bits are set to 000 when the PE router pushes VPN stacked labels.
For PE-to-CE traffic, IP policy on the PE router resets the traffic-class/color combination to the default value, best-effort/green, so that packets are queued as best-effort. The
IP precedence value is left unchanged.
In this example, the provider also offers an inter-AS VPN service. The provider's own protocol traffic, for example, BGP signaling traffic such as update messages, is also labeled, with the EXP bits set to the same value as the IP precedence.
The egress queuing of traffic as it leaves the provider is always based on either the VPN
EXP bits as received on the core side in inter-AS case, or the IP precedence value in all other cases. It is acceptable that fabric queuing is based on the incoming base label's
EXP.
310 Copyright © 2013, Juniper Networks, Inc.
Figure 64: Differentiated Services over an MPLS Network
Chapter 4: Configuring MPLS
Differentiated Services Configuration Example
To configure the differentiated services described in this example:
1.
Create and attach an IP input policy for the QoS Internet service to CE interfaces on the PE router for incoming traffic.
host1(config)#ip classifier-list prec0 ip any any precedence 0 host1(config)#ip classifier-list prec1 ip any any precedence 1 host1(config)#ip policy-list qos-service host1(config-policy-list)#classifier-group prec0 host1(config-policy-list-classifier-group)#user-packet-class 0 host1(config-policy-list-classifier-group)#traffic-class class0 host1(config-policy-list-classifier-group)#color green host1(config-policy-list)#classifier-group prec1 host1(config-policy-list-classifier-group)#user-packet-class 1 host1(config-policy-list-classifier-group)#traffic-class class1 host1(config-policy-list-classifier-group)#color green host1(config)#interface atm 3/0.1
host1(config-subif)#ip policy input qos-service
2.
Create and attach an IP input policy for the plain Internet service to CE interfaces on the PE router for incoming traffic. All traffic is treated as best effort, so no classifier group is necessary.
host1(config)#ip policy-list plain-service host1(config-policy-list-classifier-group)#user-packet-class 0 host1(config-policy-list-classifier-group)#traffic-class best-effort host1(config-policy-list-classifier-group)#color green host1(config)#interface atm 5/0.1
host1(config-subif)#ip policy input plain-service
3.
Attach an IP output policy for the QoS VPN service to CE interfaces on the PE router for outgoing traffic. The same qos-service policy that is attached to the input in Step
1 can be used on the output, even though the UPC setting is not needed.
Copyright © 2013, Juniper Networks, Inc.
311
JunosE 14.3.x BGP and MPLS Configuration Guide host1(config)#Interface atm 3/0.1
host1(config-subif)#Ip policy output qos-service
Attach an IP output policy for the plain VPN service to CE interfaces on the PE router for outgoing traffic. The same plain-service policy that is attached to the input in Step
2 can be used on output, although the UPC setting is not needed.
host1(config)#Interface atm 5/0.1
host1(config-subif)#Ip policy output plain-service
4.
For traffic toward the core, configure per-VR rules or per-LSP policies to set the base
EXP bits value according to the traffic-class/color combination. Issue the mpls copy-upc-to-exp command to set the VPN EXP bits value to the UPC value. The UPC value is the same as the IP precedence value for the QoS service case; for all other cases the value is 000. Configure the mpls preserve-vpn-exp command so that VPN
EXP bits are not subject to policy or to per-VR EXP rules.
host1(config)#mpls match traffic-class … color … set exp-bits … host1(config)#mpls copy-upc-to-exp host1(config)#mpls preserve-vpn-exp
You must attach a policy to the core-side IP interface to set the UPC value of the control traffic appropriately so that the EXP bits value is copied from the UPC when this traffic goes out as MPLS packets.
host1(config)#ip classier-list control-traffic-prec0 … host1(config)#ip classier-list control-traffic-prec1 … host1(config)#ip policy-list core-ip-policy host1(config-policy-list)#classifier-group control-traffic-prec0 host1(config-policy-list-classifier-group)#user-packet-class prec0 host1(config-policy-list-classifier-group)#traffic-class class0 host1(config-policy-list-classifier-group)#color green host1(config-policy-list)#classifier-group control-traffic-prec1 host1(config-policy-list-classifier-group)#-packet-class prec1 host1(config-policy-list-classifier-group)#traffic-class class1 host1(config-policy-list-classifier-group)#color green host1(config)#interface pos 0/0 host1(config-subif)ip policy output core-ip-policy
5.
For traffic from the core, configure per-VR rules or per-LSP policies to set the traffic-class/color combination—and therefore shape the egress traffic queue—according to the value of the EXP bits in the base label. This action causes host1(config)#mpls match exp-bits <value> set traffic-class <className> color
Related
Documentation
•
Configuring MPLS and Differentiated Services on page 308
•
Configuring EXP Bits for Differentiated Services on page 309
•
Classifying Traffic for Differentiated Services on page 313
312 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
Classifying Traffic for Differentiated Services
In a differentiated services domain, traffic is classified into a behavior aggregate (BA), based on the type of diff-serv behavior for the traffic. At each node, traffic belonging to a particular BA is mapped to the corresponding per-hop behavior (PHB), which provides the scheduling behavior and drop probability required by the traffic.
MPLS uses the EXP bits in the shim header to support differentiated services. The JunosE
Software supports both statically configured and signaled mapping between the EXP bits and the PHB of traffic.
In a signaled environment, you can configure on the ingress node the set of PHBs that a tunnel supports, and then the set of PHBs is signaled end to end.
To support differentiated services, MPLS employs two types of LSPs: E-LSPs and L-LSPs.
The two types differ in how their PHB is determined. In the JunosE Software, the PHB is a combination of traffic class (also called per-hop scheduling class, or PSC) and drop precedence (color).
•
E-LSPs (EXP-inferred-PSC LSP) can transport as many as eight BAs. For E-LSPs, the traffic’s PHB is learned from the MPLS shim header.
• L-LSPs (Label-only-inferred-PSC LSP) transport a single PSC. The PHB is determined from a combination of the packet’s label, which indicates the traffic class, and the EXP field of the shim header, which indicates the drop precedence.
•
indicates how the PSC (column 1) is combined with the EXP field (column 2) to determine the PHB for incoming traffic on L-LSPs.
Table 56: Incoming L-LSP PHB Determination
PSC + EXP Field = PHB
BE
CSn
AFn
000
000
001
BE
CSn
AFn1
AFn
AFn
EF
010
011
000
AFn2
AFn3
EF
For nonstandard PHBs (any that are not listed in
), the JunosE
Software uses mapping similar to AFn mapping; EXP 001 is mapped to color green,
EXP 010 is mapped to yellow, and EXP 011 is mapped to red.
presents three examples that indicate how the PSC and the
EXP field are combined to determine the PHB for traffic on incoming L-LSPs.
Copyright © 2013, Juniper Networks, Inc.
313
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 57: Examples of Incoming L-LSP PHB Determination
PSC + EXP Field = PHB
AF2
AF3
AF3
010
010
011
AF22
AF32
AF33
CSn
AFn1
AFn2
AFn3
EF
•
For outgoing L-LSPs, the EXP is determined by the PHB.
indicates the PHB-to-EXP mapping for outgoing traffic on L-LSPs.
Table 58: Outgoing L-LSP PHB Determination
PHB = EXP Field
BE 000
000
001
010
011
000
For nonstandard PHBs, the mapping is similar to AFn mapping. Red color maps to 011, yellow maps to 010, and green maps to 001.
Tasks to perform static configuration and signaled mapping between the EXP bits and the PHB of traffic include the following sets of tasks:
•
Configuring Static EXP-to-PHB Mapping on page 314
•
Signaled Mapping for RSVP-TE Tunnels on page 315
•
Preference of per-VR Versus per-LSP Behavior on page 317
Configuring Static EXP-to-PHB Mapping
You can configure static EXP-to-PHB mapping at the per-VR level, only for LSPs that do not have specific policies attached (by either per-LSP configured mapping or signaled mapping). The configured mapping applies regardless of label distribution protocol, BGP.
LDP, or RSVP-TE.
The PHB of incoming packets is determined from the EXP bits by the match values set with the mpls match exp-bits command.
The EXP bits of outgoing packets are determined from the PHB by the match values set with the mpls match traffic-class command.
314 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
To configure static EXP-to-PHB mapping:
1.
Set a combination of traffic class and color for incoming traffic that matches the specified EXP bits value in the shim header.
host1(config)#mpls match exp-bits 1 set traffic-class bronze color red
You can repeat the command to support the eight possible EXP bit values.
2.
Set the EXP bits in the shim header of outgoing traffic that matches a particular combination of traffic class and color.
host1(config)#mpls match traffic-class gold color green set exp-bits 7
You can repeat the command to support up to 24 combinations: eight traffic classes supported on the router times three colors.
Signaled Mapping for RSVP-TE Tunnels
For signaled mapping between EXP and PHB, policies apply the EXP bits matching and setting on a per-LSP basis rather than a per-VR basis. Signaled mapping applies only when RSVP-TE is the label distribution protocol.
When traffic is mapped onto the ingress router of the LSP, the EXP bits are set according to a policy attached to the LSP. The policy corresponds to the EXP-to-PHB mapping defined for the LSP. Typically, the policy sets the EXP bits differently according to classifier lists that match on internal class/color information or on a user packet class associated with a packet.
For transit routers and egress routers along the path of the LSP, the incoming EXP bits are matched to determine the traffic class and drop preference (color red, yellow, or green). This matching is accomplished by means of a policy corresponding to the signaled
EXP-to-PHB mapping that is created and attached when the LSP is established.
EXP bits are not normally changed on transit routers, but when traffic is sent out of an
LSP on a transit router, the bits can be changed by the policy. Normally, however, the net effect is that the EXP-bits remain the same through the mapping sequence of EXP bits to an internal traffic class/color combination back to EXP bits, unless the traffic class/color combination is also modified by other factors.
Because the policy (which maps the EXP bits to an internal traffic class/color combination and vice versa) attached to an LSP is created according to the PHB-ID–to–EXP mapping signaled by RSVP-TE, you must configure on each router a mapping association between
PHB IDs and the internal traffic class/color combinations.
The JunosE Software automatically generates and attaches policies when tunnels are established.
shows the mapping associations between PHB IDs, EXP bits, and traffic class (TC)/color combination in an E-LSP case.
• Mapping association between PHB ID and EXP bits is configured on ingress routers using the tunnel mpls diff-serv phb-id command.
Copyright © 2013, Juniper Networks, Inc.
315
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Mapping association between PHB ID and traffic class/color combination is configured on all routers using the mpls diff-serv phb-id traffic-class command.
• Mapping association between EXP bits and traffic class/color combination is done automatically by the JunosE Software at the appropriate routers along the path.
Figure 65: Associations Between PHB ID, EXP Bits, and Traffic
Classes/Colors
shows the operations performed at ingress, transit, and egress systems during signaled mapping sessions.
Figure 66: Signaled Mapping
316
To define a policy rule that sets the EXP bits in packets to which the policy is applied:
• Issue the mark-exp command.
host1(config-policy-list)#mark-exp 5 classifier-group claclEXP precedence 32
To create or modify an MPLS classifier control list to match on traffic class/color combination or EXP bits:
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS
•
Issue the mpls classifier-listcommand.
host1(config)#mpls classifier-list be-green traffic-class best-effort color yellow
To map the specified PHB ID to the internal traffic class/color combination:
• Issue the mpls diff-serv phb-id traffic-class command.
host1(config)#mpls diff-serv phb-id standard 45 traffic-class gold color green
To create or modify an MPLS policy:
•
Issue the mpls policy-list command.
host1(config)#mpls policy-list mpls-exp-setting
To enable collection of policy statistics for a tunnel or LSP. Collection is disabled by default.
•
Issue the mpls policy-statistics command.
host1#mpls policy-statistics boston2dc
Policy statistics are displayed when you issue the show mpls forwarding or show mpls tunnel command, if a policy is attached and policy statistics are enabled.
To specify the traffic class for which LSP-level queues are created and the scheduler profile to be used with the queues:
• Issue the mpls traffic-class command.
host1(config)#mpls traffic-class af1 scheduler-profile af1-scheduler-profile
These classes originate from E-LSPs and L-LSPs (classes derived from the signaled
PHB-ID) or regular LSPs (classes configured with the mpls traffic-class command)
To specify the PHB supported by a signaled tunnel:
•
Issue the tunnel mpls diff-serv phb-id command.
host1(config-if)#tunnel mpls diff-serv phb-id standard 35 exp-bits 5
For E-LSPs, you also use this command to map the PHB to the specified exp-bits bitValue.
You can repeat the command for up to eight PHB mappings.
For L-LSPs, do not use the exp-bits keyword. If you repeat the command, the most recent command overwrites the previous command.
Preference of per-VR Versus per-LSP Behavior
MPLS always prefers the per-LSP method of matching and setting EXP bits by means of applied policies over the per-VR method.
Per-VR matching of EXP bits is not performed on the LSP when an input policy (matching on incoming EXP bits) is attached to the ingress segment of the LSP.
Copyright © 2013, Juniper Networks, Inc.
317
JunosE 14.3.x BGP and MPLS Configuration Guide
Similarly, per-VR setting of EXP bits is not performed on the LSP when an output policy
(setting the outgoing EXP bits) is attached to the egress segment of the LSP.
See the JunosE Policy Management Configuration Guide for more information about defining policies.
Example Traffic Class Configuration for Differentiated Services
000
001
010
011
The commands in this example illustrate a partial network configuration that supports four differentiated service classes on a particular tunnel: a best-effort class, two assured forwarding classes, and an expedited forwarding class.
presents the mapping between EXP bits, PHB, PHB ID, and traffic class/color combination.
Table 59: Differentiated Services Mapping
EXP PHB PHB ID 6-bit PHB ID
Traffic
Class/Color
BE
AF11
AF12
AF13
0x0000
0x2800
0x3000
0x3800
12
14
00
10 best-effort/green af1/green af1/yellow af1/red
100
101
110
111
AF21
AF22
AF23
EF
0x4800
0x5000
0x5800
0xb800
18
20
22
46 af2/green af2/yellow af2/red ef/green
NOTE: This example includes both MPLS and policy configuration commands, and assumes that you are thoroughly familiar with the information and commands presented in the JunosE Policy Management Configuration Guide.
The four traffic classes are configured to allocate fabric resources and allow global synchronization of the three segments of the data path through an E Series router: ingress, fabric, and egress. The JunosE Software automatically creates the best-effort traffic class, with a default weight of eight. You must define the remaining three classes, af1, af2, and ef. In this example, the af1 class has twice as much fabric bandwidth as the best-effort class, and the af2 class has twice as much fabric bandwidth as the af1 class.
The expedited forwarding traffic (the ef class) requires strict-priority queuing.
host1(config)#traffic-class af1 host1(config-traffic-class)#fabric-weight 16 host1(config)#traffic-class af2
318 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS host1(config-traffic-class)#fabric-weight 32 host1(config)#traffic-class ef host1(config-traffic-class)#fabric-strict-priority
Define two scheduler profiles for the af1 and af2 classes on the egress line modules: host1(config)#scheduler-profile af1-scheduler-profile host1(config-scheduler-profile)#weight 16 host1(config)#scheduler-profile af2-scheduler-profile host1(config-scheduler-profile)#weight 32
Create queue profiles to define how queues are instantiated to implement the corresponding traffic classes and PHBs. The JunosE Software automatically creates the best-effort queue profiles.
host1(config)#queue-profile af1-queues
[Queue configuration omitted] host1(config)#queue-profile af2-queues
[Queue configuration omitted] host1(config)#queue-profile ef-queues
[Queue configuration omitted]
The scheduler and queue profiles are referenced in QoS profiles. For example, you can create a QoS profile for port-based per-class queuing or for LSP-level per-class queuing
(configuration omitted).
You must map the PHB IDs to the appropriate traffic class/color combinations: host1(config)#mpls diff-serv phb-id standard 0 traffic-class best-effort color green host1(config)#mpls diff-serv phb-id standard 10 traffic-class af1 color green host1(config)#mpls diff-serv phb-id standard 12 traffic-class af1 color yellow host1(config)#mpls diff-serv phb-id standard 14 traffic-class af1 color red host1(config)#mpls diff-serv phb-id standard 18 traffic-class af2 color green host1(config)#mpls diff-serv phb-id standard 20 traffic-class af2 color yellow host1(config)#mpls diff-serv phb-id standard 22 traffic-class af2 color red host1(config)#mpls diff-serv phb-id standard 46 traffic-class ef color green
Configuration on the Ingress Router
You must access the tunnel interface to map the PHB IDs to the EXP bits. The E Series router signals this mapping to all routers on the tunnel. You can establish different
PHB-ID–to–EXP mappings for different tunnels.
host1(config)#interface tunnel mpls:example
PHB-ID–to–EXP mapping for the best-effort traffic class: host1(config-if)#tunnel mpls diff-serv phb-id standard 0x0000 exp-bits 0
PHB-ID–to–EXP mapping for the af1 traffic class: host1(config-if)#tunnel mpls diff-serv phb-id standard 10 exp-bits 1 host1(config-if)#tunnel mpls diff-serv phb-id standard 12 exp-bits 2 host1(config-if)#tunnel mpls diff-serv phb-id standard 14 exp-bits 3
PHB-ID–to–EXP mapping for the af2 traffic class: host1(config-if)#tunnel mpls diff-serv phb-id standard 18 exp-bits 4
Copyright © 2013, Juniper Networks, Inc.
319
JunosE 14.3.x BGP and MPLS Configuration Guide host1(config-if)#tunnel mpls diff-serv phb-id standard 20 exp-bits 5 host1(config-if)#tunnel mpls diff-serv phb-id standard 22 exp-bits 6
PHB-ID–to–EXP mapping for the ef traffic class: host1(config-if)#tunnel mpls diff-serv phb-id standard 46 exp-bits 7
Define classifier control lists to classify the incoming packets into classifier groups.
Although not shown here, for each CLACL you must define the rules that will select the appropriate incoming packets: be, af1, af2, or ef.
host1(config)#classifier-list be-packets host1(config)#classifier-list af1-packets host1(config)#classifier-list af2-packets host1(config)#classifier-list ef-packets
Define a policy that maps the selected packets into traffic classes. For the assured forwarding classes, this example uses rate limit profiles to set the colors.
host1(config)#policy-list classify-packets host1(config-policy-list)#traffic-class best-effort classifier-group bf-packets host1(config-policy-list)#traffic-class ef classifier-group ef-packets host1(config-policy-list)#traffic-class af1 classifier-group af1-packets host1(config-policy-list)#traffic-class af2 classifier-group af2-packets host1(config-policy-list)#rate-limit-profile af1-profile classifier-group af1-packets host1(config-policy-list)#rate-limit-profile af2-profile classifier-group af2-packets host1(config)#rate-limit-profile af1-profile host1(config-rate-limit-profile)#committed-rate 6000000 host1(config-rate-limit-profile)#committed-burst 1000000 host1(config-rate-limit-profile)#peak-rate 8000000 host1(config-rate-limit-profile)#peak-burst 1000000 host1(config)#rate-limit-profile af2-profile host1(config-rate-limit-profile)#committed-rate 8000000 host1(config-rate-limit-profile)#committed-burst 1500000 host1(config-rate-limit-profile)#peak-rate 12000000 host1(config-rate-limit-profile)#peak-burst 1000000
You attach the policy to the ingress interface of the ingress router. As packets arrive, they are classified with the internal traffic class/color combination and forwarded into the appropriate queues in the fabric. When the packets are sent into the tunnel out of the ingress router, the EXP bits are set according to the router-generated policy (in this example called mpls-exp-setting) that the JunosE Software automatically attached to the tunnel.
Configuration on the Ingress and Transit Routers
When the tunnel is established, the JunosE Software automatically creates an output policy to map traffic-class/color combinations to EXP bits and attaches the policy to the outgoing segment of the tunnel. The JunosE Software generates classifier list and policy list names, and creates the EXP-setting policy as if the following commands were entered:
NOTE: You do not actually issue these commands; they represent the behavior automatically performed by the router.
320 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS host1(config)#mpls classifier-list be-green traffic-class best-effort color green host1(config)#mpls classifier-list ef-green traffic-class ef color green host1(config)#mpls classifier-list af1-green traffic-class af1 color green host1(config)#mpls classifier-list af1-yellow traffic-class af1 color yellow host1(config)#mpls classifier-list af1-red traffic-class af1 color red host1(config)#mpls classifier-list af2-green traffic-class af2 color green host1(config)#mpls classifier-list af2-yellow traffic-class af2 color yellow host1(config)#mpls classifier-list af2-red traffic-class af2 color red host1(config)#mpls policy-list mpls-exp-setting host1(config-policy-list)#mark 0 classifier-group be-green host1(config-policy-list)#mark 1 classifier-group af1-green host1(config-policy-list)#mark 2 classifier-group af1-yellow host1(config-policy-list)#mark 3 classifier-group af1-red host1(config-policy-list)#mark 4 classifier-group af2-green host1(config-policy-list)#mark 5 classifier-group af2-yellow host1(config-policy-list)#mark 6 classifier-group af2-red host1(config-policy-list)#mark 7 classifier-group ef-green
NOTE: For a topology-driven LSP, you have to configure and apply the classifier list and policy list manually.
Configuration on the Transit and Egress Routers
When the tunnel is established, the JunosE Software automatically creates an input policy to match the EXP bits and map them to the traffic-class/color combinations and attaches the policy to the incoming segment of the tunnel. The JunosE Software generates classifier list and policy list names, and creates the policy as if the following commands were entered:
NOTE: You do not actually issue these commands; they represent the behavior automatically performed by the router.
host1(config)#mpls classifier-list bf-packets exp 0 host1(config)#mpls classifier-list af11-packets exp 1 host1(config)#mpls classifier-list af12-packets exp 2 host1(config)#mpls classifier-list af13-packets exp 3 host1(config)#mpls classifier-list af21-packets exp 4 host1(config)#mpls classifier-list af22-packets exp 5 host1(config)#mpls classifier-list af22-packets exp 6 host1(config)#mpls classifier-list ef-packets exp 7 host1(config)#mpls policy-list mpls-exp-matching host1(config-policy-list)#traffic-class best-effort classifier-group bf-packets host1(config-policy-list)#traffic-class af1 classifier-group af11-packets host1(config-policy-list)#traffic-class af1 classifier-group af12-packets host1(config-policy-list)#traffic-class af1 classifier-group af13-packets host1(config-policy-list)#traffic-class af2 classifier-group af21-packets host1(config-policy-list)#traffic-class af2 classifier-group af22-packets host1(config-policy-list)#traffic-class af2 classifier-group af23-packets host1(config-policy-list)#traffic-class ef classifier-group ef-packets host1(config-policy-list)#color green classifier-group af11-packets host1(config-policy-list)#color green classifier-group af21-packets
Copyright © 2013, Juniper Networks, Inc.
321
JunosE 14.3.x BGP and MPLS Configuration Guide host1(config-policy-list)#color yellow classifier-group af12-packets host1(config-policy-list)#color yellow classifier-group af22-packets host1(config-policy-list)#color red classifier-group af13-packets host1(config-policy-list)#color red classifier-group af23-packets
NOTE: For a topology-driven LSP, you must configure and apply the classifier list and policy list manually.
The packets are forwarded to the appropriate fabric queue according to the traffic class/color combination. On a transit router, when the packet is forwarded out of the tunnel, the router-generated output policy then sets the EXP bits back according to the traffic class/color combination. Typically, the effect of the EXP bits to traffic class/color combination to EXP bits is no change.
On an egress router, where the tunnel terminates, no router-generated output policy is attached, and the packets pass out of the router subject to any manually configured IP policy management applied to their traffic class/color combination.
See the JunosE Policy Management Configuration Guide for more information about defining policies.
Related
Documentation
•
Configuring MPLS and Differentiated Services on page 308
•
Configuring EXP Bits for Differentiated Services on page 309
•
Example Differentiated Services Application and Configuration on page 310
•
Classifying Traffic for Differentiated Services on page 313
•
mark-exp
•
mpls classifier-list
•
mpls diff-serv phb-id traffic-class
•
mpls match exp-bits
•
mpls match traffic-class
•
mpls policy-list
•
mpls policy-statistics
•
mpls traffic-class
•
tunnel mpls diff-serv phb-id
Configuring Point-to-Multipoint LSPs
To set up a point-to-multipoint LSP, you configure the primary LSP from the ingress router and the branch LSPs that carry traffic to the egress routers. The configuration of the primary point-to-multipoint LSP is similar to a signaled LSP. In addition to the conventional LSP configuration, you specify a path name on the primary LSP and this same path name on each branch LSP. By default, the branch LSPs are dynamically
322 Copyright © 2013, Juniper Networks, Inc.
Chapter 4: Configuring MPLS signaled by means of CSPF and require no configuration. You can alternatively configure the branch LSPs as a static path.
Because E Series routers can only function as egress routers, you must use M-series routers running Junos OS as ingress routers to enable point-to-multipoint LSPs to send packets through the network to the endpoints connected to the egress routers.
Observe the following guidelines to deliver multicast data using point-to-multipoint LSPs on the egress E Series routers:
• The IP interface on which the packet arrives must be an IGMP-owned interface. An
IGMP-owned interface refers to an interface in which IGMP is the only multicast protocol enabled.
•
The actual route to the source must be through an IGMP-owned interface.
The configuration of an E Series router as an egress router depends on the type of label advertised for the LSR that is the egress router for the prefix. Penultimate hop popping
(PHP) is the default when RSVP-TE or LDP is the signaling protocol.
If the egress router advertises an implicit null label to achieve PHP on an upstream neighbor, enable IP IGMP on the static physical interface on which the unlabeled multicast packet is received by the router by using the ip igmp interface configuration command.
host1(config-if)#ip igmp
If the egress router advertises an explicit null or non-null label to its upstream neighbor to include a label in all MPLS packets, complete the following steps to configure an
E Series router as an egress router:
1.
Create a profile by using the profile command. Add commands to enable IP IGMP and IP processing on the loopback interface in the profile.
host1(config)#profile mplsdynip host1(config-profile)#ip igmp host1(config-profile)#ip unnumbered loopback 0
2.
Create a dynamic IPv4 interface on top of MPLS major interfaces and specify the profile that you created in the previous step to set attributes for this interface.
host1(config)#mpls create-dynamic-interfaces ip on-major-interfaces profile dynip
For all types of labels that are advertised for the LSR that is the egress router for the prefix, you must complete the following steps, in addition to those detailed earlier, on the E Series router:
1.
Enable IGMP on the interface which owns the route to the source by using the ip igmp command. Because the route to the source can change dynamically, we recommend that you enable IGMP on all interfaces of the router or, at least, on all interfaces that might be the next hop interface to the source.
Copyright © 2013, Juniper Networks, Inc.
323
JunosE 14.3.x BGP and MPLS Configuration Guide
2.
Disable the multicast reverse path forwarding (RPF) check policy for all the streams that will be delivered on the point-to-multipoint LSP by using the ip multicast-routing disable-rpf-check command. For more information, see Enabling and Disabling RPF
Checks in the JunosE Multicast Routing Configuration Guide.
Related
Documentation
•
Point-to-Multipoint LSPs Overview on page 275
•
show mpls tunnels
324 Copyright © 2013, Juniper Networks, Inc.
CHAPTER 5
Monitoring MPLS
This chapter describes the commands you can use to monitor and troubleshoot
Multiprotocol Label Switching (MPLS) on E Series routers.
NOTE: The E120 and E320 Broadband Services Routers output for monitor and show commands is identical to output from other E Series routers, except that the E120 and E320 router output also includes information about the adapter identifier in the interface specifier (slot/adapter/port).
This chapter contains the following sections:
•
Setting the Baseline for MPLS Statistics on page 326
•
Clearing and Re-Creating Dynamic Interfaces from MPLS Major Interfaces on page 328
•
Clearing and Refreshing IPv4 Dynamic Routes in the Tunnel Routing Table on page 329
•
Clearing and Refreshing IPv6 Dynamic Routes in the Tunnel Routing Table on page 329
•
Tracing Paths Through the MPLS User Plane on page 329
•
Monitoring ATM VCs and VPI/VCI Ranges Used for MPLS on page 330
•
Monitoring Global Call Admission Control Configuration on page 331
•
Monitoring Interfaces Configured with Traffic Engineering Bandwidth
•
Monitoring Virtual Router Configuration on page 332
•
Monitoring IP and IPv6 Tunnel Routing Tables on page 333
•
•
Monitoring MPLS Label Bindings on page 336
•
Monitoring LDP Graceful Restart on page 337
•
Monitoring Interfaces That are Synchronizing with LDP on page 338
•
Monitoring LDP Interfaces on page 339
•
Monitoring LDP Neighbors on page 341
•
Monitoring LDP Profiles on page 344
•
Monitoring LDP Statistics on page 344
•
Monitoring LDP Targeted Hello Receive and Send Lists on page 347
Copyright © 2013, Juniper Networks, Inc.
325
JunosE 14.3.x BGP and MPLS Configuration Guide
•
Monitoring MPLS Status and Configuration on page 348
•
Monitoring MPLS Explicit Paths on page 350
•
Monitoring RSVP-TE Status and Configuration on page 351
•
Monitoring the RSVP-TE Bypass Tunnels on page 352
•
Monitoring MPLS Labels Used for Forwarding on page 353
•
Monitoring MPLS Interfaces on page 354
•
Monitoring MPLS Minor Interfaces on page 360
•
Monitoring MPLS Next Hops on page 361
•
Monitoring the Configured Mapping between PHB IDs and Traffic Class/Color
•
Monitoring RSVP-TE Profiles and MPLS Tunnel Profiles on page 363
•
Monitoring RSVP Path State Control Blocks, Reservation State Control Blocks, or
•
Monitoring RSVP MD5 Authentication on page 368
•
Monitoring RSVP-TE Interfaces Where BFD is Enabled on page 369
•
Monitoring RSVP-TE Interface Counters on page 370
•
Monitoring RSVP-TE Graceful Restart on page 372
•
Monitoring RSVP-TE Hello Adjacency Instances on page 373
•
Monitoring Status and Configuration for MPLS Tunnels on page 375
•
Verifying and Troubleshooting MPLS Connectivity on page 377
•
Packet Flow Examples for Verifying MPLS Connectivity on page 379
•
Troubleshooting MTU Problems in Point-to-Point LSPs on page 386
Setting the Baseline for MPLS Statistics
You can use the baseline mpls commands to set a statistics baseline for MPLS operations.
The router implements the baseline by setting the statistics to zero and then subtracting this baseline when you retrieve baseline-relative statistics.
Use the delta keyword with the show mpls commands to display baselined statistics.
Tasks to set a baseline for MPLS statistics are:
•
Setting a Baseline for MPLS Major Interface Statistics on page 326
•
Enabling and Setting a Baseline for MPLS Forwarding Table Statistics on page 327
•
Enabling and Setting a Baseline for MPLS Next-Hop Table Statistics on page 327
•
Setting a Baseline for MPLS Tunnel Statistics on page 328
•
Enabling Statistics Collection for Policies Attached to MPLS Tunnels on page 328
Setting a Baseline for MPLS Major Interface Statistics
To set a statistics baseline for MPLS major interfaces:
326 Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
•
Issue the baseline mpls interface command for a specific MPLS major interface.
host1#baseline mpls interface boston5
There is no no version.
The following statistics are maintained for each MPLS major interface:
• receive packets and octets
• transmit packets and octets
•
• receive discarded packets receive error packets
• failed label lookups
• transmit discarded packets
• transmit error packets
Enabling and Setting a Baseline for MPLS Forwarding Table Statistics
To enable and set a statistics baseline for MPLS forwarding table entries:
1.
Issue the mpls statistics label command to enable the statistics for a specific MPLS in label.
host1#mpls statistics label 123
2.
Issue the baseline mpls label command for a specific MPLS in label.
host1#baseline mpls label 123
By default, statistics are enabled for incoming labels and RSVP-TE or LDP outgoing labels, but not for others such as BGP outgoing labels. Statistics are not stored in NVS.
When enabled, the following statistics are maintained for each forwarding table entry:
• receive packets and octets • receive discarded packets • receive error packets
There is no no version for the baseline mpls label command. However, you can disable the forwarding table statistics.
To disable the statistics for a specific MPLS in label:
•
Issue the no mpls statistics label command.
host1#no mpls statistics label 123
Enabling and Setting a Baseline for MPLS Next-Hop Table Statistics
To enable and set a statistics baseline for MPLS next-hop table entries:
1.
Issue the mpls statistics next-hop command to enable the statistics for a specific
MPLS next hop.
host1#mpls statistics next-hop 1046
2.
Issue the baseline mpls next-hop command for a specific MPLS next hop.
Copyright © 2013, Juniper Networks, Inc.
327
JunosE 14.3.x BGP and MPLS Configuration Guide host1#baseline mpls next-hop 1046
By default, statistics are enabled for next hops depending on the protocol that created the MPLS next hop. Statistics are not stored in NVS.
When enabled, the following statistics are maintained for each next-hop table entry:
• out packets and bytes
• out discarded packets
• out error packets
There is no no version for the baseline mpls next-hop command. However, you can disable the next-hop table statistics.
To disable the statistics for a specific MPLS next hop:
• Issue the no mpls statistics next-hop command.
host1#no mpls statistics next-hop 1046
Setting a Baseline for MPLS Tunnel Statistics
To set a statistics baseline for MPLS tunnel statistics:
•
Issue the baseline mpls tunnel command.
host1#baseline mpls tunnel tunnel5
There is no no version.
Enabling Statistics Collection for Policies Attached to MPLS Tunnels
To enable collection of the following statistics for each policy attached to a tunnel:
• Issue the mpls statistics policy command.
host1#mpls statistics policy tunnel5
Statistics are not stored in NVS. When enabled, the following statistics are maintained for each policy:
• packets and bytes
• classifier group
•
EXP bits value
To disable collection of policy statistics for a specific MPLS tunnel:
• Issue the no mpls statistics policy command.
host1#no mpls statistics policy tunnel5
Clearing and Re-Creating Dynamic Interfaces from MPLS Major Interfaces
To remove and re-create dynamic IPv4 interfaces and dynamic IPv6 interfaces from all
MPLS major interfaces or a specific MPLS major interface:
•
Issue the clear mpls dynamic-interfaces on-major-interfaces command: host1#clear mpls dynamic-interfaces on-major-interfaces
328 Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
You can use this command to reapply policies related to dynamic IPv4 and IPv6 interfaces on top of MPLS major interfaces.
There is no no version.
Related
Documentation
•
clear mpls dynamic-interfaces on-major-interfaces
Clearing and Refreshing IPv4 Dynamic Routes in the Tunnel Routing Table
To clear and then refresh a specified IPv4 dynamic route or all IPv4 dynamic routes from the tunnel routing table of the virtual router or a specified VRF:
• Issue the clear ip tunnel-routes command.
host1(config)#clear ip tunnel-routes *
There is no no version. This command takes effect immediately.
Related
Documentation
•
clear ip tunnel-routes
Clearing and Refreshing IPv6 Dynamic Routes in the Tunnel Routing Table
To clear and then refresh a specified IPv6 dynamic route or all IPv6 dynamic routes from the tunnel routing table of the virtual router or a specified VRF.
•
Issue the clear ipv6 tunnel-routes command.
host1(config)#clear ipv6 tunnel-routes *
There is no no version. This command takes effect immediately.
Related
Documentation
•
clear ipv6 tunnel-routes
Tracing Paths Through the MPLS User Plane
Purpose To trace paths through the MPLS user plane.
Action To trace the path that packets follow enroute to the destination IP address 10.90.101.9: host1:edge1# traceroute 10.90.101.9
Tracing route to 10.90.101.9, TTL = 32, timeout = 2 sec.
(Press ^c to stop.)
1 3ms 2ms 2ms 10.90.101.4 mplsLabel1=4009 mplsExpBits1=0
2 2ms 2ms 2ms 10.90.101.7 mplsLabel1=7004 mplsExpBits1=0
3 2ms 2ms 2ms 10.90.101.9
ICMP extensions enable LSRs to append MPLS header information (the label stack) to
ICMP destination unreachable and time exceeded messages. This sample output shows the label and EXP bits used to switch the ICMP packets.
Copyright © 2013, Juniper Networks, Inc.
329
JunosE 14.3.x BGP and MPLS Configuration Guide
Related
Documentation
•
Determining Reachability of IP Destinations in the Network
•
traceroute
Monitoring ATM VCs and VPI/VCI Ranges Used for MPLS
Purpose Display information about ATM VCs used as MPLS LSPs and VPI-VCI ranges reserved for MPLS when you use the interface label space for MPLS labels.
Action To display all VCs and reserved VC ranges on the router: host1# show atm vc
Cate Rx/Tx Rx/Tx Rx/Tx Sta
Interface VPI VCI VCD Type Encap gory Peak Avg Burst tus
------------ --- ---- ---- ---- ----- ---- ----- ----- ----- ---
ATM 3/0.2 0 101 4375 PVC AUTO CBR 1000 0 0 UP
ATM 3/0.3 0 102 4376 PVC AUTO CBR 1000 0 0 DOWN
...
ATM 3/0.8099 1 8099 8099 PVC SNAP UBR 0 0 0 UP
ATM 3/0.8100 1 8100 8100 PVC SNAP UBR 0 0 0 DOWN
8000 circuit(s) found
Reserved VCC ranges:
Start Start End End
Interface VPI VCI VPI VCI
--------- ----- ----- --- ---
ATM 2/0 2 100 2 102
ATM 2/0 3 300 3 303
2 reservation(s) found
To display a summary of all reserved VC ranges on the router, including those reserved for MPLS use: host1# show atm vc reserved
Reserved VCC ranges:
Start Start End End
Interface VPI VCI VPI VCI
--------- ----- ----- --- ---
ATM 2/0 2 100 2 102
ATM 2/0 3 300 3 303
2 reservation(s) found
Meaning
lists the show atm vc command output fields.
Table 60: show atm vc Output Fields
Field Name Field Description
Interface
VPI
VCI
VCD
Interface type and number
Virtual path identifier
Virtual channel identifier
Virtual circuit descriptor
330 Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
Table 60: show atm vc Output Fields (continued)
Field Name Field Description
Type
Encap
Category
Rx/Tx Peak
Type of circuit: PVC
Encapsulation method: AUTO, AAL5, MUX, SNAP, ILMI, F4-OAM
Service type configured on the VC: UBR, UBR-PCR, NRT-VBR,
RT-VBR, CBR
Peak rate in Kbps
Rx/Tx Avg
Rx/Tx Burst
Status
Start VPI
Start VCI
End VPI
End VCI
Average rate in Kbps
Maximum number of cells that can be burst at the peak cell rate
State of the virtual circuit: Up, Down
Starting virtual path identifier (inclusive) of the reserved VC range
Starting virtual circuit identifier (inclusive) of the reserved VC range
Ending virtual path identifier (inclusive) of the reserved VC range
Ending virtual circuit identifier (inclusive) of the reserved VC range
Related
Documentation
•
show atm vc
Monitoring Global Call Admission Control Configuration
Purpose Display global call admission control (CAC) configuration.
Action To display CAC configuration: host1# show cac resource info flood interval 180
Related
Documentation
•
show cac
Monitoring Interfaces Configured with Traffic Engineering Bandwidth Accounting
Purpose Display interfaces on which traffic engineering bandwidth accounting is configured.
Action To display information about CAC interfaces: host1# show cac interface atm2/0
bandwidth 10 kbps
IP/MPLS reserveable bw 10 kbps
Copyright © 2013, Juniper Networks, Inc.
331
JunosE 14.3.x BGP and MPLS Configuration Guide
current total available bw 10 kbps
MPLS TE flooding threshold:
up 15 30 45 60 75 80 85 90 95 96 97 98 99 100
down 100 99 98 97 96 95 90 85 80 75 60 45 30 15
MPLS TE administrative weight 0
MPLS TE attribute flags 0
Available BW at 8 priority levels:
0 10 kbps
1 10 kbps
2 10 kbps
3 10 kbps
4 10 kbps
5 10 kbps
6 10 kbps
7 10 kbps
Meaning
lists the show cac interfacevc command output fields.
Table 61: show cac interface Output Fields
Field Name Field Description bandwidth
IP/MPLS reserveable bw
Maximum physical bandwidth in Kbps; line rate
Total bandwidth in Kbps that can be reserved for MPLS; includes bandwidth that is already reserved as well as bandwidth not yet reserved current total available bw Total bandwidth in Kbps that is available to be reserved
MPLS TE flooding threshold up/down
MPLS TE administrative weight
MPLS TE attribute flags
Absolute percentages of total reservable bandwidth that trigger the flooding of the new bandwidth value throughout the network; flooding is triggered when bandwidth increases past any of the up threshold values and when bandwidth decreases past any of the down threshold values
Weight assigned to the interface that supersedes a weight assigned by the IGP
32-bit value that assigns the interface to a resource class and enables a tunnel to discriminate among interfaces by matching against tunnel affinity bits
Available BW at 8 priority levels
Bandwidth in Kbps that is available at each priority level in the range
0–7
Related
Documentation
•
show cac interface
Monitoring Virtual Router Configuration
Purpose Display the configuration of all virtual routers or a specific virtual router.
332 Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
Action To display VR configuration: host1# show configuration virtual-router euro7
Related
Documentation
•
show configuration
Monitoring IP and IPv6 Tunnel Routing Tables
Purpose Display the current state of the IPv4 or IPv6 tunnel routing table.
Action To display information about all IP tunnel routes: host1:vr2# show ip tunnel-route all
Protocol/Route type codes:
I1- ISIS level 1, I2- ISIS level2,
I- route type intra, IA- route type inter, E- route type external,
i- metric type internal, e- metric type external,
O- OSPF, E1- external type 1, E2- external type2,
N1- NSSA external type1, N2- NSSA external type2
L- MPLS label, V- VRF, *- via indirect next-hop
Prefix/Length Type Next Hop Dst/Met Interface
------------------ --------- --------------- ---------- ----------------------------------------
200.200.200.1/32 Ldp 111.111.1.1[L18 110/2 ATM5/1.1
]
Rsvp 200.200.200.1[L 110/2 ATM5/1.1
25]
To display information about all IPv6 tunnel routes: host1:pe1:pe11# show ipv6 tunnel-route all
Protocol/Route type codes:
O- OSPF, E1- external type 1, E2- external type2,
N1- SSA external type1, N2- NSSA external type2
L- MPLS label, V- VRF, *- via indirect next-hop
Prefix/Length Type Dst/Met Interface
-------------------------------- --------- ---------- ----------------------------------------
::21.21.21.0/126 BgpTunnel 200/0 [L20,L26] ATM5/0.10
BgpTunnel 200/0 [L20,L34] ATM5/0.10
2::2/128 BgpTunnel 200/0 [L20,L26] ATM5/0.10
BgpTunnel 200/0 [L20,L34] ATM5/0.10
To display detailed information about all IP tunnel routes beginning with address
200.200.200.1/32: host1:vr2# show ip tunnel-route 200.200.200.1/32 detail
Protocol/Route type codes:
I1- ISIS level 1, I2- ISIS level2,
I- route type intra, IA- route type inter, E- route type external,
i- metric type internal, e- metric type external,
O- OSPF, E1- external type 1, E2- external type2,
N1- NSSA external type1, N2- NSSA external type2
L- MPLS label, V- VRF, *- via indirect next-hop
200.200.200.1/32 Type: Ldp Distance: 110 Metric: 2 Tag: 0 Class: 0
MPLS next-hop: 3, label 18 on ATM5/1.1 (ip19000003.mpls.ip), nbr 111.111.1.1
Copyright © 2013, Juniper Networks, Inc.
333
JunosE 14.3.x BGP and MPLS Configuration Guide
To display detailed information about all IPv6 tunnel routes beginning with address
::21.21.21.0/126: host1:pe1:pe11# show ipv6 tunnel-route ::21.21.21.0/126 detail all
Protocol/Route type codes:
O- OSPF, E1- external type 1, E2- external type2,
N1- SSA external type1, N2- NSSA external type2
L- MPLS label, V- VRF, *- via indirect next-hop
::21.21.21.0/126 Type: BgpTunnel Distance: 200 Metric: 0 Class: 0
MPLS next-hop: 18, label 20, VPN traffic, resolved by MPLS next-hop 13
MPLS next-hop: 13, resolved by MPLS next-hop 34, peer ::ffff:2.2.2.2
MPLS next-hop: 34, ECMP next-hop, leg count 2
MPLS next-hop: 17, resolved by MPLS next-hop 16, peer 2.2.2.2
MPLS next-hop: 16, primary(in use): label 26 on ATM5/0.10, secondary: resolved by MPLS next-hop 0
Meaning
lists the show ip tunnel-route command and show ipv6 tunnel route command output fields.
Table 62: show ip tunnel route and show ipv6 tunnel-route Output Fields
Field Name Field Description
Prefix
Length
Type
Next Hop
IPv4 or IPv6 address prefix of network destination
Network mask length for prefix
Type of route; protocol
IP address of the next hop to the route, whether it is a local interface or another router; not displayed for IPv6 tunnel routing table
Dst or Distance
Met or Metric
Interface
Tag
Class
Administrative distance for the route
Number of hops; metric
Interface type and interface specifier
Numeric tag that identifies route
Attribute of a route applied only as a result of set route-class clause in a table map
Related
Documentation
•
show ip tunnel-route
•
show ipv6 tunnel-route
Monitoring LDP
Purpose Display information about LDP.
334 Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
Action To display LDP information: host1# show ldp
LDP
LSR ID is 80.0.0.2
FEC Deaggregation is off
Egress label: implicit-null
Label distribution control mode: ordered control
LDP session retry 0 times at interval 10
LDP session hold time: 180
LDP session keepalive interval: 20
LDP targeted-hello hold time: 45
LDP targeted-hello interval: 15
Topology Driven LSP enabled
LSPs used for IP forwarding
for host addresses only
NOTE: The mpls keyword is optional and is provided for compatibility with non–E Series implementations.
Meaning
lists the show ldp command output fields.
Table 63: show ldp Output Fields
Field Name Field Description
LSR ID
FEC Deaggregation
Egress label
IP address of label-switched router
State of FEC deaggregation, on or off
Type of label advertised for the LSR that is the egress router for the prefix, implicit null, explicit null, or a non-null label
Label distribution control mode
Label distribution control mode used by LDP for label distribution, independent control, or ordered control
LDP session retry Configured values for the number of LDP session retry attempts and the retry interval
LDP session hold time
LDP session keepalive interval
LDP targeted-hello hold time
Configured value for the LDP session hold time
Interval at which LDP sends session keepalive messages, in seconds
LDP targeted-hello hold time, in seconds
LDP targeted-hello interval LDP targeted-hello interval, in seconds
Topology Driven LSP Status of topology-driven LSP, enabled or disabled
Copyright © 2013, Juniper Networks, Inc.
335
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 63: show ldp Output Fields (continued)
Field Name Field Description
LSPs used for IP forwarding LSPs are placed in the IP routing table for forwarding plain IP traffic; displayed only when the mpls ldp ip-forwarding command has been configured. Indicates whether the LSPs that are used for IP forwarding are host only, subject to a specified access list, or subject to a specified prefix list.
LDP proto stats totalPeersDiscovered
LDP protocol statistics
Number of LDP peers discovered totalAdjacenciesEstablished Number of LDP adjacencies established totalSessionsEstablished Number of LDP sessions established totalFECElements totalFECs
Number of FEC elements
Number of FECs totalInLabels totalOutLabels
Number of in labels (sent to upstream neighbor)
Number of out labels (received from downstream neighbor) totalCrLSPSetup totalCrLSPDeleted
Number of constraint-based routed LSPs set up
Number of constraint-based routed LSPs deleted
Related
Documentation
•
show ldp
Monitoring MPLS Label Bindings
Purpose Use to display label bindings from the MPLS label information base.
Action To display MPLS label bindings: host1# show mpls binding
Frame Relay over MPLS vc-id 50001 group-id 2
In 26 neighbor 10.9.1.3
Out 27 neighbor 10.9.1.3
VLAN over MPLS vc-id 240001 group-id 2
In 22 neighbor 10.9.1.3
Out 25 neighbor 10.9.1.3
10.1.1.1/32
In 10001 neighbor 10.3.11.2
Out 20001 neighbor 10.3.11.2
10.2.2.2/32
In 10002 neighbor 10.4.12.2 stale
Out 20002 neighbor 10.4.12.2 stale
336 Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
10.3.3.3/32
In 10005 neighbor 10.4.12.2 stale
Out 20003 neighbor 10.4.12.2 stale
10.4.12.0/30
In 10003 neighbor 10.5.5.2
Out 20004 neighbor 10.5.5.2
10.4.23.0/30
In 10004 neighbor 10.5.5.2
Out 20005 neighbor 10.5.5.2
NOTE: The ldp keyword and the mpls keyword display the same information.
Meaning
lists the show ldp binding command and show mpls binding command output fields.
Table 64: show ldp binding and show mpls binding Output Fields
Field Name Field Description
In
Out neighbor
Label sent to upstream neighbor for displayed route
Label received from downstream neighbor for displayed route
IP address of neighbor to which the label is sent or received stale Label that indicates neighbor has restarted
Related
Documentation
•
show ldp binding
•
show mpls binding
Monitoring LDP Graceful Restart
Purpose Display information about LDP graceful restart.
Action To display information about LDP graceful restart: host1# show ldp graceful-restart
LDP Graceful Restart is enabled
Helper Mode is enabled
Reconnect Time: 220 sec
Recovery Time: 240 sec
Max Recovery Time: 260 sec
Neighbor Liveness Timer: 280 sec
Peer 80.0.1.1:0, State: operational, Restarter Mode: disabled, Helper Mode: enabled
Peer 80.0.3.3:0, State: operational, Restarter Mode: disabled, Helper Mode: enabled
Copyright © 2013, Juniper Networks, Inc.
337
JunosE 14.3.x BGP and MPLS Configuration Guide
NOTE: The mpls keyword is optional and is provided for compatibility with non–E Series implementations.
Meaning
lists the show ldp graceful restart command output fields.
Table 65: show ldp graceful restart Output Fields
Field Name Field Description
LDP Graceful Restart
Helper Mode
Reconnect Time
State of graceful restart, enabled or disabled
State of graceful restart helper mode, enabled or disabled
Locally configured value for reconnect time, in seconds
Recovery Time
Max Recovery Time
Neighbor Liveness Timer
Peer
Locally configured value for recovery time, in seconds
Locally configured value for max-recovery timer, in seconds
Locally configured value for neighbor-liveness timer, in seconds
Address, state, and LDP graceful restart state for neighbor
Related
Documentation
•
show ldp graceful-restart
Monitoring Interfaces That are Synchronizing with LDP
Purpose Display information about interfaces that are synchronizing with LDP or the specified interface that is synchronizing with LDP.
Action To display information about interfaces synchronizing with LDP: host1# show ldp igp-sync
Atm 0/0:
LDP configured; SYNC enabled.
SYNC status: sync achieved; peer reachable.
IGP holddown time: infinite.
Peer LDP Ident: 10.130.0.1:0
IGP enabled: OSPF 1
Meaning
lists the show ldp igp-sync command output fields.
Table 66: show ldp igp-sync Output Fields
Field Name Field Description
LDP State of LDP, configured, auto-configured, or not configured
338 Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
Table 66: show ldp igp-sync Output Fields (continued)
Field Name Field Description
SYNC status
IGP holddown time
Peer LDP Ident
IGP enabled
State of synchronization, enabled or disabled
Value of IGP hold down time, infinite or number of milliseconds
IP address of LDP peer
IGP protocol
Related
Documentation
•
show ldp igp-sync
Monitoring LDP Interfaces
Purpose Display information about all LDP interfaces or the specified LDP interface.
Action To display information about all LDP interfaces: host1# show ldp interface
Interface ATM6/0.120
Interface address: 192.168.12.1/28
Enabled with profile 'default'
Configured hold time: 15
Hello interval: 5
Hold Time: 1
242 hello received, 242 hello sent, 0 hello rejected
1 adjacency created, 0 adjacency deleted,
Number of adjacencies = 1
Link hello adjacency: Address: 10.10.12.2, Transport address: 80.0.2.2,
Up for 00:20:09, Remaining hold time: 11 sec
To display brief information about LDP interfaces: host1# show ldp interface brief
Interface IP-Address Protocol
ATM6/1.1 192.168.100.21/30 enabled
ATM6/1.3 192.168.100.17/30 enabled
ATM6/1.5 192.168.100.13/30 enabled
ATM6/0.7 172.16.100.1/30 enabled
ATM6/0.8 172.16.100.22/30 enabled
ATM6/0.9 172.16.100.14/30 enabled
NOTE: The mpls keyword is optional and is provided for compatibility with non–E Series implementations.
Meaning
lists the show ldp interface command output fields.
Copyright © 2013, Juniper Networks, Inc.
339
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 67: show ldp interface Output Fields
Field Name Field Description
Interface autoconfigured
Interface address
Enabled with profile
Identifier of the interface
LDP has been autoconfigured on the interface
IP address of the interface, with address mask
Name of profile with which interface was enabled
Configured hold time
Hello interval
Hold time
Number of adjacencies
Link hello adjacency label alloc label learned accum label alloc accum label learned last restart time notf msg mapping request abort release
Configured period for which a sending LSR maintains a record of link hello messages from the receiving LSR without receipt of another link hello message from that LSR, in seconds
Negotiated interval between link-hello packets, in seconds
Lowest configured hold time among all neighbors on the same subnet, used as the effective hold time, in seconds
Number of LDP adjacencies for the interface
Address and transport address of the link hello adjacency; time adjacency has been up in hh:mm:ss; remaining hold time for the adjacency in seconds
Number of labels allocated and advertised to this peer
Number of labels received from this peer
Cumulative total number of labels allocated and advertised to this peer
Cumulative total number of labels received from this peer
Time in hh:mm:ss since session last restarted
Number of notification messages received or received bad or sent
Number of messages received or received bad or sent
Number of label mapping messages received or received bad or sent
Number of label request messages received or received bad or sent
Number of label abort messages received or received bad or sent
Number of label release messages received or received bad or sent
340 Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
Table 67: show ldp interface Output Fields (continued)
Field Name Field Description withdraw addr addr withdraw msgId
Number of label withdraw messages received or received bad or sent
Number of address messages received or received bad or sent
Number of address withdraw messages received or received bad or sent
Number of message ID messages received or sent unknown msg type err hello recv hello sent bad hello recv adj setup time last hello recv time last hello sent time remaining hold time
IP-Address
Protocol
Number of unknown message type errors received
Number of hello messages received
Number of hello messages sent
Number of hello messages received bad
Time in hh:mm:ss since adjacency set up
Time in hh:mm:ss since last hello message received
Time in hh:mm:ss since last hello message sent
Time in hh:mm:ss remaining of the hold time
IP address of the interface
Administrative state of LDP, enabled or disabled
Related
Documentation
•
show ldp interface
Monitoring LDP Neighbors
Purpose Display LDP neighbor information.
Action To display information about LDP neighbor 10.3.5.1: host1# show ldp neighbor 10.3.5.1
LDP Neighbor: 10.0.2.2
LSR: Remote 10.0.2.2:0, local 10.0.1.1:0
Transport address: remote 10.0.2.2, local 10.0.1.1
State: Operational
LDP advertisement: Unsolicited
Up for 00:20:03
Number of next-hop addresses received = 3
10.0.2.2 100.6.12.2 100.6.23.2
Copyright © 2013, Juniper Networks, Inc.
341
JunosE 14.3.x BGP and MPLS Configuration Guide
342
Number of adjacencies = 1
Link Hello adjacency: address 10.6.12.2, transport 10.0.2.2,
Up for 00:20:09, remaining hold time: 11 sec
To display brief information about all LDP neighbors: host1# show ldp neighbor brief
Neighbor Transport Address State
10.0.2.2 10.0.1.1->80.0.2.2 Operational
To display information about graceful restart for neighbors: host1# show ldp neighbor graceful-restart
LDP Neighbor: 10.0.1.1
Graceful Restart is disabled
Helper Mode is enabled
Reconnect Time: 0 msec
Recovery Time: 0 msec
State: operational
LDP neighbor 10.0.2.2
Graceful Restart is enabled
Helper Mode is enabled
Reconnect Time: 220000 msec
Recovery Time: 0 msec
State: operational
To display information about LDP statistics for the session with each LDP neighbor: host1# show ldp neighbor statistics
LDP Neighbor: 10.0.2.2
Message type Received Sent
---------------- -------- ----
Initialization 1 1
Keepalive 85 85
Notification 0 0
Address 1 1
Address withdraw 0 0
Label mapping 5 5
Label request 0 0
Label withdraw 2 2
Label release 2 2
NOTE: The mpls keyword is optional and is provided for compatibility with non–E Series implementations.
NOTE: If a password is configured for a peer, you can view the password with the show configuration command. This command displays the passwords in cleartext unless the service password-encryption command has been issued, in which case the passwords are displayed in encrypted format.
Meaning
lists the show ldp neighbor command output fields.
Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
Table 68: show ldp neighbor Output Fields
Field Name Field Description
LDP neighbor
LSR
Transport address
State
IP address of LDP peer
IP address of remote and local peers; the number following the colon is the platform label space ID, and is always 0
Transport remote and local address for the TCP session
State of the session, nonexistent (session connection not established) or operational (has received keepalive message)
LDP advertisement
Up
Graceful Restart
Helper Mode
Reconnect Time
Recovery Time
State nonexistent restarting recovering operational
Neighbor
Initialization
Keepalive
Notification
Address
Address withdraw
Label mapping
Mode of label distribution, downstream-unsolicited or downstream-on-demand
Time that the adjacency has been up, in hh:mm:ss format
State of graceful restart, enabled or disabled
State of graceful restart helper mode, enabled or disabled
Value for reconnect time received from peer in FT TLV, in milliseconds
Value for recovery time received from peer in FT TLV, in milliseconds
Status of the neighbor’s graceful restart, one of the following:
LDP session is not established
Neighbor LSR is restarting
Session with neighbor LSR has reestablished after the neighbor restarted; label bindings are being exchanged
LDP session is up
IP address of LDP peer
Number of initialization messages received and sent
Number of keepalive messages received and sent
Number of notification messages received and sent
Number of address messages received and sent
Number of address withdraw messages received and sent
Number of label mapping messages received and sent
Copyright © 2013, Juniper Networks, Inc.
343
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 68: show ldp neighbor Output Fields (continued)
Field Name Field Description
Label request
Label withdraw
Label release
Number of label request messages received and sent
Number of label withdraw messages received and sent
Number of label release messages received and sent
Related
Documentation
•
show ldp neighbor
Monitoring LDP Profiles
Purpose Display a specific LDP profile, or all LDP profiles.
Action To display the default LDP profile: host1:pe2# show ldp profile default ldp profile default: used by 2 interfaces
session retry: 10 times at interval 10
NOTE: The mpls keyword is optional and is provided for compatibility with non–E Series implementations.
Meaning
lists the show ldp profile command output fields.
Table 69: show ldp profile Output Fields
Field Name Field Description profile session retry
Number of interfaces that use the profile
Number of attempts that will be made to set up an MPLS LDP session
Related
Documentation
•
show ldp profile
Monitoring LDP Statistics
Purpose Display statistics for LDP on the current virtual router.
344 Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
Action To display all LDP statistics: host1# show ldp statistics
Message type Received Sent
---------------- -------- -----
Hello 25733 25735
Initialization 2 2
Keepalive 9646 9646
Notification 0 0
Address 2 2
Address withdraw 0 0
Label mapping 8 8
Label request 0 0
Label withdraw 0 0
Label release 0 0
Label abort 0 0
All UDP 25733 25735
All TCP 9654 9654
Event type Total
--------------------- -----
Sessions opened 2
Sessions closed 0
Topology changes 5
No router id 0
No address 0
No interface 0
No session 0
No adjacency 0
Unknown version 0
Malformed PDU 0
Malformed message 0
Unknown message type 0
Inappropriate message 0
Malformed tlv 0
Bad TLV value 0
Missing TLV 0
PDU too large 0
PDU too small 0
No Memory 0
NOTE: The mpls keyword is optional and is provided for compatibility with non–E Series implementations.
Meaning
lists the show ldp statistics command output fields.
Table 70: show ldp statistics Output Fields
Field Name Field Description
Hello
Initialization
Keepalive
Number of hello messages received and sent
Number of initialization messages received and sent
Number of keepalive messages received and sent
Copyright © 2013, Juniper Networks, Inc.
345
JunosE 14.3.x BGP and MPLS Configuration Guide
346
Label request
Label withdraw
Label release
Label abort
All UDP
All TCP
Sessions opened
Sessions closed
Topology changes
No router id
No address
No interface
No session
No adjacency
Unknown version
Malformed PDU
Malformed message
Unknown message type
Inappropriate message
Malformed tlv
Table 70: show ldp statistics Output Fields (continued)
Field Name Field Description
Notification
Address
Address withdraw
Label mapping
Number of notification messages received and sent
Number of address messages received and sent
Number of address withdraw messages received and sent
Number of label mapping messages received and sent
Number of label request messages received and sent
Number of label withdraw messages received and sent
Number of label release messages received and sent
Number of label abort messages received and sent
Number of UDP messages received and sent
Number of TCP messages received and sent
Number of session opened events
Number of session closed events
Number of topology change events
Number of no router ID events
Number of no address events
Number of no interface events
Number of no session events
Number of no adjacency events
Number of unknown version events
Number of malformed PDU events
Number of malformed message events
Number of unknown message type events
Number of inappropriate message events
Number of inappropriate message events
Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
Table 70: show ldp statistics Output Fields (continued)
Field Name Field Description
Bad TLV value
Missing TLV
PDU too large
PDU too small
Number of bad TLV value events
Number of missing TLV events
Number of PDU too large events
Number of PDU too small events
No Memory Number of no memory events
Related
Documentation
•
show ldp statistics
Monitoring LDP Targeted Hello Receive and Send Lists
Purpose Display LDP targeted hello receive or send list, or both.
Action To display both the LDP targeted hello receive and send lists: host1# show ldp targeted session
Mpls Target Session Status:
D = Dynamically, S = Statically, A = Access List Configured
Targeted session sent to 10.9.1.3 is up Used By: D
indirect nexthop index 3, resolved
Targeted session sent to 10.9.1.6 is up Used By: S
indirect nexthop index 206, resolved
Meaning
lists the show ldp targeted session command output fields.
Table 71: show ldp targeted session Output Fields
Field Name Field Description
D Targeted session created by layer 2 over MPLS connection; see
Layer 2 Services over MPLS Overview in the JunosE BGP and MPLS
Configuration Guide for more information about layer 2 over MPLS
S
A
Used By
Targeted session statically created by user
Targeted session created by access list
Letter representing source of targeted session
Related
Documentation
•
show ldp targeted session
Copyright © 2013, Juniper Networks, Inc.
347
JunosE 14.3.x BGP and MPLS Configuration Guide
Monitoring MPLS Status and Configuration
Purpose Display status and configuration information about MPLS.
Action To display information about MPLS Status and configuration: host1# show mpls
MPLS administratively enabled
Current state is Config incomplete
LSR ID is 10.2.2.2
Re-optimization timer is 3600
Label range 3000 ~ 4000
retry forever at interval 30 during LSP setup if there is route
retry forever at interval 30 during LSP setup if there is no route
Loop Detect enabled
Additional detail is shown when LDP is enabled:
LDP
LSR ID is 80.0.0.2
FEC Deaggregation is off
Egress label: implicit-null
Label distribution control mode: ordered control
LDP session retry 0 times at interval 10
LDP session hold time: 180
LDP session keepalive interval: 20
LDP targeted-hello hold time: 45
LDP targeted-hello interval: 15
Topology Driven LSP enabled
LSPs used for IP forwarding
for host addresses only
Additional detail is shown when RSVP-TE is enabled:
RSVP is enabled
LSRID 10.1.1.1
Re-optimization timer is 3600
Tunnel retry forever at interval 5 if route is available
Tunnel retry forever at interval 5 if no route is available
Refresh reduction is OFF
Message bundling is OFF
Egress label is non-null
Hellos are on with an interval of 10000 and miss limit of 4
Graceful restart is ON
Restart time 60000 milliseconds
Recovery time 120000 milliseconds
•
Additional detail shown when RSVP-TE graceful restart helper mode is enabled:
RSVP is enabled
...
Graceful restart is ON (helper mode)
Meaning
lists the show mpls command output fields.
348 Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Monitoring MPLS
Table 72: show mpls Output Fields
Field Name Field Description
MPLS
LSR ID
Re-optimization timer
Label range
Status of MPLS, administratively enabled or disabled, and configuration status
IP address of label-switched router
Frequency at which LSPs are checked for better paths
Range of platform label space retry
Loop Detect
LDP
Retry behavior to be performed during LSP setup
Status of loop detection, enabled or disabled
This field and the following fields are displayed only when LDP is enabled.
IP address of label-switched router
State of FEC deaggregation, on or off
LSR ID
FEC Deaggregation
Egress label
Label distribution control mode
Label distribution control mode used by LDP for label distribution, independent control or ordered control
LDP session retry
Type of label advertised for the LSR that is the egress router for the prefix, explicit-null or a non-null label
LDP session hold time
LDP session keepalive interval
Interval in seconds between attempts to set up an MPLS LDP session
Period in seconds for which an LSR maintains the session with its
LDP peer without receipt of any LDP message from that peer
Interval at which LDP sends session keepalive messages, in seconds
LDP targeted hello hold time
LDP targeted-hello hold time, in seconds
LDP targeted-hello interval LDP targeted-hello interval, in seconds
Topology Driven LSP Status of topology-driven LSP, enabled or disabled
LSPs used for IP forwarding LSPs are placed in the IP routing table for forwarding plain IP traffic; displayed only when the mpls ldp ip-forwarding command has been configured. Indicates whether the LSPs that are used for IP forwarding are host only, subject to a specified access list, or subject to a specified prefix list.
Copyright © 2013, Juniper Networks, Inc.
349
JunosE 14.3.x BGP and MPLS Configuration Guide
Table 72: show mpls Output Fields (continued)
Field Name Field Description
RSVP is enabled
LSRID
Re-optimization timer
Tunnel retry
This field and the following fields are displayed only when RSVP-TE is enabled.
IP address of label-switched router
Frequency at which LSPs are checked for better paths
Retry behavior to be performed during LSP setup
Refresh reduction
Message bundling
Egress label
Hellos
Graceful restart helper mode
Restart time
Recovery time
State of RSVP-TE summary refresh reduction, OFF or ON
State of RSVP-TE summary refresh message bundling, OFF or ON
Type of label advertised for the LSR that is the egress router for the prefix, explicit-null or a non-null label
State of RSVP-TE hello feature, including the hello refresh interval and hello miss limit
State of RSVP-TE graceful restart, OFF or ON
Graceful restart helper mode is enabled when this field is displayed
Graceful restart time, in milliseconds
Graceful restart recovery time, in milliseconds
Related
Documentation
•
show mpls
Monitoring MPLS Explicit Paths
Purpose Display MPLS explicit paths.
Action To display information about all MPLS explicit paths: