Advanced Junos Service Provider

Routing
12.a

Student Guide
Volume 2

Worldwide Education Services

1133 Innovation Way

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net

Course Number: EDU-JUN-AJSPR

This document is produced by Juniper Networks, Inc.
This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks
Education Services.
Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.

Advanced Junos Service Provider Routing Student Guide, Revision 12.a

Copyright © 2013 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.a — March 2011
Revision 10.b—September 2011
Revision 11.a—January 2012
Revision 12.a—September 2013
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 12.3R3.4. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary,
incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.

Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has
no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.
 Contents

Chapter 8: BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

Review of BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
BGP Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-22
BGP Path Selection and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-29
Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-39
BGP and BGP Attributes Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-56

Chapter 9: BGP Attributes and Policy—Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1

BGP Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10
Origin and MED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-24
AS Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-42
BGP Attributes: Next-Hop, Origin, MED, and AS Path Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-69

Chapter 10: BGP Attributes and Policy—Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Local Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13
BGP Attributes: Local Preference and Communities Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-47

Chapter 11: Route Reflection and Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Route Reflection Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3
Configuration and Routing Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-9
BGP Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-28
Scaling BGP Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-37

Chapter 12: BGP Route Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

Route Flap and Damping Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3
Route Damping Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10
Configuring and Monitoring Route Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
BGP Route Damping Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-26

Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACR-1

www.juniper.net Contents • iii

iv • Contents www.juniper.net
Course Overview

This four-day course is designed to provide students with detailed coverage of OSPF, IS-IS, BGP, and routing policy. Through
demonstrations and hands-on labs, students will gain experience in configuring and monitoring the Junos operating system
and in monitoring device and protocol operations. This course uses Juniper Networks MX Series 3D Universal Edge Routers
for the hands-on component, but the lab environment does not preclude the course from being applicable to other Juniper
hardware platforms running the Junos OS. This course is based on the Junos OS Release 12.3R3.4.
Objectives
After successfully completing this course, you should be able to:
• Describe the various OSPF link-state advertisement (LSA) types.
• Explain the flooding of LSAs in an OSPF network.
• Describe the shortest-path-first (SPF) algorithm.
• List key differences between OSPFv2 and OSPFv3.
• Describe OSPF area types and operations.
• Configure various OSPF area types.
• Summarize and restrict routes.
• Identify some scenarios in a service provider network that can be solved using routing policy or specific
configuration options.
• Use routing policy and specific configuration options to implement solutions for various scenarios.
• Explain the concepts and operation of IS-IS.
• Describe various IS-IS link-state protocol data unit (PDU) types.
• List IS-IS adjacency rules and troubleshoot common adjacency issues.
• Configure and monitor IS-IS.
• Display and interpret the link-state database (LSDB).
• Perform advanced IS-IS configuration options.
• Implement IS-IS routing policy.
• Explain the default operation in multiarea IS-IS.
• Describe IS-IS address summarization methods.
• Configure and monitor a multiarea IS-IS network.
• Describe basic BGP operation.
• List common BGP attributes.
• Explain the route selection process for BGP.
• Describe how to alter the route selection process.
• Configure some advanced options for BGP peers.
• Describe various BGP attributes in detail and explain the operation of those attributes.
• Manipulate BGP attributes using routing policy.
• Explain the causes for route instability.
• Describe the effect of damping on BGP routing.
• Explain the default behavior of damping on links.
• Describe the operation of BGP route reflection.
• Configure a route reflector.

www.juniper.net Course Overview • v

 • Describe the operation of a BGP confederation.
• Configure confederations.
• Describe peering relationships in a confederation.
• Control damping using routing policy.
• View damped routes using command-line interface (CLI) commands.
Intended Audience
This course benefits individuals responsible for implementing, monitoring, and troubleshooting Layer 3 components of a
service provider’s network.
Course Level
Advanced Junos Service Provider Routing is an advanced-level course.
Prerequisites
Students should have intermediate-level networking knowledge and an understanding of the Open Systems
Interconnection (OSI) model and the TCP/IP protocol suite. Students should also attend the Introduction to the Junos
Operating System (IJOS), Junos Routing Essentials (JRE), and Junos Intermediate Routing (JIR) courses prior to attending
this class.

vi • Course Overview www.juniper.net

Course Agenda

Day 1
Chapter 1: Course Introduction
Chapter 2: OSPF
OSPF Multiarea Networks Lab
Chapter 3: OSPF Areas
OSPF Route Summarization Lab
Chapter 4: OSPF Case Studies and Solutions
Advanced OSPF Options and Routing Policy Lab
Day 2
Chapter 5: IS-IS
IS-IS Configuration and Monitoring Lab
Chapter 6: Advanced IS-IS Operations and Configuration Options
Advanced IS-IS Configuration Options and Routing Policy Lab
Chapter 7: Multilevel IS-IS Networks
Configuring a Multilevel IS-IS Network Lab
Day 3
Chapter 8: BGP
BGP and BGP Attributes Lab
Chapter 9: BGP Attributes and Policy—Part 1
BGP Attributes: Next-Hop, Origin, MED, and AS Path Lab
Day 4
Chapter 10: BGP Attributes and Policy—Part 2
BGP Attributes: Local Preference and Communities Lab
Chapter 11: Route Reflection and Confederations
Scaling BGP Lab
Chapter 12: BGP Route Damping
BGP Route Damping Lab

www.juniper.net Course Agenda • vii

Document Conventions

CLI and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user
interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter
text according to the following table.

Style Description Usage Example

Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.

Courier New Console text:

commit complete
• Screen captures
• Noncommand-related Exiting configuration mode
syntax
GUI text elements:
Select File > Open, and then click
• Menu names Configuration.conf in the
Filename text box.
• Text field entry

Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances will be shown in the
context of where you must enter them. We use bold style to distinguish text that is input versus text that is simply
displayed.

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Enabled
Normal GUI
View configuration history by clicking
Configuration > History.

CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.

Defined and Undefined Syntax Variables

Finally, this course distinguishes between regular text and syntax variables, and it also distinguishes between syntax
variables where the value is already assigned (defined variables) and syntax variables where you must assign the value
(undefined variables). Note that these styles can be combined with the input style as well.

Style Description Usage Example

CLI Variable Text where variable value is already policy my-peers

assigned.
GUI Variable Click my-peers in the dialog.

CLI Undefined Text where the variable’s value is Type set policy policy-name.
the user’s discretion or text where
ping 10.0.x.y
the variable’s value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.

viii • Document Conventions www.juniper.net

Additional Information

Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class locations from the World
Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/.
About This Publication
The Advanced Junos Service Provider Routing Student Guide was developed and tested using software Release
12.3R3.4. Previous and later versions of software might behave differently so you should always consult the
documentation and release notes for the version of code you are running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development team. Please send
questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the format in which you
want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC
(within the United States) or 408-745-2121 (from outside the United States).

www.juniper.net Additional Information • ix

x • Additional Information www.juniper.net
Advanced Junos Service Provider Routing

Chapter 8: BGP
Advanced Junos Service Provider Routing

We Will Discuss:
• Basic BGP operation;
• Common BGP attributes;
• The route selection process;
• The alteration of the route selection process; and
• The configuration of some advanced options for BGP peers.

Chapter 8–2 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Review of BGP
The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net BGP • Chapter 8–3

Advanced Junos Service Provider Routing

What Is BGP?
The Border Gateway Protocol (BGP) is a routing protocol between autonomous systems (ASs) and is sometimes referred to as
a path-vector routing protocol because it uses an AS path, used as a vector, to prevent interdomain routing loops. The term
path vector, in relation to BGP, means that BGP routing information includes a series of AS numbers, indicating the path that
a route takes through the network. Although BGP is primarily used for inter-AS routing, BGP is also used in large networks for
MPLS-based VPNs and is used to separate large OSPF domains. BGP is much more scalable and offers a greater amount of
control through policy than an IGP.
BGP exchanges routing information among ASs. An AS is a set of routers that operate under the same administration. BGP
routing information includes the complete route to each destination. BGP uses the routing information to maintain an
information base of Network Layer reachability information (NLRI), which it exchanges with other BGP systems.
BGP is a classless routing protocol, that supports prefix routing, regardless of the class definitions of IP version 4 (IPv4)
addresses. BGP routers exchange routing information between peers. The peers must be connected directly for inter-AS BGP
routing (unless certain configuration changes are done). The peers depend on established TCP connections, which we
address later in this chapter.
BGP version 4 (BGP4) is essentially the only exterior gateway protocol (EGP) currently used in the Internet. It is defined in
RFC 4271, which made the former standard of more than 10 years, RFC 1771, obsolete.

Chapter 8–4 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

When Should I Use BGP?

Networks with a single upstream connection receive little benefit from running a dynamic routing protocol with their Internet
service provider (ISP). These customers typically use a static default route to send all external traffic toward the Internet.
Their provider also typically uses a static route to direct traffic destined for the customer’s addresses to the customer.
Normally, a single-homed network uses addresses assigned by the provider from the provider’s aggregate. Because these
addresses are assigned to the provider and can only be used by the customer while they are a customer of the provider, they
are known as nonportable addresses. Using these addresses allows the provider to announce a single aggregate route for
many customer networks, reducing global routing table growth. Currently, the Internet routing table contains hundreds of
thousands of routes, which highlights the need for a scalable and robust protocol such as BGP.
BGP is normally used when a network has multiple upstream connections, either to a single ISP or to multiple ISPs. BGP’s
policy controls provide the ability to optimize inbound and outbound traffic flows based on a network’s technical and
business constraints. Although BGP can detect and route around failures in redundant environments, BGP sessions within
the same AS do not typically react as quickly as an IGP, and they often rely on the IGP used in the AS to remain operational
when failures occur.
Networks that are multihomed to a single ISP likely use nonportable addresses assigned by the provider. Networks that are
multihomed to multiple ISPs are likely to use portable addresses assigned directly by the regional address registry.

www.juniper.net BGP • Chapter 8–5

Advanced Junos Service Provider Routing

EBGP and IBGP Peers

BGP supports two different types of exchanges of routing information. Exchanges between ASs are known as external BGP or
EBGP sessions and handle inter-AS routing. Exchanges within an AS are known as internal BGP or IBGP sessions, and
handle intra-AS routing.
An EBGP peer connection is between a device in one AS and another device in a different AS. The connection between the
two ASs consists of a physical connection and a BGP connection. The physical connection is a shared Data Link Layer
subnetwork between the two ASs. On this shared subnetwork, each AS has at least one border gateway belonging to that AS.
The BGP connection exists between BGP speakers in each of the ASs. This session can communicate destinations that can
be reached through the advertising AS. The EBGP connection typically is established between immediately connected
devices located in two different ASs because the time-to-live (TTL) value of the EBGP packets is equal to 1, by default.
An IBGP connection is typically established between loopback interfaces of the routers not immediately connected (of
course, everything depends on the AS’s topology). BGP uses the loopback interfaces for stability reasons—these interfaces
are always alive, unless the router itself dies. Because the IBGP connection typically exists between remotely connected
routers, an IGP is required within the AS. BGP’s TCP session is established using regular routing tables.

Chapter 8–6 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

BGP Peering Sessions

Unlike other dynamic protocols, BGP requires that you manually define the neighbors with which you want the local device to
peer. Because BGP peers must be manually defined, no automatic neighbor discovery exists as with other protocols.
BGP uses TCP as its transport protocol (port 179). TCP provides a full-duplex, connection-oriented, reliable, byte-stream
service to BGP. BGP considers a connection between two peers to be idle until a TCP connection is established between
them. With the TCP connection established, the endpoints are assured of a reliable connection. The following list describes
the various BGP neighbor states:
• Idle: The Idle state is the initial state when all incoming BGP connections are refused. A start event is required
for the local system to initialize BGP resources and prepare for a transport connection with the other BGP peer.
• Connect: In the Connect state, BGP is waiting for the transport protocol connection to be completed. If the
transport protocol connection succeeds, the local system sends an Open message and transitions to the
OpenSent state. If the transport protocol connection fails, the local system restarts the ConnectRetryTimer,
searches for a connection initiated by the remote BGP peer, and changes its state to Active.
Continued on the next page.

www.juniper.net BGP • Chapter 8–7

Advanced Junos Service Provider Routing
BGP Peering Sessions (contd.)
• Active: In the Active state, BGP is trying to acquire a peer by initiating a transport protocol connection. If the
transport protocol connection succeeds, the local system sends an Open message to its peer and transitions to
the OpenSent state. If the local system’s BGP state remains in the Active state, you should check physical
connectivity as well as the configuration on both peers.
• OpenSent: In the OpenSent state, BGP waits for an Open message from its peer. When an Open message is
received, it is checked and verified to ensure that no errors exist. If an error is detected, the system transitions
back to the Idle state. If no errors are detected, BGP sends a Keepalive message.
• OpenConfirm: In the OpenConfirm state, BGP waits for a Keepalive or Notification message. If no Keepalive
message is received before the negotiated hold timer expires, the local system sends a Notification message
stating that the hold timer has expired and changes its state to Idle. Likewise, if the local system receives a
Notification message, it changes its state to Idle. If the local system receives a Keepalive message, it changes
its state to Established.
• Established: In the Established state, BGP can exchange Update, Notification, and Keepalive messages with its
peer. When the local system receives an Update or Keepalive message and when the negotiated hold timer
value is nonzero, it restarts its hold timer. If the negotiated hold timer reaches zero, the local system sends out
a Keepalive message and restarts the hold timer.

Chapter 8–8 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

BGP Message Types

BGP processes a message only after the entire message is received. The maximum message size is 4096 octets; the
smallest BGP message is a header without any data, or 19 octets. The following list details the BGP message types:
• Open: The open message is sent once the TCP three-way handshake is complete. The open message initiates
the BGP session and contains details about the BGP neighbor and information about supported and negotiated
options.
• Update: BGP uses update messages to transport routing information between BGP peers. Depending on the
receiving device’s routing policy, this routing information is either added to the routing table or ignored.
• Keepalive: BGP does not use keepalives at the Transport Layer—TCP fills this need. Instead, peers exchange
keepalives as often as needed to ensure that the hold timer does not expire.
• Notification: BGP uses notification messages to signal when something is wrong with the BGP session. A
notification is sent when an unsupported option is sent in an open message and when a peer fails to send an
update or keepalive. When an error is detected, the BGP session is closed.
• Refresh: Normally a BGP speaker cannot be made to readvertise routes that have already been sent and
acknowledged (using TCP). The route refresh message supports soft clearing of BGP sessions by allowing a
peer to readvertise routes that have already been sent. This soft clearing has some very specific uses when
working with MPLS-based VPNs and adding new customer sites to existing customer VPN structures.
Each BGP message uses the same fixed size header, which is 19 bytes. BGP keepalive messages do not include any data
portion following the header.

www.juniper.net BGP • Chapter 8–9

Advanced Junos Service Provider Routing

BGP Update Messages

BGP update messages describe a single path and then list multiple prefixes that can be reached through this same path.
BGP peers assume that this information is unchanged unless a subsequent update advertises a new path for a prefix or lists
the prefix as unreachable. Updates can list any prefixes that are no longer reachable, regardless of the path associated with
those prefixes. BGP peers use update messages to ensure that their neighbors have the most up-to-date information about
BGP routes.
BGP uses TCP to provide reliable communication, which ensures that BGP neighbors never miss an update. A system of
keepalives also allows each BGP peer to ensure that its neighbor is still functioning properly. If a neighbor goes down, the
BGP speaker deletes all routes learned from that peer and updates its other peers accordingly.
BGP uses the information within the update messages, in particular the BGP attributes, to detect routing loops and
determine the best path for a given destination prefix.

Chapter 8–10 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

BGP Attributes
The primary purpose of BGP is not to find the shortest path to a given destination; rather, its purpose is to find the best path.
Each AS determines the best path to a prefix by determining its own outbound routing preferences, the inbound routing
preferences of the route’s originator (as updated by ASs along the path between the source and destination ASs), and some
information that is collected about the path itself. All this information is contained in path attributes that describe the path to
a prefix. The path attributes contain the information that BGP uses to implement the routing policies of source, destination,
and transit ASs.
The slide lists some common BGP attributes. We cover the listed attributes in greater detail on subsequent pages.

www.juniper.net BGP • Chapter 8–11

Advanced Junos Service Provider Routing

High-Level BGP Example

The example on the slide explains the operation of BGP at a very high level. Consider the way traffic is routed to Customer A.
Customer A has a single connection to ISP A. ISP A has assigned Customer A a prefix (172.20.21.0/24) from its aggregate
address range (172.20.0.0/16).
Because Customer A is a single-homed network, it has a static default route to reach all destinations on the Internet through
its connection to ISP A. Likewise, ISP A has a static route to reach Customer A’s prefix.

Chapter 8–12 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

ISP A’s Network

The slide highlights a portion of ISP A’s network. Internally, ISP A maintains reachability information for each prefix within its
aggregate address range. Therefore, every router in ISP A has knowledge about the /24 prefix assigned to Customer A. This
reachability information can be maintained by either an IGP or by IBGP.
Even though ISP A has reachability information about each prefix internally, it advertises the aggregate prefixes externally
only. Because other networks use the same path to reach all prefixes available on ISP A’s network, other networks do not
need the more specific information. To reduce the size of the global routing table, ISPs typically do not transmit the prefixes
of their statically routed customers to their peers; rather, they just transmit the aggregate prefixes from which their
addresses are assigned.

www.juniper.net BGP • Chapter 8–13

Advanced Junos Service Provider Routing

ISP A Advertises Its Aggregate

ISP A advertises its aggregate address range of 172.20.0.0/16 through BGP along with some information about the path to
reach that route. One of these path attributes is the AS path, which is a list of the autonomous systems through which the
path to this aggregate passes. By examining the AS path, ISP B knows that the 172.20.0.0/16 network was originated within
ISP A.
ISP B then advertises the 172.20.0.0/16 prefix to ISP C. It updates the path attributes, including the AS path, when it
transmits the route. ISP C further advertises this prefix to Customer B, again updating the path attributes when it transmits
the route.

Chapter 8–14 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Customer B’s Aggregate

Customer B is currently a single-homed network but is planning on adding a second connection to another ISP in the near
future. Customer B advertises its portable /20 prefix to ISP C with an AS path, indicating that it was originated locally. ISP C
sends the advertisement to ISP B, who sends it to ISP A, with each ISP updating the path attributes as it sends the route.
ISP A does not have a BGP session to Customer A, so Customer A does not receive any routing information for Customer B’s
prefix. However, receiving the route information is not necessary because Customer A has a static default route that directs
all Internet-bound traffic to ISP A. Once the traffic reaches ISP A, ISP A follows the BGP-received route to Customer B.

www.juniper.net BGP • Chapter 8–15

Advanced Junos Service Provider Routing

Customer B Becomes Multi-Homed

Customer B decides to add a connection to ISP B. Therefore, Customer B now advertises its prefix to both its providers. In
this example, ISP B receives routing information for Customer B’s prefix both from ISP C and directly from Customer B. ISP B
chooses one of the paths as the best path and places a corresponding route for the prefix in the routing table. It then
advertises the prefix with the associated path attributes to ISP A. Because ISP B chose the path directly to Customer B as the
best path, it advertises the path attributes associated with that advertisement to ISP A. Note that it advertises an AS path
that reflects that it can directly reach Customer B and does not include any information about ISP C. Because the path
through ISP C was not chosen as the best path, ISP B does not send ISP A any of the path attributes associated with the
advertisement from ISP C.
If ISP B ceases to hear the announcement about Customer B’s prefix directly from Customer B (for example, because the
circuit fails), it will begin using the path it received from ISP C and will send updated announcements to its peers to reflect
the new path.
Although not shown, Customer B now also receives two advertisements for ISP A’s aggregate. It chooses one of those
advertisements as the best path and installs a corresponding route in the routing table.
We cover the path selection process and many of the BGP attributes in greater detail later in this chapter.

Chapter 8–16 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Loopback Peering
You maintain only one IBGP session between each internal peer. The IGP is used to maintain reachability between the
loopback addresses regardless of the physical topology, allowing the IBGP sessions to stay up even when the physical
topology changes.
The physical topology is relevant in one respect: each router along the path between BGP speakers must have enough
information to make consistent routing decisions about packet forwarding. In many cases, this requirement means that all
routers along all possible physical paths between BGP speakers must run BGP; however, in some networks this requirement
is not necessary.

Interface Peering
Recall that EBGP sessions are simply BGP sessions between two routers in different autonomous systems. When two EBGP
peers have a single path between them, EBGP sessions are usually established over the shared subnet between two peers,
using the IP addresses assigned to the interfaces on that subnet as the session endpoints. By establishing the EBGP session
using the IP address assigned to the interfaces on the shared subnet, you gain many advantages. One of these advantages
is that you prevent either AS from needing to maintain any routing information about the other AS (besides what it received
through BGP). You also ensure that all traffic flows over this particular shared subnet.

www.juniper.net BGP • Chapter 8–17

Advanced Junos Service Provider Routing

Configuring BGP
The slide illustrates the sample configuration.
In this configuration example, we see some parameters defined under the [edit routing-options] and [edit
protocols bgp] hierarchies. Under the [edit routing-options] hierarchy, we defined the system’s router
identifier (RID) and the local AS number. Optionally, you can configure the system’s local AS number under the global BGP
hierarchy for a specific BGP group, or, for a specific BGP neighbor, use the local-as configuration option. When the AS
number is configured at multiple hierarchy levels, the AS number specified at the most specific hierarchy level is used. The
ability to specify different AS numbers at different hierarchy levels can be quite useful, especially when merging networks
with different AS numbers.
Because we are using loopback-based peering for the internal BGP group, we must reference loopback addresses in the
related BGP configuration. In this case, the neighbor address is the remote peer’s loopback address. The
local-address is the local device’s loopback address. If the local address is not specified, the system uses the interface
address of the egress interface used to reach the referenced peer address. Because the peer is expecting to form an IBGP
peering session using the 192.168.100.1 address, you must specify that address as the local-address in the
configuration.
Continued on the next page.

Chapter 8–18 • BGP www.juniper.net

 Advanced Junos Service Provider Routing
Configuring BGP (contd.)
As mentioned on the slide, the session type determines whether the peering session is IBGP or EBGP. You specify an
external session type for EBGP and an internal session type for IBGP. If you omit the session type, you must specify
the peer-as number, which can be a remote AS number or the local AS number. If the specified AS number does not match
the AS number defined on the router, BGP assumes the session type is external. If the specified AS number does match the
AS number defined on the router, BGP assumes the session type is internal. The software notifies you if you did not include
the required details, as shown in the following sample output:
[edit protocols bgp]
user@router# show
group x100 {
neighbor 10.1.1.1;
}

[edit protocols bgp]

user@R1# commit
[edit protocols]
'bgp'
Error in neighbor 10.1.1.1 of group x100:
peer AS number must be configured for an external peer
error: configuration check-out failed

