Juniper JUNOSE 11.2.X BGP AND MPLS, JUNOSE 11.2.X Configuration Manual

Download

Page 1

JunosE™ Software for E Series™ Broadband Services Routers

BGP and MPLS Configuration Guide

Release

11.2.x

Published: 2010-07-16

Page 2

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

Writing: Subash Babu Asokan, Bruce Gillham, Brian Wesley Simmons, Fran Singer, Megha Shaseendran, Krupa Chandrashekar, Namrata Mehta, Pallavi Madhusudhan, Chander Aima, Poornima Goswami, Hema Priya J, Sairam Venugopalan Editing: Benjamin Mann Illustration: Brian Wesley Simmons, Nathaniel Woodward Cover Design: Edmonds Design

Revision History July 2010—FRS JunosE 11.2.x

The information in this document is current as of the date listed in the revision history.

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. The 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.

Page 3

END USER LICENSE AGREEMENT

READ THIS END USER LICENSE AGREEMENT (“AGREEMENT”) BEFORE DOWNLOADING, INSTALLING, OR USING THE SOFTWARE.

BY DOWNLOADING, INSTALLING, OR USING THE SOFTWARE OR OTHERWISE EXPRESSING YOUR AGREEMENT TO THE TERMS CONTAINED HEREIN, YOU (AS CUSTOMER OR IF YOU ARE NOT THE CUSTOMER, AS A REPRESENTATIVE/AGENT AUTHORIZED TO BIND THE CUSTOMER) CONSENT TO BE BOUND BY THISAGREEMENT. IF YOU DO NOTOR CANNOT AGREE TO THE TERMSCONTAINED HEREIN, THEN (A) DO NOT DOWNLOAD, INSTALL, OR USE THE SOFTWARE, AND (B) YOU MAY CONTACT JUNIPER NETWORKS REGARDING LICENSE TERMS.

1. The Parties. The parties to this Agreement are (i) Juniper Networks, Inc. (if the Customer’s principal office is located in the Americas) or Juniper Networks(Cayman)Limited(if the Customer’s principaloffice is locatedoutside the Americas) (such applicable entity beingreferred to herein as“Juniper”), and (ii)the person ororganizationthat originally purchased from Juniperor an authorized Juniper reseller the applicable license(s) for use of the Software (“Customer”) (collectively, the “Parties”).

2. The Software. In this Agreement, “Software” means the program modules and features of the Juniper or Juniper-supplied software, for which Customer has paid the applicable license or support fees to Juniper or an authorized Juniper reseller, or which was embedded by Juniper in equipment which Customer purchased from Juniper or an authorized Juniper reseller. “Software” also includes updates, upgrades and new releases of such software. “Embedded Software” means Software which Juniper has embedded in or loaded onto the Juniper equipment and any updates, upgrades, additions or replacements which are subsequently embedded in or loaded onto the equipment.

3. License Grant. Subject to payment of the applicablefeesand the limitations andrestrictions set forthherein, Juniper grantsto Customer a non-exclusive and non-transferable license, without right to sublicense, to use the Software, in executable form only, subject to the following use restrictions:

a. Customer shall use Embedded Software solely as embedded in, and for execution on, Juniper equipment originally purchased by Customer from Juniper or an authorized Juniper reseller.

b. Customer shall use the Software on a single hardware chassis having a single processing unit, or as many chassis or processing units for which Customer has paid the applicable license fees; provided, however, with respect to the Steel-Belted Radius or Odyssey Access Client software only, Customer shall use such Software on a single computer containing a single physical random access memory space and containing any number of processors. Use of the Steel-Belted Radius or IMS AAA software on multiple computers or virtual machines (e.g., Solaris zones) requires multiple licenses, regardless of whether such computers or virtualizations are physically contained on a single chassis.

c. Product purchase documents, paper or electronic user documentation, and/or the particular licenses purchased by Customer may specify limitstoCustomer’suse ofthe Software.Such limitsmay restrict use toa maximum number of seats, registeredendpoints, concurrent users, sessions, calls, connections, subscribers, clusters, nodes, realms, devices, links, ports or transactions, or require the purchase of separate licenses to use particular features, functionalities, services, applications, operations, or capabilities, or provide throughput, performance, configuration, bandwidth, interface, processing, temporal, or geographical limits. In addition, such limits may restrict the use of the Software to managing certain kinds of networks or require the Software to be used only in conjunction with other specific Software. Customer’s use of the Software shall be subject to all such limitations and purchase of all applicable licenses.

d. For any trial copy of the Software, Customer’s right to use the Software expires 30 days after download, installation or use of the Software. Customer may operate the Software after the 30-day trial period only if Customer pays for a license to do so. Customer may not extend or create an additional trial period by re-installing the Software after the 30-day trial period.

e. The Global Enterprise Edition of the Steel-Belted Radius software may be used by Customer only to manage access to Customer’s enterprise network. Specifically, service provider customers are expressly prohibited from using the Global Enterprise Edition of the Steel-Belted Radius software to support any commercial network access services.

The foregoing license is not transferable or assignable by Customer. No license is granted herein to any user who did not originally purchase the applicable license(s) for the Software from Juniper or an authorized Juniper reseller.

4. Use Prohibitions. Notwithstanding the foregoing, the license provided herein does not permit the Customer to, and Customer agrees not to and shall not: (a) modify, unbundle, reverse engineer, or create derivative works based on the Software; (b) make unauthorized copies of the Software (except as necessary for backup purposes); (c) rent, sell, transfer, or grant any rights in and to any copy of the Software,in anyform, to anythird party; (d)removeany proprietary notices, labels,or marks on or in any copyof the Software or anyproduct in which the Software is embedded; (e) distribute any copy of the Software to any third party, including as may be embedded in Juniper equipment sold in thesecondhandmarket;(f) use any‘locked’ orkey-restricted feature,function, service, application,operation,or capability without first purchasing the applicable license(s) and obtaining a valid key from Juniper, even if such feature, function, service, application, operation, or capability is enabled without a key; (g) distribute any key for the Software provided by Juniper to any third party; (h) use the

Page 4

Software in any manner that extends or is broader than the uses purchased by Customer from Juniper or an authorized Juniper reseller; (i) use Embedded Software on non-Juniper equipment; (j) use Embedded Software (or make it available for use) on Juniper equipment that the Customer did not originally purchase from Juniper or an authorized Juniper reseller; (k) disclose the results of testing or benchmarking of the Software to any third party without the prior written consent of Juniper; or (l) use the Software in any manner other than as expressly provided herein.

5. Audit. Customer shall maintain accurate records as necessary to verify compliance with this Agreement. Upon request by Juniper, Customer shall furnish such records to Juniper and certify its compliance with this Agreement.

6. Confidentiality. The Parties agree that aspects of the Software and associated documentation are the confidential property of Juniper. As such, Customer shall exercise all reasonable commercialefforts to maintain the Software and associated documentation in confidence, which at a minimum includes restrictingaccess to the Software to Customer employees and contractors havinga need to use the Software for Customer’s internal business purposes.

7. Ownership. Juniper and Juniper’s licensors, respectively, retain ownership of all right, title, and interest (including copyright) in and to the Software, associated documentation, and all copies of the Software. Nothing in this Agreement constitutes a transfer or conveyance of any right, title, or interest in the Software or associated documentation, or a sale of the Software, associated documentation, or copies of the Software.

8. Warranty, Limitation of Liability, Disclaimer of Warranty. The warranty applicable to the Software shall be as set forth in the warranty statementthataccompaniesthe Software (the “Warranty Statement”). Nothing inthis Agreement shallgive rise to anyobligation tosupport the Software. Support services may be purchased separately. Any such support shall be governed by a separate, written support services agreement. TO THE MAXIMUM EXTENT PERMITTED BY LAW, JUNIPER SHALL NOT BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA, OR COSTS ORPROCUREMENT OFSUBSTITUTE GOODSOR SERVICES,OR FORANYSPECIAL,INDIRECT, ORCONSEQUENTIALDAMAGES ARISING OUTOF THIS AGREEMENT,THE SOFTWARE,OR ANY JUNIPEROR JUNIPER-SUPPLIED SOFTWARE. IN NOEVENT SHALL JUNIPER BE LIABLE FOR DAMAGES ARISING FROM UNAUTHORIZED OR IMPROPER USE OF ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE. EXCEPT AS EXPRESSLY PROVIDED IN THE WARRANTY STATEMENT TO THE EXTENT PERMITTED BY LAW, JUNIPER DISCLAIMS ANY AND ALL WARRANTIES IN AND TO THE SOFTWARE (WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE), INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT DOES JUNIPER WARRANT THAT THE SOFTWARE, OR ANY EQUIPMENT OR NETWORK RUNNING THE SOFTWARE, WILL OPERATE WITHOUT ERROR OR INTERRUPTION, OR WILL BE FREE OF VULNERABILITY TO INTRUSION OR ATTACK. In no event shall Juniper’s or its suppliers’ or licensors’ liability to Customer, whether in contract, tort (including negligence), breach of warranty, or otherwise, exceed the price paid by Customer for the Software that gave rise to the claim, or if the Software is embedded in another Juniper product, the price paid by Customer for such other product. Customer acknowledges and agrees that Juniper has set its prices and entered into this Agreement in reliance upon the disclaimers of warranty and the limitations of liability set forth herein, that the same reflect an allocation of risk between the Parties (including the risk that a contract remedy may fail of its essential purpose and cause consequential loss), and that the same form an essential basis of the bargain between the Parties.

9. Termination. Any breach of this Agreement or failure by Customer to pay any applicable fees due shall result in automatic termination of the license granted herein. Upon such termination, Customer shall destroy or return to Juniper all copies of the Software and related documentation in Customer’s possession or control.

10. Taxes. All license fees payable under this agreement are exclusive of tax. Customer shall be responsible for paying Taxes arising from the purchase of the license, or importation or use of the Software. If applicable, valid exemption documentation for each taxing jurisdiction shall be provided to Juniper prior to invoicing, and Customer shall promptly notify Juniper if their exemption is revoked or modified. All payments made by Customer shall be net of any applicable withholding tax. Customer will provide reasonable assistance to Juniper in connection with such withholding taxes by promptly: providing Juniper with valid tax receipts and other required documentation showing Customer’s payment of any withholding taxes; completing appropriate applications that would reduce the amount of withholding tax to be paid; and notifying and assisting Juniper in any audit or tax proceeding related to transactions hereunder. Customer shall comply with all applicable tax laws and regulations, and Customer will promptly pay or reimburse Juniper for all costs and damages related to any liability incurred by Juniper as a result of Customer’s non-compliance or delay with its responsibilities herein. Customer’s obligations under this Section shall survive termination or expiration of this Agreement.

11. Export. Customer agrees to comply with all applicable export laws and restrictions and regulations of any United States and any applicable foreign agency or authority, and not to export or re-export the Software or any direct product thereof in violation of any such restrictions, laws or regulations, or without all necessary approvals. Customer shall be liable for any such violations. The version of the Software supplied to Customer may contain encryption or other capabilities restricting Customer’s ability to export the Software without an export license.

Page 5

12. Commercial Computer Software. The Software is “commercial computer software” and is provided with restricted rights. Use, duplication, or disclosure by the United States government is subject to restrictions set forth in this Agreement and as provided in DFARS

227.7201 through 227.7202-4, FAR 12.212, FAR 27.405(b)(2), FAR 52.227-19, or FAR 52.227-14(ALT III) as applicable.

13. Interface Information. To the extent required by applicable law, and at Customer's written request, Juniper shall provide Customer with the interface information needed to achieve interoperability between the Software and another independently created program, on payment of applicable fee, if any. Customer shall observe strict obligations of confidentiality with respect to such information and shall use such information in compliance with any applicable terms and conditions upon which Juniper makes such information available.

