AJER-12.a Student Guide Volume 2

»¿´·¿à±¬®¿·²ò½±³ò¶±
»¿´·¿à±¬®¿·²ò½±³ò¶±
Advanced Junos Enterprise 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-AJER
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 Enterprise Routing Student Guide, Revision 12.a

Copyright © 2014 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.aMarch 2011
Revision 11.aApril 2012
Revision 12.aAugust 2014
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.1X46-D20.5. 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 5: BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Review of BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
BGP Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-21
Load Balancing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28
Path Selection and Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-38
Implementing BGP Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-57
Chapter 6: BGP Attributes and Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

Policy and BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
BGP Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10
Details and Manipulation of Common BGP Path Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . .6-14
BGP Attributes Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-48
Chapter 7: Enterprise Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

Enterprise BGP Core Network Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Enterprise External Network Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-27
Implementing Enterprise Routing Policies Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-50
Chapter 8: Introduction to Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

Overview of Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Multicast Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10
RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15
IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-27
Chapter 9: Multicast Routing Protocols and SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1

Overview of Multicast Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
PIM-SM Using the ASM Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
Implementing PIM-SM Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-43
PIM-SM Using the SSM Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-44
Implementing SSM Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-54
Chapter 10: Class of Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

CoS Components Review and Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
CoS Processing and CoS Defaults on the SRX Series Device . . . . . . . . . . . . . . . . . . . . . . . . 10-15
Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-30
Virtual Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-38
Monitoring with Resource Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-44
Implementing CoS Features in the Enterprise Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-53
Appendix A: BGP Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-1

Route Reflection Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3
Configuration and Routing Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
BGP Route Reflection Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-28
»¿´
»¿
¿´·¿à
¿à±
à±¬®
¬®¿·
¿·²²ò½±
²ò½±³
±³ò
³ ò ¶±
Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACR-1
www.juniper.net Contents iii

»¿´·¿à±¬®¿·²ò½±³ò¶±
iv Contents www.juniper.net
Course Overview
This three-day course is designed to provide students with the tools required for implementing, monitoring, and
troubleshooting Layer 3 components in an enterprise network. Detailed coverage of OSPF, BGP, class of service (CoS), and
multicast is strongly emphasized.
Through demonstrations and hands-on labs, students will gain experience configuring and monitoring the Junos operating
system and monitoring device and protocol operations. This course is based on Junos OS Release 12.1X46-D20.5.
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.
Describe OSPF area types and operations.
Configure various OSPF area types.
Summarize and restrict routes.
Identify scenarios that require routing policy or specific configuration options.
Use routing policy and specific configuration options to implement solutions for various scenarios.
Describe basic BGP operation and 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.
Describe common routing policies used in the enterprise environment.
Explain how attribute modifications affect routing decisions.
Implement a routing policy for inbound and outbound traffic using BGP.
Identify environments that may require a modified CoS implementation.
Describe the various CoS components and their respective functions.
Explain the CoS processing along with CoS defaults on SRX Series Services Gateways.
Describe situations when some CoS features are used in the enterprise.
Implement some CoS features in an enterprise environment.
Describe IP multicast traffic flow.
Identify the components of IP multicast.
Explain how IP multicast addressing works.
Describe the need for reverse path forwarding (RPF) in multicast.
Explain the role of Internet Group Management Protocol (IGMP) and describe the available IGMP versions.
Configure and monitor IGMP.
Identify common multicast routing protocols.
Describe rendezvous point (RP) discovery options.
Configure and monitor Physical Interface Module (PIM) sparse modes.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Configure and monitor RP discovery mechanisms.
www.juniper.net Course Overview v

Describe the basic requirements, benefits, and caveats of source-specific multicast (SSM).
List the address ranges used for SSM.
Illustrate the role of Internet Group Management Protocol version 3 (IGMPv3) and PIM sparse mode
(PIM-SM) in an SSM implementation.
Configure and monitor SSM.
Intended Audience
This course benefits individuals responsible for configuring and monitoring devices running the Junos OS.
Course Level
Advanced Junos Enterprise Routing is an advanced-level course.
Prerequisites
Students should have basic networking knowledge and an understanding of the Open Systems Interconnection (OSI)
model and the TCP/IP protocol suite. Students should also have working experience with basic routing principles.
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
Lab 1: Configuring and Monitoring OSPF
Chapter 3: OSPF Areas
Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization
Chapter 4: OSPF Case Studies and Solutions
Lab 3: Configuring and Monitoring Routing Policy and Advanced OSPF Options
Day 2
Chapter 5: BGP
Lab 4: Implementing BGP
Chapter 6: BGP Attributes and Policy
Lab 5: BGP Attributes
Chapter 7: Enterprise Routing Policies
Lab 6: Implementing Enterprise Routing Policies
Day 3
Chapter 8: Introduction to Multicast
Chapter 9: Multicast Routing Protocols and SSM
Lab 7: Implementing PIM-SM
Lab 8: Implementing SSM
Chapter 10: Class of Service
Lab 9: Implementing CoS Features in the Enterprise
Appendix A: BGP Route Reflection
Lab 10: BGP Route Reflection (Optional)
»¿´·¿à±¬®¿·²ò½±³ò¶±
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.
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.
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 variables value is Type set policy policy-name.
the users discretion or text where
ping 10.0.x.y
the variables 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 Enterprise Routing Student Guide was developed and tested using software
Release 12.1X46-D20.5. 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
Chapter 5: BGP
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Will Discuss:
Basic Border Gateway Protocol (BGP) operation;
Common BGP attributes;
The route selection process;
How to alter the route selection process; and
Configuring some advanced options for BGP peers.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Chapter 52 BGP www.juniper.net
Review of BGP
The slide lists the topics we will discuss. We discuss the highlighted topic first.
»¿´·¿à±¬®¿·²ò½±³ò¶±
www.juniper.net BGP Chapter 53
BGP Review
BGP is a routing protocol between autonomous systems (ASs). It is sometimes referred to as a path-vector routing protocol
because it uses an AS path as a vector to prevent inter-domain 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 virtual private
networks (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 interior gateway protocol (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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Usage
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 customers addresses to the customer.
Normally, a single-homed network uses addresses assigned by the provider from the providers 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. BGPs
policy controls provide the ability to optimize inbound and outbound traffic flows based on a networks 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 likely use portable addresses assigned directly by the regional address registry.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP 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 topology of the AS). BGP uses the loopback interfaces for stability reasonsthese
interfaces are always alive, unless the router itself dies. Because the IBGP connection typically exists between remotely
connected routers, there is a requirement for an IGP within the AS. BGPs TCP session is established using regular routing
tables.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 state: 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 state: 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,
listens for a connection initiated by the remote BGP peer, and changes its state to Active.
Active state: 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 systems BGP state remains in the Active state, you should check
physical connectivity as well as the configuration on both peers.
Continued on the next page.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Peering Sessions (contd.)
This list is a continuation of the various BGP neighbor states from the preceding page:
OpenSent state: 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 state: 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 state: 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 message: 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 message: BGP uses update messages to transport routing information between BGP peers. Depending
on the receiving devices routing policy, this routing information is either added to the routing table or ignored.
Keepalive message: 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 message: 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 taking into account its own outbound routing preferences, the inbound
routing preferences of the routes 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 As prefix.
»¿´·¿à±¬®¿·²ò½±³ò¶±
ISP As Network

The slide highlights a portion of ISP As 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 As 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 ASs 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Customer Bs 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, which 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 Bs
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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Customer B Becomes Multihomed

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 Bs 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 Bs 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 on the slide, Customer B now also receives two advertisements for ISP As 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 ASs. 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 systems router ID (RID) and the local AS number. Optionally, you
can configure the systems 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 peers loopback address. The
local-address is the local devices 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Authentication
All BGP protocol exchanges can be authenticated to guarantee that only trusted routing devices participate in the ASs
routing. By default, authentication is disabled. You can configure 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 packets 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 can include multiple
keys. Each key contains an identifier and a secret. The key is also configured with a unique start time and an end time.
To configure the authentication key, include the key-chain statement at the [edit security
authentication-key-chains] hierarchy level, and specify the key option to create a key chain consisting of several
authentication keys. You then reference this keychain name under the appropriate BGP level. In the example, the keychain is
configured at the group level.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Operations
The slide highlights the topic we discuss next.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 exists for each established BGP peer to store all routes received from that peer.
RIB-LOCAL 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 of the local routers routing table rules. For example,
if the router knows about a particular route through both Intermediate System-to-Intermediate System (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 or not.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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. (It is irrelevant
whether the two routers are directly connected.)
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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Hidden Routes
One 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. This is not always true. There are several reason why:
The route might be a martian route;
An import policy might exist that prevents the route from being installed;
The routes protocol next-hop might be unresolvable.
Unresolvable Next-Hop
The number one 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 the reason why routes
are hidden, issue the show route hidden extensive command.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 routers peers can reach the next hop of the
routes that router sends, as long as the BGP session remains established.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 attributes 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 peers 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.
Continued on next page.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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Load Balancing Options


Router ID and Peer ID Ignored

When you configure multipath on a BGP router, the selection algorithm ignores both the router ID 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 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 2R2 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 as to 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 (indicated by the asterisk). The other version of the
route is from the R3 router (10.222.29.2), and it is not marked as active.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 as active
while the routes from the R3 router are marked as 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 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, three routes are now using the 10.222.29.2
next hop, whereas just the 172.16.20.4/30 route remains with the 10.222.28.2 next hop. As more routes are announced
between the AS networks, the selection of the next hops becomes more evenly distributed.
Although not shown on the slide, 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 being used to forward user traffic.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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, it is advantageous to alter this default, one-hop, physical peering EBGP behavior. 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 neighbors physical interface address. In addition, you
can also specify a 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 routers 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 when wanted to help 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 as destined for the local Routing Engine (RE).
»¿´·¿à±¬®¿·²ò½±³ò¶±
Accepting Remote Next Hops

In the Junos OS, if the next hop received from the single-hop EBGP peer is recognized as not sharing a common subnet, then
the route is discarded. However, in some situations, you might have to configure a single-hop EBGP peer to accept a remote
next hop with which it does not share a common subnet. To work around this limitation, you would normally configure this
peer with the multihop option. When you configure a multihop session in this situation, all next-hop routes learned through
this EBGP peer are labeled as Indirect even when they do share a common subnet. This situation breaks multipath
functionality for routes that are recursively resolved over routes that include these next-hop addresses.
Configuring the accept-remote-nexthop statement allows next-hop routes that share a common subnet to be installed
as direct, restoring multipath functionality for routes that are resolved over these next-hop addresses. When you enable a
single-hop EBGP peer to accept a remote next-hop, you must also configure an import routing policy on the EBGP peer that
specifies the remote next-hop address. Note that you cannot configure both the multihop and
accept-remote-nexthop statements for the same EBGP peer.
Furthermore, you can use this option to force an IPv4 BGP peer to accept routes with an IP version 6 (IPv6) next hop.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Case Study: Accepting Remote Next Hops over a Single-Hop EBGP Session
In this example, AS 1 is advertising two routes toward AS 2, 2.2.2.0/24 and its own aggregate of 192.168.0.0/20. When you
enable a single-hop EBGP peer to accept a remote next hop, you must also configure an import routing policy on the EBGP
peer that specifies the remote next-hop address. The R3 router has a BGP import policy in place to set the next-hop of the
2.2.2.0/24 route to 192.168.3.21. By using the accept-remote-nexthop option, along with the import policy, you allow
R3 to accept the route and still enjoy the benefits of a multipath setup.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Case Study: Accepting Routes with IPv6 Next Hops over an IPv4 EBGP Peer
In this example, we show how you can use the accept-remote-nexthop option, along with a BGP import policy, to
accept routes from an IPv4 peer that have IPv6 next-hops. Normally, in this situation, the IPv6 routes would be discarded
entirely.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Routes with Multiple Next Hops

Within the context of a BGP network, both the multihop and multipath options 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.
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 traffic10.10.1.2 and 10.10.2.2. It has currently selected the 10.10.1.2 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 if 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.2 and the 10.10.2.2 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Path Selection and Configuration Options

»¿´·¿à±¬®¿·²ò½±³ò¶±
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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 route table, the route preference is evaluated. Recall 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]).
»¿´·¿à±¬®¿·²ò½±³ò¶±
Summary of BGP Active Route Selection (contd.)
The following list is a continuation of the steps in the BGP path selection process from the preceding page:
4. If any of the remaining routes are advertised from the same neighboring AS, the router checks the multiple exit
discriminator (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(s) 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(s) of the instance with the lowest Junos OS preference is used. Often, this means that BGP uses
the inet.3 version of the next hop, through an MPLS label-switched path.
b. Should the preference values in the inet.0 and the inet.3 routing tables tie, the physical next hop(s)
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(s) 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 router ID (usually the loopback IP address).
When comparing external routes from two distinct neighboring ASs, if the routes are equal up to the router ID
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 router ID, 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 ID.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 routers 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 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).
»¿´·¿à±¬®¿·²ò½±³ò¶±
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. Prior to Junos OS Release 7.0,
advertise-peer-as was the Junos default behavior.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Restart Capability Is Negotiated

When a BGP router supports graceful restart, it can restart its routing process without causing a topology change event in
the network. Thus, no routes are withdrawn or announced based on the restart event, which can avoid the network
converging on a new topology.
During the establishment of the peering session, the two routers negotiate the ability to support graceful restart. The restart
mechanism is only used when the feature is supported by both peers. When the local router restarts its routing process its
peer continues to forward traffic to it. In addition, the loss of keepalive messages from the local router does not cause the
peer to withdraw the active routes from the restarting router.
The restarting router signals its peers that it has restarted by setting the restart state bit in the capability announcement
within the open message. The signal alerts the peer to retain the restarting routers routes and not run the path selection
algorithm. In addition, the restarting router might also set the forwarding state bit in the capability announcement as well to
alert the peer that it might still forward user traffic through the restarting router.
Continued on next page.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Use End-of-RIB Markers
After the restarting router returns to service and the session is established again, the peers exchange their active routes with
each other. When the last route is sent, an end-of-RIB marker is advertised to inform the peer that the process is complete.
This marker is simply an update message with no withdrawn or advertised routes. The receipt of the end-of-RIB marker
allows each router to run the path selection algorithm and select new active routes, if necessary.
Configuration Options
The graceful restart capability within the Junos OS is controlled under the [edit routing-options] configuration
hierarchy. The following configuration enables the restart functionality:
routing-options {
graceful-restart;
}
The graceful-restart syntax is also a configuration hierarchy within BGP, which contains three options specific to the
operation within the protocol. Those options include the following:
disable: This option stops the local router from participating in any graceful restart function.
restart-time: This negotiable timer sets the amount of time that can elapse for the peering session to
reestablish. The default value for this timer is 120 seconds, and its range is between 1 and 600 seconds.
stale-routes-time: This timer specifies the amount of time that routes from the restarting peer can be
used before they are withdrawn. The default value for this timer is 300 seconds, and its range is between 1 and
600 seconds.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 either 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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, technically, is 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, it
is not a question of one AS 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.
In 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 edge router in AS 1000 that faces the Internet or other EBGP peers. 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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. Subsequent 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, there is nothing unusual about the AS path operation.
»¿´·¿à±¬®¿·²ò½±³ò¶±

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.
»¿´·¿à±¬®¿·²ò½±³ò¶±

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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
MED and IGP Metrics

The Junos OS allows you to configure a MED value for all BGP routes to an individual peer, peer group, or all peers. The
configuration statement uses the keyword metric-out and has several optional parameters.
To set the MED to a static numeric value, use the metric-out value statement. We can see this option, setting the MED
to 10, for the 192.168.2.2 peer.
You can set the MED to match the internal IGP metric to reach the IBGP peer that advertised the route. Use the
metric-out igp command to do this. As the IGP metric to this peer changes (up or down), the MED value associated with
these routes also changes. We can see this option on the 192.168.3.3 peer on the slide.
If the MED behavior of metric-out igp 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 will not increase the MED value. Use the metric-out minimum-igp command to do this. We can see this
option on the 192.168.4.4 peer on the slide.
Lastly, you can add MED values or subtract them in conjunction with both the igp and minimum-igp options. To alter the
MED in this fashion, use the metric-out igp offset command. We can see this option on the 192.168.5.5 peer on
the slide, which adds 5 to the MED based on the IGP metric. To subtract 5, use 5.
»¿´·¿à±¬®¿·²ò½±³ò¶±
MED Default Behavior

Within the Junos OS, the default action of BGP is to compare the MED values on routes from the same neighboring AS. This
process of grouping routes into the advertising AS is known as deterministic MED selection and is currently considered a
best practice in the Internet. To see the effect of the deterministic MED operation, consider the following three route
announcements. Each of the announcements was received on the local router in quick succession (within 1 second) in the
following order:
#1 AS Path:65001 MED:200 From EBGP peer
#2 AS Path:65002 MED:150 From IBGP peer IGP cost:5
Paths 1 and 3 were received from the same AS, so their MED values are compared. Path 3 has a better MED value, so path
1 is no longer considered. Path 3 is now compared against path 2. Both paths were received from IBGP peers, so the IGP
cost of path 2 makes it the active path for the local router.
Continued on next page.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Always Compare MED Values
The always-compare-med configuration statement allows you to override the default BGP behavior for MED evaluation.
When configured, BGP compares all routes to each other to determine the route with the smallest MED value, not just routes
from the same AS. BGP then selects the route with the lowest MED value as the active BGP path, regardless of the
neighboring AS the route came from.
Be careful when comparing MEDs from different AS networks. Some inherent danger exists when using the
always-compare-med configuration option to compare MEDs from more than one AS because every autonomous system
in the Internet can set its own good and bad values for MEDs. One AS might consider a MED of 50 as the best, whereas
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 (they are optional), which essentially sets the MED value to 0.
To see the effect of using the always-compare-med command, we again examine the following three route
following order:
The MED values of all three paths are compared against each other. Path 3 has a lower MED value then the other two paths,
so the local router installs Path 3 as the active path.
Emulate Cisco Default Behavior

The cisco-non-deterministic configuration statement allows you to emulate the default BGP MED behavior of a
Cisco Systems router. We do not recommend this configuration option for use in your network because it selects paths based
on the order they are received. It is provided as a method of interoperability to aid in the consistent, although potentially
incorrect, selection of routes in your network.
When configured, the local router compares the received routes in the order they arrived. This process does not account for
multiple paths through the same neighboring AS, which might lead to an incorrect route selection based on current best
practices.
You can see the effect of the cisco-non-deterministic command by once again examining the following three route
following order:
Path 3 was received the most recently, so it is compared against the previously received path, Path 2. The IGP cost of Path 2
is better than Path 3, so Path 3 is no longer considered by the algorithm. Path 2 is then compared against Path 1, which was
received first. Path 1 was received from an EBGP peer, whereas Path 2 was received from an IBGP peer. The EBGP-over-IBGP
preference rule causes the path selection algorithm to prefer Path 1, which is then installed as the active path for the local
router.
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Discussed:
Basic BGP operation;
Common BGP attributes;
The route selection process for BGP;
How to alter the route selection process; and
Configuring some advanced options for BGP peers.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Review Questions
1.
2.
3.
4.
5.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Implementing BGP Lab

The slide provides the objective for this lab.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 the 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.
The five valid ways to solve the BGP next-hop issue are: Next-hop self; IGP passive interfaces; Export direct routes into IGP; Static
routes; and IGP adjacency formed on inter-AS links to EBGP peers.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Chapter 6: BGP Attributes and Policy
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Will Discuss:
Routing policy with BGP;
Default BGP route movement through router;
BGP attributes and common BGP attributes in detail; and
Manipulation of BGP attributes.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Chapter 62 BGP Attributes and Policy www.juniper.net
Policy and BGP

»¿´·¿à±¬®¿·²ò½±³ò¶±
www.juniper.net BGP Attributes and Policy Chapter 63
BGP and Policy Dependency