www.juniper.net BGP • Chapter 8–19

Advanced Junos Service Provider Routing

BGP Authentication
All BGP protocol exchanges can be authenticated to guarantee that only trusted routing devices participate in the AS’s
routing. By default, authentication is disabled. You can configure Message Digest 5 (MD5) authentication. The MD5
algorithm creates an encoded checksum that is included in the transmitted packet. The receiving routing device uses an
authentication key (password) to verify the packet’s MD5 checksum.

Hitless Key Rollover

Hitless authentication key rollover allows users to choose the algorithm through which authentication is established. The
user associates a keychain and an authentication algorithm with a BGP neighbor session. The keychain includes multiple
keys. Each key contains an identifier and a secret. The key is also configured with a unique start time and an end time.
[edit protocols bgp]
authentication-key-chain “bgp key chain”
group int-65503 {
type internal;
local-address 192.168.100.1;
neighbor 192.168.100.2
}
Continued on the next page.

Chapter 8–20 • BGP www.juniper.net

 Advanced Junos Service Provider Routing
Hitless Key Rollover (contd.)
[edit security]
authentication-key-chains {
key-chain “bgp key chain” {
key 1 {
secret juniper1;
start-time 2011-03-01.02:00:00;
}
key 2 {
secret juniper2;
start-time 2011-04-01.02:00:00;
}
}
}

www.juniper.net BGP • Chapter 8–21

Advanced Junos Service Provider Routing

BGP Operations
The slide highlights the topic we discuss next.

Chapter 8–22 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

BGP Route Tables

BGP uses three different storage tables known as routing information bases (RIBs) as databases to maintain routing
knowledge. A separate Adjacency-RIB-IN table exists for each established BGP peer to store all routes received from that
peer. The RIB-LOCAL table is where BGP stores routes used for traffic forwarding. A separate Adjacency-RIB-OUT table is also
created for each established BGP peer to house the routes that are to be advertised to that peer.

BGP Active Routes

BGP can move only active BGP routes in the routing table into the Adjacency-RIB-OUT tables and advertise them to BGP
peers. In addition, BGP places only the single, best BGP path to each separate IP route destination in the RIB-LOCAL and
Adjacency-RIB-OUT tables.
At times, the best BGP path might not be advertised to a peer because the local router’s routing table rules. For example, if
the router knows about a particular route through both IS-IS and BGP, the IS-IS route will be active in the local routing table
because of the default Junos OS protocol preference values. Therefore, the BGP version of that route is not sent to any peers
because BGP advertises only active routes (routes used by BGP). To override this default action, you can use the
advertise-inactive command. This command always forces the advertisement of the single, best BGP path to any
destination, regardless of whether the route is currently active in the local routing table.

www.juniper.net BGP • Chapter 8–23

Advanced Junos Service Provider Routing

Default BGP Advertisement Rules

By default, only active BGP routes are advertised. The slide illustrates the default BGP advertisement rules. The rules are as
follows:
1. IBGP peers advertise routes received from EBGP peers to other IBGP peers.
2. EBGP peers advertise routes learned from IBGP or EBGP peers to other EBGP peers.
3. IBGP peers do not advertise routes received from IBGP peers to other IBGP peers.
The purpose of the advertisement rules is to prevent routing loops on a BGP network.

Chapter 8–24 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

IBGP Route Propagation

IBGP speakers send routes to their IBGP peers that they received from EBGP peers and routes that they originated
themselves. IBGP speakers never send routes to IBGP peers that they learned from other IBGP peers. For all IBGP speakers
in an AS to have consistent routing information, a full mesh of IBGP sessions must exist between all BGP speakers. Without
this full mesh, some BGP speakers might not receive all the required routing information.
In the example on the slide, a full mesh of IBGP sessions does not exist. R1 receives the announcement through an EBGP
session. Because it is the best route it has for that prefix, it propagates the route to its IBGP peer R2. R2 also determines
that route to be its best path for the prefix; however, it does not send the route to its IBGP peer R3. Because it received the
route through IBGP, it cannot send the route to any IBGP peers. Therefore, R3 does not receive or install a route for the prefix
advertised from AS 65502. This situation can be alleviated by adding an IBGP session between R1 and R3. (Whether the two
routers are directly connected is irrelevant.)
If IBGP routers readvertised IBGP routes to other IBGP peers, a loop would form. Because the AS path is not updated by each
router, but rather only when the associated prefix is advertised to an EBGP peer, the AS path cannot be used to detect loops
for BGP routes advertised within an AS. For this reason, BGP enforces advertisement rules that require the full-mesh peering
of IBGP routers to ensure consistent routing information on all IBGP routers within the AS.
Using route reflectors or confederations can also alleviate this situation, both of which can reduce or alleviate the full-mesh
requirement. Route reflectors and confederations will be covered in a later chapter of this class.

www.juniper.net BGP • Chapter 8–25

Advanced Junos Service Provider Routing

Hidden Routes
You might expect all routes received from a BGP peer would be installed in the RIB-LOCAL table and be visible using the
show route protocol bgp command. But hidden BGP routes occur for several reasons:
• The route might be a martian route;
• An import policy might exist that prevents the route from being installed; or
• The route’s protocol next-hop might be unresolvable.

Unresolvable Next-Hop
The most common reason for hidden BGP routes is an unresolvable next-hop. The BGP Update message contains a protocol
next-hop IP address. If the router cannot resolve this address using its routing table, the route cannot be used and is not
installed in the routing table.
The number of hidden routes is always shown in the output of the show route command. To view why routes are hidden,
issue the show route hidden extensive command.

Chapter 8–26 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

IBGP Next-Hop Propagation

By default, the next-hop attribute attached to a route is unchanged as it passes through an AS. Because routers can use the
BGP routes only if they already have a route to the next hop, you must either configure the routers to advertise external
interfaces through the IGP, or configure the routers to change the next-hop attribute attached to BGP routes using policy.
When EBGP speakers send routes to a peer, they set the next-hop attribute to the interface they share with that peer. In this
example, R1 receives a route from its EBGP peer with the next-hop attribute set to 172.24.1.1. R1 sends this route to R2
without changing the next-hop attribute. Therefore, to use this route, R2 either must know how to reach 172.24.1.1 through
the IGP or static routing, or R1 must send the routes with a different next hop.
You can send the appropriate external routes into the IGP, if wanted; however, using the next-hop self action in a policy
has some advantages. Using the next-hop self action in a policy causes the router to send BGP routes to its peers using
the same IP address it uses to establish that BGP session. For the BGP session to remain established, the peer must have a
route to that IP address. Therefore, using next-hop self guarantees that a router’s peers can reach the next hop of the
routes that router sends, as long as the BGP session remains established.

www.juniper.net BGP • Chapter 8–27

Advanced Junos Service Provider Routing

BGP Next-Hop Solutions

Numerous ways exist to solve this BGP next-hop reachability problem. However, only two are considered as best practices in
a networking environment.
The most commonly used (and recommended) solution is next-hop self. With this solution, when a BGP router
advertises an EBGP-learned route to an IBGP peer, it alters the BGP next-hop attribute. The next-hop attribute’s IP address of
the remote EBGP peer is replaced with the IP address of the BGP router itself. Because the IBGP session was most likely
established using the peer’s loopback address, this new BGP next-hop value is reachable, and the advertised BGP route can
be used. We create next-hop self by using a policy to match specific routes with an action of changing the next-hop
attribute value. The Junos OS then applies this policy as an export policy to any IBGP peers.BGP Next-Hop Solutions (contd.)
With IGP passive, the IGP is configured on the inter-AS link and advertises the interface addresses, but forms no adjacency
(it is passive). Both methods inject the interface addresses into the local routing table for the IGP to use.
An IGP passive interface allows the local IGP to advertise the subnet on a particular interface without forming an adjacency
at the IGP level to the remote EBGP peer, which has the advantage of not using a policy, but it requires explicit configuration
for each interface and subnet address that you want to advertise.

Chapter 8–28 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

BGP Path Selection and Options

The slide highlights the topic we discuss next.

www.juniper.net BGP • Chapter 8–29

Advanced Junos Service Provider Routing

Summary of BGP Active Route Selection

Before the router installs a BGP route, it must ensure that the BGP next-hop attribute is reachable and that no routing loops
exist. If the BGP next hop cannot be resolved or if a loop is detected, the route is not evaluated through the BGP route
selection process or installed in the route table.
Before the Junos OS installs a BGP route in the routing table, the route preference is evaluated. Remember that the route
preference can be changed through policy so the route preference can differ for the same prefix learned through different
BGP paths. If the route preference for a BGP prefix learned through different BGP paths differs, the BGP route with the lower
route preference is selected. Note that this evaluation occurs prior to the BGP selection process outlined on the slide.
When a BGP route is installed in the routing table, it must go through a path selection process if multiple routes exist to the
same destination prefix and the route preference is the same. The BGP path selection process proceeds in the following
order:
1. The router compares routes for the highest local preference (the only choice based on a higher, rather than
lower, value).
2. The router evaluates the AS-path attribute next, where a shorter path is preferred. This attribute is often a
common tiebreaker for routes.
3. The router evaluates the origin code. The lowest origin code is preferred: ( I [IGP] < E [EGP] < ? [Incomplete]).
Continued on the next page.

Chapter 8–30 • BGP www.juniper.net

 Advanced Junos Service Provider Routing
Summary of BGP Active Route Selection (contd.)
4. If any of the remaining routes are advertised from the same neighboring AS, the router checks the MED
attributes for the lowest value. The absence of a MED value is interpreted as a MED of 0.
5. If multiple routes remain, the router prefers any routes learned through an EBGP peer over routes learned
through an IBGP peer. If all remaining routes were learned through EBGP, the router skips to Step 9.
6. If the remaining routes were learned through IBGP, use the path with the lowest IGP cost to the IBGP peer. For
each IBGP peer, install a physical next hop based on the following three rules:
a. BGP examines both the inet.0 and the inet.3 routing tables for the BGP next-hop value. The physical
next hop of the instance with the lowest Junos OS preference is used, which often means that BGP uses
the inet.3 version of the next hop, through an MPLS LSP.
b. Should the preference values in the inet.0 and the inet.3 routing tables tie, the physical next hop of
the instance in inet.3 is used.
c. When a preference tie exists and the instances are in the same routing table, the number of equal-cost
paths of each instance are examined. The physical next hop of the instance with more paths is installed.
This tie might occur when the traffic-engineering bgp-igp option is used for MPLS.
7. BGP then uses the route advertised from the peer with the lowest RID (usually the loopback IP address). When
comparing external routes from two distinct neighboring ASs, if the routes are equal up to the RID comparison
step, the currently active route is preferred. This preference helps prevent issues with MED-related route
oscillation. The external-router-id command overrides this behavior and prefers the external route with
the lowest RID, regardless of which route is currently active.
8. The router then examines the cluster-list attribute for the shortest length. The cluster list is similar in function to
an AS path.
9. The router prefers routes from the router with the lowest peer IP address.

www.juniper.net BGP • Chapter 8–31

Advanced Junos Service Provider Routing

RID and Peer ID Ignored

When you configure multipath on a BGP router, the selection algorithm ignores both the RID and the peer ID selection
criteria. Should multiple copies of a route reach those portions of the route selection process, BGP installs all copies into the
local routing table. Each version is listed in the table with only one of them marked as active. This active route is the version
of the route that would have been selected by the algorithm had the multipath option not been configured. However, the
next-hop values for the nonactive routes are also listed as valid next hops for the active route. This listing allows the Junos OS
default load-balancing options to be used.
The Junos OS also utilizes the link bandwidth extended community to unequally load-balance traffic in conjunction with the
multipath command. If used, data packet forwarding is performed in a proportional manner to the bandwidth advertised
in the extended community.
The multipath command allows multiple copies of a route from the same remote router. It also allows multiple copies of a
route from two different routers in the same AS (either a local or remote AS). The entire concept centers around resiliency
and redundancy.
The slide shows the R1 router peering with two routers in AS 2—R2 and R3. Both of the AS 2 routers are advertising the same
four routes. Currently, the versions of the routes from R2 (10.222.28.2) are selected and placed into the routing table. We
have some clues into this behavior by examining the output of the show bgp summary command. The route information
from R2 shows 4/4/4/0, which means that the four received routes are active in the local routing table. R3, on the other
hand, has route information of 0/4/4/0. Its four advertised routes are not active in the routing table.

Chapter 8–32 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Single Next Hop for All Routes

The local routing table of the R1 router is shown on the slide. We see the four routes advertised from AS 2: 172.16.20.4/30,
172.16.20.8/30, 172.16.20.12/30, and 172.16.20.16/30. Each listing of the prefix contains two versions of the route. One
route is from the R2 router (10.222.28.2), and this route is marked active. The other version of the route is from the R3
router (10.222.29.2), and it is marked inactive.

www.juniper.net BGP • Chapter 8–33

Advanced Junos Service Provider Routing

Configure multipath on R1
The configuration of the R1 router now contains the multipath command within the peer group for AS 2. After committing
the configuration, we examine the contents of the local routing table. We still see the four routes advertised from AS 2, and
each listing of the prefix still contains two versions of the route. As before, the routes from the R2 router are marked active
while the routes from the R3 router are marked inactive.
The effect of the multipath command on the routes from AS 2 is that the next hop for the routes from R3 (10.222.29.2)
are now added to the version of the route from R2. The next-hop information for the inactive route version does not change in
this environment.
Because each active route now has two next hops in the routing table, the default Junos OS load-balancing process can be
used. Each route has a single next hop selected, and this single next hop is placed into the forwarding table. All traffic for
each route uses just that single next hop. The overall benefit of this system is the total amount of traffic sent from AS 1 to
AS 2 can now be load-balanced over the two inter-AS links. In our small example, the 172.16.20.4/30 and 172.16.20.16/30
routes are using the 10.222.28.2 next hop, while the other two routes use the 10.222.29.2 next hop. As more routes are
announced between the AS networks, the selection of the next hops becomes more evenly distributed.
Continued on the next page.

Chapter 8–34 • BGP www.juniper.net

 Advanced Junos Service Provider Routing
Configure multipath on R1 (contd.)
As shown below, you can also see the effects of using multipath in the output of the show bgp summary command. The
route information from both R2 and R3 now appears as 4/4/4/0. The routes from R2 are active, while the next-hop values
from R3 are also used to forward user traffic.
user@R1> show bgp summary
[...]
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/
Damped...
10.222.28.2 2 53 53 0 0 1:53:13 4/4/4/0 0/0/0/0
10.222.29.2 2 54 51 0 0 1:53:13 4/4/4/0 0/0/0/0

www.juniper.net BGP • Chapter 8–35

Advanced Junos Service Provider Routing

BGP Multihop Peering

The default for an EBGP connection is to peer over a single physical hop using the physical interface address of the peer. In
some cases, altering this default, one-hop, physical peering EBGP behavior is advantageous. One such case is when multiple
physical links connect two routers that are to be EBGP peers. In this case, if one of the point-to-point links fails, reachability
on the alternate link still exists. You must take three extra configuration steps to accomplish a single BGP peering session
across these multiple physical links.
First, each router must establish the peering session with the loopback address of the remote router. You can configure this
session using the local-address command, which alters the peer address header information in the BGP packets.
Second, use the multihop command to alter the default use of the neighbor’s physical interface address. In addition, you
can also specify a time-to-live (TTL) value in the BGP packets to control how far they propagate. On the slide, we use a TTL
value of 1 to ensure that the session cannot be established across any other backdoor links in the network. Third, each
router must have IP routing capability to the remote router’s loopback address. As the slide shows, we often accomplish this
capability by using a static route to map the loopback address to the interface physical addresses.
Note that when multihop is configured, the Junos OS sets the TTL value to 64, by default. You can specify a TTL value
explicitly to limit the scope of the EBGP session. Note that a TTL value of 1 is sufficient to enable an EBGP session to the
loopback address of a directly connected neighbor because the IP TTL is decremented for egress traffic only, and this traffic
will be considered destined for the local Routing Engine.

Chapter 8–36 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Routes with Multiple Next Hops

Within the context of a BGP network, both the multihop and multipath tools can result in a route being installed in the local
routing table with multiple next hops. As we previously discussed, this route allows the Junos OS to perform per-prefix load
balancing as the total amount of traffic sent towards the destinations is spread across the multiple next hops. However, each
route selects a single next hop for forwarding traffic, which is installed into the forwarding table on the Packet Forwarding
Engine (PFE).
The slide shows the BGP route of 172.16.20.4/30, which is active in the routing table. This route has two possible next hops
it can use to forward traffic—10.10.1.1 and 10.10.2.1. It has currently selected the 10.10.2.1 next hop, which we verify in the
forwarding table with the show route forwarding-table command. The router output shows this single next hop in
the table with a type set to ucst, for unicast transmission.

www.juniper.net BGP • Chapter 8–37

Advanced Junos Service Provider Routing

Load Balancing
You can alter the default behavior of the Junos OS to install a single next hop per route in the forwarding table with a routing
policy. The policy should contain the action of then load-balance per-packet and be applied as an export policy to
the forwarding table within the [edit routing-options] configuration hierarchy.
After committing the configuration, we see the same 172.16.20.4/30 route in the routing table of the local router. The same
protocol information is displayed and again, a single next hop has been selected. This selection mechanism is not affected
by our load-balancing policy, so we cannot verify whether it is working by examining the routing table. Instead, a look at the
forwarding table shows the outcome of our policy. Both the 10.10.1.1 and the 10.10.2.1 next hops are listed as valid
outbound interfaces for the 172.16.20.4/30 route. Traffic destined for this route is now forwarded across both available next
hops using a microflow hashing algorithm. The default inputs to the microflow hash are the incoming router interface, the
source IP address, and the destination IP address. You can modify the inputs to the hashing algorithm at the [edit
forwarding-options hash-key family inet] configuration hierarchy. Specifying the layer-4 command at this
configuration hierarchy incorporates Layer 4 source and destination port information into the hash key.

Chapter 8–38 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Configuration Options
The slide highlights the topic we discuss next.

www.juniper.net BGP • Chapter 8–39

Advanced Junos Service Provider Routing

passive Option
By default, a local router initiates a BGP open message to the remote router to establish the session. The passive
command stops this default action, and no open message is sent. The IP address and AS of the remote peer are still
configured, but the remote router must initiate the BGP session.

allow Option
The related option of allow also stops the sending of a BGP open message to the remote router. In addition, the allow
command also relaxes the requirement of explicitly configuring the remote router’s IP address by allowing you to define a
subnet range for connections. BGP processes any open message received from an IP address within the configured range
and initiates a session with that remote router.

Chapter 8–40 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Limiting the Number of Prefixes Accepted

By default, each BGP router accepts any number of routes sent from each of its peers. You might want to alter this default
setting for either security or memory reasons. You can use the prefix-limit command to set a limit on the maximum
number of routes received from any individual peer. Use the maximum option to set the total amount of routes able to be
received. When a BGP peer sends more routes than allowed, the peering session is terminated and restarted immediately
with the teardown option. The value that immediately follows the teardown option is a percentage of routes upon which
the router starts to generate system log messages. You can halt the BGP peering session between the two routers for up to
40 hours by specifying a value (in minutes) with the idle-timeout option. In addition, you can specify a value of
forever. This value requires you to intervene manually to restart the peering session.

Altering the Session Hold Time

When two BGP peers establish their peering session, they negotiate the hold time for that relationship. By default, the Junos
OS uses a value of 90 seconds to negotiate for the hold time of the session. The hold-time command allows you to alter
this value from as short as 20 seconds to as long as 65,535 seconds (18 hours, 12 minutes, and 15 seconds).

www.juniper.net BGP • Chapter 8–41

Advanced Junos Service Provider Routing

Disabling Suppression of Route Advertisements

By default, the Junos OS does not advertise the routes learned from an EBGP peer back to the same EBGP peer. In addition,
the software does not advertise those routes back to any EBGP peer that is in the same AS as the originating peer. You can
modify the default behavior with the advertise-peer-as command. Before Junos OS release 7.0,
advertise-peer-as was the Junos OS default behavior.

Chapter 8–42 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Graceful Restart
Graceful restart (GR) addresses the situation described on the previous slide. GR allows a router undergoing a restart event,
including a restart of the routing protocol daemon (rpd), to inform its adjacent neighbors and peers of its condition. The
restarting router requests a grace period from the neighbor or peer, which can then cooperate with the restarting router.
When a restart event occurs and GR is enabled, the restarting router can still forward traffic during the restart period, and
convergence in the network is not disrupted. The neighbors or peers of the restarting router, also known as helper routers,
hide the restart event from other devices not directly connected to the restarting router. In other words, the restart is not
visible to the rest of the network, and the restarting router is not removed from the network topology.
The GR request occurs only if the following conditions are met:
• The network topology is stable;
• The neighbor or peer cooperates;
• The restarting router is not already cooperating with another restart already in progress; and
• The grace period does not expire.

www.juniper.net BGP • Chapter 8–43

Advanced Junos Service Provider Routing

GR Support
As shown on the slide, GR is supported by several standards-based protocols. A number of RFCs and drafts exist that
document the operational details for GR and each of the protocols for which GR is supported. While these different protocols
implement GR slightly differently, the basic concepts and operations are the same from a high availability point of view.

GR Requirements
Routers must have GR enabled to support both GR router modes—the restarting router mode and helper router mode. By
default, Junos devices can operate as helper routers but not as restarting routers; restarting router mode functionality must
be enabled through configuration. We cover GR configuration on subsequent slides.
In addition to having the GR functionality enabled, the router must support nonstop forwarding operations, which simply
means the router must be able to continue forwarding traffic during times of control plane instability. Nonstop forwarding is
an inherent attribute of Junos devices because of the architectural design, which cleanly separates the control and
forwarding planes.

Chapter 8–44 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Configuring GR: Part 1

GR helper mode is enabled by default on all Junos devices. You can disable GR helper mode globally for all supported
protocols at the [edit routing-options] hierarchy or on a per-protocol, per-group, or per-neighbor basis, depending
on the specific protocol. The slide illustrates the syntax required to disable GR helper mode globally, enable GR helper mode
for the BGP protocol, and disable GR for a BGP peer. As with many similar configuration scenarios, the most specific
definition is used.

www.juniper.net BGP • Chapter 8–45

Advanced Junos Service Provider Routing

Configuring GR: Part 2

GR’s restarting router mode is not enabled by default. You can enable GR restarting router mode through configuration at
the [edit routing-options] hierarchy. The slide provides a sample configuration used to enable GR’s restarting
router mode globally and for all protocols along with a sample configuration that disables GR for a specific BGP peer.
The following are the available GR configuration options for BGP:
[edit protocols]
user@R1# set bgp graceful-restart ?
Possible completions:
<[Enter]> Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
disable Disable graceful restart
restart-time Restart time used when negotiating with a peer (1..600)
stale-routes-time Maximum time for which stale routes are kept (1..600)
| Pipe through a command

Chapter 8–46 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Modifying the Local Preference

The Junos OS provides a configuration option within BGP that alters the local preference attribute value for all advertised
routes. You can use the local-preference command at the global, group, or peer level in the BGP configuration. All
advertised routes will inherit this value for the local preference attribute.
The exception to this rule are any routes whose attributes are modified by an applied routing policy. These routes abide by
the action defined in the policy and take precedence over the configured value. In other words, the configuration option is
applied before the routing policy is applied for all outbound BGP routes.

www.juniper.net BGP • Chapter 8–47

Advanced Junos Service Provider Routing

Eliminating Private AS Numbers

In spite of the wording in the BGP RFC, many vendors include configuration options in their BGP implementations that
remove information from the AS path, which is technically not allowed. This removal, however, only operates on specific
information in the AS path attribute, and it does not apply to making arbitrary changes to the actual AS path. Typically, the
information removed was placed there by the AS itself or by other routers within the administrative control of the AS. Thus,
one AS is not trampling on the path information another AS has put into the AS path attribute.
One example of this type of configuration option is the remove-private configuration statement. This keyword allows an
ISP to remove private AS numbers from paths received from BGP customers when those customers are using private AS
numbers. Because the customers are effectively within the administrative scope of the ISP, the provider is allowed to remove
the private AS numbers from the path.
On the slide, AS 1000 has three different customers connected using BGP. The customers are using AS 65001, AS 65002,
and AS 65003 for the BGP peer communications. Within AS 1000, each of the BGP routers sees the private AS numbers
within the path.
The remove-private option is enabled on the R1 router in AS 1000. As BGP advertises the customer routes out of AS
1000, the private AS numbers are removed from the AS path attribute. In this case, BGP views all customer networks as
having originated within AS 1000.
You should not use this option in a BGP confederation network. We describe why the remove private option should not be
used with BGP confederation in a subsequent chapter.

Chapter 8–48 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Modifying the AS Path Attribute: Part 1

Another option for removing AS path attribute information is the local-as configuration statement. The purpose of the
local-as keyword is to aid an ISP in migrating BGP customers to a new AS number. The following slides display an
example of how you can use the local-as option.
Consider the normal BGP AS path operation first. AS 1 has two customers for which it provides service: AS 222 and AS 333.
As AS 1 announces these routes from AS 222 and AS 333 on to the Internet, AS 1 injects its own AS number (1) into the AS
path attribute, as the BGP RFC expects.
So far, nothing is unusual about the AS path operation.

www.juniper.net BGP • Chapter 8–49

Advanced Junos Service Provider Routing

Modifying the AS Path Attribute: Part 2

Next, consider what happens if AS 1 merges with AS 777. This situation is shown on the slide.
Suppose the resulting merged organization decides to use AS 777 as the official AS to represent both networks on the
Internet. To ease in the migration of the customer BGP configurations from AS 1 to AS 777, the edge routers can use the
local-as 1 configuration option.
The effect of this option is that the customer routes within AS 777 see both AS 1 and the customer AS numbers (AS 222 and
AS 333). As AS 777 advertises those routes to the Internet, it prepends its own value of AS 777 onto each of the routes.
Therefore, even though AS 1 has been merged into AS 777, AS 1 still shows up on the paths sent to the Internet.

Chapter 8–50 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Modifying the AS Path Attribute: Part 3

You can use an optional parameter with the local-as configuration statement that actually does remove AS path
information from the BGP AS path attribute. This optional parameter restricts knowledge of AS 1 to the edge router
connected to the customer (AS 222 and AS 333) only. This situation is shown on the slide.
On the slide, the edge router in the formerly intact AS 1 is configured with the option of local-as 1 private. As the
edge router advertises the customer routes into AS 777, AS 1 information is removed from the AS path attribute, as shown
on the slide. At this point, the AS 777 routers, as well as the Internet, have no knowledge of AS 1.
The local-as 1 private statement now has indeed removed AS path information. Again, this example applies to a type
of special case and should not be used arbitrarily to attempt to change AS path information received from another AS.
Other options are the following:
• local-as autonomous-system alias: A BGP peer considers any local AS to which it is assigned as
equivalent to the primary AS number configured for the routing device. When you use the alias option, only
the AS (global or local) used to establish the BGP session is prepended in the AS path sent to the BGP neighbor.
• local-as loops number: Specify the maximum number of times that the local AS number can appear in
an AS path received from a BGP peer. For number, include a value from 1 through 10.

www.juniper.net BGP • Chapter 8–51

Advanced Junos Service Provider Routing

Overriding the Default Prepend Action

In certain situations, the default mechanics of the AS path prepend mechanism might cause routes to not be received by a
peer. One such situation is displayed on the slide.
AS 65432 is providing transit service to AS65022, which peers at two different locations. For reasons that we do not discuss
in this chapter, the two portions of AS 65022 do not have any other peering links between them. In fact, these two sections
of the network rely on AS 65432 for reachability information to the other half of the AS. By default, the R3 router does not
advertise 172.16.10.0/24 route to AS 65022. After all, AS 65022 is already in the AS path.
Assume both EBGP peers in AS 65432 alter their configuration with their peers in AS 65022 to include the as-override
command. This command allows the routers in AS 65432 to examine the AS path before advertising the route and look for
any instances of AS 65022 already in the path. Should it find any, they are replaced with the peer’s own AS, 65432 in this
case. The R3 peer then performs the default prepend action before advertising the route to R4. The R4 router in AS 65022
now receives the route without an AS path loop and installs it in its local routing table.

Chapter 8–52 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Allowing AS Paths Loops

The Junos OS allows you to configure your router to accept an AS path loop in certain situations. The slide once again shows
AS 65432 providing transit service to AS65022. As before, the
172.16.10.0/24 route is not accepted by the router in AS 65022 because of an AS path loop.
The configuration option used in this example is performed on the router in AS 65022 itself. The optional keyword loops is
appended to the autonomous-system command within the [edit routing-options] configuration hierarchy. This
keyword allows the local AS number to appear multiple times in the path. The route can then be received by the router in AS
65022.
This scenario also requires the EBGP peer in AS65432 to be configured with the advertise-peer-as command.
Otherwise, routes learned from one instance of AS 65022 will not be advertised to the second instance of AS 65022.

www.juniper.net BGP • Chapter 8–53

Advanced Junos Service Provider Routing

We Discussed:
• Basic BGP operation;
• Common BGP attributes;
• The route selection process for BGP;
• The alteration of the route selection process; and
• The configuration of some advanced options for BGP peers.

Chapter 8–54 • BGP www.juniper.net

 Advanced Junos Service Provider Routing

Review Questions
1.

2.

3.

4.

5.

www.juniper.net BGP • Chapter 8–55

Advanced Junos Service Provider Routing

BGP and BGP Attributes Lab

The slide provides the objective for this lab.

Chapter 8–56 • BGP www.juniper.net

 Advanced Junos Service Provider Routing
Answers to Review Questions
1.
Using loopback addresses for peering sessions between IBGP neighbors maintains reachability even when the physical topology
changes as long as a viable path exists.
2.
EBGP-learned routes are advertised to both EBGP and IBGP peers. IBGP-learned routes are advertised to EBGP peers. However,
IBGP-learned routes are not advertised to other IBGP peers to prevent routing loops.
3.
With Junos OS, all new BGP routes have an origin code of I=Internal.
4.
When you configure multipath on a BGP router, the route selection algorithm ignores both the router ID and the peer ID selection
criteria.
5.
Five approaches can solve the BGP next hop issue: Next-hop self; IGP passive interfaces; Export direct routes into IGP; Static routes;
and IGP adjacency formed on inter-AS links to EBGP peers.

www.juniper.net BGP • Chapter 8–57

Advanced Junos Service Provider Routing

Chapter 8–58 • BGP www.juniper.net

Advanced Junos Service Provider Routing

Chapter 9: BGP Attributes and Policy—Part 1

Advanced Junos Service Provider Routing

We Will Discuss:
• Various BGP attributes in detail and explains the operation of those attributes; and
• The manipulation of BGP attributes using routing policy.

Chapter 9–2 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

BGP Policy
The slide lists the topics we cover will discuss. We discuss the highlighted topic first.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–3

Advanced Junos Service Provider Routing

BGP and Policy Dependency

BGP is a very policy-oriented protocol, in the sense that import and export policies largely determine BGP behavior. The
router can use all the BGP attributes. You can adjust these attributes to influence the behavior of the local router as well as
other routers receiving the route.
You can use each of the BGP attributes as a match criterion for a policy, and you can modify each attribute using a policy
action. You can further decide to act on a BGP attribute based on whether it is an EBGP or IBGP route. To understand better
where BGP import and export policies are applied to BGP routes, we detail the process of how a router uses BGP routes.

BGP RIB Tables

BGP uses three different storage tables, known as routing information bases (RIBs), as databases to maintain routing
knowledge. A separate RIB-IN exists for each established BGP peer to store all routes received from that peer. A RIB-LOCAL is
where BGP stores routes used for traffic forwarding. A separate RIB-OUT exists for each established BGP peer to store routes
to be advertised to that peer.
Continued on the next page.

Chapter 9–4 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing
BGP and Active Routes
Only active BGP routes in the routing table can be moved into the RIB-OUT tables and are advertised to BGP peers. In
addition, only the single best BGP path to each separate IP route destination is placed in the RIB-LOCAL and RIB-OUT tables.
At times, it is possible that the best BGP path is not advertised to a peer because of the local router’s routing table rules. For
example, if the router knows about a particular route through both IS-IS and BGP, the IS-IS route will be active in the local
routing table because of the default Junos OS route preference values. Therefore, the BGP version of that route will not be
sent to any peers because BGP advertises only active routes (routes used by BGP). To override this default action, you can
use the advertise-inactive command. This command always forces the advertisement of the single best BGP path to
any destination, regardless of whether the route is currently active in the local routing table.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–5

Advanced Junos Service Provider Routing

Import Policies and BGP

BGP stores the information about routes received from BGP peers in the RIB-IN table. No policies are applied yet; all BGP
routing information that is received is stored in this table except routes that fail AS path or cluster-ID sanity checks, as well as
VPN routes that do not have a matching target community.
As BGP moves the routes that it received from peers to the RIB-LOCAL table, the Junos routing policy framework can apply
import policies. These policies can reject (filter) routes or can change attributes and affect what the BGP route selection
process uses to pick the best route.
After the BGP import policy or policies (if any are configured and applied) has filtered and manipulated the BGP attributes,
the BGP decision process chooses the best route to use and installs that route into the IP routing table. Note that even if no
routing policies are configured, the default (and unseen) BGP import policy is always applied.

Chapter 9–6 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Sample BGP Import Policy

The slide shows an example of some BGP import policies in action.
Some policies are configured that reject the default route (0/0) if received from AS 1, prefer the AS 1 version of
192.168.14.0/24, and accept all other routes from AS 3. These three policies, which might be three separate policies or a
single policy with three terms, are configured as import policies for BGP.
Import policy is evaluated as the BGP process attempts to move routes from the RIB-IN table to the BGP decision process,
where the active route is selected.
The result of this policy example is that the forwarding table correctly reflects the user’s desire to forward through AS 1 for
traffic matching the 192.168.14.0/24 prefix and AS 3 for traffic matching the 0/0 default route. Note that the routing table
(not shown) will contain two entries for the 192.168.14.0/24 prefix, because the 192.168.14.0/24 prefix coming from AS 3
is not filtered in this example. The AS 1 version of this prefix is preferred and is installed in the forwarding table as a result.
The following list summarizes the overall effects of this policy example:
• The 0.0.0.0/0:AS1 route is rejected.
• The 192.168.14.0/24 route from AS3 is accepted but not preferred.
• The 192.168.14.0/24 route from AS1 is accepted and preferred.
• All other AS3 routes are accepted.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–7

Advanced Junos Service Provider Routing

Export Policies and BGP

BGP stores the information about routes to be advertised to BGP peers in the RIB-OUT table.
As BGP moves the routes from the RIB-LOCAL table to the RIB-OUT table, the Junos routing policy framework can apply export
policies. These policies can reject (filter) routes and affect which BGP routes are advertised to BGP peers or can change the
BGP attributes of advertised routes.
In addition, the Junos OS can inject new routing information into the BGP routing process at this point.

Chapter 9–8 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Sample BGP Export Policy

The slide shows an example of some BGP export policies in action.
Some policies are configured that reject the default (0/0) route, do not send some routes to AS 4, alter a BGP attribute on
routes sent to AS 2, and inject new route information into the BGP process. These four policies, which might be four separate
policies or one policy with four terms, are then configured as export policies within BGP.
As the BGP routing process attempts to move those routes from the RIB-LOCAL table to the RIB-OUT tables, the Junos OS
applies the export policies. The net result of this policy application is shown on the slide and summarized as follows:
• The 0.0.0.0/0:AS3 route is rejected and is not advertised.
• The 192.168.27.0/24:AS3 route is only sent to AS 2.
• The 192.168.14.0/24 route is sent to both AS 2 (with a metric of 10) and AS 4.
• The 172.31.10.0/20 aggregate is sent to both AS 2 and AS 4.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–9

Advanced Junos Service Provider Routing

Next Hop
The slide highlights the topic we discuss next.

Chapter 9–10 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

The Next-Hop BGP Attribute

The next-hop concept in IGPs, such as IS-IS and OSPF, is relatively straightforward. IGPs basically exist to give adjacent
routers next-hop reachability information, which is then flooded (in one form or another) throughout the AS. However, BGP
does not flood BGP peers. And BGP cannot peer unless an underlying IGP route to the peer exists because BGP requires a
TCP session for routes to be exchanged. Thus, BGP cannot bootstrap its own next hops as an IGP does.
Therefore, a next hop in BGP is more elaborate than in any IGP. The concept of the BGP next-hop attribute is important.
Without reachability to the IP address listed in this BGP attribute, a BGP router cannot use the advertised route. This
situation is a very common problem to be solved in any ISP network.
Continued on the next page.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–11

Advanced Junos Service Provider Routing
How BGP Gets Its Next-Hop Information
The default actions for changing the next-hop attribute are detailed below. Subsequent slides discuss various ways to
provide the required reachability.
The BGP next-hop attribute value is only changed when a route is advertised across an EBGP link. In this situation, the IP
address of the advertising router is placed into the attribute. Should the receiving router choose to advertise this
EBGP-learned route to any IBGP peers, it does so without modifying that IP address value. Thus, the EBGP next hop
advertised into a local AS is an address from the remote AS. How is the local IGP supposed to know how to reach this
external address?
When new routing information is injected (or redistributed) into the BGP process, the coding of the next-hop attribute
depends on the specifics of the route being injected. When a redistributed route is associated with a forwarding next hop,
the BGP next-hop attribute is coded with that forwarding next hop. This behavior accommodates optimal forwarding because
it allows a BGP speaker to forward directly to the source of a particular route, even though that source might not speak BGP.
This behavior is known as a third-party next hop. When a redistributed route is not associated with a forwarding next hop,
such as in the case of a locally defined static route with a reject next hop, the next-hop attribute is set to the local router’s
peer ID. For IBGP sessions, the peer ID is typically the local router’s loopback address. For EBGP sessions, the peer ID is
usually a peering address associated with a physical link.

Chapter 9–12 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Next-Hop BGP Example: Part 1

The next few slides graphically show the default BGP behavior with respect to the next-hop attribute. The slide shows the
physical interface addresses along with the loopback addresses of each router.
The slide shows the details for the R3 router. The R3 router has an EBGP session with the R4 router using 10.10.1.2.
The output of the show bgp summary command is listed on the slide. The R3 router is receiving one route from R4 (peer
10.10.1.2) and actively uses that route (signified by the 1/1/1/0 in the output).
You can verify this with the show route receive-protocol bgp 10.10.1.2 output, where 172.19.20.0/24 is
listed as an active route from protocol BGP and a next hop of 10.10.1.2.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–13

Advanced Junos Service Provider Routing

Next-Hop BGP Example: Part 2

The slide shows the output from the R1 router. The R1 router has an IBGP session with the R3 router using R3’s loopback
address of 192.168.10.3.
The output of the show bgp summary command shows that the R1 router is receiving one route from the R3 router (peer
192.168.10.3), but it is not used to forward traffic (last column is 0/1/0).
In fact, a look at the show route receive-protocol bgp 192.168.10.3 output does not show 172.19.20.0/24
(the active BGP route on the R3 router) listed at all. If the 172.19.20.0/24 route is received by the R1 router from the R3
router, then the route should appear as the active route (there is no chance of an AS 1 IGP also supplying this AS 2 route).
What is the problem?

Chapter 9–14 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Next-Hop BGP Example: Part 3

You can see the problem with the absent route to 172.19.20.0/24 on the R1 router with the help of the show route
hidden extensive command run on the R1 router.
The output from this command shows the 172.19.20.0/24 route, but the route is hidden. By examining the output a little
more closely, you can determine that the next hop is unusable (Next hop type: Unusable).
Why is this route unusable? Obviously, connectivity exists from R1 to R3. Notice, however, that the current BGP next-hop
attribute for the 172.19.20.0/24 route is set to 10.10.1.2 (the physical interface IP address of the R4 router). The R3 router
does not change the BGP next-hop attribute before the route is advertised to the R1 router, which is the default
EBGP-to-IBGP behavior—not to change the advertised next-hop attribute value.
Issuing a show route 10.10.1.2 command on the R1 router reveals that it does not have a route to 10.10.1.2. Because
the R1 router does not have reachability to the IP address listed as the BGP next-hop attribute, it cannot use the received
BGP route. On a Juniper Networks router, this type of unusable route is marked as a hidden route.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–15

Advanced Junos Service Provider Routing

BGP Next-Hop Solutions

Numerous ways exist to solve this BGP next-hop reachability problem. However, only two are considered as best practices in
a networking environment.
Perhaps the most commonly used (and recommended) solution is next-hop self. With this solution, when a BGP router
advertises an EBGP-learned route to an IBGP peer, it alters the BGP next-hop attribute. The next-hop attribute’s IP address of
the remote EBGP peer is replaced with the IP address of the BGP router itself. Because the IBGP session was most likely
established using the peer’s loopback address, this new BGP next-hop value is reachable, and the advertised BGP route can
be used. You create next-hop self by using a policy to match specific routes with an action of changing the next-hop attribute
value. The Junos OS then applies this policy as an export policy to any IBGP peers.
The other option is to use passive IGP interfaces. With IGP passive, the IGP is configured on the inter-AS link and advertises
the interface addresses, but forms no adjacency (it is passive). This method injects the interface address(es) into the local
routing table for the IGP to use.
An IGP passive interface allows the local IGP to advertise the subnet on a particular interface without forming an adjacency
at the IGP level to the remote EBGP peer. This option has the advantage of not using a policy, but it requires explicit
configuration for each interface and subnet address that you want to advertise.

Chapter 9–16 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Example Using Next-Hop Self: Part 1

The next few slides show how the use of next-hop-self in a routing policy provides reachability for IBGP peers.
The slide details the situation on the R3 router. The R3 router has an EBGP connection to the R4 router using 10.10.1.2 and
two IBGP connections to the R2 router and to the R1 router.
The R3 router is now configured with the next-hop-self policy shown on the slide as the output of the show
policy-options configuration command. The policy matches all routes (no from) and replaces the BGP next-hop
attribute (because only BGP has a next-hop attribute) with the value self (a keyword for the local router’s physical interface
address on which the route is advertised).
This next-hop-self policy is applied as an export policy to the BGP group int, which includes the R1 router.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–17

Advanced Junos Service Provider Routing

Example Using Next-Hop Self: Part 2

This slide shifts the focus of attention to the R1 router.
The output of the show bgp summary command now shows that the R1 router is receiving one route from the R3 router
(192.168.10.3) and that this route is actively used to forward traffic (signified by 1/1/1/0 in the output).
A look at the show route terse output now shows the 172.19.20.0/24 listed as a BGP route with a next hop of
10.40.4.1. This next-hop address is the self next-hop address advertised for the route to the R1 router by the R3 router
because the route was advertised on the 10.40.4.1 interface.

Chapter 9–18 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Example Using Next-Hop Self: Part 3

How do you know that the BGP next-hop attribute was really changed with the policy? To verify that the policy on the R3
router has indeed changed the BGP next-hop attribute, you can look at the output of the show route 172.19.20.0/24
extensive command on the R1 router.
The output lists the BGP next hop for the 172.19.20.0/24 prefix (which is in AS 2) as 192.168.10.3, the loopback address of
the R3 router. Because the R1 router has IGP reachability to the R3 router, the R1 router also has reachability to the BGP
next-hop value and can use the BGP route.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–19

Advanced Junos Service Provider Routing

Next-Hop Equals Peer Address

The default action of the BGP protocol is for an EBGP-speaking peer to modify the next-hop attribute prior to advertising a
route to peers. The address of the EBGP peering session is the address used for the next hop.

EBGP Peer Can Alter Attribute

An EGBP peer can alter this default action through the use of a policy or a BGP configuration statement. The advertised
address could be an additional EBGP router on a broadcast network. The address could be an IBGP router in the sending
autonomous system (AS). Problems could arise in this situation because the advertised next hop might not be reachable by
the local router. This situation would result in the routes being hidden and unusable.

Policy Used to Change Incoming Next Hop

The local router can use an import policy to alter the next-hop attribute to be the address of the EBGP peer. This address can
guarantee that the local router has connectivity to that next hop. Hence, the advertised routes are usable and active in the
inet.0 routing table.

Chapter 9–20 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Example Using Next-Hop Peer Address: Part 1

The next few slides show how the use of next-hop peer-address in a routing policy corrects the advertisement of
improper addresses.
The slide details the situation on the R1 router. The R1 router has a multihop EBGP connection to the R2 router using
172.16.20.1.
The R2 router advertises routes to the R1 router with a BGP next hop of 172.16.30.1. Because the R1 router does not
currently have IP reachability to the advertised next-hop address, the received routes are unusable. The routes then appear
as hidden routes within the inet.0 routing table.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–21

Advanced Junos Service Provider Routing

Example Using Next-Hop Peer Address: Part 2

The slide shows the policy next-hop-to-peer-address on the R1 router. The policy is applied as an import policy
within the peer group for the R2 router.

Chapter 9–22 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Example Using Next-Hop Peer Address: Part 3

After the configuration on the previous slide is committed, the received routes from the R2 router are then usable.
On the slide, note that the current Protocol Nexthop is listed as 172.16.20.1, which is the peering address of the R2
router. This address is then recursively associated with 10.10.1.2, which is the physical next hop used to reach the R2
router’s loopback address.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–23

Advanced Junos Service Provider Routing

Origin and MED

The slide highlights the topic we discuss next.

Chapter 9–24 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Set by Router Originating the Information

The first router to inject the route into BGP attaches the origin attribute to a prefix (that is, a route). Other routers can change
this value, of course, as the route makes its way through an AS and on to other ASs.

How Believable Is This Information?

The intent of the origin code is to provide a measure of believability as to the origin of a particular route. In other words, the
intent is to provide a kind of where did you get this from? clue for other routers seeing the route.

Well-Known Mandatory BGP Attribute

The origin code is a well-known, mandatory BGP attribute (the Type Code is 1), meaning that each route associated with BGP
must have an origin code assigned to it.

Internal, External, or Unknown

The values available for the origin attribute are internal, external, and incomplete. The internal (I) origin is a tag designated
for all routes learned through a traditional IGP, such as OSPF, IS-IS, or RIP. These types of routes were typically seen as best
sources of information because of their stability at the time BGP was created. The external (E) origin is a tag designated for
routes learned through the original Exterior Gateway Protocol (EGP). This protocol was the precursor to BGP but was not as
robust, and it was generally less reliable than the IGP routes. The last origin code of incomplete (?) is a tag designated for all
routes that did not fall into either the internal or external categories.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–25

Advanced Junos Service Provider Routing
Internal Better than External Better than Unknown
Each of the origin tags is assigned a value for use in transmitting the attribute to other BGP speakers. The values are 0 for
internal origin (I), 1 for external origin (E), and 2 for unknown (incomplete) origin (?). A lower value is better, so routes learned
from an IGP are preferred over routes learned from an EGP. EGP routes are better than incomplete routes.

The Junos OS Default Is Internal—IGP

Because all routing information eligible to be injected into BGP on a Juniper Networks router resides in inet.0, the Junos OS
sees all possible routes as internal routes. These internal routes all receive a BGP origin code of internal when placed into
BGP.

Chapter 9–26 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

How Origin Is Used

The slide shows the default BGP behavior within the Junos OS with regard to the origin code.
Within the AS shown, the static routes of 10.0.0.0/8, 172.16.0.0/16, and 192.168.27.0/24 exist. An export policy placed
these routes into BGP. A direct route of 192.168.14.0/24 exists that was exported into BGP. The route to 172.31.0.0/24 was
learned from another AS altogether, and this route contains an origin attribute coded to 2, which indicates an unknown
origin. Finally, an IGP-learned route of 10.20.0.0/16 exists in the network. The router does not know whether this route is an
OSPF route or an IS-IS route, but the route had the appropriate export policy and, therefore, was placed into BGP.
To the Juniper Networks router, it does not matter that these routes are advertised to another AS through EBGP; the BGP
origin code is not altered as the routes are advertised to an EBGP peer. On the basis of the origin attribute alone, the
172.31.0/24 prefix appears less attractive to the remote AS.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–27

Advanced Junos Service Provider Routing

Example of Origin Attribute Use: Part 1

In the collection of AS networks on the slide, for all routes originated by AS 1, the BGP origin code is at its default setting of
internal. These routes are sent to each of the AS networks on the slide.
How will AS 40 send traffic to AS 1? Through AS 30, or AS 20, or AS 10? Assume that the local-preference BGP attribute is
the default, and that the AS-path BGP attribute accurately reflects the actual path for the route.
Routers in AS 40 see the AS 1 routes advertised from both AS 20 and AS 10. Because the local-preference values and
AS-path lengths are the same for both sets of routes, the origin code is examined.
For both sets of routes, the origin code is the same as well. Some other method must be used to determine which path the
AS 40 routers use. Although that determination is outside the scope of this slide, the important point here is that AS 1 has
no way to control how the AS 40 routers reach the AS 1 networks, based on the default value of the origin code alone.

Other AS Networks
Note that routers in AS 30 use AS 20 to reach the networks in AS 1, because of a shorter AS-path length through AS 20. Also,
routers in AS 20 use AS 2 to reach the networks in AS 1, because of a shorter AS-path length. Finally, routers in AS 10 use AS
3 to reach the networks in AS 1, because of a shorter AS-path length. Why should AS 40 be the only AS confused about the
best way to reach AS 1?

Chapter 9–28 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Example of Origin Attribute Use Part 2

On the previous slide, only AS 40 had multiple path options after examining the AS-path length, because both AS 10 and AS
20 are the same distance away from AS 1. At this point, the value of any other tiebreakers that AS 40 might use to pick one
of those two paths through AS 10 or AS 20 is unknown to AS 1.
However, perhaps AS 1 now decides that traffic sent to it from AS 40 should use AS 10 rather than AS 20 (for reasons of
economics, politics, or something else). By using a routing policy, AS 1 alters the BGP origin code to incomplete (?) on all
routes advertised to AS 2. Consider the effect of this policy on AS 40.
Routers in AS 40 still see the AS 1 routes advertised from both AS 20 and AS 10. Because the local-preference and AS-path
lengths are the same for both sets of routes, the origin code is examined. The routes received by AS 40 from AS 10 have an
origin of internal (0) while the routes received from AS 20 have an origin code of incomplete (2). Internal is better (lower)
than incomplete, so the routes from AS 10 are used to reach the networks in AS 1. By altering the origin code, AS 1 can now
influence the routing decisions in AS 40.
Continued on the next page.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–29

Advanced Junos Service Provider Routing
Other AS Networks
Note that, because of shorter AS-path length, the following occur:
Routers in AS 30 still use AS 20 to reach the networks in AS 1.
Routers in AS 20 still use AS 2 to reach the networks in AS 1.
Routers in AS 10 still use AS 3 to reach the networks in AS 1.
Notice also that all the other AS networks on the slide (besides AS 40) still use the AS-path length for route selection. The
origin code is truly only effective when the AS-path lengths are equal.

Chapter 9–30 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Modifying Origin with a Policy

The slide shows an example of a BGP export policy that changes the origin code. This example finds all BGP routes and
changes the origin code from internal (0) to incomplete (2).
The match criteria for the policy are all active BGP routes that currently have an origin code of internal. The action for the
policy is to change the origin code to incomplete. Once applied as a BGP export policy and committed, this policy starts
altering the origin code for all BGP routes advertised to all BGP peers.
The Junos OS has specific keywords to represent the different BGP origin codes. They are:
• igp: Internal (value 0);
• egp: External (value 1); and
• incomplete: Incomplete (value 2).

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–31

Advanced Junos Service Provider Routing

MED Is Optional, Nontransitive

The BGP multiple exit discriminator (MED) attribute is an optional, nontransitive attribute of BGP. Thus, a BGP
implementation does not have to understand or use MEDs at all, and a MED is not sent through one AS and on to another
AS. In other words, MEDs are only exchanged between pairs of directly connected ASs. So, by default, MED values are
transmitted along with BGP routes within the AS where the MED first originated and to all neighboring ASs. The MED travels
no further without some intervention from a policy or alternate configuration.

Used with Multiple Inter-AS Links

The MED is a type of routing metric assigned to BGP routes. The function of the MED is to assist a neighboring AS to pick
which of multiple links connecting the remote AS to the local AS (ingress paths) to use for traffic to a particular route (prefix).

Seeks to Influence Inbound Traffic

MEDs are an attempt by the local AS to influence the routing decisions in the remote AS for traffic inbound to the local AS,
just like the origin attribute. And just like the origin attribute, MEDs are a negative-bias mechanism to make some paths look
worse than others.
Continued on the next page.

Chapter 9–32 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing
Primitive Load Balancing
You can use MED values to perform some form of primitive load balancing between ASs with multiple links between them.
However, the use of MEDs for load balancing is neither efficient nor particularly effective, compared to more sophisticated
mechanisms available.

Usually Taken from IGP Metric

You can set MED values from multiple locations, including administrator configuration or IGP metrics. However, it is very
common to take MED values from the metric values in the IGP.

Effects Not Guaranteed

Despite the best efforts on the part of a local AS to manipulate MED values to influence inbound traffic flows to the local AS,
other ASs can always preempt, or even ignore, the MED. This reaction is not only because the MED is an optional BGP
attribute, but also because several other BGP attributes are more important than MED in the BGP route selection process.
For example, an altered local-preference attribute always overrides the MED.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–33

Advanced Junos Service Provider Routing

Simple MED Use

The slide shows a very basic example in the use of the BGP MED attribute to influence inter-AS traffic flows.
AS 1 assigned its IP address spaces so that it can summarize its network into two major segments. Furthermore, AS 1 is
relatively cleanly divided into networks near the left most router (10.10.0.0/16 networks are nearby) and networks near the
right most router (10.20.0.0/16 networks are nearby). Perhaps the split is between Eastern and Western operations, but
there are many other alternatives.
AS 1 has two EBGP sessions to the customer Acme and advertises both the 10.10.0.0/16 and the 10.20.0.0/16 networks to
Acme on each EBGP session, as shown on the slide.
Naturally, AS 1 would like Acme to return traffic to the closest point in the network so that timely packet delivery and low
latency can be achieved. Ordinarily, AS 1 would have no real way to convey this desire to Acme, and Acme would simply send
traffic to AS 1 over whichever router Acme decides to use based on its own routing policies.
However, the MED attribute offers a method for AS 1 to influence the routing policy on Acme for traffic sent to AS 1. To
accomplish this closest point goal, AS 1 alters the MED values on the routes that it advertises to Acme with a BGP export
routing policy.
Both of the networks in AS 1 are advertised across both links for redundancy. All things being equal, the routers in Acme still
see multiple network paths to the routes in AS 1 as the AS 1 routes are passed along throughout Acme. The Acme routers,
however, use the MED values of 10 and 20 (10 being preferred) to choose the BGP path to install in their local routing tables.
Thus, within Acme, traffic to 10.10.0.0/16 networks flows to the left most router and out to AS 1, while traffic to 10.20.0.0/
16 networks flows to the right-most router and out to AS 1. AS 1 influenced Acme, and, at the same time, achieved a
primitive type of load balancing.

Chapter 9–34 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Sophisticated MED Use

The use of the MED attribute is straightforward when adjacent pairs of ASs are considered. The use of the MED attribute
becomes a little more complicated when more than one AS is involved.
Consider the AS networks on the slide. Both AS 2 and AS 3 advertise the 192.168.13.0/24 route to AS 1 and want to
influence the way AS 1 sends traffic to 192.168.13.0/24. All three of the advertisements have identical local-preference
values, AS-path lengths, and BGP origin codes. The other IP addresses on the slide represent the router IDs of the three
routers in R1, R3, and R4.
The MED value from the AS 2 router is the lowest among the three advertisements. Yet, when the router in AS 1 chooses the
BGP path to use in its local routing table, the AS 1 router most likely chooses R1 in AS 3. Why should this be?
The problem in this scenario is that the default evaluation of the MED attribute only happens when route advertisements
come from the same neighboring AS. In this scenario, only two of the three advertisements come from the same AS: those
from R3 and R1. Between those two advertisements, the route from R1 is the best, because of its lower MED value.
The route from R4 in AS 2 cannot be compared to the two routes from AS 3 because it is from a different AS. At this point, AS
1 is left with the R1 and the R4 routes. The R1 route will most likely be selected as the active path because this router has a
lower router ID than R4.
However, the routers in AS 1 can compare the MED values for all three of these routes with the use of the
always-compare-med configuration statement. With this configuration, the path to 192.168.13.0/24 through R4 should
be chosen, based on the lowest MED value.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–35

Advanced Junos Service Provider Routing

Always Compare MEDs

By default, only the MED values from the same neighboring AS are compared to select a BGP path. However, the
always-compare-med configuration statement allows you to override the default BGP behavior for MED evaluation.
When configured, all routes that have the shortest AS-path length are compared to each other to determine the route with
the smallest MED value, not just routes from the same AS. The route with the lowest MED value is then selected as the active
BGP path, regardless of the AS the route came from. The lowest MED value is selected as long as other path selection values
for the route, such as local preference, are the same.
You must be cautious when comparing MED values from different ASs. Some inherent danger exists when using the
always-compare-med configuration option to compare MED values from more than one AS because every AS in the
Internet can set its own good and bad values for MEDs.
One AS might consider a MED of 50 as the best, while another AS might consider a MED of 5 to be good. To complicate
matters further, some AS networks might not set the MED value at all (MEDs are optional), which essentially sets the MED
value to 0.

Chapter 9–36 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

MED Is Metric Applied to BGP

The Junos routing policy framework can use the BGP MED attribute as both a match condition and as an action. The metric
statement applied to BGP indicates the MED value. That is, a policy can match on a certain MED value or set the MED value
to a certain value as an action.

Value Can Be Manipulated Mathematically

Moreover, you can set the MED value not only to a specific value, but you can manipulate it mathematically (add 100 to MED
or subtract 50 from MED).
The example on the slide shows the MED attribute modified for certain routes. As mentioned, the metric statement
represents the MED value. Within a policy, you can set the metric to a value, you can add to its current value, or you can
subtract from its current value.
The policy shown:
• Sets the MED to 50 for the 172.31.25.0/24 route;
• Increases the current MED value by 50 for all routes within the 192.168.32.0/20 network; and
• Decreases the current MED value by 50 for all routes within the 10.124.0.0/16 network with a mask shorter
than /24. Should the current value be less than 50, the result of this policy action will be a MED value of 0.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–37

Advanced Junos Service Provider Routing

Setting the MED Directly

The MED value can be set directly using the metric-out statement at the group or neighbor level of [edit protocols
bgp]. The following options are available:
• Set to a specific value;
• Set to the current IGP metric;
• Set to the minimum IGP metric ever learned;
• Can add or subtract from the IGP metric; and
• Can use the statement within a routing policy.

Chapter 9–38 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

MED and IGP Metrics

MED values do not have to be arbitrary. In many cases, the MED values are coordinated with the metric values used by an
IGP. Thus, BGP can set the MED value on routes advertised based on the IGP metric leading to the BGP peer from which the
route was received.

Use of Metric in a Policy

You can set the MED value to match the internal IGP metric to reach the IBGP peer that advertised the route. Use the
metric igp command to do this. As the IGP metric to this peer changes, the MED value associated with these routes also
changes. You can see this within the term possible-igp-setting in the policy on the slide.
The MED value changes every time the IGP metric to the peer changes. If this is undesirable, you can associate the MED to
the lowest possible IGP metric ever known for the specific IBGP peer. The MED might decrease if the IGP metric lowers, but a
network failure that increases the IGP cost does not increase the MED value—the metric minimum-igp command alters
this value. You can see this setting within the term possible-minimum-igp-setting in the policy on the slide.
Lastly, you can use the addition and subtraction functions used with the add or subtract policy functions of the metric
command in conjunction with both the igp and minimum-igp options. To alter the MED this way, use the metric igp
offset or metric minimum-igp offset command. You can both add to and subtract from the metric.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–39

Advanced Junos Service Provider Routing

Aggregates Lose MED Information

MED values have, by default, a limited scope of operation. For example, by default, MED values are not propagated through
one AS and on to another AS (nontransitive). This limiting concept also applies when route aggregation is examined.
When a new aggregate route is created, any MED values currently assigned to any contributing route remain only with those
routes. The aggregate route has no MED value assigned to it, which is a MED value of 0. While at first this might seem to be
a contradiction, because 0 is a MED, the aggregate route has no method for determining which one MED value to choose, so
a MED value of 0 is used.
No alternative really exists. Because a BGP route can have only one MED value, the aggregate must choose what that value
should be. Should the aggregate take the worst MED value from the contributors and be conservative? Should the aggregate
take the best MED value to not penalize that contributing route? Should the aggregate average the contributors MED values
together? None of these would adequately represent all the contributing information, so the aggregate route takes the
ultimate conservative approach: MED equals 0, or no MED at all.

Chapter 9–40 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Default Aggregate MED Behavior

The slide shows the default MED behavior regarding aggregate routes. The router receives the 192.168.17.0/24 route with a
MED of 10. You see this from the output of the show route protocol bgp command, as shown on the slide.
The router has a locally defined aggregate route, which a policy injects into BGP (the policy is not shown on the slide).
By examining the show route advertising-protocol bgp output, you can see that both the aggregate route and
the more specific, received BGP route are advertised. The 192.168.17.0/24 route maintains its MED of 10, and the
aggregate route of 192.168.16.0/20 has no MED value (MED=0) assigned. Of course, you can always change the MED value
on the aggregate with a routing policy, but this lack of an aggregate MED value is the default behavior.
Thus, it is ironic that MEDs, which are most useful between AS pairs, are useless by default on aggregates, which are exactly
the types of routes you want to send between AS pairs!

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–41

Advanced Junos Service Provider Routing

AS Path
The slide highlights the topic we discuss next.

Chapter 9–42 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

The AS-Path Attribute

The AS-path attribute describes the path of autonomous systems that the route has been through since it was sourced into
BGP. When a BGP router receives routes in an update message, the first action is to examine the current AS path to see if the
local AS number (ASN) is in the path. If it is in the path, it indicates that the route has been through the AS already; accepting
the route would cause a loop. Therefore, BGP drops the route. The Junos OS performs a verification to ensure that the
receiving router’s AS number is not listed in the AS path. If the receiving router’s AS number is listed in the AS path, the
router does not advertise the route.
By default, the AS-path value is changed as a route transitions between autonomous systems. The AS-path value is null until
the associated route is advertised out of the originating AS. As the route leaves an AS, the BGP router adds the local AS
number to the front of the path before sending it to a peer. Using routing policy, you can prepend your ASN information to the
AS-path attribute. By prepending your ASN information to the AS-path multiple times, you can affect the routing decision
made by routers in other autonomous systems and discourage those routes from using that path because of the longer
AS-path.
The AS-path attribute is mandatory; thus, it must always be present for all BGP routes.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–43

Advanced Junos Service Provider Routing

16-bit Autonomous System Numbers

AS numbers are assigned in blocks by the Internet Assigned Numbers Authority (IANA) to Regional Internet Registries (RIRs).
The RIR then assigns AS numbers to entities within its designated area.
RFC 1930 defined 65536 ASNs using 16-bit integers. The ASNs 0, 56320–64511, and 65535 are reserved by the IANA and
should not be used in any routing environment. IANA designated AS numbers 64512 through 65534 to be used for private
networks.

32-bit Autonomous System Numbers

RFC 4893 defines 32-bit ASNs. These numbers are written either as simple integers, or in the form x.y, where x and y are
16-bit numbers. Numbers of the form 0.y are exactly the old 16-bit AS numbers, 1.y numbers and 65535.65535 are
reserved, and the remainder of the space is available for allocation.

Chapter 9–44 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Manipulating the AS Path

If the AS-path attribute is changed before the route is readvertised to other BGP routers, a route through the local AS can
look less attractive to another AS. Note that making the route more attractive by shortening the AS path should not really be
possible. However, you can lengthen the path to make the AS-path attribute another type of negative-bias path selection
mechanism. In other words, unlengthened paths look more attractive for other AS networks to use than artificially
lengthened AS paths.

AS-Path Prepending
The only standard approach to alter the AS-path attribute is to add information to it by prepending. You can use a routing
policy to extend (by prepending) AS-path information artificially onto an existing AS path. This type of a policy is often an
attempt to influence traffic coming into an AS from another AS.
Continued on the next page.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–45

Advanced Junos Service Provider Routing
AS-Path Prepending (contd.)
On the slide, AS 1 announces its routes to both AS 2 and AS 3. Using a routing policy, AS 1 prepends its own AS number four
times (shown as 1 1 1 1 1 on the slide) onto all route announcements to AS 2. This action causes the following:
• AS 2 will use AS 20 to forward packets to AS 1;
• AS 10 will use AS 3 to forward packets to AS 1;
• AS 20 will use AS 10 to forward packets to AS 1;
• AS 30 will use AS 40 to forward packets to AS 1; and
• AS 40 will use AS 10 to forward packets to AS 1.
Note that this behavior on the part of AS 2 (using AS 20 instead of sending directly to AS 1) is unexpected and would not
occur without the routing policy. This behavior is extended to AS 20 as well, because AS 2 cannot shorten the AS path
advertised by AS 1, even if AS 2 would like to shorten it.

Chapter 9–46 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Policy to Prepend AS Path

The slide shows the routing policy AS 1 used in the previous example.
A policy named longer-as-path was created on the AS 1 router. Because no from statement exists, all candidate routes
match the policy. The action taken on all of the matched routes is to add AS 1 to each route four times. You can use either
the as-path-prepend as-number or the as-path-expand last-as count number policy options to add AS
numbers to the AS-path attribute in an attempt to make a given route appear less desirable. The latter option automatically
locates the most recent AS in the path (the last entry) and prepends it the specified number of times prior to advertising the
route to EBGP peers. This particular action is performed with the as-path-prepend statement. This routing policy then is
applied for routes exported by BGP to the external BGP peer in AS 2.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–47

Advanced Junos Service Provider Routing

The Symbol Tells All

A symbol can provide information on an object. For example, when looking at the AS path on a Juniper Networks router:
• Brackets ([ ]): Enclose the local AS number associated with the AS path if more than one AS number is
configured on the router or if the AS number is being prepended.
• Braces ({ }): Enclose AS sets—groups of AS numbers in which the order does not matter. A set commonly results
from route aggregation. The numbers in each AS set are displayed in ascending order.
• Parentheses ( ( ) ): Enclose a confederation.
• Brackets inside parentheses ( ( [ ] ) ): Enclose a confederation set.
In the output on the slide, you can see four routes with different AS paths. The second route represents a bracket output, the
third route represents an AS set, and the fourth route represents a confederation.

Chapter 9–48 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Regular Expressions
Often, administrative BGP routing policies require that route announcements or prefixes be found and acted on based on the
information contained within the AS-path attribute. This requirement might be to enforce some administrative policy
regarding other AS networks. Sometimes, it is just easier to find routes based on their AS path than by looking for many
specific prefixes and routes individually.

Other Uses
The slide lists some examples of the types of information that must be found in the AS path.

Regular Expressions Can Find Prefixes

Through the use of regular expressions, you can quite easily find this type of information in the AS-path attribute.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–49

Advanced Junos Service Provider Routing

Regular Expressions for Pattern Matching

A regular expression (often called regex) is a powerful, pattern-matching tool you can apply in a routing policy to act on
AS-path strings. This pattern-matching engine can find specific strings of text or textual patterns.

Different from Wildcards

When used in a routing policy, regular expressions work not only on fixed strings, like wildcard operators such as an asterisk
(*), but also on variable patterns of text, through the combination of basic text patterns and special operators.

Text Plus Operators

Regular expressions are made up of a combination of basic text patterns and special operators.

Context-Sensitive Matching
Regular expressions allow information in a string to be found within a specific context, not just in isolated instances. You can
use regular expressions in conjunction with the BGP AS-path attribute to match routes within a policy.

Chapter 9–50 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Configure a Regular Expression

Regular expressions have two main components to them—the term and the operator. These expressions take the form term
operator.

Terms Are AS Numbers in the AS-Path Attribute

The regular expression term is the core matching component to be found by the pattern-matching engine. The term is a
mandatory object, and each regular expression must have at least one term. Terms identify the AS number. This AS could be
a single number (1024), a complete AS path
(1024 2685 3957), or a wildcard character (.) representing any single AS number (1024 . 3957).

Each AS Is an Entity
Within the Junos AS-path regular expression syntax, the term is a complete AS value. You can use the wildcard character of
the dot ( . ) to represent a single AS number as well. Thus, the Junos OS detects an AS number of 1024 (for example) not as
the four character text string of 1, 0, 2, 4, but as the single entity of 1024. To the Junos OS, AS numbers are not sequences
of characters.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–51

Advanced Junos Service Provider Routing

Regular Expression Operators

All regular expressions take the form term operator. Use of the term is mandatory.

The Operator Is Optional

However, the regular expression operator is an optional component of the pattern-matching engine. You can associate an
operator with a single, regular expression term. If used, the operator appears immediately after the term on which it is
operating.
Two special regular expression operators can appear between regular expression terms. These special characters are the
pipe ( | ) and the dash ( - ). You use the pipe ( | ) operator between terms to indicate OR (1024 OR 2685 is 1024 | 2685).
You use the dash ( - ) operator between terms to indicate range (1024 through 2685 is 1024-2685).

More Than One

An individual regular expression can contain multiple term-operator pairs.

Chapter 9–52 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Regex Operators for the AS Path

The table on the slide shows a subset of the possible regular expression operators you can use with routing policies. Some
operators are a shorthand for their longer equivalents.
Of special note is the use of the parentheses. Typically, you use the parentheses ( ) operator to group multiple terms
together in conjunction with an operator. For example, the regular expression (1|2)? is translated as either AS 1 or AS 2 can
be present in the AS path zero times (absent), or at most one time (this is what the ? operator means).
The parentheses operator also has another special use. When used with no spaces in between, parentheses represent a
null AS-path value. We cover the concept of the null AS path on future slides.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–53

Advanced Junos Service Provider Routing

AS-Path Regex Examples

The table on the slide shows some examples of regular expression pattern matching as applied to AS paths.
The first column shows the AS-path string that the routing policy is trying to match. The second column shows the regular
expression used to match that pattern. The last column shows examples of values of the BGP AS-path attribute that the
regular expression will match. In some cases, the list is not exhaustive, so more AS paths will match the pattern.

Chapter 9–54 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

More AS-Path Regex Examples

The table on the slide shows more examples of regular expression pattern matching as applied to AS paths.
As before, the first column shows the AS-path string that the routing policy tries to match. The second column shows the
regular expression used to match that pattern. The last column shows examples of values of the BGP AS-path attribute that
the regular expression will match. In some cases, the list is not exhaustive, so more AS paths will match the pattern.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–55

Advanced Junos Service Provider Routing

Regular Expressions and Policies

You can use AS-path regular expressions as the match criteria within a routing policy. This application of the regular
expression is similar in concept to the application of a policy. As such, AS-path regular expressions follow the Junos
abstraction concept of first defining the entity and then applying the entity.

Format
Both the definition and application of the AS-path regular expressions occurs within the policy-options configuration
hierarchy. The regular expression in proper term operator format is given a name with the as-path statement.

AS-Path Name
You can reference the regular expression name within a policy.

Spaces Are Allowed

The name can be up to 255 characters long and can even include spaces, as long as the name is enclosed in double
quotation marks. In practice, however, this practice is not common.

Applied After Definition

Once defined, you can apply the AS-path regular expression as a policy match condition.

Chapter 9–56 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

AS-Path Regex Policy Example

The example on the slide shows an AS-path regular expression used as a policy match condition. The goal is to have a BGP
routing policy that accepts only routes with the exact AS path of
1234 56 78 9.
We defined an AS path named digits-route within the double quotation marks. The AS path contains only terms (no
operators) and defines an exact AS-path match of “1234 56 78 9”.
We then used the digits-route path definition within the from-digits-route policy to match routes and accept them. A
second term in the policy rejects all other routes.
When you apply this policy as an import BGP policy, only routes matching the AS path defined in digits-route are
accepted. All other routes seen by BGP are rejected.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–57

Advanced Junos Service Provider Routing

Another AS-Path Regex Policy Example

The example on the slide shows another AS-path regular expression used as a policy match condition. This time, however,
the AS path uses both terms and operators.
The goal this time is to reject routes that either originate in ASs 123–125, transited through ASs 123–125, or were
advertised directly from ASs 123–125.
To do this, we defined an AS path named not-a-good-route. The AS path contains both terms and operators. Thus,
not-a-good-route defines an AS-path match as follows:
• The AS path starts off with any AS value zero or more times, followed by…
• Any AS value between 123 and 125, followed by…
• Any AS value zero or more times.
The not-a-good-route path definition is then used within the from-not-a-good-route policy to match routes and
reject them.
When you apply this policy as an import BGP policy, only routes matching an AS path defined in not-a-good-route are
rejected.

Chapter 9–58 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Given a Policy
Consider the routing policy shown on the slide.

Look at the Results

Does this policy, when properly applied, accept a route with the path 1024 44 44 2685, given the as-path statements
listed on the slide?
Using the different as-path definitions within the testing-as-paths policy gives the following results:
• “.* 1024”: Starts with any AS zero or more times, followed by 1024. The route will not match the term
as-paths. This definition does not allow for AS numbers after 1024. Therefore, it is rejected by the final
action.
• “1024 .*”: Starts with 1024, followed by zero or more AS numbers. The route does match the term
as-paths. It is accepted.
• “.* 1024 .*”: Starts with any AS zero or more times, followed by 1024, followed by zero or more AS
numbers. The route does match the term as-paths. It is accepted.
Continued on the next page.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–59

Advanced Junos Service Provider Routing
Look at the Results (contd.)
• “.* 44{1,2} .*”: Starts with any AS zero or more times, followed by 44 once or twice, followed by zero or
more AS numbers. The route does match the term as-paths. It is accepted.
• “2685 44{1,3} 1024”: Start with AS 2685, followed by 44 one to three times, followed by 1024. The route
does not match the term as-paths. Therefore, it is rejected by the final action.
• “1024 44{1,3} 2685”: Start with AS 1024, followed by 44 one to three times, followed by 2685. The route
does match the term as-paths. It is accepted.

Chapter 9–60 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

AS Path Regular Expression Enhancements

The AS-path regular expression examples shown thus far are perfectly workable. However, circumstances occur where
support for as-path-groups can save you some configuration work and possible mental anguish. AS-path groups allow
you to define a list of individual AS-path regular expressions for evaluation as a logical OR within a policy. The example on the
slide shows an AS-path group named as-group-1, which comprises three individual AS-path regular expressions. The
as-group-1 AS-path group is referenced in the test-as-group policy using a single \ statement. You can specify
multiple AS-path groups as part of a single from statement if needed.
Achieving the same result without the as-path-group feature requires that you define three separate AS-path regular
expressions that are evaluated as a logical OR:
[edit policy-options]
user@router# show
policy-statement not-ideal {
from as-path [ path_1 path_2 path_3 ];
}
as-path path_1 ".* 1 .*";
as-path path_2 ".* 2 .*";
as-path path_3 ".* 3 .*";
Continued on the next page.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–61

Advanced Junos Service Provider Routing
AS Path Regular Expression Enhancements (contd.)
Or, achieving the same result without the as-path-group feature requires that you define a single, and possibly quite
long, AS-path regular expression:
[edit policy-options]
user@router# show
policy-statement not-ideal-either {
from as-path customers;
}
as-path customers ".* 1 .*|.* 2 .*|.* 3 .*";
Using the as-path-group feature alleviates both of these issues. The example on the slide is functionally identical to both
of the alternatives shown here.

Chapter 9–62 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Role of Null AS Path

The concept of the null AS path is quite important for the Internet. Routes originating within a particular AS have yet to
prepend the BGP AS-path attribute. Therefore, no information is contained in the AS-path attribute for routes originating
within the AS, and the AS path is assumed to be null (empty).
So, how are routes originating within the AS that were advertised with BGP to be found with a routing policy using an AS-path
policy? They are found by creating a match condition based on the null AS path.

Defining the Null AS Path

To specify the null AS path using a regular expression, use the parentheses with no space in between them.
In the example on the slide, the router receives four routes from IBGP. By examining the routing table, you can see that the
AS path column is empty (I is for the origin code). Therefore, these routes were sourced within the router’s own AS. The null
AS path finds these routes.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–63

Advanced Junos Service Provider Routing

Finding Local Routes

You can use the null AS path to find routes advertised by BGP that originated within the local AS path. When would this be
helpful? Usually, when one AS path does not want to carry transit traffic for another AS path.
In the example on the slide, the null AS path is used to halt BGP transit traffic from AS 1 through AS 2. AS 2 does not want to
readvertise the routes from AS 1 to AS 4, which could lead to AS 4 routing traffic for AS 1 through AS 2. However, AS 2 still
must advertise its own routes to AS 4 so that these prefixes are reachable. AS 2 defines an as-path applied as a BGP
export policy towards AS 4 that rejects all routes except those with a null AS path.

Chapter 9–64 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Use of Null AS Path: Part 1

The slide shows an example of null AS path in action.
We applied the not-a-transit policy on the slide as an export policy on R2 towards the EBGP peer on the right side of
the diagram. The policy has a term called accept-my-as that matches BGP routes with an as-path regular expression of
(). The reject-all-else term rejects all other routes.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–65

Advanced Junos Service Provider Routing

Use of Null AS Path: Part 2

The slide shows the results of the previously configured and applied policy.
The show route protocol bgp output shows that the router R2 receives five BGP routes from its IBGP peer R1. One of
these routes is from AS 1, and the other four are sourced from within the AS.
The show route advertising-protocol bgp output shows that only the four routes sourced from within the AS are
sent to the EBGP peer. The null AS-path regular expression in the routing policy rejects transit routes.

Chapter 9–66 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

We Discussed:
• Various BGP attributes in detail and explained the operation of those attributes; and
• How to manipulate BGP attributes using routing policy.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–67

Advanced Junos Service Provider Routing

Review Questions
1.

2.

3.

4.

Chapter 9–68 • BGP Attributes and Policy—Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

BGP Attributes: Next-Hop, Origin, MED, and AS Path Lab

This slide provides the objectives for this lab.

www.juniper.net BGP Attributes and Policy—Part 1 • Chapter 9–69

Advanced Junos Service Provider Routing
Answers to Review Questions
1.
An import policy operates between the RIB-IN and the RIB-LOCAL. An export policy operates between the RIB-LOCAL and the
RIB-OUT.
2.
The Junos OS sees all possible routes to be injected into BGP as internal routes and sets the origin code as I=Internal.
3.
Different ASs can set the MED values differently. A good MED value from one AS may be a bad value from another AS.
4.
The purpose of prepending the AS PATH is to make the route advertisement look undesirable.

Chapter 9–70 • BGP Attributes and Policy—Part 1 www.juniper.net

Advanced Junos Service Provider Routing

Chapter 10: BGP Attributes and Policy—Part 2

Advanced Junos Service Provider Routing

We Will Discuss:
• The BGP attributes local preference and communities and explains the operation of those attributes; and
• The manipulation of those BGP attributes using routing policy.

Chapter 10–2 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Local Preference
The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–3

Advanced Junos Service Provider Routing

Local-Preference Power
The BGP attribute of local preference is the highest tiebreaker in the BGP path selection process. If a BGP next hop is
reachable, and BGP knows multiple routes, BGP always chooses the route with the highest local preference. Thus, local
preference is the first BGP attribute that favors one path over another.

Highest Local Preference Wins

Because of the position of the BGP local preference, neither the AS-path length, nor the origin code, nor the MED value
matters. The route with the highest local-preference value is always chosen as the exit point of the AS—the end.

Chapter 10–4 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Local-Preference BGP Attribute

Do not confuse the BGP attribute of local preference with the Junos OS concept of route preference. The Junos OS route
preference is local to an individual router and assists the routing table in choosing the active route among many possible
paths.
The BGP local-preference attribute is used only within BGP itself. The BGP routers transmit the local preference within an AS.
If you do not explicitly configure a value for local preference, the default value used on BGP routes is 100. You can change
this value on a per-peer basis using the local-preference command within the [edit protocols bgp]
configuration hierarchy directory. In addition, you can alter the value using a policy on a per-route basis. The policy action
also uses the local-preference command to alter the attribute value.

Default Local Preference = 100, BGP Preference = 170

The default local preference applied to a BGP route is 100. However, the default route preference applied to BGP itself is
170. The Junos preference applies to the entire routing protocol. Preference is also set in the [edit protocols bgp]
configuration hierarchy directory, but as preference, not local-preference (which applies only to BGP).

Pay Attention
When it comes to routing policy configurations, make sure to change local preference on the BGP routes, not the preference
of the BGP protocol as a whole!

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–5

Advanced Junos Service Provider Routing

IBGP Peers Exchange Local Preference

Only IBGP peers exchange the values of the local-preference BGP attribute. EBGP peers never see a local preference set on
route information sent between AS networks.

Sets Exit Point

You typically use the local preference to set the preferred exit point for a particular route from an AS. This use can be
important when several links exist between two ASs.

IBGP Distributes Local-Preference Information

Once the local preference for a route is set, IBGP propagates that information throughout the entire AS.
Continued on the next page.

Chapter 10–6 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing
How to Get to 172.17.2.0/24?
The slide shows the concept of how local preference affects traffic leaving an AS. The administrators of the AS on the left
know that Router B should always be used to reach the 172.17.2.0/24 network in the AS on the right. Therefore, the
administrators of the AS on the left can configure their edge routers to set the local-preference value higher on the copy of
the route received on Router B than the copy received on Router A. IBGP makes sure that every router in the AS knows that
the preferred exit point for this route is Router B. Note that the AS on the right neither knows nor cares about the value of the
local preference assigned to the route by Router A or Router B.
The AS on the left still has failover capability because it receives the route from the AS on the right through both routers.
Although Router B is the primary exit point for the route, user traffic can use Router A to reach the AS on the right in the event
of a failure.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–7

Advanced Junos Service Provider Routing

Example of Local-Preference Use

The slide shows an example of local-preference use within an AS.
The network administrators in ISP A decided that the routers in ISP A should use R2 to reach the 192.168.27.0/24 network
in ISP C. This decision is because of the greater bandwidth capacity available on that 10 Gigabit Ethernet link.
To perform this router assignment, the ISP A network administrators set the local preference to 200 on the route to
192.168.27.0/24 advertised to R1 by ISP B, and set the local preference to 300 on the route to 192.168.27.0/24 advertised
to R2 by ISP D.
In contrast to almost every other metric associated with routing protocols, the highest local preference is better. Thus, for this
route, the exit point of the AS is through R2. IBGP makes these values known to all other routers in ISP A.
The link on R1 can still be used for inbound traffic flows from ISP C and for outbound failover traffic if the 10 Gigabit Ethernet
link is not useable because of a router or link failure.

Chapter 10–8 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Local AS Only
The slide points out the local nature of local preference. Consider another AS called ISP E linked by two lower-speed, but
equal, links to ISP A. Which link should ISP E use to reach 192.168.27.0/24 in ISP B?
Because EBGP does not propagate the local-preference values used inside ISP A, the ISP E AS has no knowledge of the
local-preference routing decisions made within ISP A with regard to the 192.168.27.0/24 route. ISP A, of course, still wants
traffic from ISP E to flow towards R2 to avoid shuttling all this traffic across its backbone.

Another Method Needed

However, ISP A cannot accomplish this goal with local preference. ISP A must use other BGP attributes instead of local
preference, such as AS path or MED, to influence ISP E’s flow of traffic to ISP A. This is because of the strictly local nature of
the local-preference attribute.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–9

Advanced Junos Service Provider Routing

Changing Local Preference with a Policy

In many cases, when it comes to local preference, a routing policy does not consider routes in isolation but considers other
BGP attributes, such as the AS path, to select routes for preferred local handling.
The example on the slide alters the local-preference value for all received routes that match the AS path of
look-for-path. Within the term got-path, we specified an action of local-preference 200. This action changes
the local-preference attribute value for those routes to 200.
This routing policy does not affect any other received BGP routes.

Chapter 10–10 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Local Preference and Routing Loops

The case study on the slide provides an interesting look at the operation of BGP in general, and how BGP uses local
preference specifically.
Considering that the local-preference attribute overrides all other BGP attributes in the path selection process, it might be
possible to create a routing loop in BGP. Routing loops are especially bad because the destination is technically reachable,
but some or even all routers within an AS cannot find the proper path to the destination.
In the example on the slide, both R1 and R2 have an export policy in place that sets the local preference to 1000 on EBGP
routes before these routes are readvertised to IBGP peers. Note that R1 and R2 have an IBGP peering relationship with each
other, which means that both routers also advertise the route to each other.
Theoretically, both R1 and R2 could see the preferred value of 1000 in the copy of the route they receive from each other.
This information makes each router determine that the IBGP version is better than the local (EBGP) copy of the route! This
determination occurs because the local preference on the EBGP version of the route that is stored within the router is still set
to 100. As a result, R1 and R2 see each other as the best route to 172.17.0.0/16, and a routing loop occurs as the two
routers shuttle traffic back and forth.
Note that this situation is easily avoided by setting a route’s local preference at ingress using an import policy. In this case,
the local copy of the route as received from an EBGP peer will correctly reflect the local preference modification.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–11

Advanced Junos Service Provider Routing

Split Horizon for Local Preference

It turns out that BGP is smart in this case. The following chain of events assumes that R2 received the EBGP route of
172.17.0.0/16 first and advertises the route with a local preference of 1000 to its IBGP peers. (If R1 accomplishes this first,
the roles are easily reversed, but the point is the same.)
First, R2 receives the EBGP route of 172.17.0.0/16 from its peer in the other AS. Because R2 detects this route as the
current best, R2 installs the route in its routing table.
Next, R2 alters the local preference to 1000 and advertises this route to its IBGP peers with this local-preference value. At
this point, both R1 and R3 receive the 172.17.0.0/16 route through IBGP.
R1 then also receives the EBGP route for 172.17.0.0/16 from the other AS. At this point, R1 determines that it already has a
route to 172.17.0.0/16 from R2, with a local preference of 1000. The presence of this route to R2 overrides the
EBGP-received route.
Because the current version of the route on R1 is from R2, and because IBGP implements split horizon, the routing loop
never forms. R1 just sends traffic for 172.17.0.0/16 to R2. And because only active BGP routes are advertised, no confusion
develops on R3 with regard to the best path to reach 172.17.0.0/16—R2 is the choice.

Chapter 10–12 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Communities
The slide highlights the topic we discuss next.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–13

Advanced Junos Service Provider Routing

Optional, but Transitive

The BGP community attribute is an optional attribute, so not all implementations of BGP must recognize and use
communities. However, if BGP communities are associated with a BGP route, the BGP community attribute must be passed
along to all other BGP peers, both within an AS and between AS networks (transitive).

Routes Having Something in Common

The BGP community attribute is an administrative tag that you can use to associate routes together that share common
properties. The BGP community attribute is not complex. The main role of the BGP community attribute is to make it easy to
group routes that should be treated the same by a routing policy. BGP communities are very flexible: a BGP route can belong
to many BGP communities.

Make Routing Simpler

The attraction of BGP communities is that they can simplify routing policies. BGP communities identify routes based on the
logical boundaries you establish and not what the AS number (too broad in most cases) or individual IP prefix (too granular in
most cases) establishes.

Use with Other BGP Attributes

You can use the community attribute within routing policies to accept or reject routes based on the values of the BGP
community tags. In addition, you can use the community attribute values with other BGP attributes to implement routing
policies that accept, prefer, or advertise BGP routes.

Chapter 10–14 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Clubs for Routes

BGP communities establish various logical categories for routes (prefixes). Think of BGP communities as communities of
interest or even clubs for routes. And just as people can belong to more than one club, routes can fit into more than one BGP
community.

Can Carry Local-Preference Value Beyond Local AS

The BGP community attribute value often implements policies for customer networks, such as altering the local-preference
attribute on incoming routes.

Goal: Less Work

The community attribute can assist you in the configuration and maintenance of policies. This cuts down on the time needed
for manual reconfiguration and the complexity of the overall maintenance task.
Continued on the next page.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–15

Advanced Junos Service Provider Routing
Community Use Example
As an example, consider the addition of a new prefix for a new customer within an AS. If you use communities to enforce
routing for customer networks, and you can place the new prefix into an existing community, you do not need any changes to
overall routing policies. When new customers are brought into the network, you must only assign the new routes the proper
community attribute. Without the use of communities, you might need to update each policy in the network to include the
new customer information.

Too Many Communities

However, you must be careful when establishing communities for the first time. Too many communities defeat the whole
purpose. Maintenance of the communities then becomes as tedious as maintaining a whole list of route filters.

Overlapping Communities
You should also avoid having too many overlapping communities. Customer routes belonging to multiple communities can
also be an issue.
When it comes to communities, simplicity is always a worthwhile goal.

Chapter 10–16 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Well-Known Communities
Certain well-known communities have a global meaning and special purposes. They are defined in RFC 1997. All BGP
implementations that understand communities (communities are optional, but transitive) must know these communities
and respect their functions.

Communities for Local Use

BGP communities that are not well-known are for local use. You must define local-use communities locally, but because the
BGP community attribute follows the BGP route wherever it goes, even local-use communities are circulated outside the AS.
So, you must take care in using BGP community attribute values arriving from other AS networks. BGP communities are best
thought of as a category for a group of routes (such as, all customers).

Community Format
The BGP community attribute itself is just a list of the individual community attribute values associated with the route (tags).
Because no real limit exists on the number of tags in the list, a route can belong to many communities. No predefined, upper
limit exists on the number of communities allowed on a route.
Continued on the next page.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–17

Advanced Junos Service Provider Routing
Community Format (contd.)
The community attribute values themselves are designed so the values can be uniquely assigned in the global Internet. The
BGP community attribute itself is a 32-bit (4-octet) value that has two parts. The two high-order octets (16 bits) form the first
part and are set aside for the AS number of the network that assigned the community to the route in the first place. The two
low-order octets (16 bits) form the second part and are set aside for use by the specific AS networks. Because the AS value
is included in the community, the value is guaranteed to be unique on the whole Internet.
When written in bits or hexadecimal format, community values can look very odd. Thus, communities are usually
represented in decimal form as AS:number. For example, 200:666 is community 666 in AS 200. One restriction on possible
communities values is that the AS values of 0 and 65535 are reserved and cannot be assigned to a route. Therefore, in
combination, this restriction covers values 0x00000000 to 0x0000FFFF (AS 0) and 0xFFFF0000 to 0xFFFFFFFF
(AS 65535).
RFC 4360 provides support for an “extended community attribute”. An extended community attribute consists of eight
octets. The BGP extended communities attribute format has three fields: type:administrator:assigned-number.

Chapter 10–18 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

The Three Well-Known Communities

Three community attribute values are designated as well-known communities. These well-known communities share the
AS value of 65535 (0xFFFFxxxx). The three communities are no-export, no-advertise, and no-export-subconfed, as follows:
• No-export (0xFFFFFF01): This value tells routers to distribute routes with this community tag within the
confederation or AS, but no farther.
• No-advertise (0xFFFFFF02): This value tells routers not to advertise these routes to other BGP peers at all.
(Despite appearances, this BGP community is quite useful.)
• No-export-subconfed (0xFFFFFF03): This value tells routers not to distribute routes with this community tag to
external BGP peers (thus, they are confined to the sub-AS).

No-Export
The no-export community typically makes sure that route aggregation is optimal by suppressing more specific routes. The
no-export-subconfed just extends this aggregate concept to the sub-AS.

No-Advertise
The no-advertise community has a very narrow scope. Routes go to a BGP peer and no farther, usually because peers know
the routes through other means. This community is often used in a LAN-connected router environment or when two BGP
peers have multiple links between them.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–19

Advanced Junos Service Provider Routing

Sample Use of No-Advertise

The slide shows an example of the scope of the no-advertise community. The arrow at the lower right shows a BGP route with
the no-advertise community injected by R1 into an AS with sub-confederations.
The well-known community attribute value of no-advertise is designed such that a route can be sent to a single BGP peer and
be advertised no farther. Routes are restricted to the next-hop router R2.

Chapter 10–20 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Sample Use of No-Export-Subconfed

The slide shows an example of the scope of the no-export-subconfed community. The arrow at the lower right shows a BGP
route with the no-export-subconfed community injected by R1 into an AS with sub-confederations.
The well-known community attribute value of no-export-subconfed is designed such that a route can be sent into a BGP
confederation network and have the information remain with a particular sub-AS. The routing information is advertised no
farther than the sub-AS routers R3 and R4, as shown on the slide.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–21

Advanced Junos Service Provider Routing

Sample Use of No-Export

The slide shows an example of the scope of the no-export community. The arrow at the lower right shows a BGP route with
the no-export community injected by R1 into an AS with sub-confederations.
The well-known community attribute value of no-export is designed such that a route can be sent into a neighboring AS and
have the information remain within that neighboring AS. Normally, BGP communities are transitive and are passed from
each AS to all others, even if the router does not support or use the BGP community option. However, the routing information
with the no-export community tag is not advertised beyond the AS routers R5, R6 and R7, as shown on the slide.

Chapter 10–22 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

No-Export Example
The slide shows a typical use of the BGP no-export community.
AS 1 has multiple BGP sessions to its neighbor, AS 2. AS 1 also uses AS 2 as a transit AS for connectivity to the Internet. AS
1 wants to advertise 172.17.0.0/16 to the Internet because AS 1 owns that entire address space. In addition, AS 1 also
wants to advertise more specific route information (shown as 172.17.0/17 and 172.17.128/17) only to its peer, AS 2.
Advertising the specifics as well as the aggregate to AS 2 would assist AS 2 to route user traffic into AS 1 more efficiently
because load sharing could be used on the more specific routes, as shown on the slide. However, why should the whole
Internet know or care about these specifics?
To assist AS 2 in finding and rejecting the more specific routes, AS 1 assigns the no-export community to the 172.17.0.0/17
and the 172.17.128.0/17 routes. The BGP edge routers in AS 2 that connect to the Internet automatically suppress and do
not readvertise the /17 routes. Only the /16 route is readvertised to the Internet.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–23

Advanced Junos Service Provider Routing

No-Export and Multihoming

The BGP well-known community no-export is also useful when a customer is multihomed to two ISPs. In the example on the
slide, the customer wants to receive Internet traffic through one main ISP but be able to receive locally originating traffic
from the other ISP (perhaps a major trading partner uses AS 2 as its ISP).
One way to do this (among other ways) is with the BGP no-export community. In this example, the customer has AS 1 as its
main ISP.
Customer AS 20 has address space 172.17.144.0/20, taken from AS 1’s address space of 172.16.0.0/16. The
172.17.144.0/20 route is advertised with BGP to both AS 1 and AS 2. Because AS 2 is not the primary ISP, and only traffic
originating in AS 2 should reach AS 20 directly, the route advertised to AS 2 is given the BGP no-export community. This route
goes no farther than AS 2. AS 2 advertises 172.31.0.0/16 to AS 1 and the Internet, but does not advertise 172.17.144.0/20.
AS 1 covers the 172.17.144/20 address space with aggregate 172.17.0.0/16, as shown on the slide. This is advertised to AS
2 and the Internet. Thus, AS 20 is reachable through AS 1 from the Internet, but AS 20 is only reachable by local AS 2 users.
A drawback of this scenario is that if the link from AS 20 to AS 1 fails, the 172.17.144.0/20 route is not reachable from the
Internet through AS 2. However, because AS 2 is not the primary ISP for AS 20, this might be acceptable.

Chapter 10–24 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Transit AS for Backup

One of the most common uses of the BGP community attribute addresses one major limitation of the BGP local-preference
attribute. Local preference is only distributed within an AS, and no local-preference information is ever sent between two AS
networks. Yet, local preference is a valuable way to establish proper exit points for a route within an AS, especially when the
AS has multiple links. How can another AS be informed of the local preferences of a route learned from another AS? The
most popular way to do this is with BGP communities.
In the example on the slide, the customer AS at the bottom agreed to provide backup transit service to both AS 1 and AS 2 in
case their links to each other are lost. The slide shows the address spaces used. The customer AS uses 172.17.64.0/18 and
172.20.128.0/18.
The customer wants to make the 172.20.0.0/16 route sent to AS 1 to have a lower local preference than the default of 100,
and to make the 172.17.0.0/16 route sent to AS 2 to have a lower local preference than the default of 100 there as well.
Continued on the next page.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–25

Advanced Junos Service Provider Routing
Transit AS for Backup (contd.)
The key to making this work is with the BGP communities on routes sent to AS 1 and AS 2. Route 172.20.0.0/16 sent to AS
1 is tagged as community 1:60. This says to AS 1, “AS 1, within your AS, this route should have a local preference of 60.” The
route 172.17.0.0/16 sent to AS 2 is tagged as community 2:70. This says to AS 2, “AS 2, within your AS, this route should
have a local preference of 70.” In this example, AS 1 and AS 2 only advertise aggregate routes to each other and the
Internet.
If AS 1 and AS 2 set the local preferences on these routes as requested, the exit points through the customer’s AS are only
active when there is no normal peering route available (local preference = 100).

Enforcing Communities
Of course, setting local preferences in other AS networks with communities requires all the AS administrators to cooperate.
Nothing makes an AS respect the community attribute value.

Chapter 10–26 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Policies and Transit AS

The BGP community attribute plays a key role in defining whether an AS is a transit or nontransit network. A transit AS carries
traffic that neither originates in that AS nor is destined for hosts within the AS. A nontransit AS only carries traffic that has its
own addresses appearing as either the source or the destination. Nontransit AS networks must be careful when advertising
BGP routes outside the AS. A nontransit AS can advertise only local routes.

Communities Can Hold Back Routes

You can use routing policies in combination with BGP communities to make an AS appear to be a transit AS or a nontransit
AS. Communities make it much easier to hold back routes that might be advertised and attract transit traffic.
Generally, a small ISP must advertise its own local routes but never be a transit AS for larger ISPs. Such a situation could
easily swamp the operation of a small ISP.
The slide shows a small ISP linked to two larger, national ISPs: National ISP #1 and National ISP #2. As an example of what
could happen, consider that National ISP #1 advertises BGP routes to R1 of the small ISP as shown on the left. R1
advertises not only its own local routes to R2 in the small ISP, but also National ISP #1’s routes, so that all users can reach
these routes.
But R2 should never, ever advertise National ISP #1’s routes to National ISP #2! R1’s and R2’s local routes are okay to send
to National ISP #2. However, if R2 ever advertises the National ISP #1 routes to National ISP #2, and the link (or links)
between the two national ISPs ever fail, National ISP #2 will think that a good way to reach National ISP #1 is through the
small ISP! Hence, the small ISP is now a transit network.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–27

Advanced Junos Service Provider Routing

Configuring Communities
You configure BGP communities in the Junos OS at the [edit policy-options] CLI hierarchy level. You simply give the
community a name and a number of members in the form of the community ID. When you define multiple community
members, a logical AND is between them. Thus, a given name represents Community1, AND Community2, AND
Community3, and so on.

Community ID Format
The community ID has an as-number:community-value format, with a colon (:) separating the high-order and
low-order octets. You can use the keywords no-export, no-advertise, and no-export-subconfed to specify the
well-known community values.

Can Use in Policy

When used in a routing policy, you can use the community name as a match condition (that is, find these BGP communities)
or as an action. Actions applied to communities include the adding, deleting, or setting of community attribute values.

Chapter 10–28 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Add to the Community String

The slide shows the definition and application of a community in a routing policy. This policy leaves the existing community
tags on the route in place but also adds the specified community attribute value to the route.
Route 192.168.0.0/24 currently has four community tags on the route: 64512:567, 100:20, 50:70, and 1234:66.
Because the policy community-actions has no from statement, all routes are matched. It is not necessary to check for
just the BGP routes because only BGP has a community attribute to change. (Including a from protocol bgp statement
does not change the action of the routing policy.)
All BGP routes have the community tag test-comm value of 65001:1234 added to the existing community tags on the
route. The action of then community add test-comm performs this test.
After you correctly apply this routing policy, the 192.168.0.0/24 route has five community tags on the route: 64512:567,
100:20, 50:70, 1234:66, and the added 65001:1234.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–29

Advanced Junos Service Provider Routing

Delete from the Community String

This slide also shows a policy that defines and applies a community in a routing policy. This policy removes only the specified
values of the existing community tags and leaves other existing community tags in place.
Route 192.168.0.0/24 currently has the same four community tags on the route: 64512:567, 100:20, 50:70, and 1234:66.
Because the policy community-actions has no from statement, all routes are matched.
All BGP routes have the community tag test-comm value of 64512:567 deleted from the existing community tags on the
route. The action of then community delete test-comm performs this task.
After you correctly apply this routing policy, the 192.168.0.0/24 route has only three community tags on the route: 100:20,
50:70, and 1234:66.

Chapter 10–30 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Set the Community String

The slide also shows a policy that defines and applies a community in a routing policy. This policy removes all the values of
the existing community tags and adds (that is, sets) the new community tag (or tags) in place.
Route 192.168.0.0/24 currently has the same four community tags on the route: 64512:567, 100:20, 50:70, and 1234:66.
Because the policy community-actions has no from statement, all routes are matched.
All BGP routes have the community tag test-comm value of 65001:1234 set as the existing community tag on the route.
The action of then community set test-comm performs this task.
After you correctly apply this routing policy, the 192.168.0.0/24 route has only one community tag on the route:
65001:1234.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–31

Advanced Junos Service Provider Routing

First Example Using Community

The slide shows a realistic application of the BGP community attribute. The goal is to create a community named
customers. We define the community as having two members: 56:2379 AND 23:46944.
When we use this community in a routing policy to find (that is, match) routes, the community matches routes that have both
56:2379 AND 23:46944 as a community tag value.
Once found, these routes are assigned a MED value (the BGP metric) of 20 and a local-preference value of 200 (instead of
the default 100).

Chapter 10–32 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Second Example Using Community

The slide shows another realistic example of a BGP community. The goal is to define and attach a community named
my-accept to routes that are accepted by the policy. In this example, the policy drops routes that are too specific, based
upon the prefix’s address class, while tagging all other routes with the community value of 567:1.
The drop-specifics routing policy accepts the desired routes using a series of route filters that are based upon address
classes (A, B, and C) and the allowed prefix length. The community add statement attaches the 567:1 community to any
existing communities on routes that match the route filters.
The final reject action serves to reject all routes that are not matched by the previous route filters. It bears stressing that
this reject statement is part of a unnamed term with no match criteria. Operators often forget that the final term in a
policy can be unnamed, and it is easy to mistake the reject action in this example as belonging to the drop-specifics
term if you do not take careful analysis.
Continued on the next page.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–33

Advanced Junos Service Provider Routing
Second Example Using Community (contd.)
An equally workable approach that makes use of a single unnamed term is shown here:
[edit policy-options policy-statement drop-specifics]
user@router# show
from {
route-filter 0.0.0.0/1 upto /19 {
community add my-accept;
next policy;
}
route-filter 128.0.0.0/2 upto /16 {
community add my-accept;
next policy;
}
route-filter 192.0.0.0/3 upto /24 {
community add my-accept;
next policy;
}
route-filter 0.0.0.0/1 upto /32;
route-filter 128.0.0.0/2 upto /32;
route-filter 192.0.0.0/3 upto /32;
}
then reject;
In this approach, a series of class-based route filters are added to match on Class A, B, and C addresses that have prefix
lengths longer than 19, 16, and 24 respectively. Note that the final series of route filters do not have any actions specified in
the route filter statement. As a result, traffic that matches these statements is subjected to the unnamed term’s reject
action. Some might argue that this approach is better because the policy's single term means that the J-tree is only
evaluated once. In reality, the performance benefit, if any, is negligible, making both policies equally workable.

Chapter 10–34 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Routing Policies and Deletions

In contrast to other BGP attributes like AS path, BGP allows you to delete some or all the community attribute values on a
BGP route. In fact, deleting these values is very useful to do at the boundaries of an AS because there is no guarantee that
any other AS understands or respects the values of the communities established in one AS.

Default Is to Send
If you do not delete community attribute values, by default, all BGP communities are sent to all peers inside an AS and
outside the AS. Why clutter up the routing updates with useless and potentially harmful information?

To Stop, Use Delete

To stop the community from being advertised beyond the local AS, you must delete the community.

Delete All Communities

The slide shows a routing policy that deletes all communities from a BGP route. This example uses the wildcard asterisk
character (*) to match all communities. The action of community delete wild-match performs this task.
Note that you must apply the wildcard to both halves of the community—the AS number as well as the community value. The
syntax is therefore “*:*” to match all communities.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–35

Advanced Junos Service Provider Routing

Simple Community Regular Expressions

You can use a regular expression (also called, regex), first introduced in an earlier section on AS paths, also with BGP
communities to produce a powerful pattern-matching system for finding communities that match a given regex. Regular
expressions used with communities implement the full capabilities of a complete regex implementation, unlike the AS-path
regex syntax, which used a subset.
Consider two forms of regular expressions used with routing policies concerned with BGP communities. These two forms are
simple and complex regular expressions. These are informal terms, defined in this course as follows. Simple community
regular expressions contain only the asterisk (*) or dot (.) wildcard characters separately. Complex community regular
expressions can use the asterisk and dot in conjunction with each other. Further, the complex regex statements can use
additional operator syntax characters.
The asterisk matches any single AS number or community value. The dot matches any single digit within the AS number or
community value. Note that the combination of these characters (.*) is a complex community regex, which we discuss on a
later slide.
Continued on the next page.

Chapter 10–36 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing
Examples of Simple Community Regular Expressions
Some examples of simple community regex matches are:
• *:1000 = Any possible AS number with a value of 1000.
• 65001:* = AS 65001 with any possible community value.
• 65001:100. = AS 65001 with community values of 1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007,
1008, or 1009.
• 11.1:1000 = AS 1101, 1111, 1121,1131, 1141, 1151, 1161, 1171, 1181, or 1191 with a community value of
1000.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–37

Advanced Junos Service Provider Routing

Matching the Community: Part 1

You can use standard CLI commands with simple regular expressions to find the routes (if any) associated with any
community. The slide shows a few examples.
To find all routes having a community value of 20, regardless of AS number, use the command show route community
*:20 terse. This command shows the routes but not the complete community attribute values associated with the routes.
To see the communities and more detailed information, use show route community *:20 detail.

Chapter 10–38 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Matching the Community: Part 2

In addition to the standard CLI commands seen previously, you can also locate a route using the name of a community.
The example on the slide shows a community called community-1 defined within [edit policy-options]. This
community represents the value of 1:20. You can use this community name in the show route community-name
community-1 detail command to view all routes having this community assigned.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–39

Advanced Junos Service Provider Routing

Complex Community Regular Expressions

You can use more complex regular expressions (regex) with communities. A community regular expression is character
based, unlike the regular expressions used with AS paths, which match entire AS numbers.
The format for the community regular expression is still term operator as in AS-path regular expressions, but the
application of the term and operator is different.
When formulated for use with communities, the regular expression anchors of start (^) and end ($) are not required, but
these anchors can be helpful to organize and clearly represent the regular expression.
You can use complex regular expressions in both the show route CLI commands and within a policy as a match condition.

Chapter 10–40 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Community Regular Expression Operators

The table on the slide shows a list of the possible regular expression operators you can use with BGP communities. Some
operators are shorthand for their longer equivalents. For example, the plus (+) is the same as {1,}. Both match one or
more repetition of the term preceding the operator.
The square brackets ( [ ] ) match a range ([2-8]) or array ([256]) of numbers. Thus, the first regular expression in the
previous sentence matches 2 through 8, and the second one matches 2 or 5 or 6.
Of special note is the use of the parentheses. Typically, you use the parentheses ( ) operator to group multiple terms in
conjunction with an operator. The parentheses operator also has another special use. When used with no spaces in
between, parentheses represent a null value.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–41

Advanced Junos Service Provider Routing

Examples of Complex Community Regular Expressions

The slide shows some examples of quite complex regular expressions you can use to match communities in routing policies.
The first column shows the BGP community string that the routing policy is trying to match. The second column shows the
community regular expression used to match that pattern. The last column shows examples of values of the BGP community
attribute that the regular expression matches. In some cases, the list is not exhaustive, so more possible communities
match the pattern.
Note the presence of the colon (:) to separate the AS number of community value sections of the community.

Chapter 10–42 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Complicated Community Regular Expression Example

The answer to the question on the slide is yes, the community regular expression on the slide meets the criteria outlined.
This complex regular expression uses multiple term-operator pairs in its definition. To understand better how the expression
operates, let’s reconstruct it from the ground up.
First, we have a basic expression of ^():()$. This part of the expression sets the foundation for the complete expression.
Loosely speaking, we search for an exact match of an AS number followed by a colon (:), followed by an exact match of a
community value.
Next, we assign the AS value. This AS value is actually a regular expression in itself that states the AS is either 105, 207, or
309. The pipe ( | ) operator separates the three AS numbers into logical OR groupings. The extra parentheses are used to set
aside each AS number explicitly from the pipe operator. The regular expression now appears as
^((105)|(207)|(309)):()$.
Now we can define the community values. As with the AS numbers, the values can be one of three separate entities. Again,
we use the pipe operator to separate the values and the parenthesis to define the possible values explicitly. The regular
expression is now ^((105)|(207)|(309)):(()|()|())$. Each of the possible community values in this example is
an individual expression itself. We’ll examine each one in turn.
Continued on the next page.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–43

Advanced Junos Service Provider Routing
Complicated Community Regular Expression Example (contd.)
The first possible value is a 4- or 5-digit number, where the first character is a 1. Because the community expressions are a
character-based match, the expression starts simply with a 1. The following characters in the value can be any number, so
the wildcard of dot (.) is used to represent that. Because the total value should be 4 or 5 digits, the wildcard can be
operated upon with a {3,4}, which means at least three instances of any number can appear, but no more than four
instances. Combined with the character of 1 to start the value, the wildcard-operator pair makes the value a 4- or 5-digit
number. The regular expression now appears as: ^((105)|(207)|(309)):((1.{3,4})|()|())$.
The second possible value can be any length, but it must start with either a 2, 5, or 6. Again, the community expressions are
character based, so this value should also start with a character. These are actually three possible characters in this single
position, so the brackets are used ([256]) to signify a range of possible values. Following that, there can be more
characters in the value, or there could be no characters in the value. To represent this possibility, we once again use the
wildcard dot (.). In this case, the wildcard is operated on by the asterisk (*), which results in a .* notation. This represents
any possible value present zero or more times. Combined with the [256], this wildcard-operator pair gives any possible
value of any length as long as it starts with a 2, 5, or a 6. The regular expression now appears as:
^((105)|(207)|(309)):((1.{3,4})|([256].*)|())$.
The final possible value can again be any length. This time, it must end with either a 3, 4, 7, or 9. The logic for this value is
exactly the opposite of the logic for the second value, so we can use the same operators. In this case, the value starts with
the .*, which again represents any possible value present zero or more times. This is followed by the bracket notation of
[3479] to represent a single character in that single position. When combined, the result is any possible value of any
possible length, as long as it ends with a 3, 4, 7, or a 9. The regular expression now appears as:
^((105)|(207)|(309)):((1.{3,4})|([256].*)|(.*[3479]))$.

Chapter 10–44 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

We Discussed:
• The BGP attributes local preference and communities in detail and explained the operation of those attributes;
and
• How to manipulate those BGP attributes using routing policy.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–45

Advanced Junos Service Provider Routing

Review Questions
1.

2.

3.

4.

Chapter 10–46 • BGP Attributes and Policy—Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

BGP Attributes: Local Preference and Communities Lab

The slide provides the objectives for this lab.

www.juniper.net BGP Attributes and Policy—Part 2 • Chapter 10–47

Advanced Junos Service Provider Routing
Answers to Review Questions
1.
Local preference is a BGP attribute that influences traffic flow. Route preference is local to an individual router and assists the routing
table in choosing the active route.
2.
Local preference influences outbound traffic flow.
3.
The well-known communities are: No-export; No-advertise; and No-export-subconfed.
4.
The add community action adds the specified community string to the existing community attribute. The set community action deletes
any existing communities and adds the specified community string.

Chapter 10–48 • BGP Attributes and Policy—Part 2 www.juniper.net

Advanced Junos Service Provider Routing

Chapter 11: Route Reflection and Confederations

Advanced Junos Service Provider Routing

We Will Discuss:
• The operation of BGP route reflection;
• How to configure a route reflector;
• The operation of a BGP confederation;
• How to configure confederations; and
• Peering relationships in a confederation.

Chapter 11–2 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Route Reflection Operation

The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net Route Reflection and Confederations • Chapter 11–3

Advanced Junos Service Provider Routing

IBGP Full Mesh

Unlike link-state routing protocols, internal BGP (IBGP) does not flood routing updates. Instead, IBGP uses an explicit peering
model that normally results in the exchange of routing information to peers that are connected in a full mesh. The need for a
full-mesh IBGP topology stems from the fact that BGP uses the AS path attribute to provide loop detection, but IBGP
speakers do not add the local AS number in the updates they send to other IBGP speakers. Lacking AS number based loop
detection, IBGP speakers are normally precluded from readvertising routes to other IBGP speakers when the route in
question was learned from an IBGP speaker. This default IBGP behavior leads to the need for a full mesh of IBGP peerings.
Requiring that all IBGP peers within an autonomous system (AS) be fully meshed has inherent scalability problems. For
example, every time a new router is added to the AS, each existing IBGP router must have its configuration updated to
include a peering statement for the router that has been added. This process can become quite an issue when there are
100, 200, or even 1000 routers in an AS. In fact, with only 100 routers in a full IBGP mesh, each router is required to
maintain 99 IBGP peering sessions, with the network having to support a total of 4,950 IBGP sessions! Surely there has to
be a better way.

Two Ways to Improve Scalability

The two primary ways to eliminate the need for a full BGP mesh are route reflection, as defined in RFC 4456, and BGP
confederations, as defined in RFC 3065. This chapter explores the configuration and operation of both mechanisms.

Chapter 11–4 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

IBGP Peers Can Readvertise Routes

BGP route reflection relaxes the restriction that an IBGP peer should not readvertise IBGP-learned routes to other IBGP
speakers. The routers allowed to override this default behavior are known as route reflectors (RR).

Route Reflector Sends the Active Route

RRs only readvertise the active routes to their clients. You configure an RR by using the cluster statement within an IBGP
peer-group configuration. BGP considers each of the peers configured within that peer group to be clients of the RR. The RR
clients require no configuration changes; they do not have any knowledge of the presence of the RR—they simply see the RR
as an IBGP peer.

IBGP Attributes Not Changed

One of the primary drivers behind requiring the IBGP full mesh in the first place was loop prevention, because the AS path
attribute is not modified within an AS. Route reflection does not change that behavior. In fact, none of the existing BGP
attributes changes, by default, when BGP uses route reflection in an AS. However, loop prevention is still a critical part of
BGP, so new BGP attributes were introduced to facilitate loop detection in a route reflection network.
Continued on the next page.

www.juniper.net Route Reflection and Confederations • Chapter 11–5

Advanced Junos Service Provider Routing
New BGP Attributes
Two new BGP attributes are defined to support route reflection; these attributes are the cluster list and the originator ID. An
RR creates or modifies these attributes when it readvertises the routes to both clients and non-clients. The route reflector’s
cluster ID is added to all routes that the RR touches, meaning that both clients and non-clients receive the cluster list
attribute. This attribute contains a sequence of all cluster IDs that represent all RRs that have handled the route update.

Chapter 11–6 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

New Cluster Attributes Prevent Loops

Without the new cluster attributes, a loop can be created:
1. Client sends routes to RR1;
2. RR1 sends routes to all clients and to RR2 and RR3;
3. Because route reflection allows IBGP peers to send routes to other IBGP peers, RR2 sends the routes to RR3;
and
4. Because RR3 has no way of knowing the routes received from RR2 came from RR1, RR3 sends them to RR1,
forming a loop.

www.juniper.net Route Reflection and Confederations • Chapter 11–7

Advanced Junos Service Provider Routing

Cluster List
The cluster list attribute is analogous to the AS path attribute and is used to prevent loops. If an RR receives a route with its
own cluster ID in the cluster list, it drops the route. In addition, each router in the network can use this attribute in the BGP
path selection algorithm prior to using the peer IP address attribute. BGP chooses the route with the shortest cluster list
length. This process follows the same theory as the AS path attribute.
The cluster ID is very similar to an AS number and should be unique within an individual AS. The cluster ID is added to the
cluster list attribute when a route is sent to clients and non-clients.

Originator ID
The originator ID attribute provides the router ID of the first router to advertise the route in the AS. It also is used for loop
prevention in the rare case where the cluster list does not prevent a loop.

Chapter 11–8 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Configuration and Routing Knowledge

The slide highlights the topic we discuss next.

www.juniper.net Route Reflection and Confederations • Chapter 11–9

Advanced Junos Service Provider Routing

Clients in a Peer Group

Within the Junos OS configuration syntax, all clients of an individual route reflector are placed within a single peer group.
This placement allows the route reflector to easily determine which peers are clients of a particular cluster. No configuration
changes are needed in the client’s configuration.

Route Reflector Uses the cluster Command

Once the clients are placed into their respective peer groups, use the cluster command to activate the route reflection
process of the route reflector. The cluster command is used to assign each cluster its cluster ID. This cluster ID is a 32-bit
value that uniquely describes the cluster within the BGP AS. If only a single route reflector exists in the cluster, the router ID
of the route reflector is often used as the cluster ID.
The common practice is to configure the same cluster ID on each reflector when more than one reflector exists within a given
cluster. Assigning the same cluster ID has the advantages of reducing the total number of routes stored, and it tends to
make sense when cluster and route reflection boundaries are graphically depicted. Some people maintain that it is better to
assign unique cluster IDs in these circumstances; the main advantage to unique cluster IDs is that the routes exchanged
between route reflectors in that cluster are now stored because the receiving route reflector does not detect its own cluster
ID. While this approach increases the number of routes being stored, it can offer increased redundancy in certain situations.
The redundancy benefits of assigning unique cluster IDs are largely made moot by the practice of loopback peering for IBGP
sessions, which is why the assignment of a common cluster ID is generally considered the current best practice.
Continued on the next page.

Chapter 11–10 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing
Clients Peer to Route Reflectors
The clients in the cluster must peer to the route reflector itself. The clients have no knowledge of the cluster and see the
reflector as a regular IBGP peer.

www.juniper.net Route Reflection and Confederations • Chapter 11–11

Advanced Junos Service Provider Routing

Basic Route Reflection

The slide shows an AS network using a typical route reflection topology.
BGP-speaking routers along the edge of the network all have a single peer configured in the form of the route reflector for the
local cluster.
The route reflectors are, in turn, fully meshed using standard IBGP peering procedures. The result is that all routes received
by any BGP router will eventually be seen by all other BGP routers in the AS.
It is a common best practice to have the logical route reflection topology follow the physical topology of the network.

Chapter 11–12 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Route Propagation
The next series of slides shows the flow of routing information in a route reflection network using a basic topology.
We begin with a client in the left-most cluster advertising the 10.10.10.0/24 route to the cluster’s route reflector.
The slide details how the 10.10.10.0/24 route is readvertised to all other clients in the cluster as well as to all non-client
IBGP peers of the reflector. This process applies to all other routes the route reflector receives from a client in its cluster.
This slide shows how the other route reflectors in the network readvertise all routes received from IBGP peers (the other
reflectors in this example) to all of their cluster clients.

www.juniper.net Route Reflection and Confederations • Chapter 11–13

Advanced Junos Service Provider Routing

Dual Route Reflectors in a Cluster

The slide shows a cluster containing two route reflectors. This type of cluster design is popular because it avoids a single
point of network failure. When a cluster has only a single route reflector, the clients might become segmented from the
network in the event of a failure of that RR. A design that includes two RRs in each cluster ensures that the failure of a single
router does not segment the network.
Each of the client routers simply configure two IBGP peers and forward EBGP-learned routes to both route reflectors. The
route reflectors themselves can peer either within the cluster as clients of each other or outside of the cluster as normal
IBGP peers. Either way, routes from within the cluster are dropped when advertised between the RRs because of cluster list
routing loops.
Each of the route reflectors also establish IBGP peering sessions with the other RRs in the entire AS.
As previously mentioned, a debate exists as to whether each route reflector should be assigned the same or unique cluster
ID. In most cases, using unique cluster IDs is preferred. The drawback is that using unique cluster IDs requires more BGP
route state at the route reflectors. This generally does not outweigh the advantage of maintaining connectivity.

Chapter 11–14 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Hierarchical Route Reflection

The slide shows an AS network using a more complex, hierarchical, route reflection topology.
Hierarchical route reflection occurs when the route reflectors for some clusters are themselves clients in another route
reflection cluster. Very often AS networks evolve to this type of setup when the reflector full mesh shown on a previous slide
becomes too large to manage. In this case, the internal route reflector full mesh might evolve into a route reflection cluster.

www.juniper.net Route Reflection and Confederations • Chapter 11–15

Advanced Junos Service Provider Routing

Clients Can Peer with Other Clients

Clients within a cluster can peer with other clients in a full-mesh environment. This ability does not change the operation or
need for the route reflector. The reflector still sends routes from the clients to the remainder of the IBGP network and
forwards routes from the IBGP network into the cluster. What the client full mesh does provide is the ability of clients to use
other clients’ routes natively when logical BGP connectivity exists between the clients.
In this situation, each of the clients receives two versions of the route. One version is from the other client, and one version
is from the route reflector. Because the extra copy of the route from the reflector is not needed, you can disable the internal
cluster readvertisements using the no-client-reflect command. Once configured, the route reflector only forwards to
the clients routes which arrive from outside of the cluster.

Chapter 11–16 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Route Reflector Can Modify Attributes

The default operation of a route reflector is to not modify any BGP defaults. However, the Junos OS does allow an applied
routing policy to do just that. The reason for this action is the support of customer networks. For reasons outside the scope
of this course, some network administrators engineer traffic flows by altering attribute values when the route reflector
readvertises routes from a non-client into the cluster. This alteration is supported through the use of routing policies applied
to the cluster's peer group.

Forwarding Paths Should Be Unaffected

Although a client learns of a route from the cluster’s route reflector, the route reflector itself does not have to be in the
forwarding path for packets sent from clients towards the route destination. In fact, often times it is not.
In the example on the slide, the 172.16.2.2 cluster client advertises the 192.168.0.0/16 route to the cluster’s RR with the
BGP next hop set to its router ID. Because of sloppy next-hop-self policy on the RR, the BGP next hop is overwritten with the
router ID of the RR—172.16.1.1. When client 172.16.3.3 receives and installs this route, suboptimal forwarding occurs as
packets are sent through the RR instead of directly to 172.16.2.2. This situation might occur when the route reflector also
has EBGP peering sessions established. Most network designs avoid this problem by placing their route reflectors within the
core of their networks.
Continued on the next page.

www.juniper.net Route Reflection and Confederations • Chapter 11–17

Advanced Junos Service Provider Routing
Forwarding Paths Should Be Unaffected (contd.)
The solution to this problem is a selective next-hop-self policy on the RR that modifies the BGP next hop for only
EBGP-learned routes. This type of policy normally makes use of the from neighbor or from interface match
conditions, as shown here. In this example, the RR has an EBGP peering session with the 172.16.0.1 address:
[edit policy-options policy-statement selective-nhs]
user@router# show
term only-EBGP-routes {
from {
protocol bgp;
neighbor 172.16.0.1;
}
then {
next-hop self;
}
}

Chapter 11–18 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Case Study: RFC 3345 Oscillation—Part 1

Some route reflector topologies are susceptible to a persistent prefix oscillation; the triggers are using multiple exit
discriminators (MEDs) in a route reflector or confederation environment. This problem is not a corner case. In fact, it has
happened several times and major Internet backbones were affected by this problem. The issue is simple to describe but
requires a working knowledge of BGP path selection.
Consider the sample topology and the following sequence of events:
1. The R8 router is advertising the 200/24 prefix towards the R6 and R7 routers.
2. The R6 and R7 routers apply three different MED values and advertise the route to their peers (R3, R4, and R5).
3. As route reflector clients, R3, R4, and R5 advertise this route to their respective route reflector.
4. R1 now has visibility of the 200/24 route through both R3 and R4, and has chosen R4 (through ge-1/0/5) as
the best exit point due to IGP metric (4 compared to 5). It also advertises that best path to route reflector R2.
You can view sample outputs from the R1 router on the following page.
Continued on the next page.

www.juniper.net Route Reflection and Confederations • Chapter 11–19

Advanced Junos Service Provider Routing
Case Study: RFC 3345 Oscillation—Part 1 (contd.)
The following are sample outputs from the R1 router on the preceding page:
user@R1> show route 200/24
inet.0: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.0.0.0/24 *[BGP/170] 00:00:01, MED 1, localpref 100, from 192.168.10.4
AS path: 6 100 I, validation-state: unverified
> to 20.0.0.2 via ge-1/0/5.0
[BGP/170] 00:00:01, MED 10, localpref 100, from 192.168.10.3
AS path: 10 100 I, validation-state: unverified
> to 10.0.0.2 via ge-1/0/4.0

user@R1> show route advertising-protocol bgp 192.168.10.2

inet.0: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 200.0.0.0/24 192.168.10.4 1 100 6 100 I

Chapter 11–20 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Case Study: RFC 3345 Oscillation—Part 2

Our sequence of events continues as follows:
5. In addition to the R1 advertisement, route reflector R2 has also has visibility of the 200/24 route through the
R5 router.
6. R2 chooses the path through R5 as best path because of the lower MED value (0 compared to 1), and
advertises it back to R1. Up to this point, there are no problems. Sample output from R2 follows.
user@R2> show route 200/24
inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

200.0.0.0/24 *[BGP/170] 01:18:01, MED 0, localpref 100, from 192.168.10.5

AS path: 6 100 I, validation-state: unverified
> to 40.0.0.2 via ge-1/0/4.0
[BGP/170] 00:00:00, MED 1, localpref 100, from 192.168.10.1
AS path: 6 100 I, validation-state: unverified
> to 30.0.0.1 via ge-1/1/2.0

user@R2> show route advertising-protocol bgp 192.168.10.1

inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 200.0.0.0/24 192.168.10.5 0 100 6 100 I

www.juniper.net Route Reflection and Confederations • Chapter 11–21

Advanced Junos Service Provider Routing

Case Study: RFC 3345 Oscillation—Part 3

Our sequence of events continues as follows:
7. R1 now has to compare three routes to the 200/24 prefix; one through R3, one through R4, and the last one
through the other route reflector, R2.
8. Following the BGP decision process, R1 considers the route through the R2-R5 path better than the path
through R4 because of the lower MED value (0 compared to 1). However, the route through R3 is then
considered best, because of the lower IGP cost (5 compared to 13). Keep in mind that two routes come from
different autonomous systems, meaning the MED values are not considered.
9. R1 then advertises the preferred path through R3 to R2 as shown in the following output:
user@R1> show route advertising-protocol bgp 192.168.10.2

inet.0: 14 destinations, 15 routes (14 active, 1 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* 200.0.0.0/24 192.168.10.3 10 100 10 100 I

Chapter 11–22 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Case Study: RFC 3345 Oscillation—Part 4

The following are the final steps in our sequence of events:
10. At this point, R2 now compares the path through R1 and R3 with the one through R5; the winner is the route
through R1 and R3 due to a lower IGP metric (6 compared to 12).
11. This causes R2 to stop advertising the path through R5 to R1. R1 is now left with the two original paths, one
through R3 and one through R4.
12. We are back where we started. R1 picks the route through R4 and the cycle repeats itself.
Continued on the next page.

www.juniper.net Route Reflection and Confederations • Chapter 11–23

Advanced Junos Service Provider Routing
Case Study: RFC 3345 Oscillation—Part 4 (contd.)
In the following sample output, you can view the output from R1 that demonstrates the route churn described in this case
study. Take note of the route timestamps; the output encompasses only seven seconds:
user@R1> show route 200/24

inet.0: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

200.0.0.0/24 *[BGP/170] 01:19:08, MED 1, localpref 100, from 192.168.10.4

AS path: 6 100 I, validation-state: unverified
> to 20.0.0.2 via ge-1/0/5.0
[BGP/170] 01:19:08, MED 10, localpref 100, from 192.168.10.3
AS path: 10 100 I, validation-state: unverified
> to 10.0.0.2 via ge-1/0/4.0

user@R1> show route 200/24

inet.0: 14 destinations, 16 routes (14 active, 1 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

200.0.0.0/24 +[BGP/170] 01:19:10, MED 10, localpref 100, from 192.168.10.3

AS path: 10 100 I, validation-state: unverified
> to 10.0.0.2 via ge-1/0/4.0
[BGP/170] 00:00:00, MED 0, localpref 100, from 192.168.10.2
AS path: 6 100 I, validation-state: unverified
> to 30.0.0.2 via ge-1/1/2.0
-[BGP/170] 01:19:10, MED 1, localpref 100, from 192.168.10.4
AS path: 6 100 I, validation-state: unverified
> to 20.0.0.2 via ge-1/0/5.0

user@R1> show route 200/24

inet.0: 14 destinations, 15 routes (14 active, 1 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

200.0.0.0/24 +[BGP/170] 01:19:13, MED 1, localpref 100, from 192.168.10.4

AS path: 6 100 I, validation-state: unverified
> to 20.0.0.2 via ge-1/0/5.0
-[BGP/170] 01:19:13, MED 10, localpref 100, from 192.168.10.3
AS path: 10 100 I, validation-state: unverified
> to 10.0.0.2 via ge-1/0/4.0

user@R1> show route 200/24

inet.0: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

200.0.0.0/24 *[BGP/170] 01:19:15, MED 1, localpref 100, from 192.168.10.4

AS path: 6 100 I, validation-state: unverified
> to 20.0.0.2 via ge-1/0/5.0
[BGP/170] 01:19:15, MED 10, localpref 100, from 192.168.10.3
AS path: 10 100 I, validation-state: unverified
> to 10.0.0.2 via ge-1/0/4.0

Chapter 11–24 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Case Study: RFC 3345 Oscillation—Part 5

In real-life scenarios, the topology can be much more complex involving, for example, multiple levels of route reflection, or
oscillations between more than two clusters. Some potential workarounds are using the always-compare-med
parameter, using the add-path option, or making sure that the metric between routers in different clusters is higher than
the metric between routers within the same cluster.
The always-compare-med option is demonstrated on the slide. You configure this option with the set protocols
bgp path-selection always-compare-med statement. Once committed, the oscillation problem is solved. The
following sample output shows the 200/24 route after this fix has been applied. The path with the lowest MED value is
chosen.
user@R1> show route 200/24
inet.0: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.0.0.0/24 *[BGP/170] 00:00:16, MED 0, localpref 100, from 192.168.10.2
AS path: 6 100 I, validation-state: unverified
> to 30.0.0.2 via ge-1/1/2.0
[BGP/170] 00:00:12, MED 10, localpref 100, from 192.168.10.3
AS path: 10 100 I, validation-state: unverified
> to 10.0.0.2 via ge-1/0/4.0

www.juniper.net Route Reflection and Confederations • Chapter 11–25

Advanced Junos Service Provider Routing

Case Study: RFC 3345 Oscillation—Part 6

There might be times when using the always-compare-med option is not suitable. As mentioned previously, another way
to solve this oscillation problem is with the add-path option. This option was introduced in Junos OS Release 11.3 and
allows a BGP router to advertise multiple paths instead of advertising only the active path.
As shown on the slide, you can configure an Add-Path speaker to be a receiver only, sender only, or both (as shown). You can
also configure the number of paths to advertise, between 2 and 6. Furthermore, you can use the prefix-policy option
to control which routes get distributed using the Add-Path algorithm.
Continued on the next page.

Chapter 11–26 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing
Case Study: RFC 3345 Oscillation—Part 6 (contd.)
The following output is sample output from the R1 router after configuring the add-path option on both the R1 and R2
routers. Note that all three paths are now present and the oscillation issue has stopped.
user@R1> show route 200/24
inet.0: 14 destinations, 16 routes (14 active, 1 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.0.0.0/24 *[BGP/170] 00:14:56, MED 10, localpref 100, from 192.168.10.3
AS path: 10 100 I, validation-state: unverified
> to 10.0.0.2 via ge-1/0/4.0
[BGP/170] 00:14:42, MED 0, localpref 100, from 192.168.10.2
AS path: 6 100 I, validation-state: unverified
> to 30.0.0.2 via ge-1/1/2.0
[BGP/170] 00:14:52, MED 1, localpref 100, from 192.168.10.4
AS path: 6 100 I, validation-state: unverified
> to 20.0.0.2 via ge-1/0/5.0

www.juniper.net Route Reflection and Confederations • Chapter 11–27

Advanced Junos Service Provider Routing

BGP Confederations
The slide highlights the topic we discuss next.

Chapter 11–28 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Break Up the Global AS

A confederation takes a global AS and breaks it into smaller subautonomous systems. These sub-AS networks are connected
together to form the unified AS to which all other networks in the Internet peer.
Bear in mind that confederations are almost never deployed nowadays because of two inherent limitations:
1. It is not possible to migrate to or from a confederation setup without a complete BGP shutdown; and
2. Unlike route reflectors, confederations are not scalable in regards to services and address families; you could,
for example, have a dedicated set of route reflectors for Layer 3 virtual private networks (VPNs), and another set
for VPLS services, but there is no way of achieving this with confederations.

Within a Sub-AS
The confederation sub-AS networks act just like a real AS; they require a full mesh of IBGP connectivity within themselves.
Should the full mesh of the sub-AS grow too large, route reflection might be used within a sub-AS to scale the network.
Each sub-AS must have a unique AS number defined, and most administrators use a private AS number from the 64512 to
65535 range.
Continued on the next page.

www.juniper.net Route Reflection and Confederations • Chapter 11–29

Advanced Junos Service Provider Routing
Between Each Sub-AS
An EBGP-like connection that is often referred to as confederation BGP (CBGP) is used to interconnect the sub-AS networks.
CBGP is a special type of EBGP; certain attributes, such as the BGP next hop, are handled differently across CBGP sessions.
CBGP peers modify the AS path attribute to include the sub-AS numbers. This modification is performed to provide loop
prevention within only the confederation network. All other BGP attributes, such as local preference and the BGP next hop,
remain unchanged when sent across a CBGP link.
Because the router views connections between the sub-AS networks as being EBGP, some special configuration might be
warranted. The router expects to use the physical address of the CBGP for the BGP session, but many administrators prefer
to peer the CBGP routers using loopback addresses. This is accomplished through the use of the multihop command.

Chapter 11–30 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

AS Confederation Sequence
As a route is advertised over a CBGP link, BGP modifies the AS path attribute to include the sub-AS number. BGP places this
sub-AS number into an AS confederation sequence, as denoted by parentheses, within the AS path attribute. The sequence
is a new AS path segment attribute with a type code of 3.
The sub-AS values are sequenced in the order in which the route has traversed the network, with the primary purpose being
loop prevention within the confederation network. The confederation sequence is not used in the calculation of AS path
length for the BGP active route selection algorithm. For routers within a confederation network, the confederation sequence
appears as a single, internal BGP AS network.

AS Confederation Set
Should some routing aggregation occur within the confederation network, the granularity of the confederation sequence
might be lost. This process is very similar to conventional BGP route aggregation.
In this situation, the AS confederation sequence becomes an AS confederation set and is denoted by curly braces within the
AS path output. The set is also a new AS path segment attribute with a type code of 4.
The routers within the confederation view the AS confederation set in the same manner as a sequence. That is, the set is still
used for loop prevention even though the ordering of the sub-AS numbers is no longer significant.

www.juniper.net Route Reflection and Confederations • Chapter 11–31

Advanced Junos Service Provider Routing

Global AS Appears Whole

The Internet views the confederation as a single autonomous system. The AS path received by other autonomous systems
contains only the globally assigned AS number. The AS path contains only this number because all sub-AS numbers are
removed from the AS path attribute as the route is advertised to EBGP peers.
To operate a confederation network effectively, all BGP routers in the AS must know the globally unique AS number as well as
all the configured sub-AS numbers. This information is defined using the confederation command within the
routing-options stanza, as shown on the slide.

Confederation Information Removed

At the edge of the confederation network, the routers remove all confederation-related AS numbers, both sequences and
sets, from the AS path attribute of all routes prior to EBGP advertisement. This removal allows the details of the
confederation network to be hidden to all other networks in the Internet.
Note that the remove-private command is not required to remove sub-AS numbers when you operate a confederation
network. This behavior is the default for a BGP confederation and is controlled by the confederation command.

Chapter 11–32 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Confederation Peering
The slide shows an example of a BGP confederation network. The global AS of 201 is split up into five sub-AS networks—
65000, 65001, 65002, 65003, and 65004. The sub-AS networks are connected with EBGP-like connections (sometimes
called CBGP). Because the CBGP links behave like EBGP, there is no need for a full-mesh topology between each sub-AS.
Therefore, you can provision CBGP connections wherever it is logically, or physically, convenient.
Some of the sub-AS networks on the slide are using route reflection within the sub-AS to eliminate the need for a full IBGP
mesh. The combination of BGP confederations and route reflection simultaneously allows for great flexibility in scaling your
AS to hundreds or thousands of routers.

www.juniper.net Route Reflection and Confederations • Chapter 11–33

Advanced Junos Service Provider Routing

Peering Session Configurations

The configuration example on the left side of the slide represents Router 3 in sub-AS 65001. A full mesh of IBGP peering
sessions exist within the sub-AS, as seen in peer group sub-AS-65001. The remaining peer groups on that router
represent CBGP connections to other sub-AS networks in the confederation. Each group uses a connection type of
external, uses the multihop command, and configures both a peer and local AS value.
The configuration example on the right side of the slide represents Router 1 in sub-AS 65003. This sub-AS uses route
reflection to replace the IBGP full mesh, and Router 1 is the route reflector for the cluster. This configuration is seen in peer
group sub-AS-65003 where the cluster command is configured. The other peer group on the router represents the
CBGP peering connection to sub-AS 65000.

Chapter 11–34 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

We Discussed:
• Operation of BGP route reflection;
• How to configure a route reflector;
• The operation of a BGP confederation;
• How to configure BGP confederations; and
• Peering relationships in a BGP confederations.

www.juniper.net Route Reflection and Confederations • Chapter 11–35

Advanced Junos Service Provider Routing

Review Questions
1.

2.

3.

4.

5.

6.

Chapter 11–36 • Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Scaling BGP Lab

The slide shows the objectives for the lab.

www.juniper.net Route Reflection and Confederations • Chapter 11–37

Advanced Junos Service Provider Routing
Answers to Review Questions
1.
Cluster ID and Cluster List support route reflection.
2.
The cluster statement is configured only on the route reflector.
3.
No-client-reflect can be used to stop excess advertisements.
4.
An RR readvertises routes received from clients and non-clients, adding the cluster ID and cluster list attributes.
5.
Loops are prevented by examining the confederation AS sequence or AS set.
6.
Routers in a sub-AS run IBGP. Routers across a confederation boundary run CBGP. Routers external to the confederations run EBGP.

Chapter 11–38 • Route Reflection and Confederations www.juniper.net

Advanced Junos Service Provider Routing

Chapter 12: BGP Route Damping

Advanced Junos Service Provider Routing

We Will Discuss:
• The causes for route instability;
• The effect of damping on BGP routing;
• The default behavior of damping on links;
• How to control damping using routing policy; and
• How to view damped routes using command-line interface (CLI) commands.

Chapter 12–2 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Route Flap and Damping Overview

The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net BGP Route Damping • Chapter 12–3

Advanced Junos Service Provider Routing

Routing Is Dynamic
In any real network, routes can appear and disappear rapidly if a link fails and restores itself repeatedly in a short period of
time. This is because any routes (and there could be thousands) that use the failed interface as a next hop must respond to
the failure, and the change in next hop must propagate to all other routers on the network. This rapid changing of routing
next hops is called route flapping or just flapping as the link flaps up and down.

Update/Withdrawn Pairs
Flapping results in a rapid sequence of BGP update or withdrawn messages. Recall that BGP routers must maintain separate
memory tables for inbound and outbound traffic on a per-peer basis. In addition, the BGP routing protocol propagates
information on an as-needed basis. These two factors make BGP unstable in the face of a flapping link.
Every BGP router that receives one of these update or withdrawn messages must send this information on to all its BGP
router peers. Much like the link-state IGPs of OSPF and IS-IS, BGP must also recalculate its routing tables and databases
every time a new update is received. If the new information alters the path selection process, a new route is chosen for the
RIB-LOCAL, and the new route must be sent downstream to all BGP peers.
Continued on the next page.

Chapter 12–4 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing
Update/Withdrawn Pairs (contd.)
The effect of route flapping quickly cascades and affects router performance. One intermittently failing link can adversely
affect a whole network. If this type of update or withdrawal occurs on a very frequent basis, valuable resources in the router,
such as processing power normally used to forward packets, and bandwidth now needed for routing updates, are consumed.

www.juniper.net BGP Route Damping • Chapter 12–5

Advanced Junos Service Provider Routing

Bad Links
Routes in a network can flap for any number of reasons. Quite possibly, the most frequent reason for a link flap is because of
faulty circuit that is on the brink of outright failure. Any link that rapidly changes from seemingly operational to failing is a
potential source of route flapping.

Unstable IGPs
Route flapping is not totally a BGP phenomenon. IGPs that are unstable because of faulty links can affect BGP when IGP
routes are injected into BGP for advertising. BGP stability is always desirable and can be enhanced with careful use of static
definitions and aggregates instead of injecting raw IGP routes into BGP.

Bad Routing Policy

Human error can cause route flaps as well. An incorrectly configured routing policy, causing routes to be first rejected, then
accepted because of the change on the route, can cause flapping.
Continued on the next page.

Chapter 12–6 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing
Congested Links
Link congestion can cause route flaps if the overloaded links drop the BGP sessions that keep the BGP routes fresh.

Flapping and History

In the past, sometimes the routers themselves contributed to the flapping problem. Older routers were filled with software
bugs (mostly after an upgrade to a new release), had insufficient power (a busy CPU in a software-based router would drop
BGP sessions), and often had insufficient memory (routing tables must be kept in memory). Sometimes, just adding
equipment for routine network upgrades and maintenance caused route flaps.

www.juniper.net BGP Route Damping • Chapter 12–7

Advanced Junos Service Provider Routing

Route Damping
Because route flapping can be so harmful to BGP, the protocol was extended to support route damping. RFC 2439, BGP
Route Flap Damping (November 1998), defines route damping. Sometimes the term dampening is seen and used.

No Damping for IBGP

There is a difference between how damping is applied in BGP for internal and external peers. IBGP sessions ignore damping
and flap as they please. There is a very good reason for this IBGP behavior. IBGP sessions usually peer to loopbacks, so IGP
routes must be able to come and go so that IBGP sessions always have a way to reach the loopback. Recall that BGP has no
reachability information of its own and relies on the IGP to resolve next hops.

EBGP Only
Route damping is only applied to routes received from an EBGP peer. EBGP sessions can carry information about thousands
of routes. Each EBGP session must update or withdraw these routes as required. Route damping seeks to reward route
stabilities while penalizing route flapping. Once damping is enabled, the router begins to maintain a database of instability. If
an EBGP-received route experiences enough flaps, the local BGP process ignores information about that route. This reaction
results in not including this information in the route selection process and not advertising route changes to downstream BGP
peers. Note that some ISPs no longer use damping.

Chapter 12–8 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Route Damping Use by ISPs

The slide shows an example of when BGP route damping is useful.
A customer of AS 1 is connected to the AS by a link running EBGP. The customer advertises three routes: 172.31.0.0/20,
172.31.64.0/20, and 172.31.128.0/20.
AS 1 provides transit service for this customer to the Internet, so the three routes are readvertised within AS 1 and further to
the Internet.
However, look what happens when the 172.31.64.0/20 route starts to experience stability problems, causing multiple
update and withdraw messages to be sent to AS 1 (up/down/up/down, and so on). Without route damping enabled, this flap
action causes the router in AS 1 to send new update messages to other routers in AS 1. These IBGP peers then also send
new update messages to their Internet peers.
Enabling route damping can halt this wave of instability at the edge of AS 1. Once enabled, the edge router in AS 1 starts
maintaining statistics for the routes received from the customer. Once the 172.31.64.0/20 route is deemed unstable, the AS
1 router stops generating new update messages to its IBGP peers. The IBGP peers, in turn, also have no need to send update
messages to the Internet. This makes the Internet, as a whole, more stable.

www.juniper.net BGP Route Damping • Chapter 12–9

Advanced Junos Service Provider Routing

Route Damping Parameters

The slide highlights the topic we discuss next.

Chapter 12–10 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Figure of Merit Is a Number

The point at which a route is deemed to be too unstable is calculated by the damping figure of merit. It might seem more like
a figure of demerit but that is the term the RFC uses. In this context, the term figure means a number, not a picture. The
figure of merit is a type of point value given to a route. The value becomes a penalty if the figure of merit exceeds some
predetermined value (that is, the route is suppressed). It is often said that damping puts a route into a penalty box for a given
period of time.

Default Value = 0
When a previously unknown (that is, new) route arrives at a BGP router that has damping enabled, the new route is assigned
a figure of merit value of 0.
Continued on the next page.

www.juniper.net BGP Route Damping • Chapter 12–11

Advanced Junos Service Provider Routing
Event Point Values
Should the route experience any instability, the figure of merit is incremented according to the following:
• As the EBGP peer withdraws the route, the figure of merit is increased by a value of 1000;
• As the EBGP peer readvertises the route, the figure of merit is increased by a value of 1000; and
• As attributes for the route change through new update messages from the EBGP peer, the figure of merit is
increased by a value of 500.

Point Reduction
The points given to a route decay (that is, reduce in value) at a certain rate, known as the half-life. As long as points
decay faster than they accumulate, the route is not suppressed.

The Cutoff Threshold

Should the figure of merit value increase beyond a configured cutoff (suppress) threshold, the route is considered
unusable, and new information about the route from the EBGP peer is ignored. The suppress value is configurable, but it
must be less than or equal to the merit ceiling value explained further on this page.

The Reuse Threshold

The route can once again be considered usable after the figure of merit decreases below a configured threshold. The figure
of merit is decreased on a time schedule you set. Should the figure of merit not decrease below the bottom threshold in a
configured amount of time, the route can automatically be usable again (reuse).

Maximum Suppress Time

The configurable max-suppress parameter establishes the maximum time that a route can be suppressed. Also, the
figure of merit can only increase to the maximum value, called the merit ceiling. The symbol used for the merit ceiling is εc.
This maximum value is calculated from a combination of the components listed above and is determined by the following
formula:

εc ≤ εr e(t/λ)(ln 2)
where εr is the figure of merit reuse threshold, t is the maximum suppression (hold-down) time in minutes, and λ is the
half-life in minutes.

Chapter 12–12 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Cutoff Threshold
The figure-of-merit value interacts with the damping parameters. The slide lists these parameters.
The suppress variable is the configured threshold where a BGP route is considered unstable and is not used. This variable
represents the value of the penalty that establishes the point at which damping is initiated. When this value is reached, the
route is cutoff (suppressed). The default value of suppress is 3000. Possible values range from 1–20000. If changed, this
value must be less than or equal to the merit ceiling εc, or damping never occurs.

Reuse Threshold
The reuse variable is the configured threshold where a BGP route is considered usable once again. This variable is the
value to which the penalty must decay before the router considers the route in its path selection. The default value of the
reuse is 750. Possible values range from 1–20000.

Decay Half-Life
The half-life variable is the rate at which the figure of merit is decreased to half its value once the value is larger than 0.
The default value of the half-life is 15 minutes. Possible values range from 1–45 minutes.
Continued on the next page.

www.juniper.net BGP Route Damping • Chapter 12–13

Advanced Junos Service Provider Routing
Maximum Hold-Down Time
The max-suppress variable is the configured maximum amount of time that a BGP route can be deemed unusable. This
variable is the longest time that the route can be suppressed until the route is given another chance to behave. The default
value of the max-suppress is 60 minutes. Possible values range from 1–720 minutes. At the end of the max-suppress
interval, all is forgiven and the route becomes active again.

Chapter 12–14 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Sample Figure of Merit in Action

The slide shows a graphic representation of the figure of merit in use for a BGP route. The default values for suppress
(3000), reuse (750), and half-life (15 minutes) are used. Note that an exponential decay occurs on the figure of merit,
and a fixed ceiling exists on the figure-of-merit value (the merit ceiling).
After receiving a new BGP route, the figure of merit is 0 for some period of time. As soon as the route is withdrawn (or the link
is down), the figure of merit increments to 1000. As long as the route stays down, the figure of merit decays somewhat. As
the route is readvertised, the figure of merit is incremented by another 1000. Again, the figure of merit starts to decay. Now
the route is withdrawn a second time, and again, the figure of merit is increased. Now, when the route is readvertised, the
figure of merit is increased by another 1000. This time, because not enough time has elapsed between these events in this
example, the route is over the suppress limit of 3000 and is considered unusable. In short order, the route is withdrawn
and readvertised, yet again. Each time, the figure of merit increases 1000 for each action. Notice that the route is still
damped and considered unusable, but the figure of merit still increases and decreases, even while the route is suppressed.
Whenever the figure of merit is greater than 0, the value is constantly and consistently decayed using the configured
half-life value. The half-life is always configured in increments of minutes. The purpose of the half-life is to
decay exponentially the figure of merit such that the value from any point in time is reduced by half at the end of the
configured half-life (this half-life behavior is the essence of an exponential decay). The decay is made an exponential
process so that routes can be reused as they gradually cross the reuse threshold and not in large groups as a timer expires.
This has the effect of not overloading BGP routers with large amounts of updates at once, causing further route damping.

www.juniper.net BGP Route Damping • Chapter 12–15

Advanced Junos Service Provider Routing

Configuring and Monitoring Route Damping

The slide highlights the topic we discuss next.

Chapter 12–16 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Damping Parameters in a Routing Policy

Once damping is enabled within the BGP portion of the Junos OS configuration, the default values introduced on previous
slides are used for figure-of-merit calculations.
To alter these default values, you can create and define a damping profile within the [edit policy-options]
configuration hierarchy.

Applied as Policy Action

Much like the AS-path and community attributes, you name and define a damping profile first. Then you can use it within a
policy as an action. The slide shows the five damping parameters.
The presence of the disable keyword deserves a few words of explanation. You can use the keyword disable within a
damping profile to not have the figure of merit be calculated for certain routes. This is often useful to exempt certain routes
that should never be damped and made unusable. One good example of these types of routes are the root DNS servers in
the Internet. If these servers become unreachable because of damping, the ISP and its customers experience DNS lookup
failures. For example, DNS routes could have a damping profile of no-damping defined that contains a single statement:
disable.

www.juniper.net BGP Route Damping • Chapter 12–17

Advanced Junos Service Provider Routing

Example of Damping Use: Part 1

The slide shows a fairly sophisticated example of route damping in action.
On the slide, AS 1 wants to enable damping for all its EBGP peers, based on the following administrative decisions:
• AS 1 wants to operate the default damping values for routes from AS 100;
• AS 1 does not want to damp any routes from its customer; and
• AS 1 wants to damp all routes aggressively from the Internet except for certain prefixes.
The next few slides in this sequence examine how you can implement these damping policies.
The next slide outlines the routing policies you can use to accomplish these goals. We detail the application of these routing
policies on a later slide.

Chapter 12–18 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Example of Damping Use: Part 2

This slide shows all the damping profiles and policies to be used in AS 1 in the damping example. The profile do-not-damp
has a variable of disable defined. The profile aggressive-damp has defined four variables as follows:
• suppress is 1500;
• reuse is 200;
• half-life is 30; and
• max-suppress is 120.
A policy named customer-inbound is defined with no from statement, so all possible routes match the policy. The policy
has an action of damping do-not-damp. This action sets the profile of do-not-damp to all routes.
A policy named internet-inbound is defined with two terms. The let-some-through term has several
route-filter statements with a then action defined of damping do-not-damp followed by an accept action. A
second term of damp-all-others has no from statement defined, so all routes are subjected to the damping
aggressive-damp action.

www.juniper.net BGP Route Damping • Chapter 12–19

Advanced Junos Service Provider Routing

Example of Damping Use: Part 3

The routers in AS 1 are next updated to apply the policies we created on the previous slide.
Router R1 defines damping in BGP and an import policy of internet-inbound. This configuration enables damping on
the router and applies profile parameters as per the policy. As mentioned previously, the currently configured policy contains
a logic flaw that causes it not to meet the administrative requirements.
Router R2 simply defines damping within its BGP configuration. This configuration both enables damping and operates with
the default parameters on routes from AS 100. No policy is needed on this router.
Router R3 defines damping within BGP and an import policy of customer-inbound. This configuration enables damping
on the router and applies profile parameters as per the policy.

Chapter 12–20 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Damping History
The slide shows the output from the show route damping history command.
Any routes displayed by this command were withdrawn from the router. However, the router retains a record of these routes
should they be readvertised to the local router. Some notable details in the display include the following:
• The route is currently hidden. We see this in both the State: <Hidden Ext> field as well as the
Preference: /-101 field. Notice that no Junos OS protocol preference value is defined.
• There is a field (Merit) for the current figure-of-merit value. The two values that follow list the value after the
last BGP update (or withdrawal), and the current value after experiencing some decay. For this route, the values
are Merit: 2777/2454. Thus, the value at the last update/withdrawal was 2777 (note that this value need
not necessarily exceed the default suppress threshold of 3000), and the current value is 2454.
• The default parameters are used (Default damping parameters used). If this route were evaluated by
a policy with a damping action, the new damping profile name would appear in the output.

www.juniper.net BGP Route Damping • Chapter 12–21

Advanced Junos Service Provider Routing

Routes with Non-0 Figures of Merit

The slide shows the output from the show route damping decayed command.
Any routes displayed by this command were advertised to the router and are currently usable routes, but these routes have a
figure of merit greater than 0. Some things to note in the display are:
• The route is currently active. We see this both by the asterisk (*) in the output as well as the State:
<Active Ext> field.
• There is a field (Merit) for the current figure-of-merit value. The two values list the value after the last update
(or withdrawal) and the current value after experiencing some decay. For this route, the values are Merit:
2000/1954.
• The default parameters are used (Default damping parameters used). If a policy with a damping
action evaluated this route, the new damping profile name would appear in the output.

Chapter 12–22 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Damped Routes
The slide shows the output from the show route damping suppressed command.
Any routes displayed by this command were advertised to the router, but these routes have a figure of merit that is currently
above the suppress threshold, and the route is unusable.

Manual Clearing
The route remains in this state until the figure of merit crosses below the reuse threshold. A route can have the figure of
merit reduced to 0 administratively by using the clear bgp damping command.
On the slide, the route 200.200.200.0/24 is currently suppressed and hidden. After we issue the clear bgp damping
command, the route is no longer hidden.

www.juniper.net BGP Route Damping • Chapter 12–23

Advanced Junos Service Provider Routing

We Discussed:
• The causes of route instability;
• The effect that route damping has on BGP routing;
• The default behavior of damping on links;
• Controlling damping using the routing policy framework; and
• Viewing damped routes using CLI commands.

Chapter 12–24 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Review Questions
1.

2.

3.

4.

5.

www.juniper.net BGP Route Damping • Chapter 12–25

Advanced Junos Service Provider Routing

BGP Route Damping Lab

The slide provides the objective for this lab.

Chapter 12–26 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing
Answers to Review Questions
1.
IBGP sessions usually peer to loopbacks, so IGP routes must be able to come and go so that IBGP sessions always have a way to reach
the loopback.
2.
The half-life is the rate at which the figure of merit is decreased to half its value once the value is larger than 0. The default value of the
half-life is 15 minutes.
3.
The max-suppress parameter establishes the maximum time that a route can be suppressed. The default value is 60 minutes.
4.
If the suppress threshold is set higher than the merit ceiling no damping will occur.
5.
The command shows any routes that were advertised to the router and are currently usable routes, but have a figure of merit greater
than 0.

www.juniper.net BGP Route Damping • Chapter 12–27

Advanced Junos Service Provider Routing

Chapter 12–28 • BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Resources to Help You Learn More

The slide lists online resources available to learn more about Juniper Networks and technology. These resources include the
following sites:
• Pathfinder: An information experience hub that provides centralized product details.
• Content Explorer: Junos OS and ScreenOS software feature information to find the right software release and
hardware platform for your network.
• Feature Explorer: Technical documentation for Junos OS-based products by product, task, and software
release, and downloadable documentation PDFs.
• Learning Bytes: Concise tips and instructions on specific features and functions of Juniper technologies.
• Installation and configuration courses: Over 60 free Web-based training courses on product installation and
configuration (just choose eLearning under Delivery Modality).
• J-Net Forum: Training, certification, and career topics to discuss with your peers.
• Juniper Networks Certification Program: Complete details on the certification program, including tracks, exam
details, promotions, and how to get started.
• Technical courses: A complete list of instructor-led, hands-on courses and self-paced, eLearning courses.
• Translation tools: Several online translation tools to help simplify migration tasks.

www.juniper.net
Advanced Junos Service Provider Routing

www.juniper.net
 Acronym List
ABR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . area border router
ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Resolution Protocol
AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . autonomous system
ASBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . autonomous system boundary router
BFD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bidirectional Forwarding Detection
BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol
BGP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol version 4
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface
CLNP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connectionless Network Protocol
CLNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connectionless Network Service
CSNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . complete sequence number PDU
DIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . designated intermediate system
DoS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . denial-of-service
DR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .designated router
EGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . exterior gateway protocol
ES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . end system
ES-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . End System–to–Intermediate System
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface
IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Advisory Board
IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Internet Assigned Numbers Authority
IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . internal BGP
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Control Message Protocol
IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . interior gateway protocol
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IP version 4
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IP version 6
IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intermediate System
ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . International Organization for Standardization
ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet service provider
JNCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Juniper Networks Certification Program
LSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link-state advertisement
LSDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link-state database
LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .link-state PDU
MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Digest 5
MED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . multiple exit discriminator
MOSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Multicast Open Shortest Path First
NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network entity title
NLPID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network layer protocol identifier
NLRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network layer reachability information
NSSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . not-so-stubby area
OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Systems Interconnection
PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .protocol data unit
PFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Packet Forwarding Engine
PSNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . partial sequence number PDU
RIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Information Base
RID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . router ID
rpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . routing protocol daemon
SNPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .subnetwork point of attachment
SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .shortest path first
TED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . traffic engineering database
TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . type/length/value
ToS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . type of service
TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . time-to-live

www.juniper.net Acronym List • ACR–1

ACR–2 • Acronym List www.juniper.net