14. Third Party Software. Any licensor of Juniper whose software is embeddedin the Software and any supplier of Juniper whose products or technology are embedded in (or services are accessed by) the Software shall be a third party beneficiary with respect to this Agreement, and such licensor or vendor shallhave theright to enforce this Agreement in its own nameas if it were Juniper. In addition, certain third party software may be provided with the Software and is subject to the accompanying license(s), if any, of its respective owner(s). To the extent portions of the Software are distributed under and subject to open source licenses obligating Juniper to make the source code for such portions publicly available (such as the GNU General Public License (“GPL”) or the GNU Library General Public License (“LGPL”)), Juniper will make such source code portions (including Juniper modifications, as appropriate) available upon request for a period of up to three years from the date of distribution. Such request can be made in writing to Juniper Networks, Inc., 1194 N. Mathilda Ave., Sunnyvale, CA 94089, ATTN: General Counsel. You may obtain a copy of the GPL at http://www.gnu.org/licenses/gpl.html, and a copy of the LGPL

at http://www.gnu.org/licenses/lgpl.html .

15. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws principles. The provisions of the U.N. Convention for the International Sale of Goods shall not apply to this Agreement. For any disputes arising under this Agreement, the Parties hereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal courts within Santa Clara County, California. This Agreement constitutes the entire and sole agreement between Juniper and the Customer with respect to the Software, and supersedes all prior and contemporaneous agreements relating to the Software, whether oral or written (including any inconsistent terms contained in a purchase order), except that the terms of a separate written agreement executed by an authorized Juniper representative and Customer shall govern to the extent such terms are inconsistent or conflict with terms contained herein. No modification to this Agreement nor any waiver of any rights hereunder shall be effective unless expressly assented to in writing by the party to be charged. If any portion of this Agreement is held invalid, the Parties agree that such invalidity shall not affect the validity of the remainder of this Agreement. This Agreement and associated documentation has been written in the English language, and the Parties agree that the English version will govern. (For Canada: Les parties aux présentés confirment leur volonté que cette convention de même que tous les documents y compris tout avis qui s'y rattaché, soient redigés en langue anglaise. (Translation: The parties confirm that this Agreement and all related documentation is and will be in the English language)).

Page 6

Page 7

Abbreviated Table of Contents

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii

Part 1 Border Gateway Protocol

Chapter 1 Configuring BGP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2 Monitoring BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Part 2 Multiprotocol Layer Switching

Chapter 3 MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Chapter 4 Configuring MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Chapter 5 Monitoring MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Chapter 6 Configuring BGP-MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Chapter 7 Monitoring BGP/MPLS VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Part 3 Layer 2 Services Over MPLS

Chapter 8 Layer 2 Services over MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

Chapter 9 Configuring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

Chapter 10 Monitoring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561

Part 4 Virtual Private LAN Service

Chapter 11 VPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573

Chapter 12 Configuring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589

Chapter 13 Monitoring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609

Part 5 Virtual Private Wire Service

Chapter 14 VPWS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639

Chapter 15 Configuring VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651

Chapter 16 Monitoring VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663

Part 6 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683

Page 8

JunosE 11.2.x BGP and MPLS Configuration Guide

Page 9

Table of Contents

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii

E Series and JunosE Documentation and Release Notes . . . . . . . . . . . . . . . . . . xxxiii

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii

E Series and JunosE Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . xxxiii

Obtaining Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxv

Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxv

Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxv

Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvi

Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvi

Part 1 Border Gateway Protocol

Chapter 1 Configuring BGP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Conventions in This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Autonomous Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

BGP Speaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

BGP Peers and Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

BGP Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

IBGP and EBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Interior Gateway Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

BGP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

BGP Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Routing Information Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Prefixes and CIDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Path Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Transit and Nontransit Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

IPv6 BGP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

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

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Before You Configure BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Basic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Enabling BGP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Understanding BGP Command Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Inheritance of Configuration Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Limitations on Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Page 10

JunosE 11.2.x BGP and MPLS Configuration Guide

Setting the BGP Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Configuring Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Configuring BGP Peer Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Setting the Peer Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Assigning a Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Logging Neighbor State Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

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

Controlling the Number of Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Removing Private AS Numbers from Updates . . . . . . . . . . . . . . . . . . . . . . . . . 35

Checking AS Path Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Enabling MD5 Authentication on a TCP Connection . . . . . . . . . . . . . . . . . . . . 37

Setting the Maximum Size of Update Messages . . . . . . . . . . . . . . . . . . . . . . . 38

Setting Automatic Fallover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Setting Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Automatic Summarization of Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Administrative Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Configuring BGP for Overload Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Enabling Route Storage in Adj-RIBs-Out Tables . . . . . . . . . . . . . . . . . . . . . . . 41

Configuring the Address Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Enabling Lenient Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Configuring Promiscuous Peers and Dynamic Peering . . . . . . . . . . . . . . . . . . 47

Configuring Passive Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Advertising Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Prefixes Originating in an AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Advertising Best Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Redistributing Routes into BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Redistributing Routes from BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Configuring a Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Setting the Minimum Interval Between Routing Updates . . . . . . . . . . . . . . . . 58

Aggregating Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Advertising Inactive Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Verifying an AS Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Advertising IPv4 Routes Between IPv6 BGP Peers . . . . . . . . . . . . . . . . . . . . . 63

Advertising Routes Conditionally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Configuring BGP Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Types of BGP Route Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Applying Table Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Access Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Effects of Changing Outbound Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Advertising Default Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Redistributing Default Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Setting a Static Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

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 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Filtering AS Paths with a Filter List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Page 11

Table of Contents

Filtering AS Paths with a Route Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Configuring the Community Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Community Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Resetting a BGP Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Changing Policies Without Disruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Soft Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Route-Refresh Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Cooperative Route Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Configuring Route Flap Dampening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Global Route Flap Dampening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Policy-Based Route Flap Dampening . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Policy Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Selecting the Best Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

BGP Path Decision Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Configuring Next-Hop Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Next-Hop-Self . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Assigning a Weight to a Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Using the neighbor weight Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Using a Route Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Using an AS-Path Access List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Configuring the Local-Pref Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Using the bgp default local-preference Command . . . . . . . . . . . . . . . . . 113

Using a Route Map to Set the Local Preference . . . . . . . . . . . . . . . . . . . . 114

Understanding the Origin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Understanding the AS-Path Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Configuring a Local AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Configuring the MED Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Missing MED Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Comparing MED Values Within a Confederation . . . . . . . . . . . . . . . . . . . 122

Capability Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Cooperative Route Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Dynamic Capability Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Four-Octet AS Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Graceful Restarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Configuring Hold Timers for Successful Graceful Restart in Scaled

Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Route Refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Interactions Between BGP and IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Synchronizing BGP with IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Disabling Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Setting the Administrative Distance for a Route . . . . . . . . . . . . . . . . . . . . . . . 133

Configuring Backdoor Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Setting the Maximum Number of Equal-Cost Multipaths . . . . . . . . . . . . . . . 138

Detecting Peer Reachability with BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

BFD and BGP Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Page 12

JunosE 11.2.x BGP and MPLS Configuration Guide

Managing a Large-Scale AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Configuring a Confederation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Configuring Route Reflectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Configuring BGP Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Monitoring BGP Multicast Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Using BGP Routes for Other Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Configuring BGP/MPLS VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Testing BGP Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Chapter 2 Monitoring BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Setting a Baseline on All BGP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Enabling Display of BGP Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Setting the Default Output Fields While Displaying Summarized Status of BGP

Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Setting the Default BGP Routing Table Output Fields . . . . . . . . . . . . . . . . . . . . . 159

Monitoring AS-Path Access Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Monitoring the BGP Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Monitoring Advertised BGP Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Monitoring BGP Aggregate Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Monitoring BGP Routes with Nonnatural Network Masks . . . . . . . . . . . . . . . . . . . 170

Monitoring BGP Routes in a Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Monitoring BGP Community Routes in the Community List . . . . . . . . . . . . . . . . . 173

Monitoring Dampened BGP Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Monitoring BGP Routes with Matching AS Paths and AS-Path Access Lists . . . . 176

Monitoring BGP Flap Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Monitoring BGP Routes with Inconsistent AS Paths . . . . . . . . . . . . . . . . . . . . . . . 178

Monitoring BGP Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Monitoring Dampened BGP Routes of Specified Neighbors . . . . . . . . . . . . . . . . . 185

Monitoring BGP Paths of Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Monitoring Prefix List Outbound Route Filters Received from the BGP

Neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Monitoring Routes Originating from a BGP Neighbor Before Application of

Inbound Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Monitoring Routes Originating froma BGPNeighbor After Application of Inbound

Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Monitoring Networks in an Autonomous System . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Monitoring BGP Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Monitoring BGP Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Monitoring BGP Peer Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Monitoring BGP Routes with Matching AS-Paths and Regular Expressions for

Single Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Monitoring BGP Routes with Matching AS-Paths and Regular Expressions for

Multiple Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Monitoring the Status of All BGP Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Monitoring All Routes in a BGP Community List . . . . . . . . . . . . . . . . . . . . . . . . . 204

Disabling Display of BGP Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Route Reflection and Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Route Reflection and Looping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Page 13

Table of Contents

Part 2 Multiprotocol Layer Switching

Chapter 3 MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Terminology for MPLS Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

MPLS Terms and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

MPLS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

MPLS Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

MPLS References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

MPLS Label Switching and Packet Forwarding Overview . . . . . . . . . . . . . . . . . . . 218

MPLS LSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

MPLS Label Switching: Push, Look Up, and Pop . . . . . . . . . . . . . . . . . . . . . . 219

MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

MPLS Labels and Label Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

TTL Processing in the Platform Label Space Overview . . . . . . . . . . . . . . . . . . . . 222

TTL Processing on Incoming MPLS Packets . . . . . . . . . . . . . . . . . . . . . . . . . 223

TTL Processing on Outgoing MPLS Packets . . . . . . . . . . . . . . . . . . . . . . . . . 224

Rules for Processing on an LSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Rules for Processing on an LER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

MPLS Rules for TTL Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

MPLS Label Distribution Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

IP Data Packet Mapping onto MPLS LSPs Overview . . . . . . . . . . . . . . . . . . . . . . 229

Statistics for IP Packets Moving On or Off MPLS LSPs . . . . . . . . . . . . . . . . . . . . . 231

MPLS Forwarding and Next-Hop Tables Overview . . . . . . . . . . . . . . . . . . . . . . . . 233

MPLS Packet Spoof Checking Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

IP and IPv6 Tunnel Routing Tables and MPLS Tunnels Overview . . . . . . . . . . . . 234

Explicit Routing for MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

MPLS Interfaces and Interface Stacking Overview . . . . . . . . . . . . . . . . . . . . . . . . 236

MPLS Major Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

MPLS Minor Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

MPLS Shim Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Interface Stacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

MPLS Label Distribution Protocols Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

LDP Messages and Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

RSVP-TE Messages and Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

RSVP-TE State Refresh and Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

BGP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

ECMP Labels for MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

MPLS Connectivity and ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Supported TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

MPLS Connectivity Verification and Troubleshooting Methods . . . . . . . . . . . . . . 244

Point-to-Multipoint LSPs Connectivity Verification at Egress Nodes

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Ping Extensions for Point-to-Multipoint LSPs Connectivity Verification at Egress

Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

RSVP P2MP IPv4 Session Sub-TLV Overview . . . . . . . . . . . . . . . . . . . . . . . . 247

P2MP Responder Identifier TLV Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Echo Jitter TLV Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Traceroute Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Page 14

JunosE 11.2.x BGP and MPLS Configuration Guide

TLVs and Sub-TLVs Supported for Point-to-Multipoint LSPs Connectivity

Verification at Egress Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Echo Jitter TLV Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

P2MP Responder Identifier TLV Operations . . . . . . . . . . . . . . . . . . . . . . . . . 249

LDP Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

LDP Basic Discovery Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

LDP Extended Discovery Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

MPLS Traffic Engineering Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

LSP Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Path Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Reoptimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Methods for Configuring RSVP-TE Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Tracking Resources for MPLS Traffic Engineering Overview . . . . . . . . . . . . . . . . . 253

Starting Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Admission Control Interface Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Configuring Traffic-Engineering Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 254

LSP Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Topology-Driven LSPs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

LDP over RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

LDP Graceful Restart Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

LDP-IGP Synchronization Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Synchronization Behavior During Graceful Restart . . . . . . . . . . . . . . . . . . . . 260

Synchronization Behavior on LAN Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 260

Synchronization Behavior on IGP Passive Interfaces . . . . . . . . . . . . . . . . . . 260

Synchronization and TE Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Use of RSVP-TE Hello Messages to Determine Peer Reachability . . . . . . . . . . . 260

Hello Message Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Hello Message Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Sequence of Hello Message Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Determination That a Peer Has Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

RSVP-TE Graceful Restart Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Announcement of the Graceful Restart Capability . . . . . . . . . . . . . . . . . . . . 263

Restarting Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Recovery Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Preservation of an Established LSP Label . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

RSVP-TE Hellos Based on Node IDs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

BFD Protocol and RSVP-TE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

Tunneling Model for Differentiated Services Overview . . . . . . . . . . . . . . . . . . . . . 267

Pipe and Short Pipe Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Uniform Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

EXP Bits for Differentiated Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Incoming Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Outgoing Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Setting the EXP Bits for Outgoing Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Egress Address P2MP Responder Identifier Sub-TLVs . . . . . . . . . . . . . 250

Node Address P2MP Responder Identifier Sub-TLVs . . . . . . . . . . . . . . 250

Behavior of the Requesting Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Behavior of the Acknowledging Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Behavior of Both Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Page 15

Table of Contents

Point-to-Multipoint LSPs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Using E Series Routers as Egress LSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Chapter 4 Configuring MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Basic MPLS Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

MPLS Global Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

MPLS Global Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

LDP Global Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

RSVP-TE Global Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

LDP and RSVP-TE Interface Profile Configuration Tasks . . . . . . . . . . . . . . . . . . . 280

LDP Interface Profile Configuration Tasks and Commands . . . . . . . . . . . . . . 281

RSVP-TE Interface Profile Configuration Tasks and Commands . . . . . . . . . 281

MPLS Interface Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

MPLS Interface Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

LDP Interface Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

RSVP-TE Interface Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

MPLS Tunnel Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

MPLS Tunnel Profile Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Configuring Explicit Routing for MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Defining Configured Explicit Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

Specifying Configured Explicit Paths on a Tunnel . . . . . . . . . . . . . . . . . . . . . 287

Configuring Dynamic Explicit Paths on a Tunnel . . . . . . . . . . . . . . . . . . . . . . 288

Additional LDP Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Configuring LDP FEC Deaggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Configuring LDP Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Configuring LDP Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

Configuring LDP-IGP Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Configuring LDP MD5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Controlling LDP Label Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Additional RSVP-TE Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Configuring RSVP MD5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Configuring RSVP-TE Fast Rerouting with RSVP-TE Bypass Tunnels . . . . . . . . . 295

Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

Fast Reroute over SONET/SDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Configuring RSVP-TE Hello Messages to Determine Peer Reachability . . . . . . . 297

Configuring RSVP-TE Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Configuring RSVP-TE Hellos Based on Node IDs . . . . . . . . . . . . . . . . . . . . . . . . . 299

Configuring the BFD Protocol for RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Configuring IGPs and MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Configuring the IGPs for Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . 302

Configuring MPLS and Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Configuring the Tunneling Model for Differentiated Services . . . . . . . . . . . . . . . 304

Configuring EXP Bits for Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . 304

Example Differentiated Services Application and Configuration . . . . . . . . . . . . . 305

Differentiated Services Configuration Example . . . . . . . . . . . . . . . . . . . . . . 306

Classifying Traffic for Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Configuring Static EXP-to-PHB Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Signaled Mapping for RSVP-TE Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

Preference of per-VR Versus per-LSP Behavior . . . . . . . . . . . . . . . . . . . . . . . 312

Page 16

JunosE 11.2.x BGP and MPLS Configuration Guide

Example Traffic Class Configuration for Differentiated Services . . . . . . . . . . . . . 313

Configuration on the Ingress Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

Configuration on the Ingress and Transit Routers . . . . . . . . . . . . . . . . . . . . . 315

Configuration on the Transit and Egress Routers . . . . . . . . . . . . . . . . . . . . . . 316

Configuring Point-to-Multipoint LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Chapter 5 Monitoring MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Setting the Baseline for MPLS Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

Setting a Baseline for MPLS Major Interface Statistics . . . . . . . . . . . . . . . . . 322

Enabling and Setting a Baseline for MPLS Forwarding Table Statistics . . . . 323

Enabling and Setting a Baseline for MPLS Next-Hop Table Statistics . . . . . 323

Setting a Baseline for MPLS Tunnel Statistics . . . . . . . . . . . . . . . . . . . . . . . . 324

Enabling Statistics Collection for Policies Attached to MPLS Tunnels . . . . . 324

Clearing and Re-Creating Dynamic Interfaces from MPLS Major Interfaces . . . . 324

Clearing and Refreshing IPv4 Dynamic Routes in the Tunnel Routing Table . . . . 325

Clearing and Refreshing IPv6 Dynamic Routes in the Tunnel Routing Table . . . . 325

Tracing Paths Through the MPLS User Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

Monitoring ATM VCs and VPI/VCI Ranges Used for MPLS . . . . . . . . . . . . . . . . . . 326

Monitoring Global Call Admission Control Configuration . . . . . . . . . . . . . . . . . . . 327

Monitoring Interfaces Configured with Traffic Engineering Bandwidth

Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Monitoring Virtual Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Monitoring IP and IPv6 Tunnel Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Monitoring LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

Monitoring MPLS Label Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Monitoring LDP Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Monitoring Interfaces That are Synchronizing with LDP . . . . . . . . . . . . . . . . . . . . 334

Monitoring LDP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

Monitoring LDP Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Monitoring LDP Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Monitoring LDP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Monitoring LDP Targeted Hello Receive and Send Lists . . . . . . . . . . . . . . . . . . . . 342

Monitoring MPLS Status and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

Monitoring MPLS Explicit Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Monitoring the RSVP-TE Bypass Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

Monitoring MPLS Labels Used for Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Monitoring MPLS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

Monitoring MPLS Minor Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

Monitoring MPLS Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

Monitoring the Configured Mapping between PHB IDs and Traffic Class/Color

Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

Monitoring RSVP-TE Profiles and MPLS Tunnel Profiles . . . . . . . . . . . . . . . . . . . 357

Monitoring RSVP Path State Control Blocks, Reservation State Control Blocks,

or Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

Monitoring RSVP MD5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

Monitoring RSVP-TE Interfaces Where BFD is Enabled . . . . . . . . . . . . . . . . . . . . 362

Monitoring RSVP-TE Interface Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Monitoring RSVP-TE Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

Monitoring RSVP-TE Hello Adjacency Instances . . . . . . . . . . . . . . . . . . . . . . . . . 366

Page 17

Table of Contents

Monitoring Status and Configuration for MPLS Tunnels . . . . . . . . . . . . . . . . . . . 368

Verifying and Troubleshooting MPLS Connectivity . . . . . . . . . . . . . . . . . . . . . . . . 370

Sending an MPLS Echo Request Packet to an IP or IPv6 Address . . . . . . . . . 371

Tracing the Path of an MPLS Echo Request Packet to an IP or IPv6

Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Sending an MPLS Echo Request Packet to a Martini Circuit . . . . . . . . . . . . . 371

Tracing the Path of an MPLS Echo Request Packet to a Martini Circuit . . . . 371

Sending an MPLS Echo Request Packet to an L3VPN IP or IPv6 Prefix . . . . . 371

Tracing the Path of an MPLS Echo Request Packet to an L3VPN IP or IPv6

Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Sending an MPLS Echo Request Packet to an RSVP-TE Tunnel . . . . . . . . . . 372

Tracing the Path of an MPLS Echo Request Packet to an RSVP-TE

Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Sending an MPLS Echo Request Packet to a VPLS Instance . . . . . . . . . . . . 372

Tracing the Path of an MPLS Echo Request Packet to a VPLS Instance . . . . 372

Packet Flow Examples for Verifying MPLS Connectivity . . . . . . . . . . . . . . . . . . . . 372

Packet Flow Examples for MPLS LSPs to an IP Prefix . . . . . . . . . . . . . . . . . . 373

Packet Flow Example for the ping mpls Command . . . . . . . . . . . . . . . . 373

Packet Flow Example for the trace mpls Command . . . . . . . . . . . . . . . 375

Packet Flows for ping and trace to L3VPN IPv4 Prefixes . . . . . . . . . . . . . . . . 376

Inter-AS Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

Packet Flows to L3VPN IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

Troubleshooting MTU Problems in Point-to-Point LSPs . . . . . . . . . . . . . . . . . . . 379

Troubleshooting MTU Problems in a Point-to-Point MPLS LSP Associated

with an IP or IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Troubleshooting MTU Problems in a Point-to-Point MPLS LSP Associated

with an L3VPN IP or IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Troubleshooting MTU Problems in a Point-to-Point MPLS LSP Associated

with a Martini Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Troubleshooting MTU Problems in a Point-to-Point MPLS LSP Associated

with an RSVP-TE Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Troubleshooting MTU Problems in a Point-to-Point MPLS LSP Associated

with a VPLS Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Chapter 6 Configuring BGP-MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Address Families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

Equal-Cost Multipath Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

BGP/MPLS VPN Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

VPN-IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

Route Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

Distribution of Routes and Labels with BGP . . . . . . . . . . . . . . . . . . . . . . . . . 390

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Transporting Packets Across an IP Backbone with MPLS . . . . . . . . . . . . . . . . . . 394

Configuring IPv6 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

Intra-AS IPv6 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

BGP Control Plane Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

CE–PE Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400

Page 18

JunosE 11.2.x BGP and MPLS Configuration Guide

PE–PE Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400

MPLS Data Plane Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400

Providing IPv4 VPN Services Across Multiple Autonomous Systems . . . . . . . . . 401

Inter-AS Option A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

Inter-AS Option B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Inter-AS Option C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

Inter-AS Option C with Route Reflectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Providing IPv6 VPN Services Across Multiple Autonomous Systems . . . . . . . . . 408

Using Route Targets to Configure VPN Topologies . . . . . . . . . . . . . . . . . . . . . . . 409

Full-Mesh VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

Hub-and-Spoke VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410

Overlapping VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Constraining Route Distribution with Route-Target Filtering . . . . . . . . . . . . . . . . 413

Exchanging Route-Target Membership Information . . . . . . . . . . . . . . . . . . . 414

Receiving and Sending RT-MEM-NLRI Routing Updates . . . . . . . . . . . . . . . . 415

Conditions for Advertising RT-MEM-NLRI Routes . . . . . . . . . . . . . . . . . . . . . 417

Advertising a Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

Route Selection When Route-Target Filtering Is Enabled . . . . . . . . . . . . . . . 419

Configuring Route-Target Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420

Multicast Services over VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Configuring BGP VPN Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

VRF Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

PE Router Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

Creating a VRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Specifying a Route Distinguisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Defining Route Targets for VRFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

Setting Import and Export Maps for a VRF . . . . . . . . . . . . . . . . . . . . . . . . . . 428

Global Export of IPv6 VPN Routes into the Global BGP IPv6 RIB . . . . . . . . . 433

Assigning an Interface to a VRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434

Defining Secondary Routing Table Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 435

Adding Static Routes to a VRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

Configuring IGPs on the VRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

Disabling Automatic Route-Target Filtering . . . . . . . . . . . . . . . . . . . . . . . . . 439

Creating Labels per FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439

Configuring PE-to-PE LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

Enabling BGP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

Enabling BGP ECMP for BGP/MPLS VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

Enabling VPN Address Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

Configuring PE-to-CE BGP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Characteristics of Import and Global Import Maps . . . . . . . . . . . . . . . . 429

Characteristics of Export and Global Export Maps . . . . . . . . . . . . . . . . 430

Subsequent Distribution of Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430

Creating a Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

Export Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

Global Export Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

Import Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

Global Import Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

Configuring the IGP in the VRF Context . . . . . . . . . . . . . . . . . . . . . . . . . 437

Configuring the IGP Outside the VRF Context . . . . . . . . . . . . . . . . . . . . 438

Page 19

Table of Contents

Advertising Static Routes to Customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Advertising IGP Routes to Customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Disabling the Default Address Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Using a Single AS Number for All CE Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

Preventing Routing Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

Advertising Prefixes with Duplicate AS Numbers . . . . . . . . . . . . . . . . . . . . . . 451

Controlling Route Importation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

Deleting Routes for a VRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

Enabling VRF–to–VR Peering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

Achieving Fast Reconvergence in VPN Networks . . . . . . . . . . . . . . . . . . . . . 455

Fast Reconvergence with Unique RDs . . . . . . . . . . . . . . . . . . . . . . . . . . 456

Fast Reconvergence by Means of Reachability Checking . . . . . . . . . . . . 457

Configuring BGP to Send Labeled and Unlabeled Unicast Routes . . . . . . . 458

BGP Next-Hop-Self . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

BGP Processing of Received Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Labeled Unicast Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Unlabeled Unicast Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Resolving IPv6 Indirect Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Labeled VPN Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

BGP Advertising Rules for Labeled and Unlabeled Routes with the Same

AFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Providing Internet Access to and from VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461

Enabling Traffic Flow from the VPN to the Internet . . . . . . . . . . . . . . . . . . . . 461

Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461

Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462

Configuring a Default Route to a Shared Interface . . . . . . . . . . . . . . . . 462

Configuring a Fallback Global Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

Configuring a Global Import Map for Specific Routes . . . . . . . . . . . . . . 464

Creating a BGP Session Between the CE Router and the Parent VR . . . . . . 465

Enabling Traffic Flow from the Internet to the VPN . . . . . . . . . . . . . . . . . . . 467

Static Routes to a Shared IP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 467

Global Export Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468

Carrier-of-Carriers IPv4 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469

Customer Carrier as an Internet Service Provider . . . . . . . . . . . . . . . . . . . . . 470

Configuration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

Customer Carrier as a VPN Service Provider . . . . . . . . . . . . . . . . . . . . . . . . . 472

Configuration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

Enabling Carrier-of-Carriers Support on a VRF . . . . . . . . . . . . . . . . . . . . . . . 474

Carrier-of-Carriers Using BGP as the Label Distribution Protocol . . . . . . . . 475

Carrier-of-Carriers IPv6 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

Connecting IPv6 Islands Across IPv4 Clouds with BGP . . . . . . . . . . . . . . . . . . . . 476

Connecting IPv6 Islands Across Multiple IPv4 Domains . . . . . . . . . . . . . . . . 477

Configuring IPv6 Tunneling over IPv4 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 478

OSPF and BGP/MPLS VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

Distributing OSPF Routes from CE Router to PE Router . . . . . . . . . . . . . . . . 479

Distributing Routes Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 480

Preserving OSPF Routing Information Across the MPLS/VPN Backbone . . 480

OSPF Domain Identifier Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480

OSPF Route Type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480

Page 20

JunosE 11.2.x BGP and MPLS Configuration Guide

Distributing OSPF Routes from PE Router to CE Router . . . . . . . . . . . . . . . . 481

Preventing Routing Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481

Using Remote Neighbors to Configure OSPF Sham Links . . . . . . . . . . . . . . 482

Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

Configuring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

Configuring L2VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

Chapter 7 Monitoring BGP/MPLS VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Enabling the MP-BGP Events Log Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Monitoring BGP Next Hops for VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Monitoring VRF Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

Monitoring VRF Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494

Monitoring the VRF Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496

Monitoring the VRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

Monitoring Load-Balanced Martini Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

Monitoring MPLS Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505

Disabling the MP-BGP Events Log Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

OSPF Backdoor Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482

OSPF Sham Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Part 3 Layer 2 Services Over MPLS

Chapter 8 Layer 2 Services over MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

Layer 2 Services over MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

Layer 2 Services over MPLS Platform Considerations . . . . . . . . . . . . . . . . . . . . . . 510

Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510

Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

Layer 2 Services over MPLS References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

Layer 2 Services over MPLS Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

Local Cross-Connects Between Layer 2 Interfaces Using MPLS Overview . . . . . 513

MPLS Shim Interfaces for Layer 2 Services over MPLS Overview . . . . . . . . . . . . . 514

Multiple Layer 2 Services over MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

ATM Layer 2 Services over MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

AAL5 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

OAM Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

QoS Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

Control Word Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

VCC Cell Relay Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

AAL0 Raw Cell Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

Cell Concatenation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

Cell Concatenation and Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

Control Word Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

Unsupported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

HDLC Layer 2 Services over MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Interface Stacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Control Word Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Local Cross-Connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

CE-Side MPLS L2VPNs over LAG Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

Page 21

Table of Contents

Ethernet Raw Mode Encapsulation for Martini Layer 2 Transport Overview . . . . 522

S-VLAN Subinterface with an Untagged C-VLAN ID Overview . . . . . . . . . . . . . . 524

Multiple ATM Virtual Circuits over a Single Pseudowire Overview . . . . . . . . . . . . 524

Guidelines for Configuring VPI/VCI Ranges of ATM Virtual Circuits . . . . . . . 527

Guidelines for Configuring Cell Concatenation and Cell Packing Timer for

an ATM Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

Performance Impact and Scalability Considerations . . . . . . . . . . . . . . . . . . 528

Chapter 9 Configuring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

Before You Configure Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . 529

Configuring Frame Relay Layer 2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530

Configuring Interoperation with Legacy Frame Relay Layer 2 Services . . . . . . . . 530

Configuring Ethernet/VLAN Layer 2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

Configuring S-VLAN Tunnels for Layer 2 Services . . . . . . . . . . . . . . . . . . . . . . . . 532

Configuring Local Cross-Connects Between Ethernet/VLAN Interfaces . . . . . . . 533

Configuring Local ATM Cross-Connects with AAL5 Encapsulation . . . . . . . . . . . 534

Configuring an MPLS Pseudowire with VCC Cell Relay Encapsulation . . . . . . . . 535

Configuring HDLC Layer 2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538

Local Cross-Connects for HDLC Layer 2 Services Configuration

Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539

CE-Side Load Balancing for Martini Layer 2 Transport . . . . . . . . . . . . . . . . . . . . . 539

Understanding CE Load Balancing for Martini Layer 2 Transport . . . . . . . . . 539

Configuration of Many Shim Interfaces with the Same Peer, VC Type, and

VC ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

Example: Configuring Many Shim Interfaces with the Same Peer, VC Type,

and VC ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

Load-Balancing Group Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

MPLS Interfaces and Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

Configuring Load-Balancing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

Adding a Member Interface to a Group Circuit . . . . . . . . . . . . . . . . . . . . 542

Removing Member Subinterfaces from a Circuit . . . . . . . . . . . . . . . . . . 543

Example: Configuring Frame Relay over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

Example: Configuring MPLS L2VPN Tunnel over VLAN over LAG . . . . . . . . . . . . 546

Configuration on CE1 (Local CE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547

Configuration on PE1 (Local PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547

Configuration on PE2 (Remote PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 548

Configuration on CE2 (Remote CE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 550

Example: Configuring MPLS L2VPN Tunnel over LAG . . . . . . . . . . . . . . . . . . . . . 550

Configuration on CE1 (Local CE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551

Configuration on PE1 (Local PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551

Configuration on PE2 (Remote PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 552

Configuration on CE2 (Remote CE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 553

Examples: Ethernet Raw Mode Encapsulation for Martini Layer 2 Transport . . . 553 Examples: Configuring S-VLAN Subinterface with an Untagged C-VLAN ID . . . 557

Example: Multiple ATM Virtual Circuits over a Single Pseudowire . . . . . . . . . . . . 559

Chapter 10 Monitoring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561

Setting Baselines for Layer 2 Services over MPLS Statistics . . . . . . . . . . . . . . . . . 561

Monitoring ATM Martini Cell Packing Timers for Layer 2 Services over MPLS . . . 562

Monitoring ATM Subinterfaces for Layer 2 Services over MPLS . . . . . . . . . . . . . . 562

Page 22

JunosE 11.2.x BGP and MPLS Configuration Guide

Monitoring ATM Cross-Connects for Layer 2 Services over MPLS . . . . . . . . . . . . 563

Monitoring MPLS Forwarding for Layer 2 Services over MPLS . . . . . . . . . . . . . . . 564

Monitoring MPLS Layer 2 Interfaces for Layer 2 Services over MPLS . . . . . . . . . 566

Part 4 Virtual Private LAN Service

Chapter 11 VPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573

VPLS Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573

VPLS Components Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

VPLS Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575

Customer Edge Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575

VPLS Edge Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575

VPLS and Transparent Bridging Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576

Subscriber Policies for VPLS Network Interfaces Overview . . . . . . . . . . . . . . . . . 577

Network Interface Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577

Default Subscriber Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577

Modifying Subscriber Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578

Considerations for VPLS Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 579

BGP Signaling for VPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579

LDP Signaling for VPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580

Targeted Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580

PWid FEC Element TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581

BGP Multihoming for VPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581

Designated VE Device Selection for a Multihomed Site . . . . . . . . . . . . . . . . 583

Multihoming Reaction to Failures in the Network . . . . . . . . . . . . . . . . . . . . . 585

VPLS Supported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585

VPLS Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586

Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586

Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587

VPLS References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587

Chapter 12 Configuring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589

Configuring VPLS with BGP Signaling on a PE Router . . . . . . . . . . . . . . . . . . . . . 590

Configuring VPLS Instances with BGP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 590

Configuring BGP Multihoming for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592

Configuring Optional Attributes for VPLS Instances . . . . . . . . . . . . . . . . . . . . . . 593

Configuring VPLS Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594

Configuring the Loopback Interface and Router ID for VPLS . . . . . . . . . . . . . . . . 595

Configuring MPLS LSPs for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596

Configuring BGP Signaling for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596

Example: Configuring VPLS with BGP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 598

Topology Overview of VPLS with BGP Signaling . . . . . . . . . . . . . . . . . . . . . 599

Configuration on PE 1 (Local PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600

Configuration on PE 2 (Remote PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 601

Configuring VPLS with LDP Signaling on a PE Router . . . . . . . . . . . . . . . . . . . . . 602

Configuring VPLS Instances with LDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 603

Configuring LDP Signaling for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604

Page 23

Table of Contents

Configuring Routing in the Core Network for VPLS . . . . . . . . . . . . . . . . . . . . . . . 604

Example: Configuring VPLS LDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605

Topology Overview of VPLS with LDP Signaling . . . . . . . . . . . . . . . . . . . . . 606

Configuration on PE 1 (Local PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606

Configuration on PE 2 (Remote PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . 607

Chapter 13 Monitoring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609

Setting the Baseline for VPLS Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609

Setting a Baseline for a VPLS Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610

Setting a Baseline for a Network Interface associated with a VPLS

Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610

Setting a Baseline for the VPLS Virtual Core Interface associated with a

VPLS Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610

Clearing Dynamic MAC Addresses from the VPLS Forwarding Table . . . . . . . . . 610

Clearing All Dynamic MAC Addresses from the VPLS Forwarding Table . . . . 611

Clearing a Specific Dynamic MAC Addresses from the VPLS Forwarding

Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611

Clearing All Dynamic MAC Addresses for a Network Interface associated

with a VPLS Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611

Clearing All Dynamic MAC Addresses for the VPLS Virtual Core Interface

associated with a VPLS Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611

Clearing BGP Attributes for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

Clearing BGP Reachability Information for the L2VPN Address Family . . . . 612

Clearing BGP Route Flap Dampening Information for the L2VPN Address

Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

Clearing BGP Route Flap Dampening Information for the VPWS Address

Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

Clearing the Wait for End-of-RIB Marker for the L2VPN Address Family . . . 612

Monitoring VPLS Configuration and Statistics for a Specific VPLS Instance . . . . 613

Monitoring VPLS Configuration and Statistics for All VPLS Instances . . . . . . . . . 614

Monitoring Configuration, Statistics, and Status for VPLS Network Interfaces . . 616

Monitoring Configuration, Statistics, and Status for VPLS Core Interfaces . . . . . 619

Monitoring Configuration, Statistics, and Status for VPLS Ports . . . . . . . . . . . . . 621

Monitoring MAC Address Entries for a Specific VPLS Instance . . . . . . . . . . . . . . 624

Monitoring Subscriber Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625

Monitoring Layer2 NLRI for VPLS Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626

Monitoring BGP Next Hops for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629

Monitoring LDP-Related Settings for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630

Monitoring MPLS-Related Settings for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631

Monitoring VPLS-Specific Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632

Part 5 Virtual Private Wire Service

Chapter 14 VPWS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639

VPWS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639

BGP Signaling for L2VPNs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641

VPWS Components Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642

VPWS Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

Customer Edge Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

VPWS Provider Edge Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

Page 24

JunosE 11.2.x BGP and MPLS Configuration Guide

VPWS and BGP/MPLS VPNs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

BGP Multihoming for VPWS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

Designated VE Device Selection for a Multihomed Site . . . . . . . . . . . . . . . . . . . . 646

Multihoming Reaction to Failures in the Network . . . . . . . . . . . . . . . . . . . . . . . . 648

VPWS Supported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649

VPWS Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649

Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649

Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650

VPWS References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650

Chapter 15 Configuring VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651

Configuring VPWS on a PE Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651

Configuring an VPWS Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652

Configuring BGP Multihoming for VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653

Types of Interfaces to Configure in the VPWS Instance . . . . . . . . . . . . . . . . . . . . 654

Configuring Customer-Facing Interfaces in the VPWS Instance . . . . . . . . . . . . . 654

Local Cross-Connects for VPWS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655

Configuring a Local Cross-Connect for VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . 655

BGP Loopback Interface and Router ID Overview . . . . . . . . . . . . . . . . . . . . . . . . 656

Configuring the Loopback Interface and Router ID for BGP for VPWS . . . . . . . . 656

BGP Signaling for VPWS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656

Configuring BGP Signaling for VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657

MPLS LSPs for VPWS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658

Configuring MPLS LSPs for VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658

Example: Configuring VPWS on Local and Remote Routers . . . . . . . . . . . . . . . . 659

Topology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659

Configuration on PE 1 (Local PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660

Configuration on PE 2 (Remote PE Router) . . . . . . . . . . . . . . . . . . . . . . . . . . 661

Chapter 16 Monitoring VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663

Clearing BGP Attributes for VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663

Clearing BGP Reachability Information for the L2VPN Address Family . . . . 663

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

Monitoring BGP Next Hops for VPWS L2VPNS . . . . . . . . . . . . . . . . . . . . . . . . . . 669

Monitoring VPWS Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670

Monitoring VPWS Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673

Monitoring L2VPN Interfaces for VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675

Monitoring MPLS Forwarding Table for VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664

Part 6 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683

Page 25

List of Figures

Part 1 Border Gateway Protocol

Chapter 1 Configuring BGP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Figure 1: BGP Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Figure 2: Internal and External BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Figure 3: Interior Gateway Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figure 4: Routing Without CIDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 5: Routing with CIDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 6: Transit Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 7: Nontransit Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 8: IPv6 Routing over TCP IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 9: IPv6 Routing over TCP IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 10: Configuring Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 11: BGP Peer Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Figure 12: Using EBGP-Multihop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Figure 13: Prefixes Originating in an AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Figure 14: Redistributing Routes into BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Figure 15: Advertising a Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Figure 16: Setting a Static Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Figure 17: Configuring Aggregate Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

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 21: Filtering with Access Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Figure 22: Filtering Routes with an Access List . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Figure 23: Filtering with AS-Path Access Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Figure 24: Assigning a Filter List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Figure 25: Route Map Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Figure 26: Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Figure 27: Community Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Figure 28: Configuring Next-Hop Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

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

Figure 32: Configuring the Local-Preference Attribute . . . . . . . . . . . . . . . . . . . . . . 113

Figure 33: The Origin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Figure 34: AS-Path Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Figure 35: Configuring the MED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Figure 36: Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Figure 37: Disabling Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Figure 38: Administrative Distances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Page 26

JunosE 11.2.x BGP and MPLS Configuration Guide

Figure 39: Administrative Distance and Synchronization . . . . . . . . . . . . . . . . . . . 136

Figure 40: Backdoor Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Figure 41: A Fully Meshed Autonomous System . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Figure 42: A Confederation of Subautonomous Systems . . . . . . . . . . . . . . . . . . . 143

Figure 43: Simple Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Figure 44: Route Reflection: Logical Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 146

Figure 45: Route Reflection: Physical and Logical Redundancy . . . . . . . . . . . . . . 146

Figure 46: BGP Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Part 2 Multiprotocol Layer Switching

Chapter 3 MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Figure 47: Simple MPLS Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Figure 48: Label Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Figure 49: Label Stacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Figure 50: Shim Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Figure 51: TTL Processing on Incoming MPLS Packets . . . . . . . . . . . . . . . . . . . . . 224

Figure 52: TTL Processing on Outgoing MPLS Packets . . . . . . . . . . . . . . . . . . . . 226

Figure 53: LSP Creation, Downstream-on-Demand, Ordered Control . . . . . . . . . 228

Figure 54: LSP Creation, Downstream-Unsolicited, Independent Control . . . . . 229

Figure 55: Explicit Routing in an MPLS Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Figure 56: MPLS Interface Stacking for the Platform Label Space . . . . . . . . . . . 237

Figure 57: MPLS Interface Stacking for the Interface Label Space . . . . . . . . . . . 238

Figure 58: LDP Tunneled Through an RSVP-TE Core . . . . . . . . . . . . . . . . . . . . . . 256

Figure 59: Flow for Initial Setting of EXP Bits for the First Label Pushed . . . . . . . 270

Figure 60: Flow for Setting EXP Bits for All Pushed Labels . . . . . . . . . . . . . . . . . . 271

Figure 61: Simple MPLS Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Chapter 4 Configuring MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Figure 62: FEC Aggregation and Equal-Cost Paths . . . . . . . . . . . . . . . . . . . . . . . 289

Figure 63: Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Figure 64: Differentiated Services over an MPLS Network . . . . . . . . . . . . . . . . . 306

Figure 65: Associations Between PHB ID, EXP Bits, and Traffic

Classes/Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Figure 66: Signaled Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Chapter 5 Monitoring MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Figure 67: Sample MPLS L3VPN Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Chapter 6 Configuring BGP-MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Figure 68: ECMP BGP/MPLS VPN Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

Figure 69: BGP/MPLS VPN Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Figure 70: BGP/MPLS VPN Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

Figure 71: Route and Label Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390

Figure 72: Standard and Extended BGP Update Messages . . . . . . . . . . . . . . . . . 392

Figure 73: BGP/MPLS VPN Route Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

Figure 74: LSP Creation for BGP/MPLS VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

Figure 75: Traffic Across the MPLS Backbone of a BGP/MPLS VPN . . . . . . . . . . 396

Figure 76: IPv6 VPN Services over IPv4 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Figure 77: Inter-AS Topology with VRFs on Each AS Boundary Router . . . . . . . . 401

Page 27

List of Figures

Figure 78: Inter-AS Topology with End-to-End Stacked MPLS Tunnels . . . . . . . 402

Figure 79: Topology for Three-label Stack Configuration for Inter-AS Option

C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

Figure 80: Topology for Inter-AS Option C with Route Reflectors . . . . . . . . . . . . 408

Figure 81: Inter-AS IPv6 VPN Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

Figure 82: Site Connectivity in a Full-Mesh VPN . . . . . . . . . . . . . . . . . . . . . . . . . . 410

Figure 83: Route Target Configuration for a Full-Mesh VPN . . . . . . . . . . . . . . . . . 410

Figure 84: Site Connectivity in a Hub-and-Spoke VPN . . . . . . . . . . . . . . . . . . . . . 411

Figure 85: Route Target Configuration for a Hub-and-Spoke VPN . . . . . . . . . . . . 411

Figure 86: Site Connectivity in an Overlapping VPN . . . . . . . . . . . . . . . . . . . . . . . 412

Figure 87: Route Target Configuration for an Overlapping VPN . . . . . . . . . . . . . . 412

Figure 88: Overlapping VPNs on a Single PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Figure 89: Fully Meshed VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426

Figure 90: Hub-and-Spoke VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

Figure 91: Import and Export Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429

Figure 92: Configuring Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

Figure 93: BGP/MPLS VPN IBGP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442

Figure 94: BGP/MPLS VPN EIBGP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

Figure 95: PE-to-CE Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Figure 96: Network with Potential Routing Loops . . . . . . . . . . . . . . . . . . . . . . . . 449

Figure 97: Preventing Potential Routing Loops in the Network . . . . . . . . . . . . . . 450

Figure 98: Allowing Local AS in VPNv4 Address Family . . . . . . . . . . . . . . . . . . . . 451

Figure 99: Topology for Fast Reconvergence by Means ofUnique VRFRDs, Before

Tunnels Go Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456

Figure 100: Topology for Fast Reconvergenceby Means of Reachability Checking,

After Tunnels Go Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

Figure 101: Static Default Route for Internet Access . . . . . . . . . . . . . . . . . . . . . . . 463

Figure 102: Fallback Global Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464

Figure 103: Global Import Map Applied to Routes Imported from VRF BGP

RIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465

Figure 104: BGP Session Between CE Router and Parent VR . . . . . . . . . . . . . . . 466

Figure 105: Static Route to Shared IP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 468

Figure 106: Global Export Map Applied to Routes Exported from VRF BGP

RIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469

Figure 107: Carrier-of-Carriers Internet Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

Figure 108: Carrier-of-Carriers VPN Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

Figure 109: Carrier-of-Carrier IPv6 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

Figure 110: IPv6 Tunneled over MPLS-IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

Figure 111: IPv6 Tunneled Across IPv4 Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

Figure 112: OSPF Topology with Backdoor Link . . . . . . . . . . . . . . . . . . . . . . . . . . . 482

Figure 113: OSPF Sham Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Part 3 Layer 2 Services Over MPLS

Chapter 8 Layer 2 Services over MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

Figure 114: Layer 2 Services over a Provider’s MPLS Network . . . . . . . . . . . . . . . . 510

Figure 115: Common ISP Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

Figure 116: E Series Router Replacing Remote ATM Switch . . . . . . . . . . . . . . . . . . 516

Figure 117: AAL5 Pseudowire and MPLS Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

Page 28

JunosE 11.2.x BGP and MPLS Configuration Guide

Figure 118: CE-Side MPLS L2VPN Tunnel over LAG . . . . . . . . . . . . . . . . . . . . . . . . 521

Chapter 9 Configuring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

Figure 119: Local Cross-Connect Between Ethernet/VLAN Interfaces . . . . . . . . . 533

Figure 120: CE-Side Load-Balancing Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

Figure 121: Sample Frame Relay over MPLS Configuration . . . . . . . . . . . . . . . . . . 543

Figure 122: MPLS L2VPN Tunnel over VLAN over LAG Configuration Example . . 547

Figure 123: MPLS L2VPN Tunnel over LAG Configuration Example . . . . . . . . . . . 551

Figure 124: MPLS L2VPN Tunnel over LAG Configuration Example . . . . . . . . . . . 554

Figure 125: Ethernet Packet Distribution over Martini Circuits . . . . . . . . . . . . . . . 556

Figure 126: Martini Circuit with Two Pseudowires Between PE-Facing

Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557

Figure 127: Martini Circuit Deployment for Transmission of Multiple ATM VCs

over a SIngle Pseudowire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

Part 4 Virtual Private LAN Service

Chapter 11 VPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573

Figure 128: VPLS Sample Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

Chapter 12 Configuring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589

Figure 129: Topology for VPLS Configuration Example with BGP Signaling . . . . 599

Figure 130: Topology for VPLS Configuration Example with LDP Signaling . . . . 606

Part 5 Virtual Private Wire Service

Chapter 14 VPWS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639

Figure 131: VPWS Sample Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640

Figure 132: VPWS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642

Chapter 15 Configuring VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651

Figure 133: VPWS Cross-Connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655

Figure 134: Topology for VPWS Configuration Example . . . . . . . . . . . . . . . . . . . . 659

Page 29

List of Tables

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii

Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiv

Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiv

Part 1 Border Gateway Protocol

Chapter 1 Configuring BGP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Table 3: Conventions for BGP Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Table 4: Cease Notification Message Subcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Table 5: Commands Affecting BGP Globally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

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 10: Behavior of Neighbor Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Table 11: Inheritance from Other Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

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

Table 21: Default Administrative Distances for Route Sources . . . . . . . . . . . . . . . 134

Chapter 2 Monitoring BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Table 22: show bgp summary Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Table 23: show ip bgp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Table 24: show ip as-path-access-list Output Fields . . . . . . . . . . . . . . . . . . . . . . 162

Table 25: show ip bgp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Table 26: show ip bgp advertised-routes Output Fields . . . . . . . . . . . . . . . . . . . . 168

Table 27: show bgp ipv6 aggregate-address Output Fields . . . . . . . . . . . . . . . . . 169

Table 28: show ip bgp cidr-only Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Table 29: show ip bgp community Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 172

Table 30: show ip bgp community-list Output Fields . . . . . . . . . . . . . . . . . . . . . . 173

Peer Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Peer or Peer Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Page 30

JunosE 11.2.x BGP and MPLS Configuration Guide

Table 31: show ip bgp dampened-paths Output Fields . . . . . . . . . . . . . . . . . . . . . 175

Table 32: show ip bgp filter-list Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Table 33: show ip bgp flap-statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . 178

Table 34: show ip bgp inconsistent-as Output Fields . . . . . . . . . . . . . . . . . . . . . . 179

Table 35: show ip bgp neighbors Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Table 36: show ip bgp neighbors dampened-routes Output Fields . . . . . . . . . . . 186

Table 37: show ip bgp neighbors paths Output Fields . . . . . . . . . . . . . . . . . . . . . . 187

Table 38: show ip bgp neighbors received prefix-filter . . . . . . . . . . . . . . . . . . . . . 188

Table 39: show ip bgp neighbors received-routes Output Fields . . . . . . . . . . . . . 188

Table 40: show bgp ipv6 neighbors routes Output Fields . . . . . . . . . . . . . . . . . . 190

Table 41: show bgp ipv6 network Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Table 42: show ip bgp next-hops Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Table 43: show bgp ipv6 paths Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Table 44: show ip bgp peer-group Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 194

Table 45: show ip bgp quote-regexp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 197

Table 46: show ip bgp regexp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Table 47: show bgp ipv6 summary Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 201

Table 48: show ip community-list Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 205

Part 2 Multiprotocol Layer Switching

Chapter 3 MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Table 49: Conventions for MPLS Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Table 50: MPLS Terms and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Table 51: TLVs Supported by MPLS LSP ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Table 52: Sub-TLVs Supported for the Target FEC Stack TLV . . . . . . . . . . . . . . . 244

Table 53: Sub-TLVs Supported for the P2MP Responder Identifier TLV . . . . . . . 249

Table 54: Summary of LDP Graceful Restart States . . . . . . . . . . . . . . . . . . . . . . . 257

Chapter 4 Configuring MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Table 55: Configuration Tasks by Type of Network . . . . . . . . . . . . . . . . . . . . . . . . 276

Table 56: Incoming L-LSP PHB Determination . . . . . . . . . . . . . . . . . . . . . . . . . . 308

Table 57: Examples of Incoming L-LSP PHB Determination . . . . . . . . . . . . . . . . 308

Table 58: Outgoing L-LSP PHB Determination . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Table 59: Differentiated Services Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Chapter 5 Monitoring MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Table 60: show atm vc Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

Table 61: show cac interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Table 62: show ip tunnel route and show ipv6 tunnel-route Output Fields . . . . 330

Table 63: show ldp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

Table 64: show ldp binding and show mpls binding Output Fields . . . . . . . . . . . 333

Table 65: show ldp graceful restart Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 333

Table 66: show ldp igp-sync Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

Table 67: show ldp interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

Table 68: show ldp neighbor Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

Table 69: show ldp profile Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Table 70: show ldp statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

Table 71: show ldp targeted session Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 343

Table 72: show mpls Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

Page 31

List of Tables

Table 73: show mpls explicit-paths Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 346

Table 74: show mpls fast-reroute Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 346

Table 75: show mpls forwarding Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Table 76: show mpls interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

Table 77: show mpls minor-interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . 355

Table 78: show mpls next-hop Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

Table 79: show mpls phb-id Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Table 80: show mpls profile Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Table 81: show mpls rsvp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Table 82: show mpls rsvp authentication Output Fields . . . . . . . . . . . . . . . . . . . 362

Table 83: show mpls rsvp bfd interfaces Output Fields . . . . . . . . . . . . . . . . . . . . 363

Table 84: show mpls rsvp counters Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 364

Table 85: show mpls rsvp hello graceful restart Output Fields . . . . . . . . . . . . . . 366

Table 86: show mpls rsvp hello instance Output Fields . . . . . . . . . . . . . . . . . . . . 367

Table 87: show mpls tunnels Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

Chapter 6 Configuring BGP-MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Table 88: Route-Target Filtering Advertisement Rules for Routes Received from

Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416

Table 89: Characteristics of Import and Global Import Maps . . . . . . . . . . . . . . . 430

Table 90: Characteristics of Export and Global Export Maps . . . . . . . . . . . . . . . 430

Table 91: Resolution of Indirect Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Table 92: Advertising Action Taken Following Best Route Selection . . . . . . . . . . 461

Table 93: Route Types and Route Origins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480

Chapter 7 Monitoring BGP/MPLS VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Table 94: show ip bgp next-hop Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 490

Table 95: show ip interface vrf Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

Table 96: show ip protocols Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494

Table 97: show ip route Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496

Table 98: show ip vrf Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

Table 99: show mpls l2transport load-balancing-group Output Fields . . . . . . . 504

Table 100: show mpls tunnels Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505

Part 3 Layer 2 Services Over MPLS

Chapter 9 Configuring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

Table 101: Martini Circuit Scenarios Without Ethernet Raw Mode . . . . . . . . . . . . 554

Table 102: Martini Circuit Scenarios with Ethernet Raw Mode . . . . . . . . . . . . . . . 555

Chapter 10 Monitoring Layer 2 Services over MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561

Table 103: show atm mcpt-timers Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 562

Table 104: show atm subinterface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 563

Table 105: show mpls cross-connects atm Output Fields . . . . . . . . . . . . . . . . . . 564

Table 106: show mpls forwarding Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 565

Table 107: show mpls interface and show mpls l2transport interface Output

Part 4 Virtual Private LAN Service

Chapter 11 VPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573

Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

Page 32

JunosE 11.2.x BGP and MPLS Configuration Guide

Table 108: VPLS Forwarding Table on PE 1 for VPLS A . . . . . . . . . . . . . . . . . . . . . 576

Table 109: VPLS Forwarding Table on PE 1 for VPLS B . . . . . . . . . . . . . . . . . . . . . 576

Table 110: VPLS Forwarding Table on PE 2 for VPLS A . . . . . . . . . . . . . . . . . . . . . 576

Table 111: VPLS Forwarding Table on PE 2 for VPLS B . . . . . . . . . . . . . . . . . . . . . . 577

Table 112: Default Subscriber Policies for VPLS Network Interfaces . . . . . . . . . . 578

Table 113: Commands to Configure Subscriber Policies . . . . . . . . . . . . . . . . . . . . 579

Chapter 12 Configuring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589

Table 114: Commands to Configure Basic VPLS Instances . . . . . . . . . . . . . . . . . 590

Table 115: Commands to Configure BGP Signaling for VPLS . . . . . . . . . . . . . . . . 597

Table 116: Commands to Configure LDP Signaling for VPLS . . . . . . . . . . . . . . . . 604

Table 117: Commands to Configure OSPF for a VPLS Network . . . . . . . . . . . . . . 605

Chapter 13 Monitoring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609

Table 118: show bridge Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613

Table 119: show bridge groups details Output Fields . . . . . . . . . . . . . . . . . . . . . . . 615

Table 120: show bridge interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 618

Table 121: show bridge interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

Table 122: show bridge interface vpls Output Fields . . . . . . . . . . . . . . . . . . . . . . 620

Table 123: show bridge port Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622

Table 124: show bridge port brief Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 624

Table 125: show bridge table Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624

Table 126: show subscriber-policy Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 626

Table 127: show ip bgp l2vpn Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628

Table 128: show ip bgp next-hops Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 629

Table 129: show ldp vpls Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630

Table 130: show mpls forwarding Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 631

Table 131: show vpls connections Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 634

Part 5 Virtual Private Wire Service

Chapter 14 VPWS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639

Table 132: Components of VPWS NLRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641

Chapter 15 Configuring VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651

Table 133: Commands to Configure Basic VPWS Instances . . . . . . . . . . . . . . . . 652

Table 134: Commands to Configure BGP Signaling for VPWS . . . . . . . . . . . . . . 656

Chapter 16 Monitoring VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663

Table 135: Commands for Monitoring BGP Settings for the VPWS Address

Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665

Table 136: Commands for Monitoring BGP Settings for the VPWS Address

Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665

Table 137: show ip bgp l2vpn Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667

Table 138: show ip bgp l2vpn all next-hops Output Fields . . . . . . . . . . . . . . . . . 669

Table 139: show l2vpn connections Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 672

Table 140: show l2vpn instance Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 674

Table 141: show l2vpn interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 676

Table 142: show mpls forwarding Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 678

Page 33

About the Documentation

•

E Series and JunosE Documentation and Release Notes on page xxxiii

•

Audience 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 SeriesBroadband Services Routers in an Internet access environment.

E Series and JunosE Text and Syntax Conventions

Table 1 on page xxxiv defines notice icons used in this documentation.

Page 34

JunosE 11.2.x BGP and MPLS Configuration Guide

Table 1: Notice Icons

Table 2 on page xxxiv defines text and syntax conventions that we use throughout the E Series and JunosE documentation.

DescriptionMeaningIcon

Indicates important features or instructions.Informational note

Indicates a situation that might result in loss of data or hardware damage.Caution

Alerts you to the risk of personal injury or death.Warning

Alerts you to the risk of personal injury from a laser.Laser warning

Table 2: Text and Syntax Conventions

Representscommandsand keywordsin text.Bold text like this

Fixed-width text like this

Italic text like this

Plus sign (+) linking key names

Syntax Conventions in the Command Reference Guide

Representsinformationas displayedon your terminal’s screen.

•

Emphasizes words.

•

Identifies variables.

•

Identifies chapter, appendix, and book names.

keys simultaneously.

ExamplesDescriptionConvention

•

Issue the clock source command.

•

Specify the keyword exp-msg.

host1(config)#traffic class low-loss1Represents text that the user must type.Bold text like this

host1#show ip ospf 2

Routing Process OSPF 2 with Router ID 5.5.0.250 Router is an Area Border Router (ABR)

•

There are two levels of access: user and privileged.

•

clusterId, ipAddress.

•

Appendix A, System Specifications

Press Ctrl + b.Indicates that you must press two or more

terminal lengthRepresents keywords.Plain text like this

mask, accessListNameRepresents variables.Italic text like this

Page 35

Table 2: Text and Syntax Conventions (continued)

About the Documentation

ExamplesDescriptionConvention

| (pipe symbol)

or variable to the left or to the right of this symbol. (The keyword or variable can be either optional or required.)

[ ]* (brackets and asterisk)

that can be entered more than once.

Represent required keywords or variables.{ } (braces)

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

diagnostic | lineRepresents a choice to select one keyword

[ internal | external ]Represent optional keywords or variables.[ ] (brackets)

[ level1 | level2 | l1 ]*Represent optional keywords or variables

{ permit | deny } { in | out }

{ clusterId | ipAddress }

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 athttp://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

techpubs-comments@juniper.net, 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 productsupport isavailable through theJuniper NetworksTechnical Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,

Page 36

JunosE 11.2.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 verifyservice entitlement by product serialnumber, 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 .

Page 37

PART 1

Border Gateway Protocol

•

Configuring BGP Routing on page 3

•

Monitoring BGP on page 157

Page 38

JunosE 11.2.x BGP and MPLS Configuration Guide

Page 39

CHAPTER 1

Configuring BGP Routing

This chapter contains the following sections:

•

Overview on page 3

•

Platform Considerations on page 14

•

References on page 15

•

Features on page 16

•

Before You Configure BGP on page 17

•

Configuration Tasks on page 17

•

Basic Configuration on page 17

•

Configuring BGP Peer Groups on page 27

•

Advertising Routes on page 50

•

Configuring BGP Routing Policy on page 70

•

Selecting the Best Path on page 104

•

Interactions Between BGP and IGPs on page 131

•

Detecting Peer Reachability with BFD on page 138

•

Managing a Large-Scale AS on page 141

•

Configuring BGP Multicasting on page 150

•

Using BGP Routes for Other Protocols on page 153

•

Configuring BGP/MPLS VPNs on page 154

•

Testing BGP Policies on page 154

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 usedwith BGP,such as thenames 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. Table 3 on page 4 lists the terms and their variant spellings.

Page 40

JunosE 11.2.x BGP and MPLS Configuration Guide

Table 3: Conventions for BGP Terms

In RFCsIn This Chapter

AGGREGATORaggregator

AS_CONFED_SETAS-confed-set

AS_PATHAS-path or AS path

AS_SEQUENCEAS-sequence

AS_SETAS-set

ATOMIC_AGGREGATEatomic-aggregate

CLUSTER_LISTcluster-list

KEEPALIVEkeepalive

LOCAL_PREFlocal-pref

MULTI_EXIT_DISCmultiexit discriminator or MED

NEW_AS_PATHnew-as-path

NEW_AGGREGATORnew-aggregator

NEXT_HOPnext-hop or next hop

NO_ADVERTISEno-advertise

NO_EXPORTno-export

NO_EXPORT_SUBCONFEDno-export-subconfed

NOTIFICATIONnotification

OPENopen

ORIGINorigin

ORIGINATOR_IDoriginator-ID

ROUTE-REFRESHroute-refresh

UPDATEupdate

Page 41

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 calleda BGPspeaker.

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.

Chapter 1: Configuring BGP Routing

Figure 1: BGP Peers

BGP Session

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.

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

Page 42

JunosE 11.2.x BGP and MPLS Configuration Guide

TCP connection over which routing information is exchanged according to the rules of the BGP protocol.

Because BGP relieson TCP to provide reliableand flow-controlled transmission ofrouting information, the BGP protocol itself isvery simple. However it also impliesthat 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, orEBGP 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 BGPspeakerswithin anautonomous system be fullymeshed, meaning that there must be a BGP session between each pair of peers within the AS. IBGP does not require that allthe peersbe physically connected.EBGP doesnot require full meshing of BGP speakers. EBGP sessions typically exist between peers that are physically connected.

Figure 2 on page 6 shows an example of the exchange of information between routers running IBGP and EBGP across multiple ASs.

Figure 2: Internal and External BGP

Page 43

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)

Figure 3 on page 7 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

Chapter 1: Configuring BGP Routing

BGP Messages

BGP speakers exchangerouting information with eachother 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.

Page 44

JunosE 11.2.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 thesession isbeing 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. Table 4 on page 8 lists the subcodes defined for BGP notification messages bearing the cease code.

Table 4: Cease Notification Message Subcodes

Symbolic NameReasonSubcode

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.

shutting down the session.

configuration.

resetting the session.

connection (for example, because the peer is not configured locally on the speaker) after accepting a transport protocol connection.

resetting the session for some other configuration.

Maximum Number of Prefixes ReachedThe number of address prefixes received

Administratively ShutdownThe BGP speaker is administratively

Peer UnconfiguredThe BGP speaker is removing the peer

Administratively ResetThe BGP speaker is administratively

Connection RejectedThe BGP speaker is rejecting the

Other Configuration ChangeThe BGP speaker is administratively

•

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.

Page 45

BGP Route

A BGProuteconsists of twoparts, a prefixand aset of pathattributes. Itis 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 BGPspeaker applying its local policies to the routes contained in its Adj-RIBs-In.

•

Adj-RIBs-Out store routes that theBGP speaker will advertiseto its peersin theupdate messages it sends.

Chapter 1: Configuring BGP Routing

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 thehigh-order 16bits (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

Page 46

JunosE 11.2.x BGP and MPLS Configuration Guide

Without CIDR, the ISP has to advertise a route to each address, as shown in Figure 4 on page 10.

Figure 4: Routing Without CIDR

192.168.132.0

192.168.133.0

...

192.168.255.0

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 Figure 5 on page 11.

Page 47

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-pathspecifies thesequenceof autonomous systems that mustbe crossed toreach 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 attributespecifies adegree of preference that enables a router to select among multiple routes to thesame prefix. The MEDis usedfor ASs thathave 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

Page 48

JunosE 11.2.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 numbercombined with a 32-bit number to createa uniqueidentifier.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, Figure 6 on page 12 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 asingleline). Customer 1 isconnectedtoISP 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. Figure 6 on page 12 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 providesnontransit service to other ISPs. Forexample, Figure 7 on page 13 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.

Page 49

IPv6 BGP Support

Chapter 1: Configuring BGP Routing

Figure 7: Nontransit Service

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. Fora 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 (Figure 9 on page 14).

Exchange of IPv6 Routing Information over TCP IPv4

Figure 8 on page 13 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.

IPv6 addressIPv4 address

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.

::10.1.1.110.1.1.1

Page 50

JunosE 11.2.x BGP and MPLS Configuration Guide

Exchange of IPv6 Routing Information over TCP IPv6

Figure 9 on page 14 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 hopand anext hop with a link-local address. The link-local next hop is advertised even when the router has been configured with thenext-hop self feature.Advertisingthe link-local next hop enables theconfiguration 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 modifythe network address ofthe next-hop field by removing the link-local IPv6 address of the next hop.

For static BGP peers,the JunosESoftwaredoes 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 supportBGP 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.

•

See ERX Module Guide, Appendix A, Module Protocol Support for information about the modules that support BGP.

Page 51

References

Chapter 1: Configuring BGP Routing

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—Definitionsof Managed Objects for the FourthVersionof theBorder 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—Guidelinesforcreation,selection,and registrationof anAutonomous 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)

•

RFC 2270—Using a Dedicated AS for Sites Homed to a Single Provider (January 1998)

Page 52

JunosE 11.2.x BGP and MPLS Configuration Guide

•

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 2858—Multiprotocol Extensions for BGP-4 (June 2000)

•

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)

Features

•

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 Website at http://www.ietf.org for the latest drafts.

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

•

IBGP single hop

Page 53

•

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

Chapter 1: Configuring BGP Routing

Before You Configure BGP

Before you attempt to configure BGP, ensure that you have TCP/IP reachability to the BGP peerswith which you wantyour router tocommunicate. This may includetasks 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.

Configuration Tasks

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 followingsections to determine thebest method forconfiguring BGP for your needs.

Basic Configuration

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 bothfor apeer groupand fora peer, the peer configuration takes precedence for that peer, but does not affect other members of that peer group.

Page 54

JunosE 11.2.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 besortedinto thefollowing categories, each of which has adifferent scope; that is, each configures parameterswithin a different area ofapplicability. Individual command descriptions in this chapter and in “Configuring BGP-MPLS Applications” on page 383, provide more information about command behavior.

Page 55

Chapter 1: Configuring BGP Routing

•

The commands listed in Table 5 on page 19 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 graceful-restart restart-timebgp advertise best-external-to-internal

bgp graceful-restart stalepaths-timebgp always-compare-med

bgp log-neighbor-changesbgp bestpath med confed

bgp maxas-limitbgp bestpath missing-as-worst

bgp redistribute-internalbgp client-to-client reflection

bgp router-idbgp cluster-id

bgp shutdownbgp confederation identifier

ip bgp-community new-formatbgp confederation peers

overload shutdownbgp default local-preference

rib-out disablebgp default route-target filter

router bgpbgp enforce-first-as

timers bgpbgp fast-external-fallover

bgp graceful-restart

•

The commands listed in Table 6 on page 19 configure parameters for all address families within the current VRF context.

Table 6: Commands Affecting All Address Families in a VRF

synchronizationdistance bgp

•

The commands listed in Table 7 on page 19 configure parameters only for the current address family context.

Table 7: Commands Affecting the Current Address Family

disable-dynamic-redistributeaddress family

external-pathsaggregate-address

ip route-typeauto-summary

Page 56

JunosE 11.2.x BGP and MPLS Configuration Guide

Table 7: Commands Affecting the Current Address Family (continued)

•

The commands listed in Table 8 on page 20 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

maximum-pathsbgp dampening

networkbgp wait-on-end-of-rib

redistributecheck-vpn-next-hops

table-mapdefault-information originate

Table 8: Commands Affecting All Address Families for the Specified Peer or Peer Group

neighbor maximum-update-sizeneighbor advertisement-interval

neighbor passiveneighbor allow

neighbor passwordneighbor bfd-liveness-detection

neighbor peer-typeneighbor capability

neighbor remote-asneighbor description

neighbor rib-out disableneighbor ebgp-multihop

neighbor shutdownneighbor graceful-restart

neighbor site-of-originneighbor graceful-restart restart-time

neighbor timersneighbor graceful-restart

stalepaths-time

neighbor update-sourceneighbor ibgp-singlehop

neighbor weightneighbor lenient

•

The commands listed in Table 9 on page 21 configure parameters separately for each address family exchanged over the BGP session. If you configure these parameters for

Page 57

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 peer-groupneighbor activate

neighbor prefix-listneighbor advertise-map

neighbor prefix-treeneighbor allowas-in

neighbor next-hop-unchanged

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.

neighbor remote-private-asneighbor as-override

neighbor route-mapneighbor default-originate

neighbor route-reflector-clientneighbor distribute-list

neighbor send-communityneighbor filter-list

neighbor send-labelneighbor local-as

neighbor soft-reconfiguration inboundneighbor maximum-prefix

neighbor unsuppress-mapneighbor next-hop-self

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.

Page 58

JunosE 11.2.x BGP and MPLS Configuration Guide

Table 10: Behavior of Neighbor Commands

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

Category B:

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

Category D:

Set parameters for a peer, for a peer group, or globally

•

neighbor timers

Some of the commands in Table 10 on page 22 inherit global values set by other commands. Table 11 on page 22 describes the relationship between these commands.

Table 11: Inheritance from Other Commands

Inherits Global Values Set ByCategory B Command

default-information originateneighbor default-originate

Page 59

Chapter 1: Configuring BGP Routing

Table 11: Inheritance from Other Commands (continued)

Inherits Global Values Set ByCategory B Command

bgp graceful-restartneighbor graceful-restart

rib-out disableneighbor rib-out disable

bgp shutdownneighbor shutdown

bgp graceful-restart restart-timeneighbor graceful-restart restart-time

bgp graceful-restart stalepaths-timeneighbor 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.

Page 60

JunosE 11.2.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. Forcommands in categories C and D,the behaviorof the defaultversion 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.

Page 61

Chapter 1: Configuring BGP Routing

Outbound policies configured for peer groups are still inherited by peer group members, but you cannotoverridethis inherited outboundpolicy by configuring adifferentoutbound 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

next-hop-unchanged

neighbor prefix-list outneighbor

default-originate

out

neighbor filter-list out

remove-private-as

neighbor next-hop-self

neighbor route-map outneighbor

neighbor route-reflector-client

neighbor send-communityneighbor prefix-tree outneighbor distribute-list

neighbor unsuppress-mapneighbor

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

Page 62

JunosE 11.2.x BGP and MPLS Configuration Guide

Configuring Neighbors

Use theneighbor remote-as command to createa BGPpeering sessionwith agiven 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 youspecify aBGP peer group by usingthe 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.

Page 63

• 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 policiesare usually definedby route maps,filterlists, anddistribution 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. Figure 11 on page 28 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’sleftcoast peer group.

The following commands configure the eastcoast peer group on router Chicago:

Chapter 1: Configuring BGP Routing

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 BGPenable the exchange ofinformationwithin different types of address families. By default, peers and peer groups exist in the unicast IPv4 address family and exchange unicast IPv4addresses. Forinformation on configuring and activatingBGP peergroups withinaddress families, see“Configuring the AddressFamily” on page 43.

Page 64

JunosE 11.2.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

Page 65

neighbor peer-type

Chapter 1: Configuring BGP Routing

can be filled. Youcan use the neighbor peer-type command toexplicitly 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 bothof theseimplicit cases, the remoteAS is combinedwith thelocalAS, the configured confederation ID, and the configured confederation peers to determine the peer type of the peer group.

• 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

• This command takes effect immediately. If the command changes the peer type of

• All the members of the peer group inherit the characteristic configured with this

• Example

• 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 aBGP neighbor or a peer group. This is a convenient way to store minimal pertinent information about the neighbor.

neighbor description

the same confederation. Use this keyword only if confederations are employed.

the peer group, all BGP sessions for members of that peer group are automatically bounced.

command. It cannot be overridden for a specific peer, because the command applies only to peer groups.

host1(config-router)#neighbor promispeers peer-type internal

• Use to associate a textual description of up to 80 characters with a BGP neighbor or

peer group.

• If youspecify aBGP peer group by usingthe peerGroupName argument, all the members

of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.

Page 66

JunosE 11.2.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

NOTICE04/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 sourceIP address for theTCPconnectionover which theBGP session runs. If theoutgoing interface goes down, the BGP session is dropped because the IP source address is no

Page 67

neighbor update-source

Chapter 1: Configuring BGP Routing

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 IBGPsessions, however, you typically want BGP sessions tobe 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

• Use to allow a BGP session to use the IP address of a specific operational interface as

the source address for TCP connections.

• If youspecify aBGP peer group by usingthe 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. Table 13 on page 31 lists the results for different configurations.

Table 13: Source Addresses and Default Next Hop Addresses for Various Configurations

Default Next Hop Value for IPv6 Prefixes

IPv4 source address mapped to an IPv6 address

Configured Neighbor Address

Configured Update Source Address

Source Address used for TCPv4and TCPv6 Connection

Default Next Hop Value for IPv4 Prefixes

IPv4 source addressIPv4 source addressIPv4 source addressIPv4 neighbor address

Not allowedNot allowedNot allowedIPv6 source addressIPv4 neighbor address

Page 68

JunosE 11.2.x BGP and MPLS Configuration Guide

Table 13: Source Addresses and Default Next Hop Addresses for Various Configurations

(continued)

Configured Neighbor Address

Default Next Hop Value for IPv6 Prefixes

IPv6 address of the interface. If the interfacedoes not have an IPv6 address, then the IPv4address of the interface is mapped to an IPv6 address.

IPv6 source address0.0.0.0IPv6 source addressIPv6 source addressIPv6 neighbor address

Not allowedNot allowedNot allowedIPv4 source addressIPv6 neighbor address

IPv6 address of the interface

Configured Update Source Address

Interface nameIPv4 neighbor address

Interface nameIPv6 neighbor address

Source Address used for TCPv4and TCPv6 Connection

IPv4 address of the interface. If the interfacedoes not have an IPv4 address, then the session does not come up.

IPv6 address of the interface. If the interfacedoes not have an IPv6 address, then the session does not come up.

Default Next Hop Value for IPv4 Prefixes

IPv4 address of the interface

IPv4 address of the interface. If the interfacedoes not have an IPv4 address, then

0.0.0.0.

You can override anative IPv6 next-hopaddress 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 thisexample,the IPv4-mapped IPv6address 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

Page 69

Chapter 1: Configuring BGP Routing

externalpeers with the neighbor ebgp-multihop command because nodirectconnection 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

The following commands achieve the BGP configuration.

neighbor ebgp-multihop

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 youspecify aBGP peer group by usingthe 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 explicitconfiguration from the peeror peer group andreestablish inheritance of the feature configuration.

• See neighbor ebgp-multihop

Page 70

JunosE 11.2.x BGP and MPLS Configuration Guide

Specifying a Single-Hop Connection for IBGP Peers

IBGP peers are multihop by default. However, you can usethe 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 youspecify aBGP peer group by usingthe 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 therouter so thata 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 youspecify aBGP peer group by usingthe 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

Page 71

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 stateidle until you use the clear ip bgp command toissue 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 privateAS numbers fromthe range 64,512 to65,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

Chapter 1: Configuring BGP Routing

• Use to remove private AS numbers only in updates sent to external peers.

• All private ASnumbers are removed regardlessof theirposition in theAS-pathattribute

and regardless of the presence of public AS numbers.

• If youspecify aBGP peer group by usingthe 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 theremovalof private AS numbersin 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

Page 72

JunosE 11.2.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 previouslyreceived. 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 youuse thefields as-path option with theshow ip bgp command, the displayindicates 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)

Page 73

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 authenticationfeature uses theMD5 algorithm. When you specifythis 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:

Chapter 1: Configuring BGP Routing

neighbor password

•

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 outputof theshow configurationcommanddisplaysthe 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.

• 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 youspecify aBGP peer group by usingthe 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.

Page 74

JunosE 11.2.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 youspecify aBGP peer group by usingthe 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.

Page 75

Setting Timers

neighbor timers

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.

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 negotiatesthe hold timewith each neighborwhen establishingthe BGPconnection. 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.

timers bgp

• If youspecify aBGP peer group by usingthe 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.

Page 76

JunosE 11.2.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

• 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 toreenable a neighbor orpeer group thatwas previously shut down.

Use thedefault version toremovethe explicit configurationfrom the peeror peergroup and reestablish inheritance of the feature configuration.

host1(config-router)#bgp shutdown

• See neighbor shutdown.

Page 77

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.

Chapter 1: Configuring BGP Routing

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”) withthe 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-routescommand to display theroutes that have been advertised to the peer. The attributes displayed for the routes are those from the local routing table, not those

Page 78

JunosE 11.2.x BGP and MPLS Configuration Guide

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 advantageof enabling rib-out forpeer groupsis 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 theroutes that willbe advertised to thepeer groupand theattributes (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 withthe 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 theappropriate 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.

neighbor rib-out disable

Page 79

Chapter 1: Configuring BGP Routing

• Use to disable storage of routes (disable rib-out) in the specified neighbor’s

Adj-RIBs-Out table or in a single Adj-RIBs-Outtable 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’sAdj-RIBs-Out table contains thoseroutesthat the BGPspeakerintends 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 morethan tenfor peer groupsto conserve

memory resources. No limit applies to peers.

• This commandtakeseffectimmediately and automaticallybouncesthe BGPsession(s)

if the command changes the current configuration.

• Example

rib-out disable

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.

• 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 differenttypes of addressfamilies.The JunosE BGPimplementationdefinesthe following different types of address families:

Page 80

JunosE 11.2.x BGP and MPLS Configuration Guide

•

Unicast IPv4—If youdo notexplicitlyspecify theaddress 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 383.

•

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 589. For a description of VPWS, see “Configuring VPWS” on page 651.

•

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

•

VPLS—If you specifythe VPLS address family, you can configure the routertoexchange layer 2 NLRI for a specified VPLS instance. For a description of VPLS, see “Configuring VPLS” on page 589.

•

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

Any command issued outside the context of an address family applies to the unicast IPv4 address family by default.

Page 81

Chapter 1: Configuring BGP Routing

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.

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.

Page 82

JunosE 11.2.x BGP and MPLS Configuration Guide

bgp default ipv4-unicast

• Use toconfigure all neighborsto exchangeaddresses 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 issuedthe command, you mustuse 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 toexit Address Family Configurationmode andaccessRouterConfiguration mode.

neighbor activate

• Example

host1:vr1(config-router-af)#exit-address-family

• There is no no version.

• See exit-address-family.

• 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 youspecify aBGP peer group by usingthe 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 acapability 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

Page 83

• 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 thesession with the peer. The normal,nonlenient behavior is for theBGP speaker to send a notification message to the peer generating the error and to terminate the session. By default, lenient behavior is disabled.

Chapter 1: Configuring BGP Routing

host1:vr1(config-router-af)#neighbor 192.168.1.158 activate

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

Page 84

JunosE 11.2.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 isnot inthe 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 connectionmatchesthe access list of more thanone ofthese 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 apeer group has been configured with a peer typebut nota remote AS, thenthe 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 anew static peerwhile a dynamic peer forthe 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

Page 85

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

• Use the asterisk (*) to remove all BGP dynamic peers.

• This command takes effect immediately.

• Example

Chapter 1: Configuring BGP Routing

the scope. For IPv4 only, you can also include a VRF in the scope.

neighbor allow

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.

• 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 allowedby thenew configurationare removed automaticallyand 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

Page 86

JunosE 11.2.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. Anypeers that do not existwill consume resourcesas BGP repeatedlyattempts to establish a session with them.

If instead you initially configure the routeras passive for those peers, BGP will not attempt to establish sessions to thosepeers but will wait until these remote peers initiate asession, thus conserving CPU resources.

neighbor passive

Advertising Routes

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.

• 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 stopsinitiating outboundconnections to the peer. If the session isalready established, it is not bounced regardless of which side initiated the connection.

• If youspecify aBGP peer group by usingthe 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 restorethe default condition, permittingthe initiation ofoutbound

connections to the peer.

• See neighbor passive.

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

Page 87

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 114 for more information about origins. Figure 13 on page 51 shows a network structure of three autonomous systems, each with a router that originates certain prefixes.

Figure 13: Prefixes Originating in an AS

Chapter 1: Configuring BGP Routing

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

Page 88

JunosE 11.2.x BGP and MPLS Configuration Guide

command, then BGPis notifiedas soon as theroutebecomes availablein theIP routing table or IP tunnel routing table.

• For IPv4addressing, specify anetwork-numberand 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 137 for more information.

• The next hopfor the networkis thenext hop forthe route contained inthe 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 thebest route from thecompleteset of routes known

to BGP.

• For internalpeers, BGP selects the bestroute from theset of routes BGPhas received

from external and confederation peers.

• Changes apply automatically whenever BGP subsequently runsthe 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.

Page 89

• The command is disabled by default.

• Example

host2(config-router)#bgp advertise-best-external-to-internal

• Use the noversion to restore the defaultcondition, wherein BGP selects onebest 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 114 for more information about origins.

Chapter 1: Configuring BGP Routing

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 Figure 14 on page 53:

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.

Page 90

JunosE 11.2.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.

• Youcan specify a route map to filter the redistribution ofroutes from thesource routing

protocol into BGP. If you do not specify the route-map option, all routes are redistributed.

• Use the metric keywordto 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 keywordto setthe 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 issuethe bgpredistribute-internalcommand followed byclearing all BGP sessions to permit the redistribution of IBGP routes in addition to EBGP routes.

Page 91

bgp redistribute-internal

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.

• 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 bouncethe 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 informationfor adestination is unknown.A router uses thedefaultroute 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 Figure 15 on page 56, router NY originates the default route 0.0.0.0/0 to router Albany only. Router Chicago does not receive the default route.

Page 92

JunosE 11.2.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, theredistribute command does notpermit 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

• This command takes effect immediately. However, if the contents of the route map

• Outbound policy configured for the neighbor (using the neighbor route-map out

• Policy specified by a route map with the default-information originate command is

route. The route map can modify the attributes of the default route.

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.

command) is applied to default routes that are advertised because of the default-information originate command.

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

Page 93

Chapter 1: Configuring BGP Routing

• Use the no version torestorethe default,preventingthe redistribution ofdefault 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 beenconfiguredto advertise adefault 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.

Page 94

JunosE 11.2.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 youspecify aBGP peer group by usingthe 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 todefault routes thatare advertised because ofthe 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 theneighbor advertisement-interval command toset the minimuminterval between the sending of BGP updates. Lower values for the advertisement interval cause route changes to be reported more quickly, butmay cause routers to usemore 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 toset the minimum interval between thesending of BGP updates for agiven prefix.

• If youspecify aBGP peer group by usingthe 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 morespecific than the aggregate.You aggregate IPv4 routes by specifyingthe aggregate IP address, and IPv6 routes by specifying the aggregate IPv6 prefix.

Page 95

Figure 17 onpage 59 illustrates an IPv4networkstructure where youmight 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:

Chapter 1: Configuring BGP Routing

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:

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 usethe as-setoption, the atomic-aggregate

Page 96

JunosE 11.2.x BGP and MPLS Configuration Guide

attribute is not set for the aggregated route. The following commands configure router SanJose to aggregate the routes while preserving the path information:

If you do not want to aggregate all more specific routes, you can use a route map to limit aggregation. Consider Figure 17 onpage59 again. Suppose you donot want router SanJose to aggregateprefix 172.24.48.0/20. Thefollowingcommands show howyou 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

aggregate-address

You can use the attribute-map option to configure attributes for the aggregated route. In Figure 17on page 59,suppose that router LAhas been configured toset thecommunity 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:

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). ForIPv6 routes, you must specify anaggregate 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.

Page 97

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 theBGP received routefor 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

Page 98

JunosE 11.2.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 toprevent the advertisingof received BGP routesunless 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).

Verifying an AS Path

bgp enforce-first-as

• Synchronization is enabled.

• See bgp advertise-inactive.

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.

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

Page 99

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 youdo notuse the route map, then the advertised IPv4 next hopis setto 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

Chapter 1: Configuring BGP Routing

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 theproviders whena failure occurs in thepeering session with a differentprovider, 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 ofBGP routes to apeer orpeer group within an address family. BGP conditional advertisement does not create routes. The routes specified by the route map inthe neighboradvertise-map command mustalreadybe present inthe BGP routing table.

BGP conditional advertisement is supported in only the following address families:

•

Unicast IPv4

•

Unicast IPv6

•

Multicast IPv4

•

Multicast IPv6

Page 100

JunosE 11.2.x BGP and MPLS Configuration Guide

•

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 incorrectVPN 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 specifywith thenon-exist-map keyword referencesmultipleroutes, 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 theroute matches more thanone advertise route map, only thefirst 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

Juniper JUNOSE 11.2.X BGP AND MPLS, JUNOSE 11.2.X Configuration Manual

Specifications and Main Features

Frequently Asked Questions

User Manual