Professional Documents
Culture Documents
Routing
11.a
Student Guide
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 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Chapter 2: OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1
OSPFv2 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Link-State Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14
Protocol Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-41
OSPF Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-62
OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-68
Lab 1: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-80
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 in configuring and
monitoring the Junos operating system and in monitoring device and protocol operations.
Objectives
After successfully completing this course, you should be able to:
www.juniper.net
Use routing policy and specific configuration options to implement solutions for
various scenarios.
Describe various BGP attributes in detail and explain the operation of those attributes.
Implement a routing policy for inbound and outbound traffic using BGP.
Explain the CoS processing along with CoS defaults on SRX Series Services Gateways.
Describe situations when some CoS features are used in the enterprise.
Explain the role of Internet Group Management Protocol (IGMP) and describe the
available IGMP versions.
Illustrate the role of Internet Group Management Protocol version 3 (IGMPv3) and PIM
sparse mode (PIM-SM) in an SSM implementation.
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:
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
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.
Courier New
Console text:
Screen captures
commit complete
Noncommand-related
syntax
Description
Usage Example
Normal CLI
No distinguishing variant.
Physical interface:fxp0,
Enabled
Normal GUI
GUI Input
Description
Usage Example
CLI Variable
policy my-peers
GUI Variable
CLI Undefined
GUI Undefined
ping 10.0.x.y
Select File > Save, and type
filename in the Filename field.
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/.
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.
www.juniper.net
Additional Information ix
x Additional Information
www.juniper.net
www.juniper.net
Introductions
The slide asks several questions for you to answer during class introductions.
www.juniper.net
Course Contents
The slide lists the topics we discuss in this course.
www.juniper.net
Prerequisites
The slide lists the prerequisites for this course.
www.juniper.net
www.juniper.net
www.juniper.net
Additional Resources
The slide provides links to additional resources available to assist you in the installation,
configuration, and operation of Juniper Networks products.
www.juniper.net
Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and
feedback. Depending on the class you are taking, please complete the survey at the end of the class,
or be sure to look for an e-mail about two weeks from class completion that directs you to complete
an online survey form. (Be sure to provide us with your current e-mail address.)
Submitting your feedback entitles you to a certificate of class completion. We thank you in advance
for taking the time to help us improve our educational offerings.
www.juniper.net
Courses
You can access the latest Education Services offerings covering a wide range of platforms at
http://www.juniper.net/training/technical_education/.
www.juniper.net
www.juniper.net
Multiple tracks;
www.juniper.net
www.juniper.net
Find Us Online
The slide lists some online resources to learn and share information about Juniper Networks.
www.juniper.net
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice
them now so that your instructor can best address your needs during class.
This chapter contains no review questions.
www.juniper.net
www.juniper.net
Chapter 22 OSPF
www.juniper.net
OSPFv2 Review
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
www.juniper.net
OSPF Chapter 23
Link-State Protocol
OSPF is an interior gateway protocol (IGP) based on the concept of a link-state database (LSDB). As
such, each OSPF-speaking router in the network attempts to form an adjacency with each
neighboring OSPF router. When these adjacencies are in place, each router generates and floods
LSAs into the network in a reliable manner. The LSAs are placed into the LSDB on each router where
the SPF algorithm is calculated to find the best path to each end node in the network.
Chapter 24 OSPF
www.juniper.net
Hierarchical Design
OSPF gains scalability as a protocol through the use of a hierarchical design. Portions of the network
are designated as separate areas. These remote areas are then connected through a common area
called the backbone.
www.juniper.net
OSPF Chapter 25
Chapter 26 OSPF
www.juniper.net
Packet Types
Every OSPF router uses a specific set of packets to perform its functions. The packet types include
the following:
www.juniper.net
Hello: Sent by each router to form and maintain adjacencies with its neighbors.
Database description: Used by the router during the adjacency formation process. It
contains the header information for the contents of the LSDB on the router.
Link-state request: Used by the router to request an updated copy of a neighbors LSA.
Link-state update: Used by the router to advertise LSAs into the network.
Link-state acknowledgment: Used by the router to ensure the reliable flooding of LSAs
throughout the network.
OSPF Chapter 27
Hierarchical Design
The slide graphically displays the hierarchical nature of OSPF. A backbone area (0.0.0.0) is the
connecting point for all other areas. By specification, each area must attach to the backbone in at
least one location.
Areas 1, 2, and 3 each contain routers internal to that area as well as a single area border router
(ABR). The ABR generates summary LSAs that represent the routes within its area and floods those
to the backbone. The ABR is also responsible for generating summary LSAs that represent the
backbone routes and injecting these LSAs into its attached area.
Chapter 28 OSPF
www.juniper.net
OSPF Routers
OSPF routers can take on a number of different roles within an OSPF domain. The following list
shows the common types of OSPF routers along with a brief description:
www.juniper.net
Area border router (ABR): An OSPF router with links in two areas, the ABR is responsible
for connecting OSPF areas to the backbone. It transmits network information between
the backbone and other areas.
Autonomous system boundary router (ASBR): An OSPF router that injects routing
information from outside the OSPF autonomous system (AS), an ASBR is typically
located in the backbone. However, the OSPF specification allows an ASBR to be in other
areas as well.
Backbone router: Defined as any OSPF router with a link to Area 0 (the backbone), this
router can be completely internal to Area 0 or an ABR depending on whether it has links
to other, nonbackbone areas.
Internal router: An internal router is an OSPF router with all its links within an area. If
that router is located within the backbone area (Area 0.0.0.0), it is also known as a
backbone router.
OSPF Chapter 29
OSPF Interfaces
All logical interfaces associated with the area should be listed under the area. Remember the
loopback interface, if it should be advertised.
www.juniper.net
What If...?
In the slide, interface lo0.0 has four addresses configured on it. Typically, you would put interface
lo0.0 into OSPF using the set area <area-id> interface <interface-name>
command. However, doing this will create four LSAs: one for each of the configured addresses on
interface lo0.0. You might come across a situation such as this for which you do not want to
advertise all of the addresses into OSPF. A solution to this problem is offered on the next page.
www.juniper.net
Then...
The slide shows a solution to our problem. By specifying the specific interface address to advertise,
only one LSA is created in the LSDB.
www.juniper.net
OSPF Interfaces
All logical interfaces associated with the particular area should be listed under that area. Remember
the loopback interface, if it should be advertised.
www.juniper.net
Link-State Advertisements
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
LSA Types
The following list provides the details of the LSA types:
Router LSA: Sent by each router to describe its individual links and their status.
Summary LSA: Sent by an ABR to describe routes or other information from one area
into another.
AS external LSA: Sent by an ASBR to describe routes external to the OSPF domain.
Group membership LSA: Used to support Multicast Open Shortest Path First (MOSPF).
NSSA LSA: Sent by an ASBR in a not-so-stubby area (NSSA) to describe routes external
to the OSPF domain.
External attributes LSA: Used to tunnel attributes used by other routing protocols
through OSPF.
Opaque LSAs: Used to transmit information not currently supported by other LSA types.
Examples include graceful restart and traffic engineering information.
www.juniper.net
LSA Functions
Each of the LSA types listed previously has a specific function within the OSPF domain. They each
describe a portion of the topology used by the SPF algorithm to supply routing information to a
routing table. We discuss each LSA in more detail on future slides.
Each LSA has a maximum age of 3600 seconds (1 hour) associated with it. This maximum provides
a mechanism for removing stale information from the database. To ensure that its LSAs are up to
date, each OSPF router periodically refreshes them prior to reaching the maximum age limit. The
Junos operating system performs this refresh every 3000 seconds (50 minutes).
www.juniper.net
LSA Header
The following list details the information contained in the LSA header:
Link-state age (2 bytes): Measured in seconds, the LS age is the time from when the
LSA was first originated. Each router increments this field prior to reflooding the LSA.
Options (1 byte): Indicates support for OSPF options. Within the context of an individual
LSA, the E bit (position 7) is set in all external LSAs and the P bit (position 5) is set in all
NSSA external LSAs.
Link-state ID (4 bytes): Describes various portions of the OSPF domain. Each LSA type
uses this field in a different manner.
Advertising router (4 bytes): The router ID of the router that first originated the LSA.
Link-state sequence number (4 bytes): Verifies that each router has the most recent
version of an LSA. This field is incremented each time a new version is generated.
Values range from 0x80000000 to 0x7FFFFFFF.
Link-state checksum (2 bytes): The checksum of the entire LSA contents, minus the LS
age field. This field is used to ensure data integrity in the LSDB.
Length (2 bytes): The entire length of the individual LSA, including the header.
www.juniper.net
Router LSA
Each OSPF-speaking router generates a Type 1 LSA to describe the status and cost (metric) of all
interfaces on the router. This LSA is flooded to each router in the OSPF area. It is defined as having
an area scope; therefore, it is not flooded across an area boundary. In addition to the standard LSA
header, the router LSA also contains the following fields:
www.juniper.net
V, E, and B bits (1 byte): Following five bits set to a value of 0, the V, E, and B bits
represent the characteristics of the originating router. The V bit is set when a virtual link
is established. An ASBR sets the E bit. An ABR sets the B bit.
Number of links (2 bytes): Gives the total number of links represented by the remaining
six fields.
Link ID (4 bytes): Represents the type of link the far end of the link is connected to.
Link data (4 bytes): Represents what the near side of the link is connected to.
Link type (1 byte): Describes the type of link. Used with Link ID and Link data fields.
Number of type of service (ToS) metrics (1 byte): Lists the number of type of service
metrics encoded. Only a value of 0 is supported.
Metric (2 bytes): Contains the cost to transmit data out of the interface.
Transit (Type 2): A connection to a broadcast segment is always noted as a transit link.
The link ID field contains the interface IP address of the segments DR. The link data
field contains the interface IP address of the local router.
Stub (Type 3): A router advertises a stub network when a subnet does not connect to
any OSPF neighbors. Advertising a stub network occurs for the loopback interface and
any passive interfaces. In addition, the IP subnet for any point-to-point interface is
advertised as a stub because the adjacency was formed over an unnumbered interface.
The link ID field for a stub network contains the IP network number and the link data
field contains the subnet mask.
Virtual link (Type 4): A virtual link operates between an ABR connected to Area 0 and an
ABR that is not connected to Area 0. Once established, the virtual link appears in the
Area 0 router LSA of each endpoint. The link ID field contains the neighbors router ID,
and the link data field contains the interface IP address of the local router.
www.juniper.net
This router is both an ABR as well as an ASBR. We see this by the setting of bits 0x3.
Recall that position 7 (0x2) is for the E bit, which is set when the originating router is an
ASBR. Bit position 8 (0x1) is for the B bit, which is set when the originating router is an
ABR. Combining these two fields results in a value of 0x3, which we see in the database
capture.
This router has three links connected to Area 0, which we can determine because of two
factors. First, the link count field is set to a value of 3. Second, the LSA is shown in the
database within the Area 0.0.0.0 section. Recall that a router LSA has area scope, so a
separate LSA is generated for each area representing the links only within that area.
A single point-to-point link exists, and two links are connected to stub networks. This
fact is clearly visible from the information in the type fields.
www.juniper.net
This router LSA was originated by the same router from which the capture was taken.
Notice the asterisk (*) next to the link-state ID value of 192.168.16.1. Also note that
the last line of the capture states that this LSA is Ours.
The router LSA was installed 15 minutes and 47 seconds ago. If not refreshed, the LSA
will expire in 44 minutes and 13 seconds when its 3600 second maximum age is
exceeded, and the LSA was last flooded 15 minutes and 47 seconds ago. These details
are shown in the Installed, expires, and sent fields, and they are present for
every LSA in the show ospf database extensive output.
www.juniper.net
www.juniper.net
Network LSA
Each OSPF router elected to be the DR on a broadcast link generates a Type 2 LSA. This LSA lists
each router connected to the broadcast link, including the DR itself. In addition to the standard LSA
header, the network LSA also contains the following fields:
Network mask (4 bytes): This field denotes the IP subnet mask for the interface
connected to the broadcast network.
Attached router (4 bytes): This field is repeated for each router connected to the
broadcast network. The value of each instance is the router ID of the attached routers.
You can deduce the total number of routers listed by the length of the LSA.
www.juniper.net
www.juniper.net
The DR for this network is 10.222.1.1, which you can determine by examining the
link-state ID field. This field lists the DRs IP address.
Because only two instances of the attached router field are present, you can safely
deduce that only two routers are connected to the link. The router IDs of those two
routers are 192.168.20.1 and 192.168.40.1.
The DR for the segment is 192.168.20.1 and its interface address is 10.222.1.1.
www.juniper.net
Summary LSA
Each ABR that transmits information from one OSPF area into another generates a Type 3 LSA to
describe that information. This LSA is flooded to each router in the OSPF area. This LSA has an area
scope; therefore, it is not reflooded across the area boundary by another ABR. Instead, the receiving
ABR generates a new Type 3 LSA describing the link and floods it into the adjacent area.
In addition to the standard LSA header, the summary LSA also contains the following fields:
www.juniper.net
Network mask (4 bytes): This field represents the subnet mask associated with the
network advertised. It is used in conjunction with the link-state ID field, which
encapsulates the network address in a Type 3 LSA.
Metric (3 bytes): This field provides the cost of the route to the network destination.
When the summary LSA is representing an aggregated route (using the area-range
command), this field is set to the largest current metric of the contributing routes.
ToS (1 byte): This field describes any optional type of service information encoded
within the network described. The Junos OS does not use this field.
This router is an ABR because it contains a database for Area 0.0.0.0. Within that area,
three summary LSAs are listed. One of the LSAs (the third one listed) is from the router
where the capture was taken. As with the router LSA earlier, notice that there is an
asterisk (*) next to the link-state ID value of 192.168.40.1. Also note that the last
line of the LSA states that the LSA is Ours.
A second router in the backbone (192.168.36.1) generates the two other summary
LSAs. The two networks advertised by that ABR are 10.222.44.0/24 and
192.168.32.1/32. Each of the networks has a metric of 1 encoded within the LSA. The
local router adds the cost to reach 192.168.36.1 to the metric of 1 prior to calculation
of the SPF algorithm.
Note that the command output on the slide is truncated. A fourth summary LSA for the
192.168.20.1/32 network is present, but not shown. This network, however, is shown on the next
slide.
www.juniper.net
www.juniper.net
We do not know the 32-bit value for the area, but we know that an internal area router
exists within it192.168.32.1;
Using the metric values in the summary LSAs, we can determine that the area router
and the ABR are connected over the 10.222.44.0/24 subnet; and
Within Area 0.0.0.1, we now know that the 192.168.20.1 router is directly connected to
our local router of 192.168.16.1. We use the summary LSA metric value to make that
determination.
Network mask (4 bytes): This field has no meaning in a Type 4 LSA and is set to 0.0.0.0.
The address of the ASBR is encoded in the link-state ID field.
Metric (3 bytes): This field provides the cost of the route to the ASBR.
ToS (1 byte): This field describes any optional type of service information used to reach
the ASBR described. This field is not used.
www.juniper.net
www.juniper.net
This router is an ABR because it contains a database for Area 0.0.0.0. Within that area,
currently two ASBR summary LSAs are listed. The second LSA is from the local router
(where the capture was taken). As with the router LSA earlier, notice that there is an
asterisk (*) next to the link-state ID value and that the last line of the LSA states that the
LSA is Ours.
The second router in the backbone (192.168.36.1) generates the other ASBR summary
LSA.
The two ASBRs being advertised are 192.168.32.1 and 192.168.40.1. You can see this
information coded in the link-state ID fields. Because the router ID of the ASBR is a full
32-bit value, the network mask is not needed and is set to a value of 0.0.0.0.
The metrics to each of the ASBRs are encoded in the appropriate field in the LSA. As
with the summary LSA (Type 3), the local router must add the cost to reach a remote
ABR to the encoded metric prior to calculation of the SPF algorithm.
Routers 192.168.32.1 and 192.168.40.1 both have export policies configured within
OSPF, which means that they have set the E bit in their router LSAs.
Based on the E bit setting in the router LSAs, the ABRs of 192.168.16.1 and
192.168.36.1 generate ASBR summary LSAs across the area boundaries. In our case,
we see the Type 4 LSAs within Area 0.0.0.0.
www.juniper.net
AS External LSA
Each ASBR generates a Type 5 LSA to advertise any networks external to the OSPF domain. This LSA
is flooded to each nonstub router in the entire OSPF domain. In addition to the standard LSA header,
the AS external LSA also contains the following fields:
www.juniper.net
Network mask (4 bytes): This field represents the subnet mask associated with the
network advertised. It is used in conjunction with the link-state ID field, which
encapsulates the network address in a Type 5 LSA.
E bit (1 byte): The E bit determines the type of external metric represented by the metric
field. It is followed by 7 bits, all set to 0 to make up the entire byte. A value of 0, the
default value, indicates that this is a Type 2 external metric. Thus, any local router
should use the encoded metric as the total cost for the route when performing an SPF
calculation. A value of 1 indicates that this is a Type 1 external metric. Therefore, the
encoded metric of the route should be added to the cost to reach the advertising ASBR.
This additive value then represents the total cost for the route.
Metric (3 bytes): This field represents the cost of the network as set by the ASBR.
Forwarding address (4 bytes): This field provides the address toward which packets
should be sent to reach the network. A value of 0.0.0.0 represents the ASBR itself.
External route tag (4 bytes): This 32-bit value field can be assigned to the external
route. OSPF does not use this value, but it might be interpreted by other protocols.
The external LSDB lists all the LSAs. This listing denotes their domain scope status as
not belonging to a particular OSPF area.
This router is generating the first LSA listed. As with the router LSA earlier, an asterisk
(*) exists next to the link-state ID value, and the last line of the LSA states that the LSA
is Ours.
Different routers generate each of the other three LSAs because the advertising router
field is different for each LSA.
Examination of the link-state ID and the network mask fields shows that the four
different networks advertised are 192.168.17.0/24, 192.168.33.0/24,
192.168.37.0/24, and 192.168.41.0/24. Each of these networks has a metric value of
20 encoded. In addition, each of these LSAs is a Type 1 metric (as seen by the type
field). Taking these two values in conjunction with each other tells the local router to
add the cost to reach the remote ASBR to the encoded metric prior to calculation of the
SPF algorithm. The metric to the ASBR is used because the forwarding address field for
each LSA is listed as 0.0.0.0.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Notice that the LSA is listed within the Area 0.0.0.2 database. This listing denotes its
area scope status as belonging to a single NSSA area.
An examination of the link-state ID and the network mask fields shows that the network
advertised is 192.168.33.0/24. This network has a metric value of 20 encoded. It also
is listed as a Type 1 metric (as seen by the type field). Taking these two values in
conjunction with each other informs the local router to add the cost to reach the ASBR
to the encoded metric prior to calculation of the SPF algorithm.
The NSSA does not know the network connecting the ASBR to the remote domain. You
can see this fact by examining the forwarding address field where it lists the router ID of
the ASBR, 192.168.32.1.
www.juniper.net
www.juniper.net
The area attached to the 192.168.36.1 router is Area 0.0.0.2. It is also currently
configured as an NSSA.
The 192.168.33.0/24 route is being injected into Area 0.0.0.2 as a Type 7 LSA. It is
translated into a Type 5 LSA by the 192.168.36.1 router.
Future Extensibility
RFC 2370 defines the OSPF opaque LSA. It was designed to extend the protocol to support future
enhancements without generating new LSA types. As of this writing, production networks use both
the Type 9 and Type 10 opaque LSAs. The Type 9 LSA supports graceful restart. The Type 10 LSA
supports MPLS traffic engineering. The Type 11 opaque LSA is not used at this time.
Flooding Scope
The main difference between the opaque LSAs is in the flooding scope of each type: The Type 9 LSA
has a link-local scope, the Type 10 LSA has an area scope, and the Type 11 LSA has domain scope.
www.juniper.net
Protocol Operations
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
www.juniper.net
The local router is an ABR between the backbone and Area 0.0.0.1, which you can see
clearly through the existence of two databases on the router.
Within Area 0.0.0.1, a broadcast link is in use. In addition, the DR on that link is the
router whose address is 10.222.1.1. Notice the Type 2 LSA within the Area 0.0.0.1
database. The link-state ID is 10.222.1.1, the DRs IP address on the link.
Multiple routers act as ASBRs and inject routes into the OSPF domain. Those routers
are 192.168.16.1, 192.168.20.1, 192.168.32.1, and 192.168.36.1. The routes
advertised by those ASBRs can be used once the local router has knowledge of how to
reach the ASBR.
One of the ASBRs is the local router, 192.168.16.1. One of the external LSAs lists this
router ID, and that LSA is marked with an asterisk (*). A second ASBR is a router within
Area 0.0.0.1 (192.168.20.1). This router ID is found within a router LSA in the Area
0.0.0.1 database. A third ASBR is a router within the backbone (192.168.36.1). This
router ID is found within a router LSA in the Area 0.0.0.0 database. The fourth ASBR is a
router in an area beyond the backbone (192.168.32.1). This router ID is found within an
ASBR summary LSA in both the Area 0.0.0.0 and the Area 0.0.0.1 databases.
OSPF Chapter 243
www.juniper.net
Dijkstra Algorithm
After a router receives a new LSA and places it into the LSDB, the router runs the SPF algorithm. This
computation uses the database as a data source and results in a loop-free network topology using
the best metric from the local router to all nodes in the network.
During the course of this calculation, the algorithm uses three databasesthe LSDB, the candidate
database, and the tree database. As we have explored, the LSDB is the total compilation of routing
knowledge in the network. Conceptually, it consists of multiple tuples in the form of: router ID,
neighbor ID, cost. These tuples describe each link in the network.
Continued on the next page.
www.juniper.net
Evaluate each tuple in the candidate database and delete any tuples whose neighbor ID
is currently in the tree database and whose cost to the root is greater than the entry
currently in the tree database. Repeat this step until no more tuples can be deleted.
As the algorithm operates, the local router moves its own local tuple into the tree database and all
tuples for its links into the candidate database. It then performs the following steps until the
candidate database is empty:
2.
For each new entry in the candidate database, determine the cost from the root to each
neighbor ID. Move the tuple with the lowest cost from the candidate database into the
tree database. If multiple tuples exist with an equal cost, choose one randomly.
3.
If a new neighbor ID appears in the tree database, move all tuples in the LSDB with a
router ID equal to the new tree entrys neighbor ID into the candidate database.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Cost of an Interface
Prior to advertising a network into the OSPF domain, each router must determine the cost associated
with that network. Often referred to as the metric, the cost is simply what the router views as the
overhead associated with transmitting a packet on that interface. Because each OSPF-speaking
router advertises these cost values in its router LSAs, each router can determine the total cost (or
metric) to reach any destination in the network.
www.juniper.net
Reference Bandwidth
To alter the calculation values, use the reference-bandwidth command within the [edit
protocols ospf] configuration hierarchy. The value entered has a value in bits per second. You
can use the standard Junos shortcut notations of k (kilobits per second), m (megabits), and g
(gigabits). The entered value becomes the new numerator value in the bandwidth calculation. As
noted on the slide, you still can assign a metric statically to an individual interface.
www.juniper.net
SPF Calculations
After receiving a new LSA from another router in the area, the local router performs an SPF
calculation using all the values contained in the router and network LSAs. As mentioned on a
previous slide, the cost is calculated from the root node to every other node in the network using the
metric cost of the outgoing interfaces.
www.juniper.net
Overload Settings
You can turn on the overload setting, turn it off as a permanent value, or have a timer associated
with it. If the timer is omitted, the metric values are changed when you commit the configuration. The
values will remain until you remove the overload setting from the configuration and commit it again.
However, if you assign a timer value, the metrics are not changed automatically. The timer
associated with the overload setting only initializes when the routing protocol process initializes. This
timer can run from 601800 seconds. When the timer expires, the metrics return to normal in the
router LSAs, but the configuration still contains the overload option.
www.juniper.net
Case Study
Enterprise networks are typically built with multiple paths from ingress and egress points for
redundancy. During maintenance operations on a router, it can be beneficial to prevent the router
from receiving and forwarding transit traffic. The overload feature provides this function.
In the graphic on the slide, R2 is scheduled for maintenance. An alternate path exists through R3.
Once R2 is put in overload mode the other routers will be notified and transit traffic will traverse R3.
Any traffic destined for networks that terminate on R2 will still be forwarded to R2.
www.juniper.net
OSPF Router ID
Each OSPF-speaking router in a network must select a 32-bit value to use as the router ID (RID) of
the router. This RID uniquely identifies the router within the OSPF domain. It is transmitted within the
LSAs used to populate the LSDB and is used to calculate the shortest-path tree using the method
described on a previous slide.
It is very important in a link-state network that no two routers share the same RID value. If two
routers share the same RID value, the LSDB might not be consistent on all routers. This
inconsistency happens because the RID is one method to verify whether an LSA is already present in
the database. Therefore, new critical information from one of the routers is never present in all the
routers. In addition, because the Dijkstra calculation uses the RID, it is possible that an individual
router might not generate a loop-free shortest path topology. This scenario could have a disastrous
affect on IP routing.
www.juniper.net
www.juniper.net
www.juniper.net
OSPF Authentication
The slide highlights the topic we discuss next.
www.juniper.net
Authentication
The three different forms of authentication that the Junos OS supports are none, simple, and MD5.
As of Junos Release 8.3, IP Security (IPsec) was added.
Authentication Default
The default operation of the OSPF process is the none mode. Thus, no authentication key is
configured on any interface.
Plain-Text Passwords
With simple authentication type configured, each OSPF packet includes a plain-text password. This
password can be captured easily through a packet analysis system. Therefore, although this
password protects against an inadvertent configuration, it does not provide any security.
www.juniper.net
Encrypted Checksum
To provide better security in an OSPF network, we recommend that you use an authentication type of
MD5. MD5 includes an encrypted checksum in all OSPF packets instead of a simple-text password.
Each OSPF-speaking router uses the same MD5 algorithm to calculate the checksum value, so
interoperability and a correct result can be virtually guaranteed.
Authentication Keys
The actual password to verify and authenticate packets is contained within the authentication
command. You can configure each individual interface with an authentication value.
Key ID Values
You configure each individual interface with a key value. All interfaces in the area might share the
same key value, or each interface might contain a separate value.
www.juniper.net
www.juniper.net
www.juniper.net
Authentication Mismatch
OSPF routers must agree on the authentication method to be neighbors. Use the traceoptions
functionality if you suspect there might be an authentication mismatch.
The log shows that the local router is ignoring an OSPF packet from 172.20.77.1 because of an
authentication mismatch. No authentication method is configured on the local router, so the type is
none. The remote router has MD5 authentication configured.
www.juniper.net
OSPFv3
The slide highlights the topic we discuss next.
www.juniper.net
OSPFv3
OSPFv3 is defined in RFC 5340, with some additional features, such as grateful restart and
authentication, defined in separate documents (RFC 5781OSPFv3 Graceful Restart and
RFC 4552 Authentication/Confidentiality for OSPFv3).
OSPFv3 maintains the fundamental mechanisms of OSPF, including LSA flooding scopes, areas, DR
election, stub areas, NSSAs, and so on. Though OSPFv3 is often associated with IPv6 addressing, it
is also completely compatible with IP version 4 (IPv4) addressing schemes. However, some changes
are necessary to account for the differences in IPv4 versus IP version 6 (IPv6) addressing. We
address these differences on the following slides.
In terms of the Junos OS configuration, all that is required is to substitute ospf3 for ospf in the
configuration.
[edit]
user@router# show protocols ospf?
Possible completions:
> ospf
OSPF configuration
> ospf3
OSPFv3 configuration
www.juniper.net
Protocol processing per link, not per subnet: You need only a single adjacency per link
even if multiple IPv6 subnets exist on the link. These adjacencies are formed using
link-local addresses, which removes the requirement of having matching subnet and
subnet mask configurations for two routers to become adjacent.
Flooding scope is generalized: Flooding is now generalized and is coded into the LS type
field. An LSA can be either flooded on the local link, area, or throughout the AS. This
flooding also assists in the handling of unknown LSA types as the flood scope is
encoded.
www.juniper.net
www.juniper.net
Support for multiple instances per link: This support allows multiple OSPF instances to
run over a single link to support separate routing domains or to support a single link
belonging to multiple areas. Previously, this functionality was achieved in OSPFv2 by
tweaking authentication to hide OSPF packets from an OSPF router. This functionality is
now formalized by including an instance ID in the OSPF header.
Use of link-local addresses: OSPF packets are sent using the IPv6 link-local addressing.
These link-local addresses are also used as next-hop information during forwarding.
Authentication removed: Authentication uses the IPsec framework built into IPv6. As a
result, it is not required at the application layer and was removed.
LSA format changes: Summary LSAs are now referred to as inter-area-prefix LSAs, and
ASBR summary LSAs are now inter-area-router LSAs to account for differences in
address size. The intra-area-prefix LSA is also included, carrying prefix information
internal to areas that were previously carried inside router and network LSAs.
Unknown LSA handling: The old way of discarding unknown LSA types is no longer
supported because a mix of capabilities in a network, especially on a single link, causes
forwarding issues. OSPFv3 codes the proper handling of an unknown LSA type in the
LSA handing bit. The LSA is either treated as being of local scope only or stored and
forwarded as if it were understood.
www.juniper.net
www.juniper.net
The options field was expanded from 8 bits to 24 bits: The option field is included in
OSPF hello packets, database description packets, and certain LSAs (router LSAs,
network LSAs, inter-area-router LSAs, and link LSAs). Previously defined option bits are
present, as well as added support for the V6-bit and R bits. The V6-bit is used to
indicate whether the route or link should be excluded from IPv6 routing calculations.
The R bit is used like the IS-IS overload bit and indicates whether the originator is an
active router. If the R bit is clear (that is, 0) in the OSPF options field, the advertising
router can participate in OSPF without being used for transit traffic. This would be a
useful setting for hosts that are multihomed but never used to forward traffic between
interfaces.
www.juniper.net
U bit: Used to indicate how a router that does not understand the LS function code
should handle the LSA. When the code is 0, the LSA should treat the LSA as if it has
link-local scope only. When the code is 1, the router should store and flood it as if it
were understood.
S-bits and flooding scope: Used to indicate the flooding scope for the LSA:
S1
Flooding scope
Link-local scope.
Area scope.
AS scope.
Reserved.
The function codes are very much like the OSPFv2 type codes. Some exceptions, however, do exist.
Most notably, all addressing semantics are removed from the router and network LSAs. The
addresses that were advertised in the OSPFv2 versions of the LSAs are now carried in a new
intra-area-prefix LSA.
Another addition is the presence of the link LSA. The link LSA is used to advertise to directly attached
OSPF neighbors the link-local IPv6 address assigned to the interface. As indicated by the LS type, the
link LSA is not flooded beyond the physical broadcast domain.
www.juniper.net
www.juniper.net
www.juniper.net
OSPF LSAs;
www.juniper.net
Review Questions
1.
2.
3.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
OSPF Scalability
With a link-state protocol, flooding link-state update packets and running the shortest-path-first (SPF)
algorithm consumes router resources. As the size of the network grows and more routers are added
to the autonomous system (AS), this use of resources becomes a bigger and bigger issue. This issue
stems from the RFC requirement that all OSPF routers share an identical link-state database (LSDB).
Eventually, the routers spend so much time flooding and running the SPF algorithm that they cannot
route data packets. Clearly, this scenario is not optimal.
www.juniper.net
OSPF Areas
Using OSPF, you can segment an AS into smaller groups known as areas. Using areas achieves the
OSPF hierarchy that can facilitate growth and scalability. You can constrain LSA flooding by using
multiple areas, which can effectively reduce the size of the LSDB on an individual OSPF router. Each
OSPF router maintains a separate and identical LSDB for each area to which it is connected.
To ensure correct routing knowledge and connectivity, OSPF maintains a special area known as the
backbone area. The backbone area is designated as Area 0.0.0.0 (or simply Area 0). All other OSPF
areas must connect themselves to the backbone area. By default, all data traffic between OSPF
areas transits the backbone. You can alter this default behavior and eliminate the requirement of all
interarea traffic transiting Area 0.0.0.0 by configuring a multiarea adjacency on the same logical
interface. The multiarea adjacency feature is documented in RFC 5185 and is discussed in the next
chapter.
www.juniper.net
Intra-area or internal routes: Routes that are generated from within an area, where the
destination belongs to the area;
Interarea or summary routes: Routes that originate from other areas; and
External routes: Routes that originate from other routing protocols, or different OSPF
processes, and that are injected into OSPF through redistribution.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
NSSA Operation
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
NSSA Configuration
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Route Summarization
The slide highlights the topic we discuss next.
www.juniper.net
Route Summarization
To reduce the size of the LSDB in Area 0.0.0.0 (and other remote OSPF areas), you can configure the
ABR not to perform its default one-for-one mapping function. This is accomplished using an address
range statement on the ABR with the area-range command. All Type 1 and Type 2 LSAs that fall
within that address range will no longer be advertised individually into the backbone. Instead, a
single Type 3 summary LSA is advertised. The metric associated with this summary route will be
equal to the highest metric associated with the individual contributing routes.
Because only the ABR performs this mapping function, you configure the area-range command
on ABR routers only.
www.juniper.net
Route Summarization
To reduce the size of the LSDB in Area 0.0.0.0 (and other remote OSPF areas), you can configure the
ABR not to perform its default one-for-one mapping function. You can configure an address range on
the ABR by using the area-range command within the NSSA configuration hierarchy. All Type 7
LSAs that fall within that address range are not advertised individually into the backbone. Instead, a
single Type 5 external LSA is advertised.
Because only the ABR performs this mapping function, only the ABR is configured with the
area-range command.
Note that the area-range command referenced here is specific to the NSSA configuration
hierarchy and only affects Type 7 LSA routes. The area-range command discussed in the previous
slide was within the area hierarchy itself and affected Type 1 and Type 2 LSA routes. The
configuration can have these two commands in place at the same time, and they will summarize
different aspects of the local area routing domain.
www.juniper.net
Suppressing Routes
The default action of the area-range command causes the generation of a single Type 3 summary
LSA into the backbone for all prefixes that fall within the defined range. You can configure the ABR
with the restrict keyword to block one or more prefixes from advertisement into the OSPF
backbone. Such a configuration prevents routing information from each Type 1 and Type 2 LSA that
falls within the address range from being advertised to the backbone, which in turn can block
connectivity to those prefixes for routers in other areas.
Use the restrict function when you want to prevent interarea routing, or when you want a default
route to be used instead of the more preferred summary information that would otherwise be
generated.
Because only the ABR is responsible for this mapping function, you configure only ABR routers with
the area-range restrict command.
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1.
2.
3.
4.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Common Elements
The IGP transition strategies contain a few common elements. Every IGP transition strategy requires
that you know which IGP provides the active routing information for the network at every point. You
control this information in the Junos OS using route preferences. Additionally, most transition
strategies require you to export appropriate routing information between the two IGPs so that you
can ensure that all routers have access to full routing information.
www.juniper.net
Primary Tiebreaker
The Junos OS uses route preference as the primary criterion for selecting the active route.
Preference values cause routes from certain information sources to be ranked more preferably than
the same route received from another information source. The table on the slide shows the default
preference values for a selected set of routing information sources.
Continued on the next page.
www.juniper.net
Lower Is Better
Routing preference values are a 32-bit number that is 0 or higher. The router prefers lower preference
values over higher preference values. This command output demonstrates that a direct route with a
preference of 0 is preferred over an OSPF internal route with a preference of 10:
user@router> show route 10.251.254.130/31 exact
inet.0: 18 destinations, 19 routes (17 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.251.254.130/31
*[Direct/0] 1d 07:53:39
> via ge-4/0/0.0
[OSPF/10] 1d 07:53:32, metric 65
> via ge-4/0/0.0
www.juniper.net
www.juniper.net
www.juniper.net
Overlay Transition
In the overlay transition, you configure all routers in the network to run the new IGP while they are still
running the old IGP. Once you verify the proper operation of the new IGP, you configure all routers in the
network to stop running the old IGP. This transition strategy is appropriate when all routers have the
necessary resources (in particular, CPU and memory) to run both protocols simultaneously. Additionally,
you must accomplish any network redesign necessary to accommodate the new IGP as part of the
transition.
Route Redistribution
If all routers cannot run both protocols simultaneously or if you must make some topology changes
as part of the IGP change, you can gradually migrate the network one portion at a time. For example,
if you are migrating to OSPF, you might migrate one future OSPF area at a time. As you progress from
one portion of the network to another, you must configure routers on the border of the two IGPs to
conduct mutual route redistribution, exporting routes between the two IGPs.
Continued on the next page.
www.juniper.net
Integrated
If you must significantly redesign your existing topology to make it a well-designed network with the
new IGP, the integrated strategy might be the best approach. In this strategy, you create a new
network core running the new IGP, connect it to the old network core, and export routes between the
new and old IGPs. You then gradually migrate connections from the old core to the new core.
www.juniper.net
www.juniper.net
Sample Topology
This slide shows the topology this chapter uses as an overlay example. We start off with a RIP
network and then transition it to an OSPF network.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Multiarea Adjacencies
By default, a single interface can belong to only one OSPF area. However, in some situations, you
might want to configure an interface to belong to more than one area. Doing so allows the
corresponding link to be considered an intra-area link in multiple areas and to be preferred over
other higher-cost intra-area paths.
Beginning with Junos Release 9.2, you can configure a logical interface to belong to more than one
OSPF area. As defined in RFC 5185, OSPF Multi-Area Adjacency, the area border routers establish
multiple adjacencies belonging to different areas over the same logical interface. Each multiarea
adjacency is announced as a point-to-point unnumbered link in the configured area by the routers
connected to the link.
For a given logical interface, it is considered as primary for one single area. To configure that same
logical interface in additional areas, you must use the secondary option. In the slide, you can see
that interface ge-1/0/0.0 has been configured in two areas, Area 0 and Area 1. Because the
Area 1 interface has the secondary option set, the Area 0 occurrence is considered the primary.
www.juniper.net
www.juniper.net
Link Failure
In normal operation, if a link failure occurred between R1 and R3, traffic from R1 to R3 would flow
from R4 to R2 and then to R3. This creates three hops to reach a router that was previously one hop
away.
www.juniper.net
www.juniper.net
Adjacency Verification
Verify adjacencies with the show ospf neighbor command.
Normal Trace
For the case study, R3 is one hop away from R1.
www.juniper.net
www.juniper.net
Point-to-Point Interface
The output shows that the ge-1/1/0.0 interface now appears in two distinct OSPF areas, Area 0 and
Area 100. However, note the secondary link in Area 100 shows up as a point-to-point interface.
www.juniper.net
Adjacency Is Formed
Two adjacencies are now formed over ge-1/1/0.0 for Area 0 and Area 100.
www.juniper.net
External Reachability
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
Route Redistribution
For route distribution to occur, an export policy must be written and applied. Because external routes
in OSPF have an interarea flooding scope, the policies are applied globally. This feature allows
external routes to be sent into all areas that allow it. When an external route is brought into OSPF, it
appears as an external Type 5 LSA of Type 2. If an external LSA Type 1 must be configured, you can
modify it with a policy.
www.juniper.net
Mutual Redistribution
Special care must be taken when redistribution is configured in a network. When multiple
redistribution points are present sub-optimal routing and loops could occur. Generally, if the source
route has a lower preference than the protocol into which it is being redistributed, no issues occur.
However, when the source route has a higher preference, issues can occur. Several methods exist to
resolve these issues, but the easiest method usually involves modifying route preference values.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
ABR Translation
Because the route was originated from the not-so-stubby area (NSSA), the ABR must convert the
Type 7 LSA to a Type 5 for interarea advertisement.
Forwarding Address
When the ABR translates the Type 7 into a Type 5, it places the address of the autonomous system
boundary router (ASBR) into the forwarding address. This action supports optimal routing because
only one ABR will translate the Type 7 LSAs to Type 5 LSAs in the presence of multiple ABRs. This
router might not be in the optimal path for routers in other areas.
ASBR Summary
The ABR also creates a Type 4 LSA to represent the ASBR to other areas.
www.juniper.net
www.juniper.net
The Result
The result of the preference change is now a default that points properly to the ABRs in the NSSA.
www.juniper.net
SPF Review
After a router receives a new LSA and places it into the link-state database (LSDB), the router runs an
algorithm known as the Dijkstra algorithm (also called the shortest-path-first [SPF] algorithm). This
computation uses the database as a data source and results in a loop-free network topology using
the best metric from the local router to all nodes in the network.
During the course of this calculation, the algorithm uses three databasesthe LSDB, the candidate
database, and the tree database. As we have explored, the LSDB is the total compilation of routing
knowledge in the network. Conceptually, it consists of multiple tuples in the form of (router ID,
neighbor ID, cost), which describe each link in the network.
www.juniper.net
Import Policy
An import policy can be applied between the tree database and the routing table. This allows filtering
of routes from the LSDB to the routing table but it only applies to external routes, as in the case for
OSPF export policy. Note that the database stays consistent and the import policy does not block any
normal LSA flooding.
www.juniper.net
Flooding Protection
Some OSPF implementations encounter problems when large numbers of external routes are
injected into the LSDB. The Junos OS does not behave in this manner, however, and a large number
of routes are handled without a problem. Although this protocol stability is a nice feature, a
configuration mistake could make a portion of your network unusable as only routers capable of
handling such large numbers would be operating effectively.
To help you when a configuration mistake occurs, the Junos OS allows a limit to be placed on the
number of external routes exported into OSPF. The prefix-export-limit command informs the
router how many routes to accept using a routing policy configuration. The command accepts a
32-bit value, which provides a range of routes from 1 to 4,294,967,295. Once the route limit is
reached, the router transitions into an overload state where the local links are set to a metric of
65,535 in the router LSA. Additionally, all Type 5 LSAs from the router are purged from the database
and the network in general. The local router remains in this state until the number of external routes
returns to a level below the configured limit. This situation requires the administrator to manually
change the existing configuration; either the number of advertised routes must be reduced or the
routing policy must be changed.
www.juniper.net
Modify Policy
To see prefix limits in action, a policy is modified to send all RIP routes into OSPF.
RIP Redistribution
This policy causes all RIP routes to be sent into OSPF.
www.juniper.net
Prefix Limit
To stop the large amount of LSAs that could enter the router, a prefix-limit of six is configured.
The Result
The result is that no RIP routes are distributed. This prefix-limit setting ensures that a configuration
error does not affect your network.
www.juniper.net
Virtual Links
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
www.juniper.net
Summary LSA
One of the primary jobs of the ABR router is to generate summary LSAs into its attached areas. This
function provides interarea connectivity for the non-ABR routers.
www.juniper.net
www.juniper.net
www.juniper.net
Technical OSPF
From the OSPF RFC 2328:
Area border routers: A router that attaches to multiple areas. Area border routers run
multiple copies of the basic algorithm, one copy for each attached area. (Section 3.3)
Technically, you can create a multiarea OSPF network with no Area 0. However, we do not
recommend this configuration because SPF will process all LSAs in all areas and the ABR loses its
OSPF loop detection mechanism.
Functional OSPF
In practice, an ABR should always be connected to Area 0. Because the ABR calculation is similar to
a distance vector protocol when processing the Type 3 LSA, a loop avoidance mechanism must be in
place. This requirement is met with an Area 0 and a rule that SPF will only process LSAs within that
area database.
www.juniper.net
www.juniper.net
Case Study
In this case study, Alpha Corp. has acquired Bravo Corp. Both networks are running multiarea OSPF
and the integration team must get both networks communicating with each other.
www.juniper.net
www.juniper.net
www.juniper.net
Connectivity Issues
As soon as the physical connection is created, limited connectivity is achieved. For example, the B6
router can now reach the A1 router in Alpha Corps Area 0. However, Alpha Corps Area 0 routers
cannot reach Bravo Corps Area 0 routers. The cause of this limited connectivity is the lack of a
contiguous Area 0 backbone.
www.juniper.net
Virtual Link
One solution to the connectivity problem is to create a virtual tunnel between the two backbone
areas of the corporations. This feature, known as a virtual link, provides a logical connection
between areas. Essentially, OSPF packets are tunneled through a transit area to establish an OSPF
adjacency and logically connect the two areas together. This establishes full connectivity between
the two corporations.
Remember that a virtual link is a control plane feature only. SPF will still calculate the shortest
physical path between two points, which might not be the same path as the virtual tunnel. This
calculation could create some confusion when troubleshooting, which is one of the primary reasons
virtual tunnels are not considered long term solutions.
www.juniper.net
www.juniper.net
www.juniper.net
Contiguous Area 0
Once the neighbor is established over the virtual link, connectivity is restored, all LSAs are
processed, and routes to each corporation are installed into the routing table.
www.juniper.net
www.juniper.net
Review Questions
1.
2.
3.
4.
www.juniper.net
Lab 3: Configuring and Monitoring Routing Policy and Advanced OSPF Options
The slide provides the objectives for this lab.
www.juniper.net
Chapter 52 BGP
www.juniper.net
Review of BGP
The slide lists the topics we cover in this chapter. 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.
Chapter 54 BGP
www.juniper.net
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.
www.juniper.net
BGP Chapter 55
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.
Chapter 56 BGP
www.juniper.net
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.
www.juniper.net
BGP Chapter 57
Chapter 58 BGP
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.
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.
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.
www.juniper.net
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.
www.juniper.net
BGP Chapter 59
Refresh: Normally a BGP speaker cannot be made to readvertise routes that have
already been sent and acknowledged (using TCP). The route refresh message supports
soft clearing of BGP sessions by allowing a peer to readvertise routes that have already
been sent. This soft clearing has some very specific uses when working with
MPLS-based VPNs and adding new customer sites to existing customer VPN structures.
Each BGP message uses the same fixed size header, which is 19 bytes. BGP keepalive messages do
not include any data portion following the header.
www.juniper.net
BGP 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.
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
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.
www.juniper.net
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.
Continued on the next page.
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
BGP Operations
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
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.
www.juniper.net
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:
An import policy might exist that prevents the route from being installed;
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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.
Chapter 534 BGP
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
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]).
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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:
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
AS Path:65001
AS Path:65002
AS Path:65001
MED:200
MED:150
MED:100
IGP cost:5
IGP cost:10
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.
www.juniper.net
AS Path:65001
AS Path:65002
AS Path:65001
MED:200
MED:150
MED:100
IGP cost:5
IGP cost:10
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.
AS Path:65001
AS Path:65002
AS Path:65001
MED:200
MED:150
MED:100
IGP cost:5
IGP cost:10
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.
www.juniper.net
www.juniper.net
Review Questions
1.
2.
3.
4.
5.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
BGP Attributes
The slide highlights the topic we discuss next.
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
Regex Support
The Junos OS supports regex operators, which allows for flexibility when using matching conditions with
routing policy.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
Mandatory Attribute
The next-hop attribute must be understood by all BGP speakers and must be included in every BGP
update.
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.
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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.
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1.
2.
3.
4.
5.
www.juniper.net
www.juniper.net
Common Internet service provider (ISP) policies that determine policy design; and
Three common routing policies used for external connectivity in the enterprise
environment.
www.juniper.net
www.juniper.net
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.
Chapter 74 Enterprise Routing Policies
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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.
Continued on the next page.
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
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).
www.juniper.net
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.
Continued on the next page.
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1.
2.
3.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Overview of Multicast
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
www.juniper.net
www.juniper.net
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.
www.juniper.net
Designated router (DR): The DR is the router closest to the source or receiver that will
forward multicast packets into the network. If there are two or more routers attached to
the source or receiver, only one will ever become DR based on some sort of election
algorithm that depends on the multicast routing protocol being used.
www.juniper.net
www.juniper.net
(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.
www.juniper.net
(*,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.
www.juniper.net
Multicast Addressing
The slide highlights the topic we discuss next.
www.juniper.net
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.
www.juniper.net
Reserved Ranges
The following list comprises the reserved multicast address ranges:
www.juniper.net
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.
www.juniper.net
www.juniper.net
RPF
The slide highlights the topic we discuss next.
www.juniper.net
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.
Continued on the next page.
www.juniper.net
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).
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
IGMP
The slide highlights the topic we discuss next.
www.juniper.net
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 will forward 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.
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.
www.juniper.net
www.juniper.net
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.
Continued on the next page.
www.juniper.net
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.
www.juniper.net
www.juniper.net
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.
Continued on the next page.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
oif-map: Allows you to configure outbound interfaces for multicast traffic that are
different than the one where the IGMP report was received.
www.juniper.net
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 will automatically act 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.
www.juniper.net
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 will 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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
IGMP functionality.
Review Questions
1.
.
2.
.
3.
.
4.
www.juniper.net
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.
www.juniper.net
www.juniper.net
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.
www.juniper.net
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) will 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) will 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.
www.juniper.net
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).
www.juniper.net
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).
www.juniper.net
www.juniper.net
PIM Independence
PIM is indeed as it claimsprotocol independent. Whichever unicast protocol is being used, PIM will
use 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.
Continued on the next page.
www.juniper.net
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.
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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).
www.juniper.net
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).
www.juniper.net
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.50.61 was learned from a static configuration. 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 this particular RP.
www.juniper.net
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.
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.
Continued on the next page.
www.juniper.net
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.
www.juniper.net
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:
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.
www.juniper.net
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.
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:
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.
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
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.
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.
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.
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
PIM Interfaces
The show pim interfaces command lists the configured and operational interfaces for PIM.
Each interface contains the following information:
www.juniper.net
Mode: Whether the interface is in sparse only, dense only, or sparse-dense mode;
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;
PIM Neighbors
The show pim neighbors command displays information about neighboring routers running
PIM.
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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 will also specify a specific source, there is no need to
maintain an RPT.
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
PIM-SM operation and configuration when using the ASM model; and
Review Questions
1.
2.
3.
4.
www.juniper.net
www.juniper.net
www.juniper.net
Situations in which various CoS features are used in the enterprise; and
www.juniper.net
www.juniper.net
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.
www.juniper.net
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.
Continued on the next page.
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
www.juniper.net
2.
3.
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-service
based forwarding (CBF).
www.juniper.net
www.juniper.net
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.
Rewrite marker: The rewrite marker stage 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 class
for example, writing a 001 pattern into the precedence field of all family inet packets
that are classified as best effort (BE).
3.
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.
4.
Red/Congestion control: The final 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.
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.
www.juniper.net
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
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 1200,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.
www.juniper.net
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.
www.juniper.net
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.
www.juniper.net
transmit-rate rate: Transmission rate, in bits per second. The rate can be from
3200 through 160,000,000,000 bps.
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.
www.juniper.net
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.
www.juniper.net
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%.
www.juniper.net
www.juniper.net
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.
www.juniper.net
Policing
The slide highlights the topic we discuss next.
www.juniper.net
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.
www.juniper.net
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Virtual Channels
The slide highlights the topic we discuss next.
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
icmp-ping: Internet Control Message Protocol (ICMP) echo requests sent to target
address.
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.
Continued on the next page.
www.juniper.net
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
The CoS processing along with CoS defaults on SRX Series devices;
Situations in which some CoS features are used in the enterprise; and
Review Questions
1.
2.
3.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
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 nonclients.
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.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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 readvertised to all other clients in the cluster as well
as to all nonclient 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) readvertise all routes received
from IBGP peers (the other reflectors in this example) to all of their cluster clients.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1.
2.
3.
4.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Course Introduction
This chapter contains no review questions.
Chapter 2:
OSPF
1.
LSA Type 9 supports graceful restart.
2.
The metric or cost of a routers links can be automatically altered with the reference-bandwidth
command.
3.
The different forms of OSPF authentication include none, simple, and MD5.
Chapter 3:
OSPF Areas
1.
The ABR does not forward Type 4 and Type 5 LSAs into a stub area or NSSA. Type 3 LSAs are also not
forwarded in an OSPF NSSA with no summaries.
2.
You must configure all routers that are in the stub area or NSSA.
3.
The ABR of the stub area can optionally inject a 0.0.0.0/0 default route into the stub area or NSSA.
4.
The backbone area is directly affected by the area-range command. However, any area that is able to
receive summary LSAs also benefits from this command.
Chapter 4:
www.juniper.net
Chapter 5:
BGP
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.
When you configure multipath on a BGP router, the route selection algorithm ignores both the router ID
and the peer ID selection criteria.
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:
Chapter 7:
www.juniper.net
Chapter 8:
Introduction to Multicast
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:
Appendix A:
www.juniper.net
3.
The no-client-reflect command can be used to stop excess advertisements.
An RR readvertises routes received from clients and nonclients, adding the cluster-ID attribute and the
cluster-list attribute.
4.
An RR readvertises routes received from clients and nonclients, adding the cluster-ID attribute and the
cluster-list attribute.
www.juniper.net