Professional Documents
Culture Documents
Routing
10.a
Instructor 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
iv • Contents www.juniper.net
Course Overview
This four-day course is designed to provide students with detailed coverage of OSPF, IS-IS, BGP, and
routing policy. Through demonstrations and hands-on labs, students will gain experience in
configuring and monitoring the Junos operating system and in monitoring device and protocol
operations. This course is based on the Junos OS Release 10.3R1.9.
Objectives
After successfully completing this course, you should be able to:
• Describe the various OSPF link-state advertisement (LSA) types.
• Explain the flooding of LSAs in an OSPF network.
• Describe the shortest-path-first (SPF) algorithm.
• List key differences between OSPFv2 and OSPFv3.
• Describe OSPF area types and operations.
• Configure various OSPF area types.
• Summarize and restrict routes.
• Identify some scenarios in a service provider network that can be solved using routing
policy or specific configuration options.
• Use routing policy and specific configuration options to implement solutions for
various scenarios.
• Explain the concepts and operation of IS-IS.
• Describe various IS-IS link-state protocol data unit (LSP) types.
• List IS-IS adjacency rules and troubleshoot common adjacency issues.
• Configure and monitor IS-IS.
• Display and interpret the link-state database (LSDB).
• Perform advanced IS-IS configuration options.
• Implement IS-IS routing policy.
• Explain the default operation in multiarea IS-IS.
• Describe IS-IS address summarization methods.
• Configure and monitor a multiarea IS-IS network.
• Describe basic BGP operation.
• List common BGP attributes.
• Explain the route selection process for BGP.
• Describe how to alter the route selection process.
• Configure some advanced options for BGP peers.
• Describe various BGP attributes in detail and explain the operation of those attributes.
• Manipulate BGP attributes using routing policy.
• Explain the causes for route instability.
• Describe the effect of damping on BGP routing.
• Explain the default behavior of damping on links.
• Control damping using routing policy.
• View damped routes using command-line interface (CLI) commands.
Day 1
Chapter 1: Course Introduction
Chapter 2: OSPF
Lab 1: OSPF Multiarea Networks
Chapter 3: OSPF Areas
Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization
Chapter 4: OSPF Case Studies and Solutions
Lab 3: Advanced OSPF Options and Policy
Day 2
Chapter 5: IS-IS
Lab 4: IS-IS Configuration and Monitoring
Chapter 6: Advanced IS-IS Operations and Configuration Options
Lab 5: Advanced IS-IS Configuration Options and Routing Policy
Chapter 7: Multilevel IS-IS Networks
Lab 6: Configuring a Multilevel IS-IS Network
Day 3
Chapter 8: BGP
Lab 7: BGP
Chapter 9: BGP Attributes and Policy—Part 1
Lab 8: BGP Attributes: Next-Hop, Origin, MED, and AS Path
Day 4
Chapter 10: BGP Attributes and Policy—Part 2
Lab 9: BGP Attributes: Local Preference and Communities
Chapter 11: BGP Route Damping
Lab 10: BGP Route Damping
Chapter 12: Route Reflection and Confederations
Lab 11: Scaling BGP
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
CLI Undefined Text where the variable’s value is Type set policy policy-name.
the user’s discretion or text where
ping 10.0.x.y
the variable’s value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.
Introductions
The slide asks several questions for you to answer during class introductions.
Course Contents
The slide lists the topics we discuss in this course.
Prerequisites
The slide lists the prerequisites for this course.
Additional Resources
The slide provides links to additional resources available to assist you in the installation,
configuration, and operation of Juniper Networks products.
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.
Course List
You can access the latest Education Services offerings covering a wide range of platforms at
http://www.juniper.net/training/technical_education/.
Find Us Online
The slide lists some online resources to learn and share information about Juniper Networks.
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.
Chapter 2: OSPF
Advanced Junos Service Provider Routing
OSPFv2 Review
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
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.
Packet Types
Every OSPF router uses a specific set of packets to perform its functions. The packet types include
the following:
• 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 neighbor’s 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.
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.
Area 1, Area 2, and Area 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 those into its attached area.
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:
• 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 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 also be an internal or 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 Interfaces
All logical interfaces associated with the area should be listed under the area. Remember the
loopback interface, if it should be advertised.
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.
Link-State Advertisements
The slide highlights the topic we discuss next.
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.
• Network LSA: Sent by the designated router on the broadcast network.
• Summary LSA: Sent by an area border router (ABR) to describe routes or other
information from one area into another.
• AS external LSA: Sent by an autonomous system boundary router (ASBR) to describe
routes external to the OSPF domain.
• Group membership LSA: Used to support Multicast OSPF (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.
Continued on the next page.
LSA Header
The following list details the information contained in the LSA header:
• LS age (2 bytes): Measured in seconds, the LS age is the time since 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.
• LS type (1 byte): Encodes the specific LSA type.
• 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.
• LS 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.
• LS 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.
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:
• 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): This value gives the total number of links represented by the
following set of fields.
• Link ID (4 bytes): This field represents what the far side of the link is connected to. It is
used in conjunction with the link type field.
• Link data (4 bytes): This field represents what the near side of the link is connected to.
It is used in conjunction with the link type field.
• Link type (1 byte): This field describes the type of link.
• Number of ToS metrics (1 byte): This field lists the number of type of service metrics
encoded. Only a value of 0 is supported.
• Metric (2 bytes): This field provides the cost to transmit data out of the interface.
• Additional ToS data (4 bytes): This field is unused.
Network LSA
Each OSPF router elected to be the designated router (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.
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:
• 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.
• ToS metric (3 bytes): This field is not used.
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:
• 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.
• Optional ToS fields (4 bytes): These fields are unused.
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.
Protocol Operations
The slide highlights the topic we discuss next.
Dijkstra Algorithm
After a router receives a new LSA and places it into the LSDB, the router runs an algorithm known as
the Dijkstra algorithm (also called the shortest-path-first 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 databases—the 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.
1. 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. Return to Step 1.
Continued on the next page.
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.
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.
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.
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 daemon (RPD)
initializes. This timer can run from 60–1800 seconds. When the timer expires, the metrics return to
normal in the router LSAs, but the configuration still contains the overload option.
Case Study
Service provider 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 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 be forwarded to R2.
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 if 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.
OSPF Authentication
The slide highlights the topic we discuss next.
Authentication
The three different forms of authentication that the Junos OS supports are none, simple, and MD5.
As of Junos version 8.3, IPsec was added. IPsec is configured at the [edit protocols ospf
area area-id interface interface-name] hierarchy using the set ipsec-sa name;
command. See the Junos OS Routing Protocols Configuration Guide for more information.
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.
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.
Authentication Mismatch
OSPF routers must agree on the authentication method to be neighbors. Use the traceoptions
commands if you suspect there may be an authentication mismatch.
The log shows that the local router is “ignoring” an OSPF packet from 172.20.77.1 due to an
authentication mismatch. No authentication method is configured on the local router, so the type is
none. The remote router has MD5 authentication configured.
Review Questions
1.
LSA Type 9 supports graceful restart.
2.
The metric or cost of a router’s links can be automatically altered with the reference-bandwidth
command.
3.
The different forms of OSPF authentication include none, simple, and MD5.
OSPF Scalability
With a link-state protocol, flooding link-state update packets and running the shortest-path-first (SPF)
algorithm consume 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.
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.
OSPF Routers
OSPF routers can perform several different roles within an OSPF domain. The following list shows the
common types of OSPF routers along with a brief description:
• 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 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 also be an internal or area border router 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.
In addition to the LSA types already discussed, the OSPF specification also includes the following LSA
types:
• Type 6: Multicast OSPF LSA;
• Type 8: External attributes LSA;
• Type 9: Opaque LSA (link scope);
• Type 10: Opaque LSA (area scope—used for traffic engineering); and
• Type 11: Opaque LSA (AS scope).
NSSA Operation
The slide highlights the topic we discuss next.
NSSA Configuration
The slide highlights the topic we discuss next.
Route Summarization
This slide highlights the topic we discuss next.
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.
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.
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 will prevent 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.
Because only the ABR is responsible for this mapping function, you must configure only the ABR with the
area-range restrict command.
Review Questions
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 affected by the area-range command.
Virtual Links
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
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.
Technical OSPF
From the OSPF RFC 2324:
“Any router running OSPF attached to multiple areas is known as Area Border Router
(ABR). An ABR will have topological information of all attached areas and will run SPF for
each area.” (Section 3.3)
Technically, you can create 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.
Case Study
In this case study, Petroleum Inc. (ISP A) acquires Bob’s Oil and Gas (ISP B). Both networks are
running multiarea OSPF, and they must get the two networks communicating quickly.
Connectivity Issues
As soon as the physical connection is created, limited connectivity is achieved. For example, the
sales office at Bob’s (ISP B) can reach the neighbor router, but the corporate routers cannot. The
cause of this limited connectivity is the lack of a contiguous Area 0 backbone.
Virtual Tunnels
One solution to the connectivity problem is to create a virtual tunnel between the two backbone
areas of the companies. 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
companies.
Remember that a virtual tunnel 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 could
create some confusion when troubleshooting, which is one of the primary reasons virtual tunnels are
not considered long term solutions.
Contiguous Area 0
Once the neighbor is established over the virtual link, connectivity is restored, all LSAs are
processed, and routes to each company are installed into the routing table.
Multiarea Adjacencies
RFC 5185 defines multiarea OSPF adjacencies as the following:
“Multi-area adjacencies are configured between two routers having a common
interface. On point-to-point interfaces, there is no need to configure the neighbor’s
address since there can be only one neighbor. For all other network types, the neighbor
address of each multi-area adjacency must be configured as a point-to-point interfaces.
OSPF control packets are sent to the AllSPFRouters address. For all other network
types, OSPF control packets are unicast to the remote neighbor's IP address. “
Case Study
The slide displays the case study topology.
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.
Adjacency Verification
Verify adjacencies with the show ospf neighbor command.
Normal Trace
For the case study, R1 is one hop away from R3.
Point-to-Point Interface
Interface ge-1/0/4.1100 now has two OSPF links, however, the secondary link show up as a point to
point interface.
Adjacency Is Formed
Two adjacencies are now formed over ge-1/0/4.1100 for Area 0 and Area 100.
External Reachability
The slide highlights the topic we discuss next.
Route Redistribution
In order 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.
Mutual Redistribution
Special care must be taken when redistribution is configured in a networks 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 issue, but the easiest method usually involves modifying route preference values.
ABR Translation
Because the route was originated from the 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 ASBR’s address into the forwarding
address. This action supports optimal routing because only one ABR will translate the Type 7s to
Type 5s 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 create a Type 4 LSA to represent the ASBR to other areas.
The Result
The result of the preference change is now a default that points properly to the ABRs in the NSSA.
SPF Review
After a router receives a new LSA and places it into the 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 databases—the 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.
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.
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.
Prefix Limit
To stop the large amount of LSAs that could enter the router, a prefix limit of zero 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.
Review Questions
1.
Although technically you do not need a backbone area, functionally you need one because of the loop
prevention mechanisms in OSPF.
2.
Virtual links would be deployed if two companies were merging their networks together and physical link
connectivity was not an option. This could be due to cost or time constraints.
3.
If the source route has a lower preference there usually are no issues. If a source route has a higher
preference, suboptimal routing or loops can occur.
Chapter 5: IS-IS
Advanced Junos Service Provider Routing
Overview of IS-IS
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
The ISO
The protocol was developed by Digital Equipment Corporation for its DECnet Phase V. The
International Organization for Standardization (ISO) standardized IS-IS to be the routing protocol for
the ISO's Connectionless Network Protocol (CLNP) and is described in ISO 10589. The ISO was
working on IS-IS at the same time as the Internet Advisory Board (IAB) was working on OSPF. ISO
proposed that IS-IS be adopted as the routing protocol for TCP/IP in place of OSPF. This proposal was
driven by the opinion that TCP/IP was an interim protocol suite that would eventually be replaced by
the OSI suite.
CNLS
Connectionless Network Service (CLNS) is the service that Connectionless Network Protocol (CLNP)
provides to route messages to their destinations. This service is independent of any other messages
and can transmit data before a circuit is established.
Dual IS-IS
The Integrated IS-IS protocol was proposed to support the transition from TCP/IP to OSI. Integrated
IS-IS, also known as dual IS-IS, provides a single routing protocol capable of routing both CLNS and
IP. Integrated IS-IS was developed to operate in a CLNS, IP, or CLNS/IP setting.
Single Algorithm
Like all integrated routing protocols, Integrated IS-IS requires that all routers run a single routing
algorithm. Link-state protocol data units (PDUs) sent by routers running Integrated IS-IS include all
destinations running either IP or CLNP Network Layer protocols. Routers running Integrated IS-IS still
must support protocols such as Address Resolution Protocol (ARP), Internet Control Message
Protocol (ICMP) for IP, and the End System–to–Intermediate System (ES-IS) protocol for CLNP.
Continued on the next page.
Junos Support
M Series and MX Series Multiservice Edge Routers and T Series Core Routers only support IP routing
with IS-IS. They do not support CLNP or CLNS routing. SRX Series Services Gateways and J Series
Services Routers do support full IS-IS CLNP routing, including ES-IS routing.
Operation of IS-IS
An IS-IS network is a single AS, also called a routing domain, that consists of end systems (ESs) and
intermediate systems (ISs). End systems are network entities that send and receive packets.
Intermediate systems—which is the OSI term for a router—send and receive packets and relay, or
forward, packets. IS-IS packets are called protocol data units (PDUs).
IS-IS Areas
In IS-IS, a single AS can be divided into smaller groups called areas. Routing between areas is
organized hierarchically, allowing a domain to be divided administratively into smaller areas. IS-IS
accomplishes this organization by configuring Level 1 and Level 2 intermediate systems. Level 1
systems route within an area, and Level 2 intermediate systems route between areas and toward
other ASs. A Level1/Level 2 system routes within an area on one interface and between areas on
another.
A Level 1/Level 2 system sets the attached bit in the Level 1 PDUs that it generates into a Level 1
area to indicate that it is a Level 2-attached backbone router and that it can be used to reach
prefixes outside the Level 1 area. Level 1 routers create a default route for interarea prefixes, which
points to the closest (in terms of metrics) Level1/Level2-attached router.
IS-IS Areas
IS-IS and OSPF are link-state routing protocols with many similarities. Differences exist between
them as well. In IS-IS areas, a Level 1/Level 2 router fulfills the same purpose as an area border
router (ABR) in OSPF. Likewise, the collection of Level 2 routers in IS-IS is the backbone, while Area 0
is the backbone in OSPF. However, in IS-IS, all routers are completely within an area, and the area
borders are on the links, not on the routers. The routers that connect areas are Level 2 routers, and
routers that have no direct connectivity to another area are Level 1 routers. An intermediate system
can be a Level 1 router, a Level 2 router, or both (an L1/L2 router).
OSPF Areas
The slide shows the same network as the previous slide, only configured with OSPF instead of IS-IS.
Compare the two slides to identify the similarities and differences. OSPF area borders are marked by
routers. Some interfaces are in one area, and other interfaces are in another area. When an OSPF
router has interfaces in more than one area, it is an ABR.
IS-IS PDUs
The slide highlights the topic we discuss next.
PDU Type
The 1-byte PDU type field denotes whether this is a Level 1 or a Level 2 PDU. A value of 18
represents a Level 1 PDU and a value of 20 is a Level 2 PDU. With this exception as well as different
multicast destination addresses, the PDU contents and formats are identical to each other.
Overload Bit
An IS-IS router can set the overload bit to inform the other routers in the network that it is incapable
of reliably transmitting transit packets to other portions of the network. While the original intent of
the bit was to ease memory problems on individual routers, modern-era routers do not have such
constraints. In today’s network environment, the bit is often used to take a router out of service for
maintenance or to allow it to fully converge within the network before forwarding traffic.
IS Type Bits
The IS type bits inform other routers in the network about the capabilities of the local router. Two
possible settings are available for these bits. When the bits are set to a value of 01 (0x01), the local
router can only support Level 1 routing. A value of 11 (0x03), however, means that the local router
can support both Level 1 and Level 2 routing. These settings are the only two settings possible for
these bits.
Hello Transmission
Routers send hello packets at a fixed interval on all interfaces to establish and maintain neighbor
relationships. The hello interval field advertises this interval in the hello packet. By default, a
designated intermediate system (DIS) router sends hello packets every 3 seconds, and a non-DIS
router sends hello packets every 9 seconds.
Continued on the next page.
IPv6 TLVs
The following list provides the details of the TLVs that support IPv6:
• TLV 232 (IPv6 interface address): Advertises the IPv6 interface address for those
interfaces that support IPv6 traffic.
• TLV 236 (IPv6 reachability): Advertises information about the network link on which the
IPv6 protocol is operating. This TLV contains multiple sub-TLVs that contain the actual
metric information, among other things.
IS Reachability TLV
Each IS-IS router advertises its adjacencies with neighboring systems through this TLV. The various
metric fields as well as the neighbor ID field are repeated for each adjacent neighbor. The metric
values are encoded in a 6-bit field resulting in possible metrics between 0 and 63. These values are
sometimes referred to as old-style or small metrics. The IS reachability TLV contains the following
fields:
• TLV type (1 byte): The type of the TLV is encoded in this field with a constant value of 2.
• TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field.
This length allows the router to determine the number of neighbors encoded within the
TLV. Each set of neighbors and metrics occupies 11 octets of space. Therefore, the field
length minus 1 (for the virtual flag) should be divisible by 11, resulting in the number of
adjacent neighbors.
• Virtual flag (1 byte): An IS-IS router sets this flag when the advertised information
should be used to repair a nonadjacent Level 2 area. The Junos OS does not support
partition repair and this field is set to a constant value of 0x00.
Continued on the next page.
Authentication TLV
If configured to support authentication, an IS-IS router includes this TLV in all advertised link-state
PDUs. The authentication TLV contains the following fields:
• TLV type (1 byte): The type of the TLV is encoded in this field with a constant value of 10.
• TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field.
• Authentication type (1 byte): The specific form of authentication is encoded in this field.
Plain-text authentication uses a value of 1, while MD5 authentication uses a value of
54.
• Password (Variable): The actual authentication data is stored in this field. When MD5 is
used, the size of this field is always 16 bytes.
TE IP Router ID TLV
All routers configured to support traffic engineering, which is the Junos OS default setting, generate
this TLV. The router ID of the local router is placed in this field for use in the TED. The TE IP router ID
TLV contains the following fields:
• TLV type (1 byte): The type of the TLV is encoded in this field with a constant value of
134.
• TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field
with a constant value of 4.
• IPv4 address (4 bytes): The router ID of the local router is placed in this field.
Pseudo-Node
IS-IS elects a DIS on broadcast and multi-access networks for the same reason as OSPF. Rather than
having each router connected to the LAN advertise an adjacency with every other router connected
to the LAN, the network itself is considered a router—a pseudo-node. Each router, including the DIS,
advertises a single link to the pseudo-node. The DIS also advertises, as the representative of the
pseudo-node, a link to all of the attached routers.
Continued on the next page.
IP Configuration Necessary
When establishing adjacencies in OSPF, all routers on a link must agree upon the IP subnet to which
they belong, except on point-to-point links, which can be unnumbered or use /32 addressing. The
Junos OS needs the IP portion of the network to function so that the IS-IS adjacency will work.
Troubleshooting No Adjacency
The slide provides a checklist to use when troubleshooting IS-IS adjacency problems.
Reference Bandwidth
To enable the calculation, use the reference-bandwidth command within the [edit
protocols isis] configuration hierarchy. The value entered has a value in bits per second. Use
the standard Junos shortcut notations of k (kilobits per second), m (megabits), and g (gigabits). The
entered value becomes the numerator value in the bandwidth calculation.
Review Questions
1.
A PDU is a protocol data unit. It is used to send information about the IS-IS configuration between network
devices.
2.
The segments are called type/length/value (TLVs). They describe the originating router.
3.
Because IS-IS is deterministic, the added IS will assume the role of the DIS immediately and flood out new
PDUs to all other ISs on that segment.
4.
Set family iso and net on the physical and loopback interfaces. On the loopback interface, add an IP address
and an ISO address. Ensure that the Area Address portion of the NET is the same. Under [protocols
isis] disable Level 2.
IS-IS Operations
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
Dijkstra Algorithm
After a router receives a new link-state PDU and places it into the LSDB, the router runs an algorithm
known as the Dijkstra algorithm (or 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 databases—the LSDB, the candidate
database, and the tree database. Remember that the link-state database 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.
When 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:
1. For each new entry in the candidate database, the router determines the cost from 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.
2. 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 entry’s neighbor ID into the candidate database.
Continued on the next page.
Automatically Enabled
The functionality of the PRC is automatically enabled when you configure IS-IS within the Junos OS—
you do not have to do anything to benefit from the enhancement. Conversely, no configuration option
is available to disable this feature.
SPF Calculations
After receiving a new link-state PDU from another router, the local router performs an SPF calculation
using all the values contained in the LSPs in the database. 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.
Authentication Types
The Junos OS supports three different forms of authentication for the IS-IS protocol. These types are
none, simple, and Message Digest 5 (MD5). The type of authentication used must match on all
routers within a level.
Level Authentication
Configuration of any authentication at either Level 1 or Level 2 secures hello, link-state, and
sequence number PDUs.
In the example on the slide, MD5 authentication is enabled for Level 1, and simple authentication is
configured for Level 2.
Note
Take care when configuring authentication on a
point-to-point interface. IS-IS uses a single hello
PDU on these interfaces (as opposed to a
broadcast interface having a Level 1 and a Level
2 hello). Thus, the local router uses the
authentication configured at the lowest level for
the hello PDUs on this interface. Potential
problems might arise if one side of the interface
is operating both Level 1 and Level 2 while the
other side is operating only Level 2.
Full-Mesh Topologies
There are times when the default flooding mechanism might be a disadvantage. Such is the case
with a full-mesh physical or logical topology. In this type of an environment, each IS-IS router receives
extra copies of the same LSP. These extra copies are not needed and can be discarded safely.
In the example on the slide, the R4 router receives a LSP generated from the R1 router three times.
Group Numbers
To configure a mesh group within the Junos OS, assign each interface within IS-IS a group number by
using the mesh-group command. This number can be any 32-bit value. Within each local router,
any LSPs received on an interface assigned to a mesh group are not flooded out any interfaces
within that same mesh group.
Overload Settings
You can turn the overload setting on or off as a permanent value, or you can associate a timer
with it. If the timer is omitted, then the overload bit is set once you commit the configuration. The bit
remains until you remove the overload setting from the configuration, and the configuration is
committed once again. However, if you assign a timer value, the bit is not set automatically. The timer
associated with the overload bit initializes only when the routing protocol daemon (rpd) also
initializes. This timer can run from between 60 and 1800 seconds. Once the timer expires, the bit is
removed from the LSPs, but the configuration still contains the overload command.
The Result
The result of the preference change is now a default that points properly to the IS-IS router.
Review Questions
1.
The maximum default link metric is 63. By default, the Junos OS supports the sending and receiving of wide
metrics. To configure IS-IS to generate only the new pair of TLVs and thus to allow the wider range of metric
values, include the wide-metrics-only statement.
2.
None, simple, and MD5 are the three forms of IS-IS authentication.
3.
Import polices are not allowed for IS-IS, as this could lead to inconsistencies in the LSDB. The default export
policy for IS-IS is to reject everything. IS-IS floods link-state PDUs to announce local routes and any routes
learned by the protocol. Exporting can be used only to announce information from other protocols.
Multilevel Configuration
The slide highlights the topic we discuss next.
Review Questions
1.
Areas are segmented in an IS-IS L1/L2 network using L1/L2 ABRs.
2.
An IS-IS L1/L2 network is similar to an OSPF not-so-stubby-area (NSSA) with the no-summaries and
default-metric options configured.
3.
Route leaking is performed on the L1/L2 ABR. A routing policy is written matching the Level 2 routes to be
leaked. This policy is then applied at the [edit protocols isis] hierarchy.
4.
Summarization is performed on the L1/L2 ABR. An aggregate route encompassing the desired more specific
routes must be defined. Then a routing policy is created matching the aggregate with the to level 2 and
then accept actions. The policy should include a term to reject more specific routes. The policy is
applied at the [edit protocols isis] hierarchy.
Chapter 8: BGP
Advanced Junos Service Provider Routing
Review of BGP
Depending on the The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
students’ experience,
the instructor might
choose to skip or
quickly present the
“Review of BGP”
slides.
What Is BGP?
The Border Gateway Protocol (BGP) is a routing protocol between autonomous systems (ASs) and is
sometimes referred to as a path-vector routing protocol because it uses an AS path, used as a
vector, to prevent interdomain routing loops. The term path vector, in relation to BGP, means that
BGP routing information includes a series of AS numbers, indicating the path that a route takes
through the network. Although BGP is primarily used for inter-AS routing, BGP is also used in large
networks for MPLS-based VPNs and is used to separate large OSPF domains. BGP is much more
scalable and offers a greater amount of control through policy than an IGP.
BGP exchanges routing information among ASs. An AS is a set of routers that operate under the
same administration. BGP routing information includes the complete route to each destination. BGP
uses the routing information to maintain an information base of Network Layer reachability
information (NLRI), which it exchanges with other BGP systems.
BGP is a classless routing protocol, that supports prefix routing, regardless of the class definitions of
IPv4 addresses. BGP routers exchange routing information between peers. The peers must be
connected directly for inter-AS BGP routing (unless certain configuration changes are done). The
peers depend on established TCP connections, which we address later in this chapter.
BGP version 4 (BGP4) is essentially the only exterior gateway protocol (EGP) currently used in the
Internet. It is defined in RFC 4271, which made the former standard of more than 10 years,
RFC 1771, obsolete.
BGP Attributes
The primary purpose of BGP is not to find the shortest path to a given destination; rather, its purpose
is to find the best path. Each AS determines the best path to a prefix by determining its own
outbound routing preferences, the inbound routing preferences of the route’s originator (as updated
by ASs along the path between the source and destination ASs), and some information that is
collected about the path itself. All this information is contained in path attributes that describe the
path to a prefix. The path attributes contain the information that BGP uses to implement the routing
policies of source, destination, and transit ASs.
The slide lists some common BGP attributes. We cover the listed attributes in greater detail on
subsequent pages.
Loopback Peering
You maintain only one IBGP session between each internal peer. The IGP is used to maintain
reachability between the loopback addresses regardless of the physical topology, allowing the IBGP
sessions to stay up even when the physical topology changes.
The physical topology is relevant in one respect: each router along the path between BGP speakers
must have enough information to make consistent routing decisions about packet forwarding. In
many cases, this requirement means that all routers along all possible physical paths between BGP
speakers must run BGP; however, in some networks this requirement is not necessary.
Interface Peering
Recall that EBGP sessions are simply BGP sessions between two routers in different ASs. When two
EBGP peers have a single path between them, EBGP sessions are usually established over the
shared subnet between two peers, using the IP addresses assigned to the interfaces on that subnet
as the session endpoints. By establishing the EBGP session using the IP address assigned to the
interfaces on the shared subnet, you gain many advantages. One of these advantages is that you
prevent either AS from needing to maintain any routing information about the other AS (besides what
it received through BGP). You also ensure that all traffic flows over this particular shared subnet.
Configuring BGP
The slide illustrates the sample configuration.
In this configuration example, we see some parameters defined under the [edit
routing-options] and [edit protocols bgp] hierarchies. Under the [edit
routing-options] hierarchy, we defined the system’s router identifier (RID) and the local AS
number. Optionally, you can configure the system’s local AS number under the global BGP hierarchy
for a specific BGP group, or, for a specific BGP neighbor, use the local-as configuration option.
When the AS number is configured at multiple hierarchy levels, the AS number specified at the most
specific hierarchy level is used. The ability to specify different AS numbers at different hierarchy
levels can be quite useful, especially when merging networks with different AS numbers.
Because we are using loopback-based peering for the internal BGP group, we must reference
loopback addresses in the related BGP configuration. In this case, the neighbor address is the
remote peer’s loopback address. The local-address is the local device’s loopback address. If
the local address is not specified, the system uses the interface address of the egress interface
used to reach the referenced peer address. Because the peer is expecting to form an IBGP peering
session using the 192.168.100.1 address, you must specify that address as the local-address
in the configuration.
Continued on the next page.
BGP Authentication
All BGP protocol exchanges can be authenticated to guarantee that only trusted routing devices
participate in the AS’s routing. By default, authentication is disabled. You can configure MD5
authentication. The MD5 algorithm creates an encoded checksum that is included in the transmitted
packet. The receiving routing device uses an authentication key (password) to verify the packet’s
MD5 checksum.
BGP Operations
The slide highlights the topic we discuss next.
Hidden Routes
You might expect all routes received from a BGP peer would be installed in the RIB-LOCAL table and
be visible using the show route protocol bgp command. But hidden BGP routes occur for
several reasons:
• The route might be a martian route;
• An import policy might exist that prevents the route from being installed; or
• The route’s protocol next-hop might be unresolvable.
Unresolvable Next-Hop
The most common reason for hidden BGP routes is an unresolvable next-hop. The BGP Update
message contains a protocol next-hop IP address. If the router cannot resolve this address using its
routing table, the route cannot be used and is not installed in the routing table.
The number of hidden routes is always shown in the output of the show route command. To view
why routes are hidden, issue the show route hidden extensive command.
Configure multipath on R1
The configuration of the R1 router now contains the multipath command within the peer group for
AS 2. After committing the configuration, we examine the contents of the local routing table. We still
see the four routes advertised from AS 2, and each listing of the prefix still contains two versions of
the route. As before, the routes from the R2 router are marked active while the routes from the R3
router are marked inactive.
The effect of the multipath command on the routes from AS 2 is that the next hop for the routes
from R3 (10.222.29.2) are now added to the version of the route from R2. The next-hop information
for the inactive route version does not change in this environment.
As each active route now has two next hops in the routing table, the default Junos OS load-balancing
process can be used. Each route has a single next hop selected, and this single next hop is placed
into the forwarding table. All traffic for each route uses just that single next hop. The overall benefit
of this system is the total amount of traffic sent from AS 1 to AS 2 can now be load-balanced over the
two inter-AS links. In our small example, just the 172.16.20.16/30 route is using the 10.222.29.2
next hop, while the other three routes maintained 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/0. The routes from R2 are active while the next-hop values from R3 are also used to forward
user traffic.
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.1 and the 10.10.2.1 next hops are listed as valid outbound
interfaces for the 172.16.20.4/30 route. Traffic destined for this route is now forwarded across both
available next hops using a microflow hashing algorithm. The default inputs to the microflow hash
are the incoming router interface, the source IP address, and the destination IP address. You can
modify the inputs to the hashing algorithm at the [edit forwarding-options hash-key
family inet] configuration hierarchy. Specifying the layer-4 command at this configuration
hierarchy incorporates Layer 4 source and destination port information into the hash key.
Configuration Options
The slide highlights the topic we discuss next.
passive Option
By default, a local router initiates a BGP open message to the remote router to establish the session.
The passive command stops this default action, and no open message is sent. The IP address and
AS of the remote peer are still configured, but the remote router must initiate the BGP session.
allow Option
The related option of allow also stops the sending of a BGP open message to the remote router. In
addition, the allow command also relaxes the requirement of explicitly configuring the remote
router’s IP address by allowing you to define a subnet range for connections. BGP processes any
open message received from an IP address within the configured range and initiates a session with
that remote router.
Graceful Restart
Graceful restart (GR) addresses the situation described on the previous slide. GR allows a router
undergoing a restart event, including a restart of the routing protocol process (rpd), to inform its
adjacent neighbors and peers of its condition. The restarting router requests a grace period from the
neighbor or peer, which can then cooperate with the restarting router. When a restart event occurs
and GR is enabled, the restarting router can still forward traffic during the restart period, and
convergence in the network is not disrupted. The neighbors or peers of the restarting router, also
known as helper routers, hide the restart event from other devices not directly connected to the
restarting router. In other words, the restart is not visible to the rest of the network, and the
restarting router is not removed from the network topology.
The graceful restart request occurs only if the following conditions are met:
• The network topology is stable;
• The neighbor or peer cooperates;
• The restarting router is not already cooperating with another restart already in progress;
and
• The grace period does not expire.
GR Support
As shown on the slide, GR is supported by several standards-based protocols. A number of RFCs and
drafts exist that document the operational details for GR and each of the protocols for which GR is
supported. While these different protocols implement GR slightly differently, the basic concepts and
operations are the same from a high availability point of view.
GR Requirements
Routers must have GR enabled to support both GR router modes—the restarting router mode and
helper router mode. By default, Junos devices can operate as helper routers but not as restarting
routers; restarting router mode functionality must be enabled through configuration. We cover GR
configuration on subsequent slides.
In addition to having the GR functionality enabled, the router must support nonstop forwarding
operations, which simply means the router must be able to continue forwarding traffic during times
of control plane instability. Nonstop forwarding is an inherent attribute of Junos devices because of
the architectural design, which cleanly separates the control and forwarding planes.
Review Questions
1.
Using loopback addresses for peering sessions between IBGP neighbors maintains reachability even when
the physical topology changes as long as a viable path exists.
2.
EBGP-learned routes are advertised to both EBGP and IBGP peers. IBGP-learned routes are advertised to
EBGP peers. However, IBGP-learned routes are not advertised to other IBGP peers to prevent routing
loops.
3.
With Junos OS, all new BGP routes have an origin code of I=Internal.
4.
When you configure multipath on a BGP router, the route selection algorithm ignores both the router ID and
the peer ID selection criteria.
5.
Five approaches can solve the BGP next hop issue: Next-hop self; IGP passive interfaces; Export direct
routes into IGP; Static routes; and IGP adjacency formed on inter-AS links to EBGP peers.
Lab 7: BGP
The slide provides the objective for this lab.
BGP Policy
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
Next Hop
The slide highlights the topic we discuss next.
Other AS Networks
Note that routers in AS 30 use AS 20 to reach the networks in AS 1, due to a shorter AS-path length
through AS 20. Also, routers in AS 20 use AS 2 to reach the networks in AS 1, due to a shorter
AS-path length. Finally, routers in AS 10 use AS 3 to reach the networks in AS 1, due to a shorter
AS-path length. Why should AS 40 be the only AS confused about the best way to reach AS 1?
AS Path
The slide highlights the topic we discuss next.
AS-Path Prepending
The only standard approach to alter the AS-path attribute is to add information to it by prepending.
You can use a routing policy to extend (by prepending) AS-path information artificially onto an existing
AS path. This type of a policy is often an attempt to influence traffic coming into an AS from another
AS.
Continued on the next page.
Regular Expressions
Often, administrative BGP routing policies require that route announcements or prefixes be found
and acted on based on the information contained within the AS-path attribute. This requirement
might be to enforce some administrative policy regarding other AS networks. Sometimes, it is just
easier to find routes based on their AS path than by looking for many specific prefixes and routes
individually.
Other Uses
The slide lists some examples of the types of information that must be found in the AS path.
Context-Sensitive Matching
Regular expressions allow information in a string to be found within a specific context, not just in
isolated instances. You can use regular expressions in conjunction with the BGP AS-path attribute to
match routes within a policy.
Each AS Is an Entity
Within the Junos AS-path regular expression syntax, the term is a complete AS value. You can use the
wildcard character of the dot ( . ) to represent a single AS number as well. Thus, the Junos OS detects
an AS number of 1024 (for example) not as the four character text string of 1, 0, 2, 4, but as the
single entity of 1024. To the Junos OS, AS numbers are not sequences of characters.
Format
Both the definition and application of the AS-path regular expressions occurs within the
policy-options configuration hierarchy. The regular expression in proper term operator
format is given a name with the as-path statement.
AS-Path Name
You can reference the regular expression name within a policy.
Given a Policy
Consider the routing policy shown on the slide.
Review Questions
1.
An import policy operates between the RIB-IN and the RIB-LOCAL. An export policy operates between the
RIB-LOCAL and the RIB-OUT.
2.
The Junos OS sees all possible routes to be injected into BGP as internal routes and sets the origin code as
I=Internal.
3.
Different ASs can set the MED values differently. A good MED value from one AS may be a bad value from
another AS.
4.
The purpose of prepending the AS PATH is to make the route advertisement look undesirable.
Local Preference
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
Local-Preference Power
The BGP attribute of local preference is the highest tiebreaker in the BGP path selection process. If a
BGP next hop is reachable, and BGP knows multiple routes, BGP always chooses the route with the
highest local preference. Thus, local preference is the first BGP attribute that favors one path over
another.
Pay Attention
When it comes to routing policy configurations, make sure to change local preference on the BGP
routes, not the preference of the BGP protocol as a whole!
Local AS Only
The slide points out the local nature of local preference. Consider another AS called Pearnet linked
by two lower-speed, but equal, links to Applenet. Which link should Pearnet use to reach
192.168.27.0/24 in Zebranet?
Because EBGP does not propagate the local-preference values used inside Applenet, the Pearnet AS
has no knowledge of the local-preference routing decisions made within Applenet with regard to the
192.168.27.0/24 route. Applenet, of course, still wants traffic from Pearnet to flow towards R2 to
avoid shuttling all this traffic across its backbone.
Communities
The slide highlights the topic we discuss next.
Overlapping Communities
You should also avoid having too many overlapping communities. Customer routes belonging to
multiple communities can also be an issue.
When it comes to communities, simplicity is always a worthwhile goal.
Well-Known Communities
Certain well-known communities have a global meaning and special purposes. They are defined in
RFC 1997. All BGP implementations that understand communities (communities are optional, but
transitive) must know these communities and respect their functions.
Community Format
The BGP community attribute itself is just a list of the individual community attribute values
associated with the route (tags). Because no real limit exists on the number of tags in the list, a route
can belong to many communities. No predefined, upper limit exists on the number of communities
allowed on a route.
Continued on the next page.
No-Export
The no-export community typically makes sure that route aggregation is optimal by suppressing more
specific routes. The no-export-subconfed just extends this aggregate concept to the sub-AS.
No-Advertise
The no-advertise community has a very narrow scope. Routes go to a BGP peer and no farther,
usually because peers know the routes through other means. This community is often used in a
LAN-connected router environment or when two BGP peers have multiple links between them.
No-Export Example
The slide shows a typical use of the BGP no-export community.
AS 1 has multiple BGP sessions to its neighbor, AS 2. AS 1 also uses AS 2 as a transit AS for
connectivity to the Internet. AS 1 wants to advertise 172.17.0.0/16 to the Internet because AS 1
owns that entire address space. In addition, AS 1 also wants to advertise more specific route
information (shown as 172.17.0/17 and 172.17.128/17) only to its peer, AS 2.
Advertising the specifics as well as the aggregate to AS 2 would assist AS 2 to route user traffic into
AS 1 more efficiently because load sharing could be used on the more specific routes, as shown on
the slide. However, why should the whole Internet know or care about these specifics?
To assist AS 2 in finding and rejecting the more specific routes, AS 1 assigns the no-export
community to the 172.17.0.0/17 and the 172.17.128.0/17 routes. The BGP edge routers in AS 2 that
connect to the Internet automatically suppress and do not readvertise the /17 routes. Only the /16
route is readvertised to the Internet.
Enforcing Communities
Of course, setting local preferences in other AS networks with communities requires all the AS
administrators to cooperate. Nothing makes an AS respect the community attribute value.
Configuring Communities
You configure BGP communities in the Junos OS at the [edit policy-options] CLI hierarchy
level. You simply give the community a name and a number of members in the form of the
community ID. When you define multiple community members, a logical AND is between them. Thus,
a given name represents Community1, AND Community2, AND Community3, and so on.
Community ID Format
The community ID has an as-number:community-value format, with a colon (:) separating the
high-order and low-order octets. You can use the keywords no-export, no-advertise, and
no-export-subconfed to specify the well-known community values.
Default Is to Send
If you do not delete community attribute values, by default, all BGP communities are sent to all peers
inside an AS and outside the AS. Why clutter up the routing updates with useless and potentially
harmful information?
Review Questions
1.
Local preference is a BGP attribute that influences traffic flow. Route preference is local to an individual
router and assists the routing table in choosing the active route.
2.
Local preference influences outbound traffic flow.
3.
The well-known communities are: No-export; No-advertise; and No-export-subconfed.
4.
The add community action adds the specified community string to the existing community attribute. The set
community action deletes any existing communities and adds the specified community string.
Routing Is Dynamic
In any real network, routes can appear and disappear rapidly if a link fails and restores itself
repeatedly in a short period of time. This is because any routes (and there could be thousands) that
use the failed interface as a next hop must respond to the failure, and the change in next hop must
propagate to all other routers on the network. This rapid changing of routing next hops is called route
flapping or just flapping as the link flaps up and down.
Update/Withdrawn Pairs
Flapping results in a rapid sequence of BGP update or withdrawn messages. Recall that BGP routers
must maintain separate memory tables for inbound and outbound traffic on a per-peer basis. In
addition, the BGP routing protocol propagates information on an as-needed basis. These two factors
make BGP unstable in the face of a flapping link.
Every BGP router that receives one of these update or withdrawn messages must send this
information on to all its BGP router peers. Much like the link-state IGPs of OSPF and IS-IS, BGP must
also recalculate its routing tables and databases every time a new update is received. If the new
information alters the path selection process, a new route is chosen for the RIB-LOCAL, and the new
route must be sent downstream to all BGP peers.
Continued on the next page.
Bad Links
Routes in a network can flap for any number of reasons. Quite possibly, the most frequent reason for
a link flap is because of faulty circuit that is on the brink of outright failure. Any link that rapidly
changes from seemingly operational to failing is a potential source of route flapping.
Unstable IGPs
Route flapping is not totally a BGP phenomenon. IGPs that are unstable because of faulty links can
affect BGP when IGP routes are injected into BGP for advertising. BGP stability is always desirable
and can be enhanced with careful use of static definitions and aggregates instead of injecting raw
IGP routes into BGP.
Route Damping
Because route flapping can be so harmful to BGP, the protocol was extended to support route
damping. RFC 2439, BGP Route Flap Damping (November 1998), defines route damping.
Sometimes the term dampening is seen and used.
EBGP Only
Route damping is only applied to routes received from an EBGP peer. EBGP sessions can carry
information about thousands of routes. Each EBGP session must update or withdraw these routes as
required. Route damping seeks to reward route stabilities while penalizing route flapping. Once
damping is enabled, the router begins to maintain a database of instability. If an EBGP-received
route experiences enough flaps, the local BGP process ignores information about that route. This
reaction results in not including this information in the route selection process and not advertising
route changes to downstream BGP peers. Note that some ISPs no longer use damping.
Default Value = 0
When a previously unknown (that is, new) route arrives at a BGP router that has damping enabled,
the new route is assigned a figure of merit value of 0.
Continued on the next page.
Point Reduction
The points given to a route decay (that is, reduce in value) at a certain rate, known as the
half-life. As long as points decay faster than they accumulate, the route is not suppressed.
εc ≤ εr e(t/λ)(ln 2)
where εr is the figure of merit reuse threshold, t is the maximum suppression (hold-down) time in
minutes, and λ is the half-life in minutes.
Cutoff Threshold
The figure-of-merit value interacts with the damping parameters. The slide lists these parameters.
The suppress variable is the configured threshold where a BGP route is considered unstable and is
not used. This variable represents the value of the penalty that establishes the point at which
damping is initiated. When this value is reached, the route is cutoff (suppressed). The default value
of suppress is 3000. Possible values range from 1–20000. If changed, this value must be less
than or equal to the merit ceiling εc, or damping never occurs.
Reuse Threshold
The reuse variable is the configured threshold where a BGP route is considered usable once again.
This variable is the value to which the penalty must decay before the router considers the route in its
path selection. The default value of the reuse is 750. Possible values range from 1–20000.
Decay Half-Life
The half-life variable is the rate at which the figure of merit is decreased to half its value once
the value is larger than 0. The default value of the half-life is 15 minutes. Possible values range
from 1–45 minutes.
Continued on the next page.
Damping History
The slide shows the output from the show route damping history command.
Any routes displayed by this command were withdrawn from the router. However, the router retains a
record of these routes should they be readvertised to the local router. Some notable details in the
display include the following:
• The route is currently hidden. We see this in both the State: <Hidden Ext> field as
well as the Preference: /-101 field. Notice that no Junos OS protocol preference
value is defined.
• There is a field (Merit) for the current figure-of-merit value. The two values that follow
list the value after the last BGP update (or withdrawal), and the current value after
experiencing some decay. For this route, the values are Merit: 2777/2454. Thus,
the value at the last update/withdrawal was 2777 (note that this value need not
necessarily exceed the default suppress threshold of 3000), and the current value is
2454.
• The default parameters are used (Default damping parameters used). If this
route were evaluated by a policy with a damping action, the new damping profile name
would appear in the output.
Damped Routes
The slide shows the output from the show route damping suppressed command.
Any routes displayed by this command were advertised to the router, but these routes have a figure
of merit that is currently above the suppress threshold, and the route is unusable.
Manual Clearing
The route remains in this state until the figure of merit crosses below the reuse threshold. A route
can have the figure of merit reduced to 0 administratively by using the clear bgp damping
command.
On the slide, the route 200.200.200.0/24 is currently suppressed and hidden. After we issue the
clear bgp damping command, the route is no longer hidden.
Review Questions
1.
IBGP sessions usually peer to loopbacks, so IGP routes must be able to come and go so that IBGP sessions
always have a way to reach the loopback.
2.
The half-life is the rate at which the figure of merit is decreased to half its value once the value is larger than
0. The default value of the half-life is 15 minutes.
3.
The max-suppress parameter establishes the maximum time that a route can be suppressed. The default value
is 60 minutes.
4.
If the suppress threshold is set higher than the merit ceiling no damping will occur.
5.
The command shows any routes that were advertised to the router and are currently usable routes, but have a
figure of merit greater than 0.
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 router ID
attribute. BGP chooses the route with the shortest cluster list length. This process follows the same
theory as the AS path attribute.
The cluster ID is very similar to an AS number and should be unique within an individual AS. The
cluster ID is added to the cluster list attribute when a route is sent to clients and non-clients.
Originator ID
The originator ID attribute provides the router ID of the first router to advertise the route in the AS. It
also is used for loop prevention in the rare case where the cluster list does not prevent a loop.
Route Propagation
The next series of slides shows the flow of routing information in a route reflection network using a
basic topology.
We begin with a client in the left-most cluster advertising the 10.10.10.0/24 route to the cluster’s
route reflector.
The slide details how the 10.10.10.0/24 route is readvertised to all other clients in the cluster as well
as to all non-client IBGP peers of the reflector. This process applies to all other routes the route
reflector receives from a client in its cluster.
This slide shows how the other route reflectors in the network readvertise all routes received from
IBGP peers (the other reflectors in this example) to all of their cluster clients.
BGP Confederations
The slide highlights the topic we discuss next.
Within a Sub-AS
The confederation sub-AS networks act just like a real AS; they require a full mesh of IBGP
connectivity within themselves. Should the full mesh of the sub-AS grow too large, route reflection
might be used within a sub-AS to scale the network.
Each sub-AS must have a unique AS number defined, and most administrators use a private AS
number from the 64512 to 65535 range.
Continued on the next page.
AS Confederation Sequence
As a route is advertised over a CBGP link, BGP modifies the AS path attribute to include the sub-AS
number. BGP places this sub-AS number into an AS confederation sequence, as denoted by
parentheses, within the AS path attribute. The sequence is a new AS path segment attribute with a
type code of 3.
The sub-AS values are sequenced in the order in which the route has traversed the network, with the
primary purpose being loop prevention within the confederation network. The confederation
sequence is not used in the calculation of AS path length for the BGP active route selection
algorithm. For routers within a confederation network, the confederation sequence appears as a
single, internal BGP AS network.
AS Confederation Set
Should some routing aggregation occur within the confederation network, the granularity of the
confederation sequence might be lost. This process is very similar to conventional BGP route
aggregation.
In this situation, the AS confederation sequence becomes an AS confederation set and is denoted by
curly braces within the AS path output. The set is also a new AS path segment attribute with a type
code of 4.
The routers within the confederation view the AS confederation set in the same manner as a
sequence. That is, the set is still used for loop prevention even though the ordering of the sub-AS
numbers is no longer significant.
Confederation Peering
The slide shows an example of a BGP confederation network. The global AS of 201 is split up into five
sub-AS networks—65000, 65001, 65002, 65003, and 65004. The sub-AS networks are connected
with EBGP-like connections (sometimes called CBGP). Because the CBGP links behave like EBGP,
there is no need for a full-mesh topology between each sub-AS. Therefore, you can provision CBGP
connections wherever it is logically, or physically, convenient.
Some of the sub-AS networks on the slide are using route reflection within the sub-AS to eliminate
the need for a full IBGP mesh. The combination of BGP confederations and route reflection
simultaneously allows for great flexibility in scaling your AS to hundreds or thousands of routers.
Review Questions
1.
Cluster ID and Cluster List support route reflection.
2.
The cluster statement is configured only on the route reflector.
3.
No-client-reflect can be used to stop excess advertisements.
4.
An RR readvertises routes received from clients and non-clients, adding the cluster ID and cluster list
attributes.
5.
Loops are prevented by examining the confederation AS sequence or AS set.
6.
Routers in a sub-AS run IBGP. Routers across a confederation boundary run CBGP. Routers external to the
confederations run EBGP.
Chapter 2: OSPF
1.
LSA Type 9 supports graceful restart.
2.
The metric or cost of a router’s links can be automatically altered with the reference-bandwidth
command.
3.
The different forms of OSPF authentication include none, simple, and MD5.
Chapter 5: IS-IS
1.
A PDU is a protocol data unit. It is used to send information about the IS-IS configuration between network
devices.
Chapter 8: 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.