BGP is a very policy-oriented protocol, in the sense that import and export policies largely determine BGP behavior.
BGP Attributes and Policy

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.
Changing BGP Attribute Values

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 on whether it is an EBGP route or an internal BGP (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 from established BGP peers to store all routes received from those peers. 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 routers routing table rules. For
example, if the router knows about a particular route through both OSPF and BGP, the OSPF route will be active in the local
routing table. This is because of the default Junos operating system protocol 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 autonomous system (AS) path or cluster-ID
sanity checks, as well as virtual private network (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 (if any are configured and applied) has filtered and manipulated the BGP attributes, the BGP
decision process chooses the best route to use. The Junos OS then installs that route into the IP routing table and moves the
route to the forwarding table. Note that even if no routing policies are configured, the default (and unseen) BGP import policy
is always applied.

Sample BGP Import Policy

The slide shows an example of 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 users 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
will contain two entries for the 192.168.14.0/24 prefix; this is 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
overall effects of this policy example are summarized here:
The 0.0.0.0/0:AS 1 route is rejected.
The 192.168.14.0/24 route from AS 3 is accepted but not preferred.
The 192.168.14.0/24 route from AS 1 is accepted and preferred.
All other AS 3 routes are accepted.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 routing policy can inject new routing information into the BGP routing process at this point.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Sample BGP Export Policy

The slide shows an example of 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 here:
The 0.0.0.0/0:AS 3 route is rejected and is not advertised.
The 192.168.27.0/24:AS 3 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/24 is sent to both AS 2 and AS 4.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Attributes
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Attributes
A BGP prefix and its set of attributes is defined as network layer reachability information (NLRI). BGP attributes are a group of
parameters that characterize a BGP NLRI. Thus a BGP prefix is defined by both its IP address and its set of BGP attributes.
Attributes set BGP apart from other protocols. They give a network operator the flexibility to design a robust network and the
tools to engineer a scalable routing policy.
Use in Routing Policy

Attributes, combined with the extensive features of Junos routing policy, provide the ability to build a scalable set of rules
that dictate whether a network wants to filter an incoming route or influence the path of a neighbor. Junos policy can match
and manipulate the more commonly used attributes, as we will see in upcoming slides.
BGP Attribute Categories

To ease the introduction of new BGP features, the BGP designers introduced a set of categories for router vendors to follow.
All BGP attributes must fall into one of the four categories listed on the slide. This framework allows for new BGP features like
32-bit ASs or multiprotocol extensions with IP version 6 (IPv6), MPLS, or multicast backwards compatibility without affecting
running networks. The next slide describes these categories in more detail.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Attribute Categories: Part 1---Well-Known Mandatory

An attribute set as well-known mandatory must be on every BGP update and passed along to all peers. If an update message
does not contain an attribute in this category, it causes the peering to reset and send a missing well-known attribute
message.
Well-Known Discretionary
An attribute set as well-known discretionary must be understood by every BGP speaker, but it does not have to be in every
update. If an update message contains an attribute in this category and is not understood, the connection is reset and an
unrecognized well-known attribute message is sent.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Attribute Categories: Part 2---Optional Transitive

An attribute set as optional transitive does not have to be understood by every BGP speaker, but it needs to be passed to all
peers. If an unrecognized attribute such as AS4_PATH is received, it can safely be ignored, but it MUST be sent to all
neighbors.
Optional Nontransitive
An attribute set as optional nontransitive does not have to be understood by every BGP speaker, and it must not be passed
to any peer. If an unrecognized attribute such as MP_REACH_NLRI is received it can safely be ignored, but it MUST NOT be
sent to all neighbors.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Details and Manipulation of Common BGP Path Attributes


Common BGP Route Attributes

The slide lists six common BGP attributes. In the following pages, we describe the uses of these attributes and the categories
in which they fall.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Attributes: Part 1---Mandatory Attribute

The origin attribute must be understood by all BGP speakers and must be included in every BGP update.
Originating Router
The router that first inserts the prefix into BGP adds the origin attribute. Origin is supposed to measure the credibility of the
source of the route, but it is mostly used by the Junos OS as a way to influence traffic flow.

BGP Attributes: Part 2---Internal, External, or Incomplete

The values available for the origin attribute include interior gateway protocol (IGP), exterior gateway protocol (EGP), or
incomplete. The IGP origin attribute is allocated to prefixes originated by an IGP process such as OSPF. The EGP origin
attribute is allocated for routes learned through the legacy EGP. The incomplete origin attribute is assigned to routes that do
not fall under this category.
IGP origin is better than EGP, and EGP is better than incomplete, in the route-selection process.
The Junos OS sets all routes to IGP by default when it first inserts them into BGP. This process can be manipulated by policy.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Using the Origin Attribute to Influence Incoming Traffic

In this example, AS 4 is using the default path to get to AS 1; this path is not modified by any of the ASs shown.
AS 1 wants to influence this path to force downstream ASs to come through AS 3. AS 1 crafts a policy to set the origin
attribute to Incomplete for all routes sent to AS 2. AS 4 now sees a more desirable path through AS 3 for prefixes originating
in AS 1. AS 4 should still use AS 2 in case of a failure through AS 3.
»¿´·¿à±¬®¿·²ò½±³ò¶±
AS Path: Part 1---Mandatory Attribute
The AS-path attribute must be understood by all BGP speakers and must be included in every BGP update.
AS Path Contents
The AS-path attribute contains the AS number of each system advertising the route, prepended to the beginning of the
attribute. This behavior can be modified with routing policy.
»¿´·¿à±¬®¿·²ò½±³ò¶±
AS Path: Part 2---Loop Prevention

AS path is also used for loop prevention. If the AS number of a router receiving an advertisement is included in the AS path,
the router drops this prefix. This behavior can be manipulated with the use of as-override and loops options in the Junos
OS, which are used mostly in MPLS-VPN environments.
Manipulates Route Selection

AS path is also used as a tiebreaker in the route-selection algorithm. The shorter AS path is installed as an active route
before a longer AS path is installed. This process can be manipulated with policy.
Regex Support
The Junos OS supports regex operators, which allows for flexibility when using matching conditions with routing policy.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Using AS Path to Influence Incoming Traffic

As with our origin example, we will use AS-path manipulation to influence traffic into AS 1.
AS 4 currently uses an arbitrary path to get to AS 1.
AS 1 crafts a policy to set the AS-path attribute to prepend the AS twice with AS 1 for all routes sent to AS 2. AS 4 now sees a
more desirable path through AS 3 for prefixes originating in AS 1. AS 4 should still use AS 2 in case of a failure through AS 3.
»¿´·¿à±¬®¿·²ò½±³ò¶±
AS Path Regular Expressions: Part 1

Unlike other vendor implementations, the entire AS number signifies a term and not individual numbers in the AS path. The
simple dot regex character (.) matches an entire AS number instead of just one number in the AS. This is a very important
concept as you implement regular expressions into routing policy.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Regular Expression Operators: Part 2

The slide lists the regex operators used in AS path matching for policy.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Regular Expression Examples

As shown in the slide, these examples further emphasize how an entire AS number represents one regex character. The
examples also point out the flexibility regular expression matching has on crafting the desired routing policy.
»¿´·¿à±¬®¿·²ò½±³ò¶±
AS Path Regular Expression Example: Part 1

In this example, we use regex AS path matching to influence outbound traffic.
AS 15 is advertising 69.3.176.0/20 to all peers. AS 1 is receiving the route directly from AS 2, because of the shorter AS
path, AS 1 is using AS 2 to get to AS 15.
The administrators of AS 1 have requested that we start to use AS 3 to get to AS 15 because of unspecified reasons.
Because of its powerful policy flexibility, BGP is the perfect protocol for such a request.
»¿´·¿à±¬®¿·²ò½±³ò¶±

The route, from the perspective of AS 1, chooses AS 2 because of AS path length.
Regex Matching
We use a regular expression match for an as-path named REGEX-TEST. AS 1 needs to match an AS beginning with 3
and ending with 15, with anything in between.
Using the regex operators available, the matching criteria becomes ^3 .* 15$ .
Using a policy named MATCH-AS, term 1 matches an as-path named REGEX-TEST and raises the local preference of
the route, making it more desirable. (The local-preference attribute will be covered in subsequent slides.)
By using local preference, we force the router to choose the route before it takes AS path into consideration.
»¿´·¿à±¬®¿·²ò½±³ò¶±

After applying the MATCH-AS policy as an import policy on the EBGP neighbors, AS 3 becomes the active path toward AS 15.
Because the policy matches only on routes originated from AS 15 and coming from AS 3, this policy should not affect any
other routes.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Mandatory Attribute
The next-hop attribute must be understood by all BGP speakers and must be included in every BGP update.
Next Hop Reachability

A BGP speaker marks a prefix unusable if the BGP next-hop IP is not accessible. The router will perform a recursive IP route
lookup for the address in the BGP next-hop attribute. If the BGP next-hop IP is not found in the local routing table, the BGP
route is not installed into the routing table.
Default Behavior
The BGP next hop is only changed by default when it is sent across EBGP sessions. In this case, the BGP next hop is set to
the IP address of the neighbor that sent the route. For IBGP sessions, if the route is originated from an EBGP peer, the BGP
next hop remains unchanged.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Next Hop Example: Part 1

As mentioned in the previous slide, a BGP next hop is not changed on a route learned from an EBGP neighbor if it is sent to
an IBGP neighbor. In the example, R1 is learning 8.3.99.0/24 from R3 in AS 2 and sending the route to R2. Because R2 does
not have a route in the route table for the BGP next-hop 20.1.1.2 destination, it marks this route as hidden.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Next Hop Example: Part 2

Multiple ways exist to fix this problem. One very popular approach is to use policy to change the next hop to the IBGP router
receiving the route (in this case R1). Another way is to use the IGP to introduce the BGP next-hop route into the AS, as in the
example on the slide.
R1 adds the interface facing R3 into the IGP (OSPF in this case) as passive, thus avoiding any advertisement of IGP hello
messages toward the EBGP peer.
R2 now has the route to the 20.1.1.2 BGP next-hop destination.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Optional Nontransitive
Multiple exit discriminator (MED) is an optional nontransitive attribute; thus it does not need to be understood by any BGP
speaker. In the case that it is not understood, it is not sent to any peers.
Stays in the AS
MED is never passed across an AS. If a BGP router receives a route from an EBGP peer with a particular MED value, it does
not pass this MED value to any EBGP neighbors, but it does pass this MED value to all IBGP neighbors.
Comparison Rules
By default, a Juniper BGP router only compares MED values on routes coming from the same AS. This behavior can be
changed by configuring path-selection always-compare-med or path-selection
cisco-non-deterministic BGP commands.
Influence of incoming traffic

The MED value can, however, be set by the EBGP speaker on an advertisement to an EBGP neighbor. Thus it can influence
which path the neighboring AS will take to reach it.
The lowest value is preferred, and by default the value is based on the IGP metric.
»¿´·¿à±¬®¿·²ò½±³ò¶±
MED Example: Part 1

In this example, R1 and R2 receive 69.3.184.0/21 from R3 through OSPF. The metric on each route is based on the IGP
interface cost to the destination. R1 has a 10 Mbps link and its metric to reach 69.3.184.0/21 is 10. R2 has a 100 Mbps
link and its metric to reach 69.3.184.0/21 is 1.
»¿´·¿à±¬®¿·²ò½±³ò¶±
MED Example: Part 2

By default, MED is based on the IGP metric. R4 sees the MED value based on the internal IGP metric value of AS 1. The R2
path is preferred on R4 because R2 has the better metric to the destination.
»¿´·¿à±¬®¿·²ò½±³ò¶±
MED Example: Part 3

The Junos OS allows the MED value to be changed with policy. The metric (MED) value is changed to 100 on R2 in our
example and applied as export to the EBGP peers.
R4, in turn, receives a better metric from R1 now and prefers this path to AS 1.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Well-Known Discretionary
Local preference is a well-known discretionary attribute. Local preference must be understood by all BGP routers, but is not
required to be present on every BGP update.
Restricted to the AS
Local preference is only used within an AS. The value is reset to the default value on an EBGP session, and maintains its
value in an IBGP session unless it is manipulated by policy.
The Higher the Better

Unlike MED, the higher the local-preference value the better. The default local-preference value is 100. It is a 32-bit field;
therefore, the possible range is 0 to 4,294,967,295.
First Tiebreaker
Local preference is the first tiebreaker for route selection, so the router looks at local preference before any other attributes
when choosing a route. This fact, and the fact that local preference is sent to all IBGP peers, makes it a suitable tool in
choosing an exit point.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Local Preference Example: Part 1

In this example, R1 and R2 are advertising 8.8.8.0/24 learned from AS 2 to their IBGP neighbors, with the default settings.
Thus R3 chooses the path with the lowest RID, all other things being equal.
»¿´·¿à±¬®¿·²ò½±³ò¶±

Local-preference value can be changed directly under the [edit protocols bgp] hierarchy. This process can also be
done with routing policy. In our example, we use a policy named local-pref to change the local-preference value to 50
for outgoing advertisements. This policy is applied as an export policy to the rest of the IBGP peers.
You can also configure local preference directly on a neighbor, as shown in the following example:
[edit]
user@R1# show protocols bgp group IBGP-2
group IBGP-2 {
type internal;
neighbor 10.10.10.1 {
local-preference 80;
»¿´·¿à±¬®¿·²ò½±³ò¶±

After this change is committed on R1, R3 now prefers the path toward R2 that has the default value of 100.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Community: Part 1---Optional Transitive

The community attribute is not required to be understood or used by a BGP speaker, but it MUST be sent to ALL peers.
Aid to Administrative Policy

One of the main roles for the community attribute is to tag a route or group of routes. A network operator then has the option
to group common routes with a community tag, making the administrative routing policy more efficient and scalable.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Community: Part 2--Community Format

The community attribute is encoded as a 32-bit value, where the first 16 bits represent an AS number and the remaining 16
bits represent an arbitrary number defined locally.
Well-Known Communities
RFC 1997 defines three community values that are regarded to be well known and should be understood by all BGP
speakers. This makes it easier to implement routing policy in multivendor networks.
The No-Export well-known community allows routes to be advertised to neighboring ASs, but those ASs are prohibited from
sending it further upstream.
The No-Advertise well-known community allows routes to be advertised to immediate neighbors, but those neighbors are
prohibited from sending the routes to any peers.
The No-Export-Subconfed well-known community is used in networks that use BGP confederations. It allows routes to be
advertised to sub-confederation ASs but those routers are prohibited it from sending it further.

Community Regular Expressions

Unlike AS number regular expression matches, one number in a community signifies a term and not the entire community
number. The simple dot regex character (.) matches one character.
The slide lists the regex operators used in AS path matching for policy.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Regular Expression Examples

The slide examples point out the possibilities regular expression matching has on crafting a desired routing policy.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Community Example: Part 1

In the example on the slide, AS 1 wants to prohibit advertisement of the 10.0.0.0/8 private network outside of the AS. We do
not want to create any complex policies throughout the network to accomplish this simple task. The No-Export well-known
community is a perfect candidate for this task.
»¿´·¿à±¬®¿·²ò½±³ò¶±

We create a policy on R3 to tag the 10.0.0.0/8 prefix with the no-export well-known community.
The policy is applied as an export policy to all our IBGP peers.
»¿´·¿à±¬®¿·²ò½±³ò¶±

After the policy is applied, R1 and R2 learn the route with the no-export community.
R1 and R2 honor the community and do not advertise this route to their neighboring AS. As we have shown, this can be
accomplished without the need for complex policies.
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Discussed:
Routing policy with BGP;
Default BGP route movement through router;
BGP attributes and common BGP attributes in detail; and
Manipulation of BGP attributes.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Review Questions
1.
2.
3.
4.
5.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Attributes Lab

»¿´·¿à±¬®¿·²ò½±³ò¶±
1.
Import policy is enforced between the RIB-IN and RIB-LOCAL tables.
2.
Export policy is only enforced on active routes.
3.
The three BGP attributes that must be in every update are origin, AS-path, and next-hop.
4.
The ^ symbol denotes the beginning of an AS path.
5.
The next-hop attribute is only modified when it is advertised across an EBGP session.
»¿´·¿à±¬®¿·²ò½±³ò¶±
»¿´·¿à±¬®¿·²ò½±³ò¶±
Chapter 7: Enterprise Routing Policies
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Will Discuss:
BGP in the enterprise network for internal connectivity;
Common Internet service provider (ISP) policies that determine policy design; and
Three common routing policies used for external connectivity in the enterprise environment.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Chapter 72 Enterprise Routing Policies www.juniper.net
Enterprise BGP Core Network Design

»¿´·¿à±¬®¿·²ò½±³ò¶±
www.juniper.net Enterprise Routing Policies Chapter 73
BGP Strengths
Routing Policy Control: BGP cannot simply be viewed as just a routing protocol, but as a policy definition device. One of the
BGP designers intentions is to give flexibility in designing routing policy. This approach is in contrast to interior gateway
protocols (IGPs), where the intent is to provide reachability and fast reconvergence.
Diverse Administrative Control: BGP allows the configuration of autonomous systems (ASs) to scope network boundaries.
The ability to define network boundaries with ASs allows a more flexible division of administrative duties to network
personnel.
Handling Large Prefix Counts: The nature of BGP as a distance vector protocol allows it to scale well in environments with
large routing tables including the internet routing table. In comparison, most of the IGPs requirements of fast convergence
and link state characteristics limit the amount of routes that can be handled.
BGP Weaknesses
Increased Convergence Time: The strengths that BGP has do come with a price. Fast convergence is not one of the things
BGP is known for. BGP timers can be tuned or network change notifications can be deferred to a protocol like Bidirectional
Forwarding Detection protocol (BFD), but convergence is more efficient with an IGP.
Increased Complexity: An important factor to point out is that BGP is not intended to replace an IGP completely. It is rather to
act in complimentary fashion with an IGP. With this added layer, an enterprise will need more knowledgeable network
personnel.
»¿´·¿à±¬®¿·²ò½±³ò¶±
When Should BGP Be Used in the Enterprise Core?

When looking at a simple network as shown in the diagram, an IGP like OSPF should be sufficient in meeting the needs of
the network.
However, a network engineer can confuse justification for BGP with a poorly designed network. For example, if the network is
growing in the number of individual sites an engineer might prematurely introduce BGP to scope out each site into their own
ASs. This correctly scopes administration duties, but it also increases the complexity of the network greatly, to the point that
introduction of BGP is going to do more harm than good.
In a common enterprise network, an IGP like OSPF should be more than sufficient and the decision to introduce BGP or build
an initial network with BGP should be a carefully vetted process with all the pros and cons discussed.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Using BGP in the Enterprise

Different enterprises have different needs. As shown in the diagram, the complexity of an enterprise network can be quite
daunting for any network engineer. In the network shown, not only is outside connectivity needed for the network;
connectivity to data center resources, a demilitarized zone (DMZ), and remote sites connected with various WAN
technologies are needed as well. Often, connectivity to internal resources such as voice application servers, storage servers,
collaboration applications, and connections to different branch sites is more important than internet connectivity.
BGP complemented with OSPF can meet the needs of a complex network.
Using routing policy to engineer traffic, by utilizing the most optimized network path, can aid in the performance of real-time
applications like voice and video.
By setting up ASs, network engineers can delegate administration to the appropriate individuals.
BGP can be used to haul the bulk of prefixes and use an IGP like OSPF for core connectivity between routers. This approach
allows the network to take advantage of BGP to handle large prefix counts and use the IGP for fast convergence in case of
any network issues.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP in the Enterprise Case Study

This case study demonstrates the advantages and flexibility BGP gives an enterprise network. It is better to implement BGP
sooner than later as long as the solution is elegant and fits your needs. This approach saves a lot of headaches with
migration when the network is more sensitive to changes.
Enterprise, Inc. Goals

The following goals are accomplished by implementing BGP for this network:
Better handling of large prefix counts;
Easier summarization of prefixes;
Scalability for easier introduction of complex routing needs;
Routing policy flexibility for traffic engineering; and
Additional administrative boundaries with private ASs.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Enterprise, Inc. Initial Topology

As shown in the slide, this network has characteristics that make it a good candidate for implementing BGP.
Based on the diagram, it appears that a solid IP numbering scheme exists for the remote sites, allowing for sequential
summarization of common network subnets. Two slow links are connecting the R1 and R2 routers and the R3 and R4
routers, which will benefit from some routing policy to keep traffic off those links. Two multihomed sites are connected to the
core: Site B is connected with two point-to-point WAN links, and Site A with a generic routing encapsulation (GRE) tunnel
through the Internet and an MPLS WAN connection, increasing the complexity of the network
»¿´·¿à±¬®¿·²ò½±³ò¶±
.
Enterprise, Inc. Goals

The following goals are met with this network design:
Advertise the minimum amount of prefixes from the remote sites to Site A and Site B;
Keep traffic off the 20 Mbps links between R1/R2 and between R3/R4, but still use these in case of outage;
Only use the GRE tunnel between Site A and R1 in case there are problems with the MPLS provider; and
Scope Site A and Site B to their own AS for ease of administration.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Enterprise, Inc. Topology with Solutions

Highlights from the proposed topology include the following:
Created a full internal BGP (IBGP) mesh within the enterprise core, complemented with OSPF for fast
convergence and loopback peering;
Using private ASs, created EBGP peering to all of the remote sites including the MPLS WAN and GRE links; a
range of 64512 through 65534 can be used for private purposes. Most MPLS WAN providers only give an
option of BGP as the provider edge (PE) to customer edge (CE) protocol.
The individual goal solutions are laid out in detail in the next few slides.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Case Study: Prefix CountPart 1

Currently, Site A and Site B are receiving approximately 11,000 routes from each peering to the core.
One of the goals of this design is to reduce the number of prefixes advertised to each site.
»¿´·¿à±¬®¿·²ò½±³ò¶±

An aggregate route is created that overlaps the routes from remote Site A and remote Site B on both R3 and R4 routers that
peer with Site A and Site B.
A new routing policy is created with a term matching the newly created aggregate route and accept for the action. A second
term is created rejecting all other advertisements. The policy is applied to the EBGP neighbors.
»¿´·¿à±¬®¿·²ò½±³ò¶±

After the policy is applied on R3 and R4, Site A (which is connected to the MPLS cloud, which in turn connects to R3) only
receives two prefixes. These prefixes include the 10.0.0.0/8 route, which represents the remote sites.
»¿´·¿à±¬®¿·²ò½±³ò¶±

Site B receives one prefix from R3 and R4 after the policy is applied on those routers.
We have now accomplished our goal of reducing the prefix count to Site A and Site B.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Case Study: Traffic EngineeringPart 1

A majority of traffic between sites of Enterprise, Inc. is voice and video. This type of traffic is very sensitive to high latency and
packet loss. To reduce the possibility of degraded performance of real-time traffic, one of the goals for Enterprise, Inc. is to
reduce the amount of traffic that traverses the low bandwidth and high latency links between R1 to R2 and R3 to R4. These
links can still be used in case of failure.
The previous goal was to reduce the number of prefixes Site A and Site B. However, a side effect of this task is that now Site
B has lost some visibility of the network.
All things equal, Site B is going to choose the path to 10.0.0.0/8 based on which peer came up first.
»¿´·¿à±¬®¿·²ò½±³ò¶±

As shown on the slide, Site B chooses the path toward R4 for destinations to 10.0.0.0/8.
This action causes Site B to send traffic destined for 10.128.0.0/9 to R4 using the slow link between R3 and R4. The
10.128.0.0/9 belongs to remote Sites A, which is closer to R3.
»¿´·¿à±¬®¿·²ò½±³ò¶±

The solution is to create more specific aggregates from each location. R3, which is closer to the remote Sites A, adds the
aggregate route 10.128.0.0/9 to the already configured policy EXPORT-EBGP. R4, which is closer to the remote Sites B,
adds the aggregate 10.0.0.0/9 to the same policy.
»¿´·¿à±¬®¿·²ò½±³ò¶±

R3 now advertises the more specific path to the remote Sites A to Site B. Site B uses a more optimal path to get to the
remote sites, avoiding the use of the 20 Mbps link.


For the return traffic from remote Sites A, the optimal path is chosen by default because of the better IGP metric.
To avoid incomplete visibility of the network, it is best to keep aggregation of internal destinations to the minimum for the
core routers.


In case of failure, Site B still has a path to the remote sites because R3 and R4 are still advertising the least-specific
aggregate route 10.0.0.0/8.
This design meets the goal of using optimal paths in the core and using slower links in case of outage.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Case Study: Backup Link Part 1

A common goal for any enterprise is to have 100% uptime for any critical site. One way to accomplish this goal is to provide a
backup link. A backup link is set up in the form of a GRE tunnel from Site A to R1.
The goal of this task is to have the backup link idle for traffic toward the remote sites and only activate the link in case of an
outage in the MPLS WAN connection of Site A.
An EBGP connection between Site A and R1 is set up to accomplish this goal.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Case Study: Backup Link Part 2

An aggregate 10.0.0.0/8 route is created in R1. A policy is created and the first term matches the aggregate; the action is to
accept and expand the last AS 5 times. A second term is created to reject everything else to prevent R1 from advertising
more specific routes.
The policy is applied to the EBGP neighbor configuration on R1 to Site A.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Case Study: Backup LinkPart 3

Site A shows the aggregate route as active, but not preferred, because of the longer AS path.
The current path to the remote sites is through the MPLS WAN, as we intended.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Case Study: Backup LinkPart 4

By mimicking a failure in the MPLS WAN, Site A activates the path toward R1 and starts using it to reach destinations located
at the remote sites. This action accomplishes the goal of using the tunnel in case of failure.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Case Study: Administration Scope

Because of unique personnel in various remote sites at Enterprise, Inc., the engineering department needs a way to scope
administrative duties depending on which geographical location the personnel are in.
By choosing BGP, Enterprise, Inc. has made it easier to accomplish this goal by providing administrative boundaries in the
form of ASs per remote site.
As shown in the slide, Site A and Site B are divided into their own unique, private ASs.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Case Study Summary

To recap, all of our goals were accomplished using BGP. Keep in mind that most of the tasks in this case study can be
accomplished by using various IGP techniques. IGPs have the ability to summarize, optimize routing with link metric and
scope network boundaries in various ways. However as mentioned previously, IGPs were primarily designed as tools to
provide reachability and fast convergence, in contrast to BGP, which was designed primarily as a tool for routing policy. Thus
by using BGP for the solutions in this case study, we were able to provide the network with an elegant and scalable design for
any future growth.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Enterprise External Network Deployment

»¿´·¿à±¬®¿·²ò½±³ò¶±
Common Enterprise Routing Policies

Many different possibilities exist for inbound and outbound routing policies, but most enterprise routing policies fall into
roughly three categories: topology driven, primary/secondary, and load-shared per prefix. We explain these categories in the
following pages.
Organizations choose routing policies to balance many interests, among them performance, reliability, and cost. Those
decisions are generally policy decisions made by managers. It is the job of the network engineers to choose the correct
routing policies to implement those policy decisions.
Different inbound and outbound routing policies can be used to fill the needs of the organization. For example, you can use
a topology-driven outbound routing policy while using a load-shared per-prefix inbound routing policy.
Note that you can only influencebut not fully controlthe way inbound traffic reaches your AS. Because BGP is a
policy-driven protocol and each AS controls its own outbound routing policy, you can again only influencebut not control
the routing decisions other ASs make. To produce the desired result, you must think about your announcements from the
perspective of other ASs (both ISPs and other enterprises). You must think about the likely ways the path attributes you
attach to your announcements will affect their routing decisions.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Common Enterprise Topologies

Enterprise networks that have only a single ISP connected to a single router generally do not need to worry too much about
routing policy. In fact, they really do not even need to run BGP with the provider. Other enterprise networks can be
summarized by one of the topologies shown on the slide. The effect of outbound routing policies might differ slightly
depending on which of the topologies you have. In the following slides, we look at each of the routing policies, describe the
effect of that routing policy on the topologies shown on the slide, and discuss how to implement it in the topologies.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Local Preference
Many practices are fairly common among ISPs. Understanding these practices can affect the way we implement routing
policies. Among these practices is the use of local preference to prefer certain routes over others. Usually, ISPs assign
default local preferences such that customer routes are preferred over routes received from peers (or upstream ISPs). ISPs
also usually accept certain communities from customers that cause them to set a different local preference. In general,
several options are available between the default customer and peer values, and often, at least one option is available that
is less than the default peer value. We can use these communities to further influence inbound traffic flow.
Prefix Length
Most ISPs do not accept routes that are more specific (longer) than a /24 from either customers or peers. Some ISPs accept
longer routes from customers, but they do not announce them to other customers or peers.
Filter Customer Routes by Prefix, AS Path, or Both

An almost universal practice among ISPs is to apply rather strict import filters to their BGP sessions with customers. Most
filters match on prefixes, whereas some filters match the AS Path (either in addition to, or instead of, a prefix match).
Those filters that match on prefixes can perform an exact match, an orlonger match, or an upto match. Some ISPs
provide automated mechanisms for updating these filters, whereas others rely on a manual process. You should understand
your ISPs filtering policies because they might impact the way you implement a routing policy.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Topology-Driven Routing Policies

In these routing policies, all routes are accepted without attribute modification. Thus, the BGP path selection algorithm looks
primarily at topological factors (such as AS path, multiple exit discriminator (MED), and the IGP metric) to determine the best
route to send the traffic. This model should generally produce the best performance, but it is only appropriate when you have
no preference about the way traffic enters or exits your AS.
Path Selection
In this model, the router first tries to determine the best path for traffic to reach its destination. The router first looks at the
AS Path length, which should give some indication of the total distance to the destination. If that length is tied between
routers from the same next-hop AS, it compares MEDs to determine which path the next AS wants it to use. (Hopefully, the
next AS is setting its MEDs to accurately reflect internal metrics.)
If the router determines that two or more BGP-received routes are still tied in these values, the router must break the tie
between these equally well-preferred routes. Once the router reaches this point in the decision algorithm, it simply tries to
choose the closest exit. It does this by preferring EBGP-received paths over IBGP-received paths. If no EBGP-received paths
exist, the router next tries to break the tie by choosing the IBGP path with the closest exit, as determined by IGP metrics.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Outbound Routing Policy

The slide shows an example of a topology-driven outbound routing policy. We assume that Nails, Inc. is receiving a full
Internet routing table from both providers.
In this example, AS 65501 prefers to send traffic to the topologically closest exit. Note that the routers in AS 65501 make
consistent exit decisions, causing R1 to send all traffic destined for Saws Corp. to R2, and R2 to send all traffic destined to
Hammers, Inc. through R1. Thus, outbound traffic might flow between R1 and R2, which might raise the bandwidth
requirements for this connection.
Also, note that the quality of the ISPs involved is important in this model. If R1 is connected to a tier 2 or 3 ISP while R2 is
connected to a tier 1 ISP, the likelihood is that many paths will be shorter through the ISP connected to R2. This scenario
would result in most traffic exiting the network through R2, essentially creating a primary/secondary configuration.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Inbound Routing Policy

This slide shows a topology-driven inbound routing policy from Nails, Inc.s perspective. Nails, Inc. advertises its prefixes
without any modification. Assuming the other networks shown are using a topology-driven outbound routing policy, the result
is shown on the slide.
Remember that you cannot control inbound routing, only influence it. Therefore, note that Saws Corp. could decide to send
its traffic through ISP A, which would result in all the traffic from both Hammers, Inc. and Saws Corp. arriving through R1.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Path Selection
If two paths to a destination have equal AS Path lengths and MED values (if the next AS is the same), the router simply tries
to choose the closest exit from the AS. Once it gets to this point, one of the differences between having multiple border
routers and a single border router becomes clear.
In the case of multiple border routers, each border router prefers one of the EBGP-received announcements over any of the
IBGP-received announcements. Thus, traffic bound for Drills, Inc. that reaches R1 is sent through ISP B, and traffic bound for
Drills, Inc. that reaches R2 is sent through ISP C. This scenario should result in load sharing, depending on the IGP
configuration.
In the case of a single border router, the router prefers the oldest EBGP-received announcement, which results in the router
preferring the most stable path to a destination. However, in periods of great stability (or immediately following a period of
high instability, such as a router reboot), it also generally results in the router preferring a single connection for most routes
with an equal AS path. This behavior results in somewhat imbalanced load sharing; however, this behavior should result in
better performance over time (because it favors stable paths).
»¿´·¿à±¬®¿·²ò½±³ò¶±
Primary/Secondary Variations
A true primary/secondary routing policy has a single preferred ISP, over which all traffic flows while the connection to that
ISP is up. Only when that connection is down does traffic flow over the secondary connection.
Variations on the primary/secondary routing policy do exist that allow certain traffic to flow over the secondary link, even
when the primary link is up. For example, you might want to allow traffic to or from customers of the secondary ISP to use
that connection even when the connection to the primary ISP is functioning normally.
Assured Redundancy
The main benefit to a primary/secondary routing policy is to provide reliability through redundancy. To be assured of true
redundancy, you must always have enough bandwidth available to the secondary provider to fully accept the load of the
connection(s) to the primary provider. The easiest way to guarantee this availability is to use connections of the same
bandwidth to both the primary and secondary providers and to use a strict primary/secondary routing policy. This method
ensures that you always have enough bandwidth in place on the secondary link to fully accept the load on the primary link.
Implementing a strict primary/secondary model can also allow you to reduce the costs of the secondary connection. It is
usually possible to negotiate a lower monthly fixed fee for a secondary circuit in return for accepting a usage-based bill.
Provided that there are not extended outages to the primary circuit, this fixed fee will likely result in a lower cost for the
secondary circuit than if you purchased two circuits and used them both.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Local Preference
The best way to enforce a primary/secondary outbound routing policy is by modifying the local-preference path attribute. The
router always selects the route with the highest local preference (regardless of AS path) as its preferred route to a
destination. Therefore, setting a higher local preference on the routes using the primary path and a lower local preference on
the routes using the secondary path should cause the router to always prefer the routes using the primary path. However,
this setting does not necessarily mean that all traffic will flow through the primary path.
Single Versus Multiple Border Routers

The primary/secondary configuration is the same whether you have a single border router or multiple border routers. The
routers communicate local-preference values between them, resulting in a consistent routing decision.
»¿´·¿à±¬®¿·²ò½±³ò¶±
More Specific Routes

ISPs typically have slightly different sets of routes in their routing tables. For a variety of reasons (prefix length filtering,
aggregation, and so forth), it is common for each provider to have a handful (or more!) of more-specific routes that other
providers do not have. In the example on the slide, ISP B is sending both a /23 prefix as well as the two more specific /24
prefixes to AS 65501. ISP C is only receiving a /23 aggregate prefix from ISP B and, therefore, is only sending the /23 prefix
to AS 65501.
Because AS 65501 is configured to assign a higher local preference to routes received from ISP C, both R1 and R2 prefer the
announcement for the /23 prefix that is being received from ISP C. However, because AS 65501 only has one
announcement to each of the /24 prefixes, it prefers that announcement and installs routes to send traffic for the two /24
prefixes to ISP B, which effectively results in ISP B being the primary provider for the /23 prefix.
To avoid this situation and to enforce a strict primary/secondary outbound routing policy, it is best to only receive a default
route from each provider. Receiving the default route from BGP (instead of configuring a static route) causes the route to
disappear when the link to your ISP becomes unusable. Additionally, this configuration matches your intention of always
following the path to the primary ISP when it is available.
If you choose to receive only default routes, you lose a small amount of reliability. If AS 65501 receives full routes and
instability exists within ISP Cs network, ISP C might stop advertising some specific routes, at which point AS 65501 would
begin using the path through ISP B (provided it is not experiencing the same instability). However, in this scenario, there is no
guarantee that ISP C will withdraw any announcements. (Examples exist in which ISPs have continued to advertise full
Internet routing tables.) As usual, this scenario comes down to a trade-off between reliability and cost: the cost of sending
small amounts of traffic to the secondary ISP versus the small reliability gain.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Loose Primary/Secondary
In a loose primary/secondary routing policy, you make one ISP your primary ISP and another your secondary ISP, but you
want to allow traffic to select prefixes to use your secondary ISP even in normal operations.
To implement a loose primary/secondary outbound routing policy, you accept a default route from both providers, but you
also accept announcements for some specific prefixes from your secondary ISP. Because you do not receive
announcements for those specific prefixes from your primary ISP, your routers use the announcements you receive for these
prefixes from your secondary ISP.
In the example on the slide, AS 65501 is receiving the specific routes for some of ISP Bs customers. AS 65501 is preferring
to send traffic to these prefixes through ISP B.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Sample Configuration: Strict Primary/Secondary Outbound

The slide provides a sample configuration to enforce a strict primary/secondary relationship. The routing policies set the
local preference appropriately and accept only a default route.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Sample Configuration: Loose Primary/Secondary Outbound

The configuration example shown on the slide is the same as the strict primary/secondary example, except that we added
the isp-b-customers policy to the import policy chain on the secondary-isp group. The isp-b-customers policy
matches on a community that our provider adds to the path attributes of all BGP announcements originated by their
customers.
Because we allow the more-specific routes to be received from the secondary ISP only, the routers choose the secondary ISP
as the best path for those prefixes. Because these routes are more specific than the default route that is received from the
primary ISP, the router follows these routes to the secondary ISP when it receives them. If the secondary ISP fails, it follows
the default route received from the primary ISP.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Local Preference and AS Path Prepending

To ensure the correct operation of a primary/secondary inbound routing policy, it must be configured correctly. In particular,
you must pay attention to normal operation, failure conditions, and failback (restoration from failure) conditions. To ensure
correct primary/secondary inbound routing policy operation, you must often set the local preference within the providers
network through the use of communities and also prepend the AS path of the announcements sent over the secondary path.
Single Versus Multiple Border Routers

Where a single primary and a single secondary path exist, you configure the primary/secondary routing policy in the same
way whether there are one or two border routers. When multiple, equally preferred primary and secondary paths exist, this
routing policy takes on a mixture of the primary/secondary and topology-driven routing policies. Because each situation is
different, guidance with regard to the policy design of every combination is beyond the scope of this chapter. However, we
can describe a way to approach the problem. The following slides, which describe the operation of the primary/secondary
inbound routing policy, illustrate how to think about these design scenarios.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Sample Configuration: Primary/Secondary Inbound

In the configuration on the slide, the announcements to the secondary ISP are prepended to Nails, Inc.s own AS number
three times. Additionally, a community is set that causes ISP B to assign a local preference value lower than the value
assigned to the routes received from its peers and upstream providers. Note that Juniper Networks routers send
communities by default, so no additional configuration is necessary to send communities to BGP peers.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Load-Shared Per-Prefix Routing Policies

A load-shared per-prefix routing policy is really a primary/secondary routing policy, but you choose a different provider as
primary for each prefix (or set of prefixes). Because different providers should be used for traffic to certain prefixes, this
approach should lead to load sharing over multiple providers. Maintaining any sort of traffic parity over the various providers
requires fairly consistent monitoring and adjustment during setup, as well as ongoing monitoring and adjustment as traffic
patterns change.
This traffic model is appropriate where cost dictates using multiple available links to the fullest extent possible. This model
sacrifices the 1:1 redundancy found in the strict primary/secondary model and the performance found in the
topology-driven model.
Single Versus Multiple Routers

Once again, the configuration is the same whether you use one or more border routers; however, it is important to keep
configurations synchronized between multiple border routers to ensure that each router is correctly marking the routes it
receives.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Load-Shared Per-Prefix Outbound Routing Policy

To implement a load-shared per-prefix outbound routing policy, you set a higher local preference for the specific routes within
a large range for each provider. For example, this slide shows that Nails, Inc. chose to set a higher local preference on the
routes within 0.0.0.0/1 from ISP B and to set a higher local preference on the routes within 128.0.0.0/1 from ISP C. If either
ISP fails, the routes from the other ISP are used, providing reachability. However, without 1:1 redundancy, we cannot
guarantee that there would not be performance problems during a failure.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Sample Configuration: Load-Shared Per-Prefix Outbound

We can use the sample configuration on the slide to implement the scenario described on the previous page.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Load-Shared Per-Prefix Inbound Routing Policy

To implement a load-shared per-prefix inbound routing policy, you take advantage of longest-match routing. You announce
your aggregate prefix to all your providers, but you also announce a more specific prefix to each provider. As long as all
providers are functioning, all routers on the Internet follow the more specific routes, resulting in traffic for each prefix using a
different provider. However, if a provider malfunctions and does not successfully advertise one of the more specific routes,
the routers on the Internet follow the aggregate prefixes to the closest ISP announcing it. Again, without 1:1 redundancy,
there is no way to guarantee good performance during failure conditions.
Note that your more-specific prefixes must be no more specific than /24 prefixes for those announcements to propagate
through the Internet. Also note that some ISPs might enforce stricter filtering guidelines; however, if you are assigned
portable address space by a regional registry, your aggregate prefixes should be accepted by all ISP filters on the Internet,
which is yet another reason to announce the aggregate prefix along with the specific prefixes.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Sample Configuration: Load-Shared Per-Prefix Inbound

We can use the sample configuration on the slide to implement the scenario described on the previous page.
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Discussed:
The reasons to use BGP for internal connectivity;
ISP policies that affect external connectivity; and
Three common routing policies for external connectivity in the enterprise.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Review Questions
1.
2.
3.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Implementing Enterprise Routing Policies Lab

»¿´·¿à±¬®¿·²ò½±³ò¶±
1.
The benefits of BGP include routing policy control, diverse administrative control, and handling of large prefix counts.
2.
The longest subnet ISPs will usually accept is a /24 subnet mask.
3.
The course discusses topology driven, primary/secondary, and load-shared per-prefix routing policies. (Recall that some of these names are not
industry-standard terms, but are merely attempts to accurately describe a class of routing policies.) In general, a topology-driven policy
strategy provides the best performance, but usually at an increased cost and with the possibility of insufficient bandwidth in the event
of a failure. In general, a primary/secondary policy strategy provides the best performance in a failure mode (because it should, if
implemented correctly, provide equal bandwidth both in normal and failure operation), but it does so at a greatly increased cost and
sometimes sacrifices performance by ignoring the network topology. In general, a load-shared per-prefix policy strategy provides the
least expensive network, but it does so by sacrificing performance in the event of a failure and sometimes sacrificing performance in
normal operationby ignoring the network topology.

»¿´·¿à±¬®¿·²ò½±³ò¶±
Chapter 8: Introduction to Multicast
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Will Discuss:
Basic multicast terminology;
Multicast address space;
Multicast reverse path forwarding (RPF); and
Basic Internet Group Membership Protocol (IGMP) functionality.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Chapter 82 Introduction to Multicast www.juniper.net
Overview of Multicast
»¿´·¿à±¬®¿·²ò½±³ò¶±
www.juniper.net Introduction to Multicast Chapter 83
Address Types and Traffic Flow

IP version 4 (IPv4) has three fundamental types of addresses: unicast, broadcast, and multicast. You use a unicast address
to send a packet to a single destination, a broadcast address to send a datagram to an entire subnetwork, and a multicast
address to send a datagram to a set of hosts that can be on different subnetworks who are members of a multicast group.
A multicast datagram is delivered to destination group members with the same best-effort reliability as a standard unicast IP
datagram. Thus, multicast datagrams are not guaranteed to reach all members of a group or to arrive in the same order in
which they were transmitted. The only difference between a multicast IP packet and a unicast IP packet is the presence of a
group address in the IP header destination address field.
Individual hosts can join or leave a multicast group at any time. There are no restrictions on the physical location or the
number of members in a multicast group. A host can be a member of more than one multicast group at any given time and
does not have to belong to a group to send packets to members of a group.
As shown on the slide, the use of multicast can dramatically reduce traffic loads when multiple hosts want to receive the
same content.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Benefits of Multicast
As shown in the previous slide, the use of multicast to deliver content to remote hosts greatly reduces the load on both the
server that is generating the content as well as the network bandwidth usage.
Usage of Multicast
Interest in multicast as a content delivery mechanism has increased over the last few years. Because the functionality of
multicast is very similar to broadcasts from a radio or television station, it makes sense that many radio and television
companies are showing interest in using multicast-enabled IP networks to deliver their content. Multicast is now widely
deployed in enterprise networks for such applications as company meetings by video and distance learning.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Multicast Terms: Part 1

The slide describes some of the common terms used in multicast.
Source: A multicast source is any device that originates multicast IP packets.
Multicast IP Packet: A multicast packet is any IP packet that is destined to a multicast group address. The same
packet should have a unicast source address. Generally, a multicast packet uses User Datagram Protocol (UDP)
and/or Real Time Protocol (RTP) as its transport protocol. There are no guarantees that packets are received by
all members of a group. One protocol, Pragmatic General Multicast (PGM), has been developed to add loss
detection and retransmission capabilities to multicast.
Group Address: A multicast group address is an IP address in the range of 224.0.0.0/4.
Receivers: A multicast receiver is any host that is interested in receiving multicast packets. A receiver uses the
IGMP protocol to inform the directly connected router of this desire to receive multicast packets.
Designated router (DR): The DR is the router closest to the source or receiver that forwards multicast packets
into the network. If there are two or more routers attached to the source or receiver, only one ever becomes DR
based on some sort of election algorithm that depends on the multicast routing protocol being used.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Multicast Terms: Part 2

Group membership protocol - A group membership protocol is used by receivers to inform the directly connected
router of an interest in receiving packets for one or more multicast group address. That is, the host is informing
the router of its desire to become a member of a multicast group. IGMP is used by IPv4 hosts and routers for
this purpose. Multicast Listener Discovery (MLD) is used for IPv6. This course covers IPv4 multicast only.
Multicast Routing Protocol - A multicast routing protocol is used between routers to build and maintain the
multicast forwarding trees between sources and receivers. The following slides describe the basic functionality
of a multicast routing protocol. The two most common multicast routing protocols are Protocol Independent
Multicast (PIM) and Distance Vector Multicast Routing Protocol (DVMRP).
»¿´·¿à±¬®¿·²ò½±³ò¶±
(S,G) State
The forwarding path built from receiver up to source is stored and maintained in the routers as an (S, G) forwarding state (S
comma G). S indicates source address and G indicates group address. Dense Mode protocols always maintain (S,G) state.
Sparse Mode protocols only maintain (S,G) state after the receiver router learns about the source.
»¿´·¿à±¬®¿·²ò½±³ò¶±
(*,G) State
When the source is not known, a source tree can not be built yet. If a receiver requests to receive traffic for a particular group
but does not specify a specific source, the routers will need to build a tree towards an unknown source. PIM Sparse Modes
(PIM-SM) solution to this problem is to have a meeting point for sources and receivers in the network. This meeting point is
called a rendezvous point (RP). The tree built from the receiver to the RP in the network is called a shared tree (because it is
shared by all sources). The forwarding path built from the receiver router to the RP is kept as (*,G) forwarding state (*
comma G). The * indicates any source and the G indicates the group address.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Multicast Addressing
»¿´·¿à±¬®¿·²ò½±³ò¶±
Multicast Addresses
Multicast group addresses are defined to be the IP addresses whose four high-order bits are 1110, giving an address range
from 224.0.0.0 through 239.255.255.255, or simply, 224.0.0.0/4. These addresses also are referred to as Class D
addresses.
Registered Groups
The Internet Assigned Numbers Authority (IANA) maintains a list of registered IP multicast groups. The base address
224.0.0.0 is reserved and cannot be assigned to any group. The block of multicast addresses from 224.0.0.1 through
224.0.0.255 is reserved for local wire use. Groups in this range are assigned for various uses, including routing protocols
and local discovery mechanisms.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Reserved Ranges
The following list comprises the reserved multicast address ranges:
Scoped Range: The range 239.0.0.0/8 through 239.255.255.255/8 is reserved for administratively scoped
addresses. Because packets addressed to administratively scoped multicast addresses do not cross
configured administrative boundaries, and because administratively scoped multicast addresses are locally
assigned, these addresses do not need to be unique across administrative boundaries. These addresses are
available for private internal use.
GLOP addressing: The range of 233.0.0.0/8 is a statically assigned range of multicast addresses based on a
networks autonomous system (AS) number. For each AS, 255 unique multicast addresses are available for the
global use of that AS.
Source-specific multicast (SSM) addressing: The range of 232.0.0.0/8 is dedicated for use with SSM. SSM is
covered in-depth in the next chapter.
Session Description Protocol (SDP)/Session Announcement Protocol (SAP) addressing: The range of
224.2.0.0/16 is used to send and receive multimedia session announcements. Session Directory tool (SDR) is
a common application that uses SDP/SAP. These protocols do not scale well and are not recommended for
deployment on the Internet because of a potential denial of service (DoS) attack vector that they open.

Address Mapping
IANA has been allocated a reserved portion of the IEEE-802 Media Access Control (MAC) layer multicast address space. All of
the addresses in IANAs reserved block begin with 01-00-5E (hexidecimal). A simple procedure was developed to map Class
D addresses to this reserved address block to allow IP multicasting to take advantage of hardware-level multicasting
supported by network interface cards. The use of a MAC-layer broadcast would cause all machines on the subnet to expend
cycles for every multicast packet, even though these machines might not want to receive multicast. For example, the
mapping between a Class D IP address and an Ethernet multicast address is obtained by placing the low-order 23 bits of the
Class D address into the low-order 23 bits of IANAs reserved address block.

Address Mapping Example

This slide illustrates how the multicast group address 224.10.8.5 (E0-0A-08-05) is mapped into an Ethernet (IEEE-802)
multicast address. The mapping places the low-order 23 bits of the IP multicast group ID into the low-order 23 bits of the
Ethernet address. The mapping can place up to 32 different IP groups into the same Ethernet address because the upper 5
bits of the IP multicast group ID are ignored. For example, the multicast addresses 224.138.8.5 (E0-8A-08-05) and
225.10.8.5 (E1-0A-08-05) would also be mapped to the same Ethernet address (01-00-5E-0A-08-05) used in this example.
When the sender and receivers are members of the same subnetwork, or LAN, the transmission and reception of multicast
frames is a relatively simple process. The source station simply addresses the IP packet to the multicast group, and the
driver maps the Class D address to the corresponding IEEE-802 multicast address before the frame is sent. Receivers that
want to capture the frame notify their IP layer that they want to receive datagrams addressed to the group.
Things become more complicated when the sender is attached to one subnetwork and receivers reside in different
subnetworks. In this case, the routers must implement a multicast routing protocol that permits the construction of multicast
delivery trees and supports multicast data packet forwarding. In addition, each router must implement a group membership
protocol that allows it to learn about the existence of group members on its directly attached subnetworks.
»¿´·¿à±¬®¿·²ò½±³ò¶±
RPF
»¿´·¿à±¬®¿·²ò½±³ò¶±
Multicast Routing Differs from Unicast Routing

Multicast routing differs from unicast routing. Whereas unicast flows are directed toward a destination by a router based on
destination address, multicast flows are more or less directed away from a source based on source address. (Destination
multicast group addresses are useless for unicast routing purposes.)
RPF
But how is this away direction defined? With RPF, multicast-enabled routers use unicast routes to determine the best path
back to the source. RPF uses the existing unicast routing table to determine the upstream and downstream neighbors for a
particular address. A router only forwards multicast packets received on the upstream interface. These packets, in turn, are
only forwarded out interfaces considered downstream from the source.
This RPF check helps guarantee that the distribution tree is loop free. If the RPF check is successful, the packet is
forwarded. Otherwise, it is dropped. RPF checks can be done using inet.0 and normal unicast routing protocols, or RPF
can use MBGP to put unicast routes in inet.2.
Distribution Trees
Multicast-capable routers create distribution trees, which control the path that IP multicast traffic takes through the network
when delivering traffic to all receivers. The two basic types of multicast distribution trees are source trees and shared trees.
The simplest form of a multicast distribution tree is a source tree, with its root at the source and branches forming a
spanning tree through the network to the receivers. Because this tree uses the shortest path through the network, it also is
referred to as a shortest-path tree (SPT). Unlike source trees that have their root at the source, shared trees use a single,
»¿´·¿à±¬®¿·²ò½±³ò¶±
common root placed at some chosen point in the network. This root of a shared tree is called a rendezvous point (RP).

RPF
The incoming interface of an IP multicast packet is checked, and a decision is made to either forward or drop the packet.
When a packet comes in, the router examines the source address to determine whether the packet arrived on an interface
that is on the reverse path back to the source. If it is, the packet is forwarded; if not, the packet is discarded.
The RPF check ensures that multicast traffic always flows away from its source, which prevents loops and wasted bandwidth.
When using Protocol Independent Multicast (PIM), RPF checks are performed against the main routing table (inet.0), by
default. Distance Vector Multicast Routing Protocol (DVMRP), on the other hand, requires the presence of interface routes in
the inet.2 table for this purpose. Normally, inet.2 is only used in conjunction with PIM when you want unique unicast
and multicast topologies; when RPF checks are performed against the main routing instance, you effectively have the same
topology for both unicast and multicast.
»¿´·¿à±¬®¿·²ò½±³ò¶±
The RPF Check: Part 1

In the example on the slide, a packet arrives at R1s interface ge-0/0/1.0 from Source 1. R1 checks the existing unicast
routing table and determines that this interface is not on the reverse path back to the source. Thus, the packet is discarded.
»¿´·¿à±¬®¿·²ò½±³ò¶±
The RPF Check: Part 2

In the example on this slide, R1 receives a packet from Source 1 on its ge-0/0/4.125 interface and, once again, performs
an RPF check. R1 determines that the packet is coming in on an interface that is on the reverse path back to the source.
Thus, the RPF check succeeds, and the packet is forwarded to all interfaces on the outgoing interface list. Initially, all
interfaces other than ge-0/0/4.125 are on the outgoing interface list.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Dense-Mode Routing Protocol Behavior

The flood first and prune later philosophy of dense-mode protocols works well in enterprise networks where bandwidth is
high and latency is low. However, this approach does not scale well for large networks, especially where a large number of
connections are WAN links with limited bandwidth.
Source-Based Distribution Tree

The simplest form of a multicast distribution tree is a source tree with its root at the source and branches forming a spanning
tree through the network to the receivers.
Dense-Mode Protocols
Common dense-mode protocols include DVMRP, which builds a unique multicast routing table and has a finite hop count of
32. DVMRP was the first multicast routing protocol.
As mentioned, PIM dense mode (PIM-DM) uses a flood-and-prune behavior to build a source tree from the source of the
multicast.
»¿´·¿à±¬®¿·²ò½±³ò¶±
PIM-DM Operation
PIM-DM uses SPTs to deliver multicast traffic and assumes that there is at least one receiver of the multicast traffic on every
subnet in the network. Traffic is initially flooded to all points in the network. Each router running PIM-DM creates an (S,G)
state entry for each
source/group pairing. The slide shows an example of what an (S,G) state entry looks like. Routers without locally attached
receivers must prune themselves periodically from the SPT to avoid the reception of unwanted multicast traffic.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Pruning Unwanted Traffic

Because PIM-DM sends traffic to all network segments, routers send prune messages back up the source distribution tree to
shut off unwanted multicast traffic when they have no locally attached receivers, and also upon receiving a prune from their
downstream neighbors. The prune state eventually times out, so routers must reissue their prune messages periodically to
once again stem the flow of unwanted multicast traffic. When a new group membership is detected, the router issues a Join
message up the SPT to allow the flow of multicast traffic for that group. This Join message, which is sometimes called a graft
message, prevents the delays associated with having to wait for the state associated with a previous prune to time out.
»¿´·¿à±¬®¿·²ò½±³ò¶±
After the Prune

The result of the prune process is that branches without receivers are pruned off of the distribution tree, leaving only
branches that contain receivers. However, even routers that are not part of the distribution tree must continue to maintain
(S,G) entries for all known source and group combinations. This excess state is needed in the case of adding a receiver to the
network that did not previously exist.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Source Distribution Tree

A source distribution tree is an SPT between the sender and a given receiver. Dense-mode protocols have the benefit of
using SPTs between all sources and receivers. As you will soon see, the use of a shared tree, as associated with
sparse-mode operation, results in less than optimal forwarding between source and receivers.
To provide the best of both worlds, a PIM sparse-mode receiver normally instigates a Join message to an SPT after receiving
a multicast packet over the shared tree with a new source address. We describe this behavior in detail in the next chapter.
An SPT is indicated by the presence of (S,G) state. A shared tree is indicated by the presence of (*,G) state.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Adding a New Receiver

The slide shows what happens when a new receiver joins the multicast group after the SPT has been established. R3
receives an IGMP report (described in subsequent pages) from the new receiver advertising its membership to the 224.7.7.7
group. R3 and every router along the SPT between the source and receiver, in turn, sends a Join message upstream toward
the source. Note that the new receiver did not specify the sources IP address (192.168.100.10). For R3 and all of the other
routers to send the Join message toward the source, they must somehow know the IP address of the source. Any ideas?
Because we are using a dense-mode protocol, every router is aware of every source and group combination that is being
used in the network and stores that information as part of the (S,G) state. R3 looks over all of its (S,G) entries and finds the
IP address of the source for 224.7.7.7.
Each router along the SPT between the source and receiver sends a Join message toward the source until the sources DR is
reached.
»¿´·¿à±¬®¿·²ò½±³ò¶±
A Branch Is Added for Forwarding

Once the Join messages are received and sent along the new SPT, each router updates its (S,G) state to include a non-Null
inbound interface and a non-empty outbound interface list. Because in the change in (S,G) state, traffic can now be
delivered to the new receiver.
»¿´·¿à±¬®¿·²ò½±³ò¶±
IGMP
»¿´·¿à±¬®¿·²ò½±³ò¶±
IGMP
IGMP manages multicast groups participation between hosts and routers. IP hosts use IGMP to report their multicast group
memberships to their neighboring multicast routers. Multicast routers use IGMP to determine whether any hosts on their
attached networks are interested in receiving multicast traffic, and if so, in which multicast groups the hosts are
participating. IGMP is an integral part of IP and must be enabled on all routers and hosts that want to receive IP multicast.
IGMP can also help a Layer 2 switch determine which port it should use for forwarding multicast packets. Normally a Layer 2
switch forwards multicast packets in the same manner as a broadcast packet by sending a copy of received multicast
packets out of all interfaces except for the one on which the packet arrived. By enabling IGMP snooping (supported on Junos
OS Layer 2 switches), a switch is able to listen in on the IGMP report messages between hosts and attached routers. From
what the switch learns from these messages, it can make a better decision on where to send the multicast packets.
IGMP Message Exchange

For each attached network, a multicast router can be either a querier or a non-querier. The querier router periodically sends
general query messages to solicit group membership information. Hosts on the network that are members of a multicast
group send report messages. When a host leaves a group, it sends a leave-group message when running IGMP versions 2 or
3; IGMP version 1 does not support explicit leaves. Instead, it relies on the aging out of cached states to manage leaves.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Junos OS Support
On Junos OS routers, IGMP is enabled automatically on all multiaccess interfaces configured with a multicast routing
protocol such as DVMRP or PIM. You might need to configure the IGMP protocol explicitly if you want to disable IGMP support
on a given interface, or if you need to modify various IGMP parameters. The default version of IGMP is version 2; however,
the Junos OS also supports versions 1 and 3.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Group Membership Protocols Versus Multicast Routing Protocols

Multicast routing protocols work in conjunction with IGMP. IGMP allows hosts to join and leave multicast groups; multicast
routing protocols allow multicast traffic to flow between networks. Common multicast routing protocols are DVMRP and PIM.
In general, you do not have to run IGMP between routers because routers typically do not join multicast groups.
»¿´·¿à±¬®¿·²ò½±³ò¶±
IGMP Version 1
RFC 1112 defines IGMPv1. IGMPv1 routers periodically transmit host membership query messages to determine which
groups have members on their directly attached networks. Query messages are addressed to the all-hosts group address
(224.0.0.1) and have IP TTL=1. When a host receives a query message, it responds with a host membership report for each
group to which it belongs. Multicast routers periodically transmit queries to update their knowledge of the group members
present on each interface. Because queries are normally sent every 60 seconds, multicast traffic can be delivered to a
subnet with no interested hosts for several minutes after the last host has left that group.
IGMP Version 2
RFC 2236 specifies IGMPv2. RFC 2236 defines a procedure for the election of a querier for each LAN. The router with the
lowest IP address on the LAN becomes the querier. In IGMPv1, the multicast routing protocol determined the querier
election. IGMPv2 also defines a group-specific query message and a leave-group message, which improves on IGMPv1s
leave latency.
»¿´·¿à±¬®¿·²ò½±³ò¶±
IGMP Version 3
RFC 3376 defines IGMPv3 and introduces support for group-source report messages. With these messages, a host can elect
to receive traffic from specific sources of a multicast group. This capability accommodates SSM. A host identifies the IP
addresses of the specific sources from which it wants to receive traffic by generating an inclusion group-source report
message. The host generates an exclusion group-source report message to explicitly identify the sources from which it no
longer wants to receive traffic.
With IGMPv1 and v2, if a host wants to receive traffic from a given group, that host must be prepared to receive traffic from
all active sources sending packets to that group. SSM maximizes efficiency by allowing a host to receive group traffic from a
selected set of sources. The support for leave-group messages that was introduced in IGMPv2 is enhanced to support
group-source leave messages in IGMPv3.
Although IGMPv3 adds support for the SSM service model, it still offers backwards compatibility with the any-source
multicast (ASM) service model as well.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Joining a Multicast Group

When a host wants to join a specific multicast group, it sends out a membership report for the multicast group it wants to
join. This type of membership report is sometimes referred to as unsolicited because it is not generated in response to a
membership query that is generated by a multicast router. In the example on the slide, Host 1 multicasts an unsolicited
IGMPv2 membership report to 224.10.1.1 to inform the multicast routers that it wants to join the 224.10.1.1 group.
Hosts that are interested in a given group also respond to the periodic query messages, as generated by the querier router
for this subnet, with report messages to prevent the group state from timing out.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Query-Response Model
The primary function of IGMP is to inform multicast routers as to which multicast groups have active listeners on a given
segment. In the example on the slide, two hosts are reporting that they want to receive traffic for the group 224.10.1.1, and
one host reports a desire to receive traffic for group 224.20.1.1.
In this example, Router A is functioning as the querier router. The querier router is responsible for periodically sending query
messages to the all-hosts multicast group 224.0.0.1 and is the multicast router with the lowest IP address on a particular
subnet.
The example begins with the querier router sending a general query to the all-hosts multicast address. A general query does
not contain a particular group address, and as such, it applies to all possible groups. Note that IGMPv1 supports only
general queries, while IGMPv2 supports both general and group-specific query messages. Group-specific queries are
generated as a result of receiving a leave-group message from an IGMPv2 host.
Each host now starts a randomized delay timer that determines how long that host delays the transmission of the resulting
membership report for those groups in which that host is a member. In this example, Host 2 generates its report for the
224.10.1.1 group before Host 1 (step 2). When Host 1 sees this report, it suppresses its group report for the 224.10.1.1
group, which serves to reduce the amount of traffic on the network. The use of a randomized response timer helps to ensure
that duplicate reports are not generated. Host 3 also receives the query and responds with a membership report for group
224.20.1.1.
The end result is that the querier router (Router A) is now aware that there are active receivers for groups 224.10.1.1 and
224.20.1.1. The non-querier router (Router B) knows the same information because it has eavesdropped on the various
query and report messages that have transpired. This allows the non-querier to rapidly take over the querier function when
needed. »¿´·¿à±¬®¿·²ò½±³ò¶±
IGMPv2 Group Leave

This slide outlines the IGMPv2 leave mechanism, which has the host send a group-specific leave message to the all-routers
multicast group (224.0.0.2) to inform all routers it is leaving the group. The querier router then sends a group-specific query
to determine whether any host still remains active for the group. If some hosts still exist, those hosts respond with a
membership report to inform the router that a member of the group is still present.
With IGMPv1, no mechanism exists for a host to notify the router that it wants to leave a group. The router continues to send
out its query for the group, and if it stops getting membership reports, it knows that there are no active receivers for the
group. Because the query interval is 60 seconds, and the router does not time out until after missing three query messages,
the router could continue to forward multicast traffic for up to three minutes after all hosts have left the group.
»¿´·¿à±¬®¿·²ò½±³ò¶±
IGMPv3 and SSM

Version 3 of IGMP supports the concept of source-specific reports, which allow a host to issue a report for a specific source
(S,G), as opposed to all sources (*,G). This capability is called SSM. The (S,G) notation is used to indicate a specific source
(S) and a corresponding group (G). The use of a shared tree is indicated with a wildcard (*) instead of a specific source
address.
The slide shows how SSM allows a host to selectively choose the sources from which it is interested in receiving traffic, on a
per-group basis. Besides the obvious efficiency gains, SSM has the added benefit of supporting a sparse-mode topology
without an RP. In the example, Host 1 sends an IGMPv3 membership report with an include indication for source
172.16.20.1 and an exclude indication for address 192.168.30.1. Note that in IGMPv3, report messages are sent to the
IGMPv3-capable multicast routers address of 224.0.0.22. Recall that IGMPv1 and IGMPv2 send report messages to the
address of the group being reported. One reason for this modified behavior is that IGMPv3 report messages can contain
information for multiple groups.
Note that general queries are sent to the all-hosts multicast address (224.0.0.1), whereas group-specific and
group-and-source-specific queries are sent to a destination address that matches the multicast address of interest. The
disadvantage to SSM is that hosts must have a prior knowledge of the specific sources active for a given group before they
can formulate the appropriate group-source report message. This problem is complicated by the fact that some groups are
ephemeral in nature. Standards work is underway to develop ways of propagating knowledge of active sources to IGMPv3
hosts. For example, addresses in the range of 232/8 are reserved for use by SSM. Although SSM can function with groups
outside this range, attempts to perform an ASM Join message (*,G) to a 232/8 prefix should fail with an IGMPv3-compliant
router.
»¿´·¿à±¬®¿·²ò½±³ò¶±
IGMP Protocol Configuration

The slides shows the different IGMP configuration options. We describe most of these options in subsequent slides.
»¿´·¿à±¬®¿·²ò½±³ò¶±
IGMP Interface Specific Properties

Many of the settings for IGMP can be applied on an interface by interface basis. The following list describes each of these
options.
accounting: Enables join and leave notifications.
disable: Disables IGMP on this interface.
group-limit: Maximum number of (S,G) Join messages per interface.
group-policy: Allows you to block certain source and group combinations.
immediate-leave: Groups are immediately removed without sending a query for last membership. This
option is good for when only one host is attached.
no-accounting: Disables join and leave notifications.
oif-map: Allows you to configure outbound interfaces for multicast traffic that are different than the one
where the IGMP report was received.
passive: Suppresses the sending and receiving of certain IGMP messages.
promiscuous-mode: Accepts IGMP messages from a different subnet.
»¿´·¿à±¬®¿·²ò½±³ò¶±
IGMP Interface Specific Properties (contd.)
The following is a continuation of the list of IGMP settings from the preceding page:
ssm-map: When an interface is set for IGMPv3 and an IGMPv1 or v2 report arrives (no source specified), this
feature allow you to statically map a source to the group received in the report.
ssm-map-policy: Name of the SSM map policy created to match the group addresses you want translated
to IGMPv3.
static: With this setting, regardless of what is received from an attached host, the router automatically acts
as if it had received a report for the configured source and group combination. This is a great feature for testing
the multicast routing protocol without the need for a host running IGMP.
version: Sets the IGMP version number to be used.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Sample Configuration
To configure IGMP, you include statements at the [edit protocols igmp] hierarchy level of the configuration.
IGMP is enabled automatically on all non-point-to-point interfaces configured to run DVMRP or PIM in all Junos OS releases.
You can manually list the interfaces that should run IGMP or use the all keyword. In all cases, you should ensure that IGMP
does not run on the routers out-of-band interface (fxp0) by specifically listing the fxp0 interface as disabled, especially
when using the interface all approach. Interfaces enabled for IGMP run version 2, by default. You can manually select
version 1 or 3 as needed.
IGMP version 3 supports SSM. The syntax on the slide shows how you can configure a static IGMP report under a particular
interface for a given group address. This configuration causes the router to act as if it had received an IGMP report on the
interface (no IGMP reports are actually sent or received as a result of this configuration). By including a source address, you
cause the router to send an (S,G) PIM Join message while omitting the source address causes the router to send a PIM (*,G)
Join message. Static reports are useful when testing multicast in the absence of a multicast receiver.
The IGMP querier router periodically sends general host-query messages. These messages solicit group membership
information and are sent to the all-hosts multicast group address, 224.0.0.1. By default, the router sends host-query
messages every 125 seconds. You might want to change this interval to tune the number of IGMP messages sent on the
subnet.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Displaying the IGMP Interface

The output of the show igmp interface command is a listing of interfaces running IGMP, the IGMP version, and the
number of groups currently active. The IGMP querier address is also listed when it is known. The display also provides a
listing of the derived and configured timer and counter parameters used to control the operation of IGMP.

Displaying IGMP Group Information

Use the show igmp group command to show the groups joined by directly connected hosts and other routers. When a
router is attached to a LAN that has only IGMP-speaking hosts (that is, no other PIM-speaking routers), that interface must
run PIM for the router to function properly. If you explicitly enable IGMP on an interface but fail to enable PIM on that
interface also, the IGMP interface status shows the Up state, but that interface is omitted from the output of a show igmp
group command.
Note that the Junos OS always accepts and listens to groups like the all-OSPF routers or all-IGMPv3 routers addresses, even
when these functions are not actually configured. Listening causes no harm to these messages; the Junos OS does not act
upon the messages unless the corresponding functionality is configured.
To clear group membership, use the clear igmp membership command. When you want, you can clear all group
information or just the information associated with certain interfaces and groups.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Displaying IGMP Statistics

The show igmp statistics command displays a variety of IGMP-related messages and error counts. You can clear
IGMP statistics with the clear igmp statistics command.
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Discussed:
Basic multicast terminology;
Multicast address space;
Multicast RPF; and
IGMP functionality.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Review Questions
1.
2.
3.
4.
»¿´·¿à±¬®¿·²ò½±³ò¶±
1.
Two benefits of using multicast are that it reduces both the load on the source server and the bandwidth usage in a network.
2.
The designated router (DR) is the router closest to the source that is responsible for forwarding multicast traffic.
3.
The primary purpose of a multicast routing protocol is to build an SPT between sources and receivers.
4.
IGMPv3 can be used by a host to request multicast traffic from a particular source.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Chapter 9: Multicast Routing Protocols and SSM
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Will Discuss:
Basic multicast routing protocol terminology;
Protocol Independent Multicast (PIM) sparse mode operation and configuration when using the any-source
multicast (ASM) model; and
PIM sparse mode (PIM-SM) operation and configuration when using the source-specific multicast (SSM) model.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Chapter 92 Multicast Routing Protocols and SSM www.juniper.net
Overview of Multicast Routing Protocols

»¿´·¿à±¬®¿·²ò½±³ò¶±
www.juniper.net Multicast Routing Protocols and SSM Chapter 93
ASM
The ASM delivery model was designed into the original specifications of multicast in RFC 1112. This model supports traffic
from one source to many receivers. Internet Protocol Television (IPTV) video is one example that uses this model. ASM also
supports traffic between all members of a multicast group. Examples of this many-to-many model are videoconferencing and
whiteboard applications. ASM gets its name from a mechanism that allows receivers to join a group without specifying from
which source they want to receive traffic. As a result, the receivers accept multicast packets for a particular group from any
source.
SSM
In the SSM model, the receiver specifies the sources from which it would like to receive traffic. The receiver can also specify
from which sources it does not want to receive traffic. So for SSM to work, the source information must be learned from the
receiver. SSM makes deployment of multicast less complex and also makes addressing easier.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Dense Mode
When using a dense mode multicast routing protocol, traffic gets forwarded to all parts of the network (flooding). This
flooding process allows every router in the network to learn of any active sources in the network and store that information in
a state called (S,G) or S comma G. The parts of the network that are not interested in receiving the traffic (no receivers)
send Prune messages to their neighbor routers asking them to stop forwarding traffic to them. In the case where a receiver
joins a group after the branch of the forwarding tree has been pruned, the routers along the shortest-path tree (SPT) send a
graft message asking for the traffic to be forwarded again. In a dense mode network, multicast traffic is always forwarded
along the SPT between source and receiver. Dense mode multicast routing protocols include Multicast Open Shortest Path
First (MOSPF), Distance Vector Multicast Routing Protocol (DVMRP), and PIM dense mode (PIM-DM). The Junos operating
system supports DVMRP and PIM-DM, but not MOSPF.
Sparse Mode
When using PIM-SM, multicast traffic only gets forwarded into parts of the network where interested receivers exist. Only
routers along the SPT need to maintain (S,G) state. Each router along the forwarding path sends Join messages to indicate
its willingness to receive traffic. In the case where the receiver is no longer interested, the router sends Prune messages to
the upstream neighbor asking the neighbor to stop forwarding the traffic. In PIM-SM, there are two possible forwarding trees
that can be used to deliver traffic to an interested receiver: an SPT or a rendezvous-point tree (RPT). We describe each of
these forwarding trees in subsequent slides.
»¿´·¿à±¬®¿·²ò½±³ò¶±
SPT
An SPT is a multicast forwarding tree that is rooted at the first-hop router closest to the source. When a dense mode protocol
is used in the network, (S,G) state is maintained for every known source and group combination on every router, including
those routers not on the SPT. When PIM-SM is used in the network, (S,G) state is maintained for every known source and
group combination only on the routers on the SPT, as well as the rendezvous point (RP) (discussed in subsequent pages).
»¿´·¿à±¬®¿·²ò½±³ò¶±
RP Tree
An RPT can be found only in a PIM-SM network. The RP is a centralized router that is responsible for knowing all
combinations of active sources and groups in the network. The RPT is a multicast forwarding tree that is rooted at the RP in
the network and leafs out to the interested receivers. Because all last-hop routers fall on the RPT for a specific multicast
group, this tree is sometimes referred to as the shared tree. This tree is generally used temporarily for forwarding until the
routers closest to interested receivers learn the source of multicast traffic (learned from the source address of the multicast
packets). Once these routers learn the source of the multicast traffic, they build an SPT directly to the source designated
router (DR).
»¿´·¿à±¬®¿·²ò½±³ò¶±
PIM-SM Using the ASM Model

»¿´·¿à±¬®¿·²ò½±³ò¶±
PIM Independence
PIM is indeed as it claimsprotocol independent. Whichever unicast protocol is being used, PIM uses this protocol for its
reverse-path forwarding check. PIM does not care if this protocol is OSPF, Intermediate System-to-Intermediate System
(IS-IS), RIP, or even BGP!
PIM-SM Trees
The purpose of an RP and a shared tree is to allow receivers to learn of active senders for a given multicast group. Once an
active sender is detected, that is, data from sender x is received over a shared tree, PIM sparse-mode routers attempt to
optimize the topology by establishing a source-based tree. The resulting SPT removes unnecessary hops, and possibly the
RP itself from that particular multicast flow. Subsequent slides provide details of this behavior.
Design Considerations
The placement and selection of a sparse-mode RP can be a critical factor in the networks performance and fault tolerance.
Subsequent pages discuss ways of achieving RP redundancy. PIM-SM for IP version 4 (IPv4) requires a pd interface on the
RP, and a pe interface on every router that is directly attached to a multicast source. On some Juniper Networks hardware,
the pd and pe virtual interfaces require the presence of a specialized services PIC. Consult JTAC or technical documentation
to determine whether your hardware model requires specialized hardware.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Sparse-Dense Mode
The PIM protocol allows the designation of groups to be either sparse or dense. This designation allows some groups to
operate in dense mode using SPT, while other groups operate in sparse mode with a shared tree. One example of when to
use sparse-dense mode is when using auto-RP.
»¿´·¿à±¬®¿·²ò½±³ò¶±
PIM Register Messages

PIM-SM requires that source DRs encapsulate multicast traffic inside register messages, which are then sent as unicast
datagrams to the groups RP. Upon receipt, the RP removes the register encapsulation and forwards the traffic down the
shared tree as native multicast, if the tree exists.
Register encapsulation is necessary because initially no state in the network exists to allow native multicast to flow from the
sender to the RP. Put differently, the RP functions to allow receivers to locate active senders without the prior knowledge that
senders actually exist. By allowing a sender to initially contact the RP using unicast forwarding, we eliminate the problem of
the RP having no way to learn of active senders.
On a Junos OS router, the source DR and RP must have tunnel services enabled to encapsulate and decapsulate register
messages. To provide tunnel services some Junos OS routers require an Adaptive Services or Tunnel Services PIC.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Adding a Receiver
Adding a receiver to a PIM-SM network (ASM model) requires that an RPT is built from RP to receiver. The slide shows a new
receiver notifying R5 of its interest in receiving traffic destined to 224.7.7.7 by sending an Internet Group Management
Protocol version 2 (IGMPv2) report. Not knowing the source of the 224.7.7.7 group, R5 sends a (*,G) Join message in the
direction of the RP. R4, after receiving the Join message from R5, also sends its own (*.G) Join message to the RP. This
results in the building of the RPT.
Because the RP is aware of all active sources in the network (because of the reception of register messages), the RP sends
an (S,G) Join message toward the source in an attempt to build an SPT from source to RP. R2, after receiving the Join
message from the RP, also sends its own (S,G) Join message to the sources DR which completes the building of the SPT.
»¿´·¿à±¬®¿·²ò½±³ò¶±
PIM-SM: The Shared RPT

Sparse-mode routing is ideal for efficiently routing to multicast groups that might span wide-area and interdomain
internetworks. In sparse mode, routers must join and leave multicast groups explicitly. Upstream routers do not forward
multicast traffic to a downstream router unless that router has sent an explicit request (using a Join message) to receive
multicast traffic. In other words, multicast traffic is forwarded out a PIM-SM interface only if the interface has received a Join
message from a downstream router or if group members are connected directly to the interface.
The slide shows that the traffic flowing from the source to receiver does not follow an optimal path when flowing over the
shared tree. Future slides explain how this inefficiency is resolved with the signaling of an SPT.
»¿´·¿à±¬®¿·²ò½±³ò¶±
PIM-SM: Switch to SPTPart 1

The presence of traffic flow down the PIM-SM shared tree triggers a switch to an optimal SPT-based tree.
The receivers designated router (that is, the router closest to the receiver with the highest PIM priority) sends a Join
message toward the source while also pruning the (S,G) state from the shared RP tree (not shown) when it determines that
traffic is not being received over the optimal path between the source and receiver. This slide shows the process beginning
with the DR sending a PIM (S,G) Join message over the RPF path back to the source to establish an SPT.
Note that as a result of the join, multicast traffic is now being delivered from R1 to R5 over an SPT. At this time duplicate
traffic is also being received over the RPT.
In the Junos OS, the switch from a shared to an SPT is generally triggered by the receipt of the first packet from a new source
on the shared tree.
»¿´·¿à±¬®¿·²ò½±³ò¶±

After the SPT is formed between the receiver and the source and data begins to flow, the receivers designated router sends
an (S,G) Prune message to the RP. This (S,G) Prune message prevents the reception of data from that particular source over
the shared tree.
The slide shows that multicast traffic from the source is no longer received over the shared tree as a result of the Prune
messages. In this example, the RP has no need to forward traffic from the source (it has no downstream interfaces for the
(S,G) entry for the source), so the RP also sends an (S,G) prune toward R1.
The first-hop router periodically sends null register messages to the RP so that it continues to be aware of the source. This
process ensures that future receivers of this group can reach this source using the RP because they might not know of the
source itself.
»¿´·¿à±¬®¿·²ò½±³ò¶±

The slide shows the resulting SPT between the source and a specific receiver for a particular group (G) that yields optimal
forwarding.
Notice that R5 must maintain both (S,G) state for the SPT as well as (*,G) state for the RPT (that continues to exist). Because
it is possible that another source can be added to the network that might send traffic to the same group, 224.7.7.7, the RPT
must remain intact.
»¿´·¿à±¬®¿·²ò½±³ò¶±
When All Is Said and Done

No one ever said that multicast was simple or easy to understand! The average reader has likely had enough multicast
theory at this juncture. This slide concludes the previous example by showing the final result PIM-SM operation with respect
to the sender, RP, and receiver shown in the example.
The source station becomes the root of an SPT that delivers native multicast from the source to the receiver. Note that the
shared tree is pruned for this source from the perspective of the receiver shown because of the presence of the SPT.
The receiver maintains the shared tree to the RP so that it can begin receiving traffic for any new sources that might begin
sending to the multicast group in question.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Three RP Methods
The Junos OS provides three separate methods for determining which router in the domain is the RP. These methods include
static configuration, dynamic announcements using auto-RP, and dynamic announcements using a bootstrap router (BSR).
Precedence Order
In the event that a local router encounters multiple methods of learning the address of the RP, the Junos OS has a default
precedence mechanism for making the selection. The RP announced by the BSR is preferred over the RP announced using
auto-RP, which is preferred over any local static RP configurations.
Local RP Configuration
Regardless of the method used in the network for determining the RP address, a candidate rendezvous point (candidate RP)
itself must be configured to perform that role. In the example on the slide, the local portion of the [edit protocols
pim rp] hierarchy accommodates this configuration need. You define the address to be used as the RP address and any
applicable group addresses the candidate RP should operate upon. If no group addresses are defined, the candidate RP is
used for all possible group addresses (224.0.0.0/4).

Static RP
A static RP configuration is very similar to static routes in that no automatic failover exists should the statically defined RP
become unreachable. Although this configuration is simple and convenient, you might want to use this method in
combination with any-cast RP and Multicast Source Discovery Protocol (MSDP) to provide a fault-tolerant mechanism. Static
RP assignment has the benefit of operating in either a PIM version 1 or version 2 network.
In the example on the slide, the static portion of the [edit protocols pim rp] hierarchy is used to configure a
static RP address. You define the address of the RP, as well as the group addresses for which to use the RP. If no group
addresses are defined, the RP is used for all possible group addresses (224.0.0.0/4).
»¿´·¿à±¬®¿·²ò½±³ò¶±
Verifying a Static RP
The show pim rps command with the extensive switch displays a wealth of information about how an RP was learned,
which groups it handles, and the number of groups actively using the RP.
In the example on the slide, the RP at 192.168.121.1 was learned from a static configuration. It can support all groups in the
224.0.0.0/4 range, which is all possible groups.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Dynamic RP Assignment
If you want a dynamic way of assigning RPs in a multicast network, auto-RP is one option. Auto-RP has both positive and
negative aspects to its operation. From a positive perspective, it operates in both a version 1 and a version 2 PIM network.
Negatively, it is a nonstandard (non-RFC-based) function and requires the use of dense-mode PIM to advertise control traffic.
Dense Groups Needed

Auto-RP requires multicast flooding both to announce potential RP candidates and to discover the elected RPs in the
network. This flooding occurs using a PIM-DM model, where group 224.0.1.39 is used for the Announce messages and
group 224.0.1.40 is used for the Discovery messages.
Failover Capabilities
One advantage that auto-RP maintains over static RP assignment is the ability to maintain a backup RP in the network. This
backup allows you to configure multiple routers as RP candidates. Should the elected RP stop operating, one of the other
preconfigured routers can take over the RP functions. The auto-RP mapping agent controls this capability.
Mapping Agents
As multiple candidate RP routers announce their capabilities to support multicast groups, there must be a single router in
the networkthe mapping agentto perform the group-to-RP mapping. This functionality is required because only a single
RP for each multicast group can exist. The mapping agent sends out Discovery messages to the network informing all routers
»¿´·¿à±¬®¿·²ò½±³ò¶±
which RP to use for specific multicast groups.

Auto-RP Message
Each local router configured as an RP uses this auto-RP message to advertise its capability into the network. The mapping
agent in the network collects these announcements and selects the RP for each group address. This information is then
transmitted into the network using this same message format. The message fields include the following:
Version and type (1 byte): This octet is split into two 4-bit fields. The first 4 bits represent the current version of
auto-RP being used and are set to a constant value of 1. The second 4 bits are used to represent the actual
type of auto-RP message encoded. The possible values are the following:
1: RP announcement message; and
2: RP mapping message.
RP count (1 byte): This field displays the number of distinct RP addresses present in the message. For each
address present, the RP address field, as well as its associated fields, is repeated.
Hold time (2 bytes): This field displays the amount of time, in seconds, for which the RP message is valid.
Reserved (4 bytes): This field is not used and is set to a constant value of 0x00000000.
RP address (4 bytes): This field displays the first RP address included in the message. The remaining fields in
the message are repeated for each unique RP address.

Auto-RP Message (contd.)
The remaining fields of the auto-RP message are the following:
Reserved and RP version (1 byte): This byte begins with a 6-bit reserved field, which is set to all zeros. The final
2 bits are used to display the version of PIM supported on the RP. The possible values include the following:
00: Version unknown;
01: Version 1 only;
10: Version 2 only; and
11: Both versions 1 and 2.
Group count (1 byte): This field displays the number of groups associated with the RP address.
Encoded group address (6 bytes): This field contains three separate portions used to describe the group
address associated with the RP. The entire 6 bytes are repeated based on the value in the group count field.
The field portions include the following:
Reserved and N bit (1 byte): This field contains seven bits set to a value of 0, followed by the N bit. The N
bit denotes whether group address is positive or negative. A value of 0 represents a positive group
address, which should use sparse mode PIM forwarding. A value of 1 represents a negative group
address, which should use dense mode PIM forwarding.
Mask length (1 byte): This field displays the length of the group prefix to follow.
Group address (4 bytes): This field displays the multicast group address that the RP supports.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Electing an RP
The slide shows how the mapping agent learns of all of the candidate RPs, performs the RP election, and then informs all of
the routers in the network of the elected RP.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Configuring Auto-RP
To enable auto-RP successfully in a PIM network, you must complete a few steps. First, each router in the network must
enable the sparse-dense mode on all interfaces within the [edit protocols pim] hierarchy. This step allows the
router to operate in sparse mode for most groups and dense mode for others. The default action is to operate in sparse
mode unless specifically informed of a dense-mode group, which is accomplished with the dense-groups command. Both
the 224.0.1.39 and 224.0.1.40 groups must be listed, and you must apply this configuration on all routers in the network.
Once you complete the preceding steps, the actual configuration of auto-RP can take place. Each router must have the
auto-rp command configured with one of three switches: discovery, announce, or mapping. The discovery option
allows a router to receive and process the Discovery messages from the mapping agent. This function is the most basic and
limited a router can support. The announce option adds to the same abilities as the discovery option, but also allows a
router to send Announce messages into the network stating that it is a candidate RP. Finally, the mapping option adds to
the abilities of the announce option, but also allows a router to perform the group-to-RP mapping function as well as to
send Discovery messages into the network.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Verifying an Auto-RP RP
In the example on the slide, the RP at 192.168.50.61 is learned from auto-RP. It can support all groups in the 224.0.0.0/4
range, which is all possible groups. In addition, the presence of tunnel services in an RP router creates a decapsulation
interface to allow the RP to receive multicast traffic from the source. This interface is ppd0.32769 in the example.
»¿´·¿à±¬®¿·²ò½±³ò¶±
PIM Version 2 Only

Another method available to determine an RP router dynamically is the BSR. The functionality of the BSR was originally in
RFC 2362, but has been updated in RFC 5059. The specification requires that all routers wanting to support BSR be capable
of using the PIMv2 specification. This requirement stems from the method by which the BSR operates. All routers in the
domain send and collect BSR messages on a hop-by-hop basis. Although this process means that only sparse mode
interfaces are needed, it also means that all routers must be able to receive and regenerate these messages.
One BSR per Domain

Within a PIM domain, only a single BSR is ever elected. It is the function of the BSR that allows all routers in the network to
know the specific RP for any individual multicast group. The primary criterion for electing a BSR is a configured priority.
Should the priority of two routers be equal, the router with the higher loopback IP address is elected. If multiple IP addresses
are configured on the loopback, the lowest address configured is used unless any addresses have been configured with the
primary option. In this case, the lowest address configured with the primary option is used. A router with a priority of 0 is
ineligible to be the BSR and is never elected.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Multiple Candidate Routers
One advantage that the bootstrap mechanism brings to PIM is the ability to have multiple routers configured with a priority.
Although only a single BSR can be operational at one time, other routers are available to take over in the event of a failure. In
addition, you can also configure a candidate BSR to be a candidate RP. This configuration allows for easier troubleshooting
and keeps the overhead of PIM control messages centralized on a few routers.
At a minimum, you must configure only a single candidate BSR and a single candidate RP to operate a multicast network
successfully, although it is possible for both functions to be configured on a single router.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Candidate RP Advertisements
After the election of the BSR, each configured RP in the network unicasts a candidate RP advertisement (C-RP-adv) into the
domain. This announcement informs the BSR which multicast groups the RP can support, the hold time for the RP, and a
priority value. This information allows for a dynamic failover in the event of a failure.
BSR Collects Advertisements

The elected BSR collects all the C-RP-advs sent into the network. It places each of the announcements into a message
known as the RP-set, which contains all announced RP routers. Local routing policies can affect which announcements are
placed into the RP-set, allowing for maximum flexibility. Once the RP-set is complete, it is advertised into the domain in a
bootstrap message.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BSR Advertises to the Domain
The function of the BSR is completed once the RP-set is advertised into the PIM domain. At this point, it is up to the
individual routers to choose which RP should be used for which multicast group. A process defined in the RFC allows all
routers to make the same selection based on the available RP-set. This process allows different groups to be supported by
different RP routers. The steps for selecting the RP are the following:
1. Locate all RPs associated with the most specific advertised group range for the specific group in the PIM Join
message.
2. From the resulting RPs, select all devices with the best priority (the highest numerical value).
3. From the resulting RPs, compute a hash value using the group address, the RP address, and the advertised
hash mask length advertised in the bootstrap message. Select the RP with the highest hash value.
4. From the resulting RPs, select the RP with the highest IP address.

BSR Message
Each BSR message is encoded in a PIM protocol packet as type code 4. It contains as few as one multicast group address
range or multiple ranges. Each advertised address prefix includes a list of RPs capable of servicing that group. The fields of
the bootstrap message include the following:
Fragment tag (2 bytes): It is possible that an individual bootstrap message might be too large for transmission
in the network without fragmentation. This field includes a randomly generated number designed to ensure that
all fragmented packets are associated with the same bootstrap message. Each fragment receives the same
value in this field.
Hash mask length (1 byte): This field displays the length, in bits, that each router should use when calculating
the BSR hash algorithm. For IPv4 messages, a value of 30 is recommended.
BSR priority (1 byte): This field displays the priority value of the current network BSR.
BSR address (6 bytes): The address of the domains BSR is placed in this field using the encoded unicast
address format.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BSR Message (contd.)
The remaining fields of the BSR message are the following:
Group address (8 bytes): This field, as well as its associated fields, can be repeated multiple times in a single
bootstrap message. It contains the multicast group address using the encoded group address format.
RP count (1 byte): This field displays the number of RPs included in the RP-set for the associated group address.
Fragment RP count (1 byte): When a bootstrap message is fragmented, this field is used to display the number
of RPs in the RP-set included in this fragment for the group address.
Reserved (2 bytes): This field is not used and is set to a constant value of 0x0000.
RP address (6 bytes): This field is repeated based on the value in the RP count field for the associated group
address. The address of the RP is displayed using the encoded unicast address format. The RP hold time, RP
priority, and reserved fields following the RP address are associated with this single address value.
RP hold time (2 bytes): This field displays the amount of time for which the associated RP, in the preceding field,
is valid. This field is displayed in units of seconds.
RP priority (1 byte): This field displays the priority of the associated RP. It is used in the hash algorithm for
deciding which RP should be used for a particular group address.
Reserved (1 byte): This field is not used and is set to a constant value of 0x00. It is associated with the RP
address in the preceding field.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Candidate RP Advertisement Message

Once the BSR for the PIM domain is elected, each router configured as an RP generates a C-RP-adv to announce which
address groups it supports. Each C-RP-adv message is unicast to the BSR address in a PIM protocol packet as type code 8. It
contains the address of the RP and which groups it supports. The fields of the candidate RP advertisement message include
the following:
Prefix count (1 byte): This field displays the number of distinct group address ranges the local RP supports. A
value of 0 in this field means that the RP supports all possible groups224.0.0.0/4.
Priority (1 byte): The priority of the RP for its advertised group address is placed into this field. Lower numerical
values translate into a higher priority. The Junos OS uses a priority value of 0 by default.
Hold time (2 bytes): This field displays the amount of time the BSR should retain knowledge of the local RP and
its supported group addresses.
RP address (6 bytes): The address of the local RP is placed in this field using the encoded unicast address
format.
Group address (8 bytes): This field is repeated based on the value in the prefix count field. Each unique group
address range supported by the local RP is placed here using the encoded group address format.
»¿´·¿à±¬®¿·²ò½±³ò¶±
RP Election Using BSR

The slide shows how BSR learns of all of the candidate RPs, generates the candidate RP-set BSR message, and sends the
message to all of the routers in the network. A noticeable difference between auto-RP and BSR is that, in BSR, each
individual PIM-SM router performs its own elections of RPs.

Configuring a BSR
As stated on a previous slide, the router in the PIM domain with the highest configured priority becomes the BSR for the
network. Set this priority using the bootstrap-priority command within the [edit protocols pim rp]
configuration hierarchy. The possible values supported are 0 through 255. A value of 0 means that the local router is
ineligible to become the BSR for the network. This value is the default setting within the Junos OS.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Verifying the BSR

In the example on the slide, the BSR at 192.168.50.51 has been elected by all routers in the network based on having a BSR
priority of 50.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Verifying an RP Using BSR

In the example on the slide, the RP at 192.168.50.61 was learned from the BSR. It can support all groups in the 224.0.0.0/
4 range, which is all possible groups. The local router sent PIM control traffic for the 224.7.7.7 group to the RP.
»¿´·¿à±¬®¿·²ò½±³ò¶±
PIM Interfaces
The show pim interfaces command lists the configured and operational interfaces for PIM. Each interface contains
the following information:
Name: The name of the interface;
Stat: The current status (Up or Down) of the interface;
Mode: Whether the interface is in sparse only, dense only, or sparse-dense mode;
IP: Which version of IP is supported on the interface (IPv4 is the default);
V: Which version each interface is using (version 2 is the default);
State: The current state of the interfaceoptions include P2P for all nonbroadcast-capable interfaces, DR if
the interface is responsible for forwarding traffic, or NotDR if the interface is not responsible for forwarding
traffic;
Count: The number of PIM neighbors seen on the interface; and
DR Address: The address on the network link of the current DR.
»¿´·¿à±¬®¿·²ò½±³ò¶±
PIM Neighbors
The show pim neighbors command displays information about neighboring routers running PIM.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Displaying PIM Join States

The show pim join extensive command displays the (S,G) state for both shared and source trees. The use of the
shared RP tree, which is a (*,G) state, is indicated with entries using an asterisk (*) as a source address. In addition, we see
RPF information such as the interfaces on which the group should be received (Upstream interface) and on which they
should be transmitted (Downstream interface). Finally, the current state of PIM can be viewed using the Upstream
state information. On the slide, the router is currently on the SPT and RPT as noted by the Join to RP output.
You can use the clear pim join command to flush the join state of all multicast groups or a specified range of groups.
Group activity causes the router to rejoin shared and source trees as needed.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Is Multicast Traffic Flowing?

The command on the slide shows that the router is currently forwarding multicast traffic destined for 224.7.7.7 at a rate of
262 packets per second.
»¿´·¿à±¬®¿·²ò½±³ò¶±
RPF Table
To determine which table the router is currently using for RPF checks, use the show multicast rpf command. The slide
shows that the router is using inet.0 for RPF checks.
RPF Lookup Cache

Once a router performs a passing RPF check, the lookup is cached in inet.1. You can find a similar entry in the forwarding
table, which is used to forward future multicast packets from the same source and destination.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Implementing PIM-SM Lab

The slide lists the objectives for the lab.

PIM-SM Using the SSM Model

»¿´·¿à±¬®¿·²ò½±³ò¶±
Distinguishing SSM from ASM

This slide shows the new terminology used in the SSM model. One major change that you should notice is that the address
identifier is no longer just a group address. Instead, it is a combination of both a unicast source address and a multicast
group address. It is the addition of the unicast source address that ensures that every channel is globally unique. This
means that similar to the 239/8 group address space, an administrator can freely use the 232/8 address space without
having to register with Internet Assigned Numbers Authority (IANA). However, there is no need to scope the 232/8 address
space (filter at the edges of the AS) because of the global uniqueness caused by any group from that range being associated
with a unicast source.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Guarantees for 232/8

To support SSM, PIM-SMs behavior has been slightly modified to support SSMs channeled nature. To support SSM, it is
necessary that the many-source-to-many-receiver functionality called for in the original multicast specification is removed for
the 232/8 group range. The slide lists the new behavior of a PIM-SM router when dealing with the 232/8 address range.

SSM Requirement and Features

To support the delivery of multicast traffic destined for the SSM range, a receiver and associated DR must support Internet
Group Management Protocol version 3 (IGMPv3). A router ignores any IGMPv1 or v2 report that specifies a group from the
SSM range. However, with the Junos OS, it is possible for you to allow for SSM forwarding behavior from groups outside of the
SSM range when using IGMPv1 and v2. Subsequent slides show how to accomplish this task with the use of an ssm-map.
Because a receiver is expected to notify the DR of the desired source, there is no need for an RP. The DR, learning the source
from the receivers IGMPv3 report, uses PIM-SM to join the SPT. However, it is possible to support ASM and SSM models side
by side in a network. To do so would require the use of an RP.
As stated in a previous slide, an administrator can freely use the 232/8 range because its uniqueness is guaranteed by its
association with a unicast source.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Adding a Receiver in the SSM Model

The slide shows how the receivers DR, upon receiving an IGMPv3 report, builds an SPT. The RP is not needed in the case of
SSM.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Always an SPT
The slide shows the resulting SPT between the source and a particular receiver for a particular channel (S,G) that yields
optimal forwarding.
Notice that R5 must maintain only (S,G) state for the SPT. It no longer needs to maintain (*,G) state for an RPT. Because any
additional receivers also specify a specific source, there is no need to maintain an RPT.
»¿´·¿à±¬®¿·²ò½±³ò¶±
SSM Configuration
Notice that the PIM-SM configuration on the slide is minimal, with no RP configuration necessary. To support the SSM range
of addresses, you must configure IGMPv3 on the receiver-facing interface of the receivers DR.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Allowing for IGMPv1 and IGMPv2 Without an RP

The slide shows how IGMPv1 and IGMPv2 can still be supported in a network without RPs.

We Discussed:
Basic multicast routing protocol terminology;
PIM-SM operation and configuration when using the ASM model; and
PIM-SM operation and configuration when using the SSM model.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Review Questions
1.
2.
3.
4.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Implementing SSM Lab

The slide lists the objectives for the lab.
»¿´·¿à±¬®¿·²ò½±³ò¶±
1.
At the moment the receivers DR receives the first native multicast packet from the RPT, it learns the source address and joins the SPT.
2.
The RPT must remain active and available in case another source begins sending traffic to the same multicast group address, or if
another receiver wants to join the existing (S,G).
3.
The only dynamic method of learning an RP for PIM version 1 is auto-RP.
4.
The router closest to the receiver never initiates a (*,G) Join message for 232/8. Backbone routers never propagates a (*,G) Join
message for 232/8. RPs do not accept PIM Register messages or (*,G) Join messages for 232/8. A source DR does not send PIM
Register messages to RP for 232/8.
»¿´·¿à±¬®¿·²ò½±³ò¶±
»¿´·¿à±¬®¿·²ò½±³ò¶±
Chapter 10: Class of Service
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Will Discuss:
Environments that might require a modified class of service (CoS) implementation;
Various CoS components and their respective functions;
CoS processing along with CoS defaults on SRX Series devices;
Situations in which various CoS features are used in the enterprise; and
The use of the Real-Time Performance Monitoring tool.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Chapter 102 Class of Service www.juniper.net
CoS Components Review and Case Study

»¿´·¿à±¬®¿·²ò½±³ò¶±
www.juniper.net Class of Service Chapter 103
What Is CoS?
The Junos operating system refers to all facets of quality of service (QoS) as CoS. CoS provides the ability to treat some
packets differently as they transit a network. CoS is an end-to-end mechanism; enabling CoS on one router or one node does
not provide the entire solution. CoS must be implemented in hops from the source to the destination. Any hop along the
transit path of a packet could introduce latency.
Why Use CoS?
The convergence of voice and data networks is critical to characteristics like delay and jitter. On a data network, if a packet
arrives late, or if it arrives out of order, typically not much harm is done. However, in voice communication, packet
transmission is much more sensitive. Imagine participating in a phone conversation where syllables arrive out of order or are
delayed. The communication becomes garbled. This situation makes CoS absolutely necessary for real-time applications like
voice or video. The issue becomes compounded when transferring real-time applications and data across the same network.
Typically, data packets are large and utilize large amounts of bandwidth. CoS is necessary to prevent the data packets from
monopolizing network bandwidth.
»¿´·¿à±¬®¿·²ò½±³ò¶±
CoS Components
The slide illustrates the primary components of CoS. When a packet arrives on the ingress interface of a network device
performing CoS, the device examines certain IP header fields. CoS is able to use the IP header fields to differentiate various
types of traffic into traffic classes. This process is known as classification. Multiple ways exist to classify traffic. Classification
can be performed based on the first 6 bits of DiffServ code point (DSCP) values in the IP type of service (ToS) header, the
first 3 bits of IP precedence values in the IP ToS header, and other IP header fields such as the source IP address,
destination IP address, or port numbers.
Classified packets are assigned to a forwarding class. Forwarding classes are assigned to output queues. In general, the
device assigns packets to forwarding classes or output queues based on the classification of the packet. The slide depicts
different classes of traffic being assigned to different queues. A physical interface contains multiple queues.
Classified traffic is subject to policing. If the total traffic received is greater than what the interface can handle or is greater
than the bandwidth of the interface, then some packets must be dropped. This bandwidth might not be the complete
bandwidth of the interface. For example, assume traffic arrives at a 1 Gigabit Ethernet interface, but somewhere upstream
exists a device interface that can handle only 10 Mbps. If the typical traffic load is more than 10 Mbps of traffic, some of that
traffic will be dropped at the upstream device. Rather than dropping random voice and data packets, ensuring transmission
of the most important 10 Mbps of traffic is better. A policer can provide this type of granular control.
»¿´·¿à±¬®¿·²ò½±³ò¶±
CoS Components (contd.)
Policing, in its simplest form, drops packets. If traffic exceeds the policer limit, the device drops the offending packet.
However, policing can also be configured to assign an offending packet into a specific forwarding class.
Once packets have been classified and examined by a policer, they are assigned to outbound queues. This process is known
as queuing. Each queue is assigned a priority. For example, queue A might have a higher priority than queue B, which might
have a higher priority than queue C, and so forth. Each queue is also assigned a transmit rate. The transmit rate defines how
many packets the queue transmits within a given scheduling interval. The transmit rate is typically defined as a specific
bandwidth or a percentage of the interfaces bandwidth. Queues are allocated a percentage of the physical interfaces
memory to hold packets as needed. This allocation is known as a buffer.
The next stage in the output processing of CoS is the act of rewriting the bit markings. A device can manipulate the various
bits in the ToS header. Rewrite rules facilitate the separation of trust points in the network and allow networks to have a
consistent classification on downstream nodes.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Class of Service with VoIP and Data in the Enterprise

In todays networks, it is quite common to see a mixture of real-time applications and bulk data converged into a single IP
infrastructure. In this case study, users are complaining about voice quality from Site B to Site A. In the next few slides, traffic
classification and queuing settings are reviewed. Changes are then made to the default classification and scheduling to
accommodate the applications sensitive to jitter and loss.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Verify Markings
The engineers in the enterprise know that the VoIP clients are marking the traffic with the expedited forwarding (EF) DSCP
value. In this slide, a firewall filter is created to match EF-marked traffic with an action to count. The filter is applied as input
filter on the interface facing Site A. The counter increments, which confirms that the packets are coming in properly marked.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Default Classifier
When looking at the extensive interface output with the command show interfaces ge-0/0/1 extensive | find
“Queue counters”, the engineers observe that all traffic is classified into the best-effort queue regardless of
markings. The engineers also observed that the SRX Series device is dropping packets in this queue.
When viewing the default classifier with the command show class-of-service classifier type
inet-precedence name ipprec-compatibility, the engineers observed that the EF class is classified into the
best-effort queue.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Using the DSCP Default Classifier

Each type of classifier comes equipped with a default classifier in the Junos OS. If the goal is to modify only some code
points, using the default values should be sufficient. To view the default DSCP classifier, use the command show
class-of-service classifier type dscp name dscp-default.
In this slide, the default DSCP markings are imported into the CoS classifier configuration and applied to the incoming
interface of Site A. This type of classifier is known as a behavior aggregate (BA) classifier.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Default Transmit Queues

After committing the behavior aggregate configuration, the EF class traffic is classified into the queue 1 named
expedited-forwarding, as expected.
Drops in the expedited-forwarding queue continue to occur, though, and end users are still reporting problems. When
viewing the default queues with the show interfaces ge-0/0/1 extensive | find “CoS information”
command, the engineers observe that only queues 0 and 3 have reserved bandwidth.
Queue 0 has reserved 95% of the bandwidth and queue 3 has reserved 5% of the bandwidth with no traffic reservations for
queue 1. This is the default Junos OS configuration for every interface.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Bandwidth Reservation
The expedited-forwarding forwarding class is configured with a higher priority than the other queues and is reserved
the remainder of the bandwidth, which is 12% based on this configuration.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Priority Queue
After committing the CoS configuration, the drops in the expedited-forwarding queue disappear and users stop
complaining of poor voice quality. The queue counters are running counts; to get a fresh snapshot, clear the statistics with
the clear interfaces statistics command. This action clears the statistics for all interfaces; you can optionally
specify a particular interface you want to be cleared.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Priority Scheduler
In this slide, an ingress policer is created for EF class traffic. The policer reclassifies any traffic in excess of 2 Mbps into the
best-effort queue. This is done to keep the EF-class traffic from starving the lower-priority queues.
In SRX Series devices, the configured transmit-rate is only honored for queues in the same priority level. On an SRX Series
device, a high-priority queue can starve other priorities unless it is rate-limited. The same is true for medium-high and
medium, medium low, and so on down the priority chain. We discuss this behavior in subsequent slides.
»¿´·¿à±¬®¿·²ò½±³ò¶±
CoS Processing and CoS Defaults on the SRX Series Device

»¿´·¿à±¬®¿·²ò½±³ò¶±
Ingress CoS Processing

The slide demonstrates ingress and egress CoS packet flow processing through an SRX Series device. The following list
describes a packets ingress flow through the router:
1. BA classification: Packets arriving at the router are first subjected to the BA classification stage. This stage sets
the forwarding class and packet loss priority (PLP) using any of the supported BA classifier types, including IP
precedence, DSCP, Institute of Electrical and Electronics Engineers (IEEE) 802.1P, and so on.
2. Multifield classification: The next processing stage is multifield classification. Here a firewall filter can be
defined to match against numerous packet fields, incoming interfaces, and so on, to set the forwarding class or
PLP, or to override the values set during BA classification.
3. Ingress policing: When desired, a firewall or interface-level policer can be applied to limit matching traffic by
discarding, by reclassification, or by marking excess traffic with a loss priority of high. This means that, in the
event of congestion, a random early detection (RED) profile can be used to more aggressively drop PLP high
traffic.
4. Forwarding policy: The last ingress processing stage is forwarding policy. This policy can alter the existing
forwarding class or PLP setting, and it can be used to select a forwarding next hop based on a forwarding class,
a feature called class-of-servicebased forwarding (CBF).
»¿´·¿à±¬®¿·²ò½±³ò¶±
Egress CoS Processing
The following list describes a packets egress flow through the router:
1. Egress policing: After the route lookup, a packet begins its journey toward the selected egress interface. The
first egress CoS processing state is output policing, which is again based on either a firewall or an
interface-level policer. Once again, excess traffic can be discarded or marked with a loss priority for later discard
in the event of congestion.
2. Queuing and scheduling: The queuing stage involves placing packet notifications into the corresponding
forwarding class queue, where they are serviced by a scheduler that factors priority and configured weight to
determine when a packet should be dequeued from a given queue.
3. (W)RED/Congestion control: The next CoS processing stage involves a weighted random early detection (WRED)
drop decision, based on protocol, loss priority, and average queue fill level. RED tends to operate at the head of
the queue, and a RED decision is made against each packet selected for transmission by the scheduler stage.
4. Rewrite marker: The final stage is the rewrite marker stage and it allows you to alter one packet field, or in some
cases multiple packet fields, as the packet is transmitted to downstream nodes. Normally, you rewrite packet
fields to accommodate downstream BA-based classification. Rewrite markers are indexed by protocol family
and by forwarding classfor example, writing a 001 pattern into the precedence field of all family inet packets
that are classified as best effort (BE).
»¿´·¿à±¬®¿·²ò½±³ò¶±
Classification Based on Layer 2 and Layer 3 Fields

As shown on the slide, there are various Layer 2 and Layer 3 fields supported by BA classification. Some combinations of BA
classifiers simply make no sense and are mutually exclusive; for example, you cannot apply both an IP precedence and a
DSCP classifier to the same logical interface at the same time.
Default Values
BA classification can be populated by default values. The operational command show class-of-service
classifier displays all the default values and configured values.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Behavior Aggregate Configuration

A behavior aggregate classifier is first defined under the [edit class-of-service classifiers] hierarchy. The
loss-priority (PLP) bit is set for internal operations and the code-point is matched depending on which type of field is
matched. In the example on the slide, an inet-precedence type has been configured to match on code-points 001
and set the loss-priority to low.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Multifield Classifier
A multifield classifier is implemented through a firewall filter. You use this filter to perform multifield classification by
associating a set of match criteria to a then forwarding-class action. To activate multifield classification, the filter is
applied as an input filter on an ingress interface. Because BA classification is always performed first, you can always apply a
multifield classifier in combination with any BA classifier. In case of conflict, the forwarding class associated with the BA
match is overwritten by the multifield classifier's choice of forwarding class.
Multifield Classifier Configuration

In the slide, port 17000 and UDP traffic are matched and set to the assured-forwarding queue. The loss-priority
is set to low.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Rewrite Marker
One of the most important design goals for Enterprise CoS is to enable classification and marking close to the edge of the
network. Doing so simplifies the classification logic and configuration on the rest of the routers in the network.
Default Markings
As with behavior aggregates, a rewrite configuration can be populated with the default values. These values can be viewed
with the show class-of-service rewrite-rules operational command.
Rewrite Rule Configuration

In the example on the slide, a DSCP-type rewrite rule is created and the default values are imported. An explicit rewrite rule is
created for packets in the best-effort queue with loss-priority set to low and code-point set to 000001. Keep
in mind that any explicit rule you configure will override imported default values.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Scheduling and Queuing

Because different transmit weights can be assigned, the SRX Series devices implement a modified deficit round-robin
(MDRR) scheduler defined by three variables.
Buffer size: This is the delay buffer for the queue that allows it to accommodate traffic bursts. You can configure
a buffer size as a percentage of the output interface's total buffer capacity or as a temporal value from 1
200,000 microseconds, which simply represents buffer size as a function of delay, rather than bytes.
Quantum: The quantum is the number of credits added to a queue every unit of time and is a function of the
queue's transmit weighting. The queue's transmit rate specifies the amount of bandwidth allocated to the
queue and can be set based on bits per second or as a percentage of egress interface bandwidth. By default, a
queue can be serviced when in negative credit, as long as no other queues with the same priority have traffic
pending. When desired, you can rate-limit a queue to its configured transmit rate with inclusion of the exact
option. MDRR uses a deficit counter to determine whether a queue has enough credits to transmit a packet. It
is initialized to the queue's quantum, which is a function of its transmit rate, and it is the number of credits that
are added to the queue every quantum.
Priority: The priority can be low, medium-low, medium-high, high, or strict-high, and it determines the sequence
in which queues are serviced. The scheduler services high-priority queues before it addresses any low-priority
queues.

Per-Unit Scheduler
By default, when you apply a scheduler to an interface, it takes effect at the port, or interface device (ifd) level. This is fine
when the port in question is configured with a single logical interface (ifl), such as would be the case when running Cisco
High-Level Data Link Control (HDLC) or the Point-to-Point Protocol (PPP). However, when the interface is partitioned into
multiple logical unitsfor example, as the result of adding virtual LAN (VLAN) taggingyou need to use the
per-unit-scheduler option. This option provides fine-grained queuing by creating a set of queues and an associated
scheduler for each logical interface.

Scheduler Configuration
In this slide, a scheduler named test is configured. The scheduler has a high priority, a transmit-rate of 50% of the
total interface speed, and a buffer-size of 30% of the total interface buffer. A drop profile named high-drop is
referenced for any packets that are marked with a loss-priority (PLP) of low. The scheduler is then mapped to the
forwarding-class expedited-forwarding and applied to the ge-0/0/0 physical interface.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Configuring the Scheduler Transmission Rate

The transmission rate control determines the actual traffic bandwidth from each forwarding class you configure. The rate is
specified in bits per second (bps). Each queue is allocated some portion of the bandwidth of the outgoing interface. This
bandwidth amount can be a fixed value, such as 1 megabit per second (Mbps), a percentage of the total available
bandwidth, or the rest of the available bandwidth.
To configure transmission scheduling, include the transmit-rate statement at the [edit class-of-service
schedulers scheduler-name] hierarchy level. You can specify the transmit rate as follows:
transmit-rate rate: Transmission rate, in bits per second. The rate can be from 3200 through
160,000,000,000 bps.
transmit-rate percentage: Percentage of transmission capacity.
transmit-rate remainder: Use remaining rate available.
exact Option
You can, optionally, enforce the exact transmission rate or percentage you configure with the transmit-rate rate or
transmit-rate percent statement. Under sustained congestion, a rate-controlled queue that goes into negative credit
fills up and eventually drops packets. Note that, in the configuration, you cannot combine the remainder and exact
options.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Configuring the Scheduler Buffer Size

To control congestion at the output stage, you can configure the delay-buffer bandwidth. The delay-buffer bandwidth
provides packet buffer space to absorb burst traffic up to the specified duration of delay. Once the specified delay buffer
becomes full, packets with 100 percent drop probability are dropped from the head of the buffer.
To configure the buffer size, include the buffer-size statement at the [edit class-of-service schedulers
scheduler-name] hierarchy level. For each scheduler, you can configure the buffer size as one of the following:
A percentage of the total buffer: The total buffer per queue is based on microseconds and differs by platform
type. Use the percent percentage option.
The remaining buffer available: The remainder is the buffer percentage that is not assigned to other queues.
In the example on the slide, we have assigned 40 percent of the delay buffer to the sched-best scheduler,
allowed sched-network to keep the default allotment of 5 percent, and assigned the remainder to
sched-exped. With this configuration, the sched-exped scheduler will use approximately 55 percent of the
delay buffer.
A temporal value, in microseconds: For the temporal setting, the queuing algorithm starts dropping packets
when it queues more than a computed number of bytes. This maximum is computed by multiplying the logical
interface speed by the configured temporal value. This value differs by platform; please refer to the
documentation for your particular device.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Congestion Control with WRED

The general goal of WRED is to perform indiscriminate drops on traffic. By default, the Junos OS applies a 100% drop at
100% fill, effectively disabling RED on that queue. This can potentially cause TCP global synchronization issues in the
network.
Configured with drop-profiles

A drop profile is configured under the [edit class-of-service] hierarchy and referenced in the scheduler.
Juniper supports up to four drop profiles. The drop profiles can be referenced based on a traffic type of TCP, or UDP, or both,
with a loss-priority (PLP) of high or low. The result is a weighting of RED drop actions, based on traffic type.
drop-profiles Configuration
On a previous slide, the scheduler referenced a drop profile named high-drop for any traffic with a loss-priority of
low. Under the [edit class-of-service] hierarchy, a drop profile named high-drop is configured with a
fill-level of 40% with a drop-probability of 0%, a fill-level of 50% with a drop-probability of 10%,
and a fill-level of 70% with a drop-probability of 20%.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Junos CoS Defaults

The Junos OS comes with a set of default CoS settings that are designed to ensure that both transit and control plane traffic
are properly classified and forwarded. The default CoS setting supports two forwarding classes (BE and network control [NC])
and implements an IP precedence-style BA classifier that maps NC traffic into queue 3 while all other traffic is placed into
queue 0 as BE. A scheduler is placed into effect on all interfaces that allocates 95% of the bandwidth to queue 0 and the
remaining 5% to queue 3. Both of the queues are low priority, which guarantees no starvation in either platform.
A default WRED profile with a single loss point is placed into effect. The 100% drop at 100% fill setting effectively disables
WRED.
No IP packet rewrite is performed with a default CoS configuration. Packets are sent with the same markers as when they
were received.
The default CoS configuration defines four forwarding classes: BE, EF, assured forwarding (AF), and NC, which are mapped to
queues 0, 1, 2, and 3, respectively. However, as noted earlier, there is no default IP classification that will result in any traffic
being mapped to either the AF or the EF class. This is good because, as also noted earlier, no scheduling resources are
allocated to queues 1 or 2 in a default CoS configuration. Some very interesting and difficult-to-solve problems occur if you
begin to classify AF or EF traffic without first defining and applying schedulers for those classes. Doing so typically results in
intermittent communications for the AF/EF classes; this intermittency is tied to the loading levels of the BE and NC queues,
given that when no BE or NC traffic exists, more AF/EF traffic can be sent, despite the 0% default weighting.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Default Classification
The Junos OS creates a complete set of BA classifier and rewrite marker tables for each supported protocol family and type,
but most of these tables are not used in a default CoS configuration. For example, there is both a default IP precedence (two,
actually) and a default DSCP classifier and rewrite table. You can view default and custom tables with the show
class-of-service classifier or the show class-of-service rewrite-rule command.
The default values in the various BA classifier and rewrite tables are chosen to represent the most common/standardized
usage. In many cases, you will be able to simply apply the default tables. Because you cannot alter the default tables, it is
suggested that you always create custom tables, even if they end up containing the same values as the default table. This
does not involve much work, given that you can copy the contents of the default tables into a custom table and, in the future,
you will be able to alter the custom tables as requirements change.
In a default configuration, input BA classification is performed by the ipprec-compatibility table and IP rewrite is in
effect. As a result, the ToS marking of packets at egress match those at ingress.

Policing
»¿´·¿à±¬®¿·²ò½±³ò¶±
Token Based
To rate-limit traffic entering an interface, you can deploy a policer. Implemented policers are token based and use the IP
packet to limit based on bandwidth and bursts. Bandwidth is measured as the average number of bits over a one-second
interval.
Burst Size
The burst size will set the initial and maximum sizes of a bucket in bytes (tokens) that would be accessed each time data
needs to be sent. As a packet is sent, the bucket bytes (tokens) are removed from the bucket. If there are not enough tokens
to send the packet, the packet is policed. The bucket is then replenished at the bandwidth rate.
Policer Actions
Once the policer limits have been configured, you must choose the action taken if a packet exceeds the policer limit. Two
types of policing are available: soft policing and hard policing. Hard policing specifies that the packet will be dropped if it
exceeds the policer's traffic profile. Soft policing simply marks the packet or reclassifies the packet, which could change the
probability of the packet being dropped at the egress interface during times of congestion. Soft policing is implemented by
either setting the packet loss priority (PLP) setting on the packet or by placing the packet into a different forwarding class.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Policing in the Enterprise Case Study

The following tasks are set to be accomplished in this case study. All configuration is done on the customer premises
equipment (CPE) device.
Drop traffic destined to port 80 if going over 5 Mbps.
Set the loss-priority to high and classify to the best-effort queue if traffic in the EF class exceeds
10 Mbps.
The rest of the traffic should be sent to the best-effort queue and loss-priority set to high if
exceeding 15 Mbps.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Rate Limit Web Browser Traffic

One of the goals of this enterprise is to hard-limit all traffic destined to the Hypertext Transfer Protocol (HTTP) port to 5 Mbps.
A policer named port80 is created with a bandwidth-limit of 5 Mbps and a burst-size-limit of 62500 bytes per
second. The policer is then referenced in a firewall filter named RemoteSites and a term matching destination-port
http (80), with an action of then policer port80.
Omitting the interface-specific statement and applying the same filter to multiple interfaces results in a shared
policer, which in this example would cap the aggregate EF class rate to 5 Mbps.
The setting of the burst-size-limit has always seemed to be a mystery for many operators. Set this value too low, and
potentially all packets will be policed. Set the value too high, and no packets will be policed. The rule of thumb is that the
burst-size-limit should never be lower than 10 times the maximum transmission unit (MTU). The recommended
value is to set the amount of traffic that can be sent over the interface in five milliseconds. So, if your interface is a Fast
Ethernet interface, the minimum is 15,000 bytes (10 * 1,500), and the recommended value would be 62,500 bytes
(12,500 bytes/ms * 5).
»¿´·¿à±¬®¿·²ò½±³ò¶±
Rate Limit EF Class Traffic

In this configuration, a policer named voice is created that, if it exceeds 10 Mbps of traffic, classifies the exceeding traffic
as best-effort and sets the loss-priority (PLP) bit to high.
A term named voice matching traffic with DSCP class ef is created with an action of then policer voice.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Limit All Traffic

The last task is to limit all other traffic to 15 Mbps. If this limit is exceeded, set the loss-priority to high and classify
the traffic into the best-effort forwarding-class.
In the configuration, a policer named all is created with the appropriate criteria for the task. The policer is then used in a
term named all created on the same firewall filter used in the previous slides. No matching criteria is used for the term;
thus it matches all traffic.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Applying the Firewall

When all the tasks are configured as policers and referenced in the firewall filter, the filter is then applied as input on the
interfaces facing the remote sites.

Verifying the Policers

Policers that are referenced in a firewall filter automatically get counters created for them based on the policer name,
interface applied, and direction. You can view these counters with the show firewall command.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Virtual Channels
»¿´·¿à±¬®¿·²ò½±³ò¶±
Virtual Channels
Virtual channels are used to ensure that a central site with a high bandwidth connection does not overrun remote sites that
access the network at slower rates.
Used in Frame Relay Networks

In a Frame Relay service, the absolute limit on data transfer rate is the logical port speed, which can be lower than the
transmission link's physical bit rate. This means that a central site can have a full T1 line rate available and a remote site is
using a fractional T1 (FT1) circuit to access the provider, but pays for only 128 kilobits per second (Kbps) of port speed and
can use only 128 Kbps of the T1's capacity. Regardless of the committed information rate (CIR) or the state of network
congestion, the remote site is physically limited to the reception of no more that 128 Kbps of traffic. The problem, if not
already obvious, is that the central site can easily burst to full T1 rates, and if these bursts are of any appreciable duration,
massive loss will result because of buffer overflow in the network. This causes TCP-based sources to sense congestion and
throttle back. If not corrected, this can lead to an ongoing boom/bust cycle as the sources ramp up, sense loss, and then
ramp back down, resulting in diminished throughput and higher latency because of buffering within the network
Configured at the Central Site

All configuration of the virtual channels is done at the central site with the high-speed access.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Virtual Channel Example: Part 1

In the diagram on the slide, the central site terminates at a T1 switch port in the service providers network, while the remote
sites are terminated at significantly lower speeds.
»¿´·¿à±¬®¿·²ò½±³ò¶±

Two virtual channels are defined, one for each remote site. In the slide, Site A is set as the default virtual channel. Traffic that
is routed out the logical interface to which the virtual-channel-group is applied will default to the virtual channel for
Site A, unless directed through a firewall filter to Site B.
A virtual-channel-group configuration links multiple virtual channel definitions together for application to a logical
interface. In the example, the cloud-group configuration links the siteA-default and siteB definitions, much like a
scheduler-map links multiple scheduler policies. When applied to a logical interface, eight queues are created for each
virtual channel associated with the group, and a scheduler-map is used to control scheduling into each set of
per-virtual-channel queues. This example shapes each virtual channel to the remote site's port speed, but if desired, some
virtual channels can be left unshaped to allow bursting up to physical interface speed.
»¿´·¿à±¬®¿·²ò½±³ò¶±

The virtual-channel-group is applied to an interface at the logical unit level. You cannot commit the configuration
unless you remove any shaping or scheduler-map configuration on the same logical unit.


The final step in the virtual-channel configuration is the definition of the filter that directs traffic to the correct
virtual-channel, where it is in turn shaped according to the remote site's port speed. Recall that one
virtual-channel in each group must be designated the default virtual-channel, which means it is used when no
explicit virtual-channel mapping is found.
The vc_select filter matches on packets addressed to Site B and directs them to the
scheduler/shaper associated with the Site B virtual-channel. Any traffic not matched by the vc_select term is
matched by the default term, which results in a mapping to the default virtual-channel. The vc_select filter is
placed into service in the output direction.
The per-unit-scheduler option must be enabled on the physical interface to support scheduling into each virtual
channel.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Monitoring with Resource Performance Monitoring

»¿´·¿à±¬®¿·²ò½±³ò¶±
Resource Performance Monitoring

Real-time performance monitoring (RPM) enables you to monitor network performance in real time and to assess and
analyze network efficiency. Typically, network performance is assessed in real time based on the jitter, delay, and packet loss
experienced on the network.
Uses Probes and a Client-Server Model Approach

RPM is a service available in the Junos OS that enables a router to measure metrics such as round-trip delays and
unanswered echo requests. To achieve this, RPM exchanges a set of probes with other IP hosts in the network for monitoring
and network tracking purposes. These probes are sent from a source node to other destination devices in the network that
require tracking.
Measure Multiple Traffic Attributes

Data such as transit delay and jitter can be collected from these probes, and this data can be used to provide an
approximation of the delay and jitter experienced by live traffic in the network. Different live traffic metrics like round-trip
time (RTT), positive egress jitter, negative egress jitter, positive ingress jitter, negative ingress jitter, positive round-trip jitter,
and negative round-trip jitter can be gleaned from the results. RPM calculates minimum, maximum, average, peak-to-peak,
standard deviation, and sum calculations for each of these measurements.
»¿´·¿à±¬®¿·²ò½±³ò¶±
RPM Configuration Example: Part 1

RPM in its most simplistic form can be described as having a client (source) that sends out probe queries and a server
(destination) that responds. During a probe, the client device sends a packet across to a remote server, which in turn returns
the packet with an acknowledgment to the sender. Both the type and content of the queries sent from the client are user
configurable. Both the source and destination nodes running RPM services are aware that the packets in the probe are used
to compute information such as RTT and jitter delay. For each probe, RPM makes several measurements (for RTT as well as
for different positive and negative jitter). For each type of measurement, RPM calculates the minimum, maximum, average,
peak-to-peak, standard deviation, and overall sum over several different collections of measurements. For example, some of
these collections include the current test, the most recently completed test, a moving average of n number of most recent
probes, as well as all tests performed (including the one in progress).
In the example on the slide, a probe named test_probe is configured for SRX-1. The probe defines a test named
udp_test that uses UDP packets as indicated by the udp-ping option. The probe is set to run 15 times with a two-second
interval. Furthermore, it is configured to mark the packets with the EF DSCP class and, if 5 packets are lost, an SNMP trap is
generated. The remote device, SRX-2, is configured as an RPM server to listen for UDP packets on port 52000.
»¿´·¿à±¬®¿·²ò½±³ò¶±

Probes can be one of the following types:
udp-ping-timestamp: UDP timestamp requests sent to target address.
udp-ping: UDP packets sent to target.
tcp-ping: TCP packets sent to target.
icmp-ping: Internet Control Message Protocol (ICMP) echo requests sent to target address.
icmp-ping-timestamp: ICMP timestamp requests sent to target address.
http-get: HTTP get requests sent to target URL.
http-metadata-get: HTTP get request for metadata to target URL.
Note that the icmp-ping option is the default probe type on devices running the Junos OS.
An RPM measurement can consist of multiple tests, each consisting of a different probe type and exchanged between a
particular source-destination IP address pair. The interval between the probes and the tests is user configurable, as is the
content of the probes data portion. The user can also control the number of probes that belong to a test. The probe packets
are timestamped with the times at which they are sent and received at both the source and destination endpoints.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Timestamps
Timestamping is needed to account for any latency in packet communications. Timestamps are applied on the client, the
server, or both the client and server. All nodes in the network must be synchronized to a common, accurate clock source
(preferably a Stratum 3 level) using Network Time Protocol (NTP). The probe types that support timestamping functionality
include:
icmp-ping;
icmp-ping-timestamp;
udp-ping; and
udp-ping-timestamp.
The timestamping activity consists of the source (client) node applying a timestamp to the RPM packets with the time at
which they leave the node. The destination (server) node applies a second timestamp when it receives the probe and a third
timestamp when the probe leaves the destination back to the source. The source receives the response and applies a fourth
timestamp. Different metrics are calculated based on these timestamps collected from a series of probes.
»¿´·¿à±¬®¿·²ò½±³ò¶±

Typically, a homogeneous set of probes, collectively called a test, is configured for each device on the network, and the
information collected from these tests is stored in the Ping Management Information Bases (MIBs) and the RPM MIB.
The probed target is specified using its IP version 4 (IPv4) address, and each probed target is monitored over the course of a
test that contains multiple probes. During a test, probes are generated and responses collected at a rate defined by the
probe interval. A probe is considered lost if the probe interval expires before a response is received.
You can see the results of a test using the show services rpm probe-results operational command.
Each configured test is displayed. Results are displayed in alphabetical order, sorted first by owner name and then by test
name.
»¿´·¿à±¬®¿·²ò½±³ò¶±

Polling can also be done from an SNMP network management system (NMS) device. Historical graphs with information given
by the probes can be created with the polling information. This helps engineers build network baselines and aids in
troubleshooting network performance issues. A trap server can also be configured to notify network personnel for the
various configured thresholds under the RPM configuration. A full explanation of how to configure an NMS device for RPM
polling is beyond the scope of this course.
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Discussed:
Environments that might require a modified CoS implementation;
The various CoS components and their respective functions;
The CoS processing along with CoS defaults on SRX Series devices;
Situations in which some CoS features are used in the enterprise; and
The use of the Real-Time Performance Monitoring tool.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Review Questions
1.
2.
3.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Implementing CoS Features in the Enterprise Lab

»¿´·¿à±¬®¿·²ò½±³ò¶±
1.
Behavior aggregate classification is performed first. Because a multifield classifier is processed after a behavior aggregate classifier, the
multifield classifier can overwrite conflicting values.
2.
The loss priority status is an internal flag that is set based on classification or policing actions.
3.
A policer can drop a packet or set the forwarding class and loss priority bit.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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
»¿´·¿à±¬®¿·²ò½±³ò¶±
www.juniper.net
Appendix A: BGP Route Reflection
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Will Discuss:
The operation of BGP route reflection; and
How to configure a route reflector.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Appendix A2 BGP Route Reflection www.juniper.net
Route Reflection Operation

»¿´·¿à±¬®¿·²ò½±³ò¶±
www.juniper.net BGP Route Reflection Appendix A3
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 autonomous system (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 re-advertising 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 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 must 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 appendix explores the configuration and operation of route reflection.
»¿´·¿à±¬®¿·²ò½±³ò¶±
IBGP Peers Can Re-Advertise Routes

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

RRs only re-advertise 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 RRthey 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 is loop prevention. This is 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.
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 re-advertises the routes to both clients and non-clients. The RRs cluster ID is
»¿´·¿à±¬®¿·²ò½±³ò¶±
added to all routes that the RR touches, meaning that both clients
attribute contains a sequence of all
clients and non-clients receive the cluster list attribute. This
all cluster IDs that represent all RRs that have handled the route update.

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; and
3. Because route reflection allows IBGP peers to send routes to other IBGP peers, RR2 sends the routes to RR3.
RR3 has no way of knowing the routes received from RR2 came from RR1. As a result, RR3 sends them to RR1, forming a
loop.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Configuration and Routing Knowledge

»¿´·¿à±¬®¿·²ò½±³ò¶±
Clients in a Peer Group

Within the Junos operating system configuration syntax, all clients of an individual RR are placed within a single peer group.
This placement allows the RR to easily determine which peers are clients of a particular cluster. No configuration changes
are needed in the clients configuration.
RR Uses the cluster Command

Once the clients are placed into their respective peer groups, the cluster command activates the route-reflection process.
Use the cluster command 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 a single RR exists in the cluster, the router ID of the RR 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 RRs in that cluster are now stored because the receiving RR 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.
Clients Peer to RRs

The clients in the cluster must peer to the RR itself. Clients have no knowledge of the cluster and see the reflector as a
regular IBGP peer. »¿´·¿à±¬®¿·²ò½±³ò¶±
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 RR for the local
cluster. The RRs 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 clusters RR (RR1).
The slide details how the 10.10.10.0/24 route is re-advertised to all other clients in the cluster as well as to all non-client
IBGP peers of the RR. This process applies to all other routes the RR receives from a client in its cluster.
This slide shows how the other RRs in the network (RR2 and RR3) re-advertise all routes received from IBGP peers (the other
reflectors in this example) to all of their cluster clients.

Dual RRs in a Cluster

The slide shows a cluster containing two RRs. This type of cluster design is popular because it avoids a single point of
network failure. When a cluster has only a single RR, 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 configures two IBGP peers and forwards EBGP-learned routes to both RRs. The RRs
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 RRs also establishes IBGP peering sessions with the other RRs in the entire AS.
As previously mentioned, a debate exists as to whether each RR should be assigned the same cluster ID or a 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 RRs. This generally does not outweigh the advantage of maintaining connectivity.

Hierarchical Route Reflection

The slide shows an AS network using a more complex, hierarchical, route-reflection topology.
Hierarchical route reflection occurs when the RRs 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 RR full mesh might evolve into a route-reflection cluster.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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 RR. 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 RR. Because the extra copy of the route from the reflector is not needed, you can disable the internal cluster
re-advertisements using the no-client-reflect command. Once configured, the RR only forwards, to the clients,
routes that arrive from outside of the cluster.

RR Can Modify Attributes

The default operation of a RR 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 RR re-advertises 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 clusters RR, the RR itself does not have to be in the forwarding path for packets
sent from clients toward the route destination. In fact, oftentimes 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 clusters RR with the
BGP next hop set to its router ID. Because an active next-hop-self policy exists on the RR, the BGP next hop is overwritten
with the router ID of the RR172.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 RR also has
EBGP peering sessions established. Most network designs avoid this problem by placing their RRs within the core of their
networks.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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]
user@router# show policy-statement selective-nhs
term only-EBGP-routes {
from {
protocol bgp;
neighbor 172.16.0.1;
}
then {
next-hop self;
}
}
»¿´·¿à±¬®¿·²ò½±³ò¶±
Case Study: RFC 3345 OscillationPart 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 because of the 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Case Study: RFC 3345 OscillationPart 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
> 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
> to 10.0.0.2 via ge-1/0/4.0
user@R1> show route advertising-protocol bgp 192.168.10.2

Prefix Nexthop MED Lclpref AS path
* 200.0.0.0/24 192.168.10.4 1 100 6 100 I
»¿´·¿à±¬®¿·²ò½±³ò¶±

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.

AS path: 6 100 I
> to 40.0.0.2 via ge-1/0/4.0
AS path: 6 100 I
> to 30.0.0.1 via ge-1/1/2.0

* 200.0.0.0/24 »¿´·¿à±¬®¿·²ò½±³ò¶±
192.168.10.5 0 100 6 100 I


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:

* 200.0.0.0/24 192.168.10.3 10 100 10 100 I
»¿´·¿à±¬®¿·²ò½±³ò¶±

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 because of the 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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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:


AS path: 6 100 I
> to 20.0.0.2 via ge-1/0/5.0
AS path: 10 100 I
> to 10.0.0.2 via ge-1/0/4.0

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

AS path: 10 100 I
> to 10.0.0.2 via ge-1/0/4.0
AS path: 6 100 I
> 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
> to 20.0.0.2 via ge-1/0/5.0

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

AS path: 6 100 I
> 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
> to 10.0.0.2 via ge-1/0/4.0


AS path: 6 100 I
> to 20.0.0.2 via ge-1/0/5.0
AS path: 10 100 I
> to 10.0.0.2 via ge-1/0/4.0
»¿´·¿à±¬®¿·²ò½±³ò¶±

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.
AS path: 6 100 I
> to 30.0.0.2 via ge-1/1/2.0
AS path: 10 100 I
»¿´·¿à±¬®¿·²ò½±³ò¶±
> to 10.0.0.2 via ge-1/0/4.0


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.
»¿´·¿à±¬®¿·²ò½±³ò¶±
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.
AS path: 10 100 I
> to 10.0.0.2 via ge-1/0/4.0
AS path: 6 100 I
> to 30.0.0.2 via ge-1/1/2.0
AS path: 6 100 I
> to 20.0.0.2 via ge-1/0/5.0
»¿´·¿à±¬®¿·²ò½±³ò¶±
We Discussed:
The operation of BGP route reflection; and
How to configure an RR.
»¿´·¿à±¬®¿·²ò½±³ò¶±
Review Questions
1.
2.
3.
4.
»¿´·¿à±¬®¿·²ò½±³ò¶±
BGP Route Reflection Lab

The slide lists the objective for this lab.
»¿´·¿à±¬®¿·²ò½±³ò¶±
1.
The Cluster List attribute and Originator ID attribute support route reflection.
2.
The cluster statement is configured only on the route reflector.
3.
The no-client-reflect command can be used to stop excess advertisements.
4.
An RR re-advertises routes received from clients and non-clients, adding the cluster-ID attribute and the cluster-list attribute.
»¿´·¿à±¬®¿·²ò½±³ò¶±
»¿´·¿à±¬®¿·²ò½±³ò¶±
Acronym List
ABR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . area border router
AF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . assured forwarding
AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . autonomous system
ASBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . autonomous system boundary router
ASM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . any-source multicast
BE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . best effort
BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol
BGP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol version 4
CBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .class-of-service-based forwarding
CBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . connection-based forwarding
CIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . committed information rate
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface
CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .class of service
C-RP-adv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .candidate RP advertisement
CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . class selector
DR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .designated router
DSCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DiffServ code point
DVMRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Distance Vector Multicast Routing Protocol
EGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . exterior gateway protocol
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface
HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .High-Level Data Link Control
IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Internet Assigned Numbers Authority
IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . internal BGP
IGMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Group Management Protocol
IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . interior gateway protocol
IPsec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IP Security
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IP version 4
ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet service provider
JNCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Juniper Networks Certification Program
LSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link-state advertisement
LSDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link-state database
MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .media access control
MDRR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . modified deficit round-robin
MOSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Multicast Open Shortest Path First
NC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network control
NLRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network layer reachability information
NSSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . not-so-stubby area
OSPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Shortest Path First
PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .process ID
PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Independent Multicast
PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Point-to-Point Protocol
QoS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . quality of service
RID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . router ID
RP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . rendezvous point
rpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . routing protocol daemon
RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . reverse path forwarding
RPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . reverse-path multicasting
RR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .route reflector
SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Network Management Protocol
SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .shortest-path-first
SPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . shortest path tree
SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .source-specific multicast
ToS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . type of service
TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . time-to-live
www.juniper.net Acronym List ACR1

»¿´·¿à±¬®¿·²ò½±³ò¶±
ACR2 Acronym List www.juniper.net

AJER-12.a Student Guide Volume 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AJER-12.a Student Guide Volume 2

Uploaded by

Copyright:

Available Formats

»¿´·¿à±¬®¿·²ò½±³ò¶±

Worldwide Education Services

1133 Innovation Way

Course Number: EDU-JUN-AJER

Advanced Junos Enterprise Routing Student Guide, Revision 12.a

Chapter 5: BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Chapter 6: BGP Attributes and Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

Chapter 7: Enterprise Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

Chapter 8: Introduction to Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

Chapter 9: Multicast Routing Protocols and SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1

Chapter 10: Class of Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Appendix A: BGP Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-1

www.juniper.net Contents  iii

www.juniper.net Course Overview  v

CLI and GUI Text

Style Description Usage Example

Courier New Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Defined and Undefined Syntax Variables

Style Description Usage Example

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

Education Services Offerings

BGP Peering Sessions

BGP Message Types

High-Level BGP Example

ISP As Network

ISP A Advertises Its Aggregate

Customer Bs Aggregate

Customer B Becomes Multihomed

[edit protocols bgp]

Hitless Key Rollover

BGP Route Tables

BGP Active Routes

Default BGP Advertisement Rules

IBGP Route Propagation

IBGP Next-Hop Propagation

BGP Next-Hop Solutions

Load Balancing Options

Chapter 528  BGP www.juniper.net

Router ID and Peer ID Ignored

Single Next Hop for All Routes

BGP Multihop Peering

Accepting Remote Next Hops

Routes with Multiple Next Hops

Path Selection and Configuration Options

BGP Update Messages

Summary of BGP Active Route Selection

Limiting the Number of Prefixes Accepted

Altering the Session Hold Time

Disabling Suppression of Route Advertisements

Restart Capability Is Negotiated

Modifying the Local Preference

Eliminating Private AS Numbers

Modifying the AS Path Attribute: Part 1

Modifying the AS Path Attribute: Part 2

Modifying the AS Path Attribute: Part 3

MED and IGP Metrics

MED Default Behavior

Emulate Cisco Default Behavior

Implementing BGP Lab

Chapter 6: BGP Attributes and Policy

Policy and BGP

www.juniper.net Contents iii

www.juniper.net Course Overview v

ISP As Network

Customer Bs Aggregate

Chapter 528 BGP www.juniper.net

Chapter 66 BGP Attributes and Policy www.juniper.net

Chapter 614 BGP Attributes and Policy www.juniper.net

Chapter 616 BGP Attributes and Policy www.juniper.net

Chapter 640 BGP Attributes and Policy www.juniper.net

BGP Case Study: Prefix CountPart 1

BGP Case Study: Prefix CountPart 2

BGP Case Study: Prefix CountPart 3

BGP Case Study: Prefix CountPart 4

BGP Case Study: Traffic EngineeringPart 1

BGP Case Study: Traffic EngineeringPart 2

BGP Case Study: Traffic EngineeringPart 3

BGP Case Study: Traffic EngineeringPart 4

Chapter 718 Enterprise Routing Policies www.juniper.net

BGP Case Study: Traffic EngineeringPart 5