OSPF Case Studies

IN
TE
R
AL
SE
N
LY
<Course
OSPF
Case
Title>
Studies and Solutions
AL
SE
N
LY
OSPF Case Studies and Solutions
Area Border Router
IN
TE
R
Technically speaking, an area border router (ABR) is a router that connects two OSPF areas together.
In normal cases, ABRs will be connecting Area 0 to other areas. However, networks can actually
function without an Area 0 and with only two areas. So, is this router an ABR? How does OSPF
indicate its ABR status to other routers?
www.juniper.net
AL
SE
N
LY
The Router LSA
IN
TE
R
An OSPF router is an ABR when the B bit is set in the router link-state advertisement (LSA), also
referred to as a Type 1 LSA. The slide indicates this setting by the bits field of 0x1. The other bits in
the field are used to indicate virtual links or autonomous system boundary routers (ASBRs).
www.juniper.net
Summary LSA
AL
SE
N
LY
IN
TE
R
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
AL
SE
N
LY
Adding a Third Area
IN
TE
R
To change things up a bit, connect another area to R5. In this case, Area 0 is connected to R5. As
soon as R5 establishes an adjacency with Area 0, routes to R1 and R2 disappear from the routing
table.
www.juniper.net
AL
SE
N
LY
Summary LSAs Are Still Present
TE
R
Building on the previous slide and issuing a show ospf database netsummary command, the
summary LSAs are present on R5 for R1 and R2. R5 is also generating summary LSAs for its
attached areas as designated by the asterisk (*) in the output.
SPF Does Not Install
IN
Even though the LSAs are present in the OSPF database, a show ospf route command does not
show the routes to R1 and R2. The SPF calculation is removing those entries in its decision tree. The
loop detection mechanism in OSPF causes this action. Essentially, R5 will only accept summary LSAs
from routers from the backbone. Because an ABR would have a full view of each connected area,
and it does not see R1 and R2, it ignores the summary LSA.
www.juniper.net
AL
SE
N
LY
Technical OSPF
TE
R
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)
IN
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.
www.juniper.net
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.
AL
SE
N
LY
Acquisitions and Mergers
IN
TE
R
Companies are acquired or merged with other companies every day. These mergers present many
interesting challenges, including how to combine the IP networks into one network. For example,
imagine two companies running OSPF that must merge networks. For OSPF to work correctly, each
company must connect their respective Area 0s together to form a single contiguous backbone. The
easiest solution will be new physical connections between the routers in each company. However,
this solution is often easier said than done, and time can be a deciding factor. For these cases, a
temporary solution such as virtual tunnels or virtual links can be deployed.
www.juniper.net
AL
SE
N
LY
Case Study
IN
TE
R
In this case study, ISP A has acquired ISP B. Both networks are running multiarea OSPF and they
must get both networks communicating with each other.
www.juniper.net
AL
SE
N
LY
Integration Case Study
IN
TE
R
During the acquisition phase, an integration team is formed to look at all facets of combining the two
companies, including their OSPF networks. The determination is that connecting both Area 0
networks together with physical connections is not a viable short term option. An alternative solution
must be used.
10
www.juniper.net
AL
SE
N
LY
Initial Physical Connection
IN
TE
R
The first step is to establish some physical connectivity between the two companies. In this case, the
integration team chose to connect ISP As A6 router and ISP Bs B4 router. For now, the new interface
will be configured in Area 10 on the A6 and B4 routers.
www.juniper.net
11
AL
SE
N
LY
Connectivity Issues
IN
TE
R
As soon as the physical connection is created, limited connectivity is achieved. For example, the B6
router can now reach the A1 router in ISP As Area 0. However, ISP As Area 0 routers cannot reach
ISP Bs Area 0 routers. The cause of this limited connectivity is the lack of a contiguous Area 0
backbone.
12
www.juniper.net
AL
SE
N
LY
Virtual Tunnels
IN
TE
R
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.
www.juniper.net
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
calculation could create some confusion when troubleshooting, which is one of the primary reasons
virtual tunnels are not considered long term solutions.
13
AL
SE
N
LY
Virtual Link Established
IN
TE
R
In this case, a virtual link is established between ABRs in each company. These ABRs must be
attached to Area 0.
14
www.juniper.net
AL
SE
N
LY
Virtual Link Configuration
TE
R
The configuration of a virtual link takes place within the Area 0.0.0.0 portion of the OSPF hierarchy.
The virtual-link command itself requires both a transit area and a neighbor ID to be
configured. The transit area is the OSPF area through which you configure the virtual link. The
neighbor ID is the 32-bit router ID (RID) of the router on the far end of the virtual link. Once each side
completes this configuration, each router begins to send unicast OSPF traffic towards the far-end
router to complete the link setup and form an adjacency.
IN
Virtual Link as an Interface

Once the two ends of the link can communicate, the virtual link becomes an operational OSPF
interface. It appears in show commands and within the OSPF link-state database (LSDB). It is always
noted in a format of vl-neighbor-id, where vl denotes it as a virtual link, and the
neighbor-id is the RID of the far-end router.
www.juniper.net
15
AL
SE
N
LY
Contiguous Area 0
IN
TE
R
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.
16
www.juniper.net
AL
SE
N
LY
Multiarea Adjacencies
IN
TE
R
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. For example, you configure an interface to belong to multiple
areas with a high-speed backbone link between two ABRs to enable you to create multiarea
adjacencies that belong to different areas.
www.juniper.net
As defined in RFC 5185, OSPF Multi-Area Adjacency, the ABRs 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
each area, one of the logical interfaces is treated as primary, and the remaining interfaces that are
configured for the area are designated as secondary.
17
Case Study
AL
SE
N
LY
IN
TE
R
The slide displays the case study topology.
18
www.juniper.net
AL
SE
N
LY
Link Failure
IN
TE
R
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, which creates three hops to reach a router that was previously one
hop away.
www.juniper.net
19
AL
SE
N
LY
Link Failure with Multiarea Adjacency
IN
TE
R
With multiarea adjacency configured, a hop to reach R3 is eliminated.
20
www.juniper.net
AL
SE
N
LY
Adjacency Verification
TE
R
Verify adjacencies with the show ospf neighbor command.
Normal Trace
IN
For the case study, R1 is one hop away from R3.
www.juniper.net
21
AL
SE
N
LY
Disable the Interface
TE
R
To test normal operations, disable the interface between R1 and R3.
Trace Under Link Failure
IN
The trace from R1 to R3 now takes a 3 hop path.
22
www.juniper.net
AL
SE
N
LY
Multiarea Adjacency Configuration
TE
R
To configure multiarea adjacency in the Junos operating system, configure a secondary logical
interface for an OSPF area using the secondary statement. Any logical interface not
configured as a secondary interface for an area is treated as a primary interface for that area. A
logical interface can be configured as a primary interface for only one area. For any other area
in which you configure the interface, you must configure it as a secondary interface.
IN
Point-to-Point Interface
www.juniper.net
Interface ge-1/0/4.1100 now has two OSPF links, however, the secondary link show up as a
point-to-point interface.
23
AL
SE
N
LY
Adjacency Is Formed
TE
R
Two adjacencies are now formed over ge-1/0/4.1100 for Area 0 and Area 100.
Trace with Multiarea
IN
With the multiarea adjacency feature configured, the trace now requires only 2 hops, compared with
the default case of 3 hops.
24
www.juniper.net
AL
SE
N
LY
OSPF Default Export Policy
TE
R
Recall that any policy applied to OSPF affects only external routes that are either Type 5 or Type 7
LSAs. Because OSPF does not inject any external routes by default, the default export policy is to
reject all routes. In other words, no external routes are send without a routing policy applied.
IN
Route Redistribution
www.juniper.net
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.
25
AL
SE
N
LY
Mutual Redistribution
IN
TE
R
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 issue, but the easiest method usually involves modifying route preference values.
26
www.juniper.net
AL
SE
N
LY
Case Study Topology
IN
TE
R
The slide displays the case study topology that will be used in subsequent slides. R1, R2 and C1 are
all running RIP.
www.juniper.net
27
AL
SE
N
LY
Case Study Background
IN
TE
R
The slide describes the goal of the case study. The goal is to advertise a single RIP route into OSPF
as well as send a default route to RIP.
28
www.juniper.net
AL
SE
N
LY
Create a Policy for the RIP Route
TE
R
The first step is to create a policy and apply the policy to OSPF. In this case, two match conditions
were used, creating a logical AND. This policy will be applied to both R1 and R2 under [edit
protocols ospf] by performing a set protocols ospf export redistribute-rip
command.
IN
Verify Policy Operation
www.juniper.net
Verify that the policy is working by examining the database and finding the Type 7 LSA associated
with the RIP route.
29
AL
SE
N
LY
ABR Translation
TE
R
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
IN
When the ABR translates the Type 7 into a Type 5, it places the ASBRs 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 ABRs also create a Type 4 LSA to represent the ASBR to other areas.
30
www.juniper.net
AL
SE
N
LY
Redistribution of Default Route
TE
R
The next step is to redistribute the default route into OSPF using an export policy under RIP. By
default, RIP has a lower preference than OSPF external routes.
Because RIP has a better preference, the default route for RIP is preferred. In the sample network,
this preference creates a loop, because the OSPF routers point to the RIP router as their gateway,
and the RIP router points to the OSPF ASBRs.
IN
To fix the loop, modify the OSPF route preference to a lower value than the RIP route.
www.juniper.net
31
The Result
AL
SE
N
LY
IN
TE
R
The result of the preference change is now a default that points properly to the ABRs in the NSSA.
32
www.juniper.net
AL
SE
N
LY
SPF Review
TE
R
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.
IN
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, and cost), which describe each link in the network.
www.juniper.net
33
Import Policy
AL
SE
N
LY
IN
TE
R
An import policy can be applied between the tree database and the routing table. This policy 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.
34
www.juniper.net
AL
SE
N
LY
The Junos OS Supports Large Numbers of Routes
IN
TE
R
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. While this protocol stability is a nice feature, a
configuration mistake could make a portion of your network unusable, because only the Juniper
Networks routers 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
35
Modify Policy
AL
SE
N
LY
TE
R
To see prefix limits in action, a policy is modified to send all RIP routes into OSPF.
RIP Redistribution
IN
This policy causes all RIP routes to be sent into OSPF.
36
www.juniper.net
AL
SE
N
LY
Prefix Limit
TE
R
To stop the large amount of LSAs that could enter the router, a prefix limit of zero is configured.
The Result
IN
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
37

OSPF Case Studies

Uploaded by

Copyright:

Available Formats

OSPF Case Studies

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OSPF Case Studies

Uploaded by

Copyright:

Available Formats

IN

OSPF Case Studies and Solutions

Area Border Router

OSPF Case Studies and Solutions

The Router LSA

OSPF Case Studies and Solutions

OSPF Case Studies and Solutions

Adding a Third Area

OSPF Case Studies and Solutions

Summary LSAs Are Still Present

SPF Does Not Install

OSPF Case Studies and Solutions

From the OSPF RFC 2324:

OSPF Case Studies and Solutions

Acquisitions and Mergers

OSPF Case Studies and Solutions

OSPF Case Studies and Solutions

Integration Case Study

OSPF Case Studies and Solutions

Initial Physical Connection

OSPF Case Studies and Solutions

OSPF Case Studies and Solutions

OSPF Case Studies and Solutions

Virtual Link Established

OSPF Case Studies and Solutions

Virtual Link Configuration

Virtual Link as an Interface

OSPF Case Studies and Solutions

OSPF Case Studies and Solutions

OSPF Case Studies and Solutions

The slide displays the case study topology.

OSPF Case Studies and Solutions

OSPF Case Studies and Solutions

Link Failure with Multiarea Adjacency

With multiarea adjacency configured, a hop to reach R3 is eliminated.

OSPF Case Studies and Solutions

Verify adjacencies with the show ospf neighbor command.

For the case study, R1 is one hop away from R3.

OSPF Case Studies and Solutions

Disable the Interface

To test normal operations, disable the interface between R1 and R3.

Trace Under Link Failure

The trace from R1 to R3 now takes a 3 hop path.

OSPF Case Studies and Solutions

Multiarea Adjacency Configuration

OSPF Case Studies and Solutions

Trace with Multiarea

OSPF Case Studies and Solutions

OSPF Default Export Policy

OSPF Case Studies and Solutions

OSPF Case Studies and Solutions

Case Study Topology

OSPF Case Studies and Solutions

Case Study Background

OSPF Case Studies and Solutions

Create a Policy for the RIP Route

Verify Policy Operation

OSPF Case Studies and Solutions

OSPF Case Studies and Solutions