Page 1
Tweet
0
Blog Home | INE Home | Members | Contact Us | Subscribe
Free Resources
View Archives
All Access Pass
CCIE Bloggers
Aug
17
OSPF Route Filtering Demystified
51 Comments
Posted by Petr Lapukhov, 4xCCIE/CCDE in IGP
Intro
There was a lot of blogging related to OSPF topics recently. In this post, I would like
to clarify some common misunderstandings that many people have about OSPF route
filtering. I have seen so many folks wrongfully understanding the underlying behavior so it’s
about time to make the things clear.
OSPF Data Structures
To begin with, avoid using the term “LSA filtering” with OSPF. You cannot really filter LSAs –
with the exception of one special case – you filter the network reachability information. To
understand this in depth, start by recalling that OSPF deals with the following data
structures:
1) Topological information. Outlines the connections in the graph describing the routers and
the links in the network. This is what OSPF LSAs are about – they contain information about
attached links. Think of LSAs as the objects that correspond to the “edges” of the graph.
LSAs are stored in the LSBD – link state database. No real “routes” are stored in the LSDB,
since this is the database for topological objects. However, routing or network reachability
information is attached to the LSAs.
2) Network Reachability information. Contains the actual IP subnets. This information is
“associated” with the network graph “edges” and you may think of it as “leaves” connected
to the edges. Routing information does NOT describe any connectivity, just the prefix
associated with the link. This information is contained in the LSAs, but as an “attribute”, and
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
1 of 25 12/22/2011 11:26 AM
Page 2
is used to populate the routing table – i.e. the RIB.
3) Main routing table. This is the router’s RIB, as OSPF does not have a RIB of its own,
unlike BGP. This structure is used when OSPF generates new summary or external LSAs as
we see later.
4) Routers routing table. This structure is unique to OSPF, and contains the IP addresses to
reach the “border” routers – ASBRs and ABRs. It is used when calculating the respective
inter-area routes, by adding the router path cost to the respective prefix advertised by this
router. You may display the contents of this data structure by using the command show ip
ospf border-routers.
OSPF route calculation overview
1) Routers establish adjacencies to flood topological information. The flooding process in
OSPF is pretty complicated, and ensures the LSAs are delivered to all routers in a single
area. As mentioned, topological information is carried in the form of LSAs and cannot be
filtered, which it is essential to the OSPF algorithm. The only thing that limits LSA
propagation is the flooding domain associated with the particular LSA type. Using the
topological information learned, all routers within an area build the consistent graph of the
network connections.
2) After all routers have a consistent topology view, they may calculate intra-area paths
using the SPF algorithm and finally associate the network reachability information with the
paths. This is where the “secondary”, leaf-level information comes in play. The leaves are
attached to the paths and the routing table entries are calculated. So keep this in mind – first
LSA flooding, then LSDB population, then SPF computations, and finally the RIB population.
3) After the intra-area paths have been calculated, inter-area routes are computed based on
type-3/4 LSAs contents for other area information summarization. This process uses a quick
and simple distance-vector computation algorithm, without the need for SPF computations.
The router’s routing table is used extensively during this process.
When you can REALLY filter LSAs
Now, back to the case of LSA filtering. Some may recall the commands ip ospf database-
filter all out or neighbor <IP> database-filter all out. Good point, but what it does is
prevent the OSPF process from sending any LSAs out of the particular adjacencies. This
could be done only if you’re sure that the LSAs will be flooded to all routers in the area by
some other means. This is the special case I’ve been talking about previously. The purpose
of this feature is to compensate for the absence of “mesh-groups” and limit the amount of
flooding on NBMA subnets shared by many routers.
Overview of OSPF route-filtering
All right, so if you cannot really filter LSAs, how do you perform “route filtering” with OSPF?
Using the term “route filtering” is the correct way of saying “LSA filtering”. You may apply
route filtering to OSPF using the following two general methods:
1) Preventing optimal paths generated by OSPF from entering the RIB. This is what you can
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
2 of 25 12/22/2011 11:26 AM
Page 3
do by applying the command distribute-list in under the OSPF process. This affects routes
installed in the RIB. There is one special extension of this method to filtering the FA
(forwarding address) to block external OSPF routes.
2) Affecting the LSA generation process, by changing the “source” information used to
generate the LSAs. There is a bunch of ways to do this, each specific to a particular LSA
type. To understand this completely, we need to recall all the basic LSA types and their
flooding scopes.
How OSPF generates different LSA types
LSA type 1. Describes an attached circuit, different link types. This is the fundamental
building block of the topology graph. This LSA is flooded within the single area and never
gets past the ABRs. The sources of information for LSA type-1 are the directly connected
links. If you want to remove the network reachability information, just remove the link
LSA type 2. Generated only on the “shared” networks (BROADCAST/NON-BROADCAST
network types) to minimize the amount of topological information generated. Imagine that
you have 10 routers on a shared Ethernet segment. Normally, to fully describe the topology,
every router would need to generate an LSA describing its connection to all other 9 routers.
This would result in 90 LSAs. Using LSA type-2 and the Designated Router concept, every
router needs to declare a connection to the DR, and the DR will generate a Type 2 LSA
describing all routers on the segment (the “bunch”). In our example, this will result in 11
LSAs total. This LSA does not carry any real “network reachability” information with the
exception of the netmask and the list of routers on the segment. It is used along with
information from type 1 LSAs to describe the shared network. I like to think of it as a “glue”
LSA. The flooding domain is one area as flooding stops at ABRs.
LSA type 3. Now this type is a bit tricky and brings in a lot of confusion. It is generated by
an ABR to tell the routers in one area about the network in another area. Essentially, the
router “pretends” like all the “foreign” networks are attached to it. From a topological
perspective, this is true, because areas never know anything about another area’s topology
– this information is lost when crossing the area boundaries. How are Type 3 LSAs
generated? First of all, keep in mind that OSPF generates those by walking the main
routing table, not the LSDB. This is per RFC 2328 clause 12.4.3 and in full accordance
with distance-vector protocol behavior. Every route in the table has additional OSPF
information associated with it, such as area number, route-type (intra-area, inter-area,
external) next hop, and so on.
1) The ABR goes over the network reachability information in the RIB associated with
intra-are routes for the particular area X and summarizes them honoring the area X range
command settings. This results in Type-3 LSAs being generated and advertised into all
other areas. Pay attention to the following important things:
1.1) Only intra-area routes are summarized. You cannot summarize inter-ara routes installed
by processing type-3 LSAs learned from Area 0. Those will generate new type-3 LSAs in the
ABR and will propagated them into non-backbone areas unmodified.
1.2) The intra-area routes are summarized PRIOR to applying the distribute-list filter and
blocking the routes from entering the RIB. This is needed to allow for generation of a
summary route, even if you don’t want the specific prefixes in the local RIB and calculate the
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
3 of 25 12/22/2011 11:26 AM
Page 4
correct metric if needed. Thus, even though OSPF walks over the RIB to gather the
intra-area prefixes for summarization, it does so BEFORE applying the filter. The ultimate
goal is making summarization the highest priority task, in order to increase network stability.
1.3) The OSPF metric for the summarized route is taken as the minimal among all intra-area
routes. To ensure better routing stability, it is usually recommended setting the metric
manually, to prevent LSA re-flooding in case some component route flaps and affects the
summary metric.
2) Now, for dealing with the inter-area routes learned by the ARB, first of all, keep in mind
that an ABR ONLY accepts and processes type-3 LSAs received from the backbone area.
This is the well-know loop prevention mechanism built into OSPF, since OSPF behaves as a
distance-vector protocol when dealing with inter-area routing information. This is a short
description of how an ABR processes type-3 LSAs:
2.1) Ignore the type-3 LSA if it is NOT from the backbone area (prevents routing loops).
2.2) Walk over the inter-area routes learned via Area 0 in the RIB and generate respective
type-3 LSAs which are flooded into the attached non-backbone areas. Thus, LSAs are
effectively being re-generated based on the RIB contents.
Next, consider an important aspect of this process. The re-generated summary LSAs are
generated AFTER applying the OSPF filter associated with the routing-process via the
distribute-list in command. Thus, if you filter some of the inter-area routes from entering
the RIB, the respective new summary LSAs will NOT get generated. This will stop routing
information propagation into the attached non-backbone areas.
This quickly summarizes the type-3 LSA generation process. Notice that filtering the routing
information is not based on some “LSA” filtering procedure, but rather on the routes
contained in the RIB. At this moment, some people may recall the command area X
filter-list prefix {in|out}. Good news here – this command applies after all summarization
has been done and filters the routing information from being used for type-3 LSA generation.
It applies to all three type of prefixes: intra-area routes, inter-area routes, and summaries
generated as a result of the area X range command. All information is being learned from
the router’s RIB.
Oh, almost forgot – LSA type-3 flooding scope is one area, it never crosses ABR boundaries
– it just gets re-generated when needed! Now, here is a summary of inter-area router
filtering commands (applicable only at an ABR):
Method 1: Filter the inter-area routes generated at ABR
router ospf 1
area 10 filter-list prefix in NAME
Method 2: Filter out intra-area routes
router ospf 1 area 10 range 1.1.1.0 255.255.255.0 no-advertise
Method 3: Filter inter-area routes learned by ABR from Area 0
router ospf 1
distribute-list 1 in
LSA type 4
This type has always been confusing to many people. This LSA describes the metric that
the ABR uses to reach the respective ASBR. This LSA contains the router-ID of the ASBR
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
4 of 25 12/22/2011 11:26 AM
Page 5
and the metric to reach it. ABRs generate type-4 LSAs based on the special “router routing”
table which is visible when you issue the command show ip ospf border-routers. This
command is the essense of the distance-vector OSPF behavior. During the inter-area path
calculations, the ABR populates this table with “host” routing entries for every ABR and
ASBR detected with the respective metrics. This table is never transferred to the main router
routing table, but rather used for inter-area path computations and type-4 LSA generation.
Effectively, the metrics in this table are used as metric offsets for the paths learned from
ABRs and ASBRs.
The ABR generates type-4 summary LSAs into every normal attached area, to make sure
the routers in there can reach the prefixes from the ASBR. You cannot really filter the
contents of this LSA, as they are taken from the router routing table. The information from
this LSA is used to populate the non-ABR routers “special” router routing table. The flooding
domain is one area as it stops at the ABR.
LSA type 5
This LSA is originated by an ASBR (router redistributing external routes) and flooded
through the whole OSPF autonomous system. You cannot limit the way this LSA is
generated except to controlling the routes redistributed into OSPF. When a type-5 LSA is
being generated, it uses the RIB contents and honors the summary-address commands in
the ABR. You may filter the redistributed routes by using the command distribute-list out
configured under the protocol, which is the source of redistribution or simply applying
filtering with your redistribution.
Method 1:
router ospf 1
distribute-list 10 out rip!
access-list 1 deny 1.1.1.0
access-list 1 permit any
Method 2:
router ospf redistribute rip route-map RIP_TO_OSPF
!
route-map RIP_TO_OSPF match ip address 1
Method 3:
router ospf
summary-address 10.0.0.0 255.255.25.0 no advertise
There is yet one more way to filter the routing information found in type-5 LSAs. If the LSA
contains non-zero “FA” (forwarding address) field, OSPF process will check for this address
to be accessible via RIB (RFC specifies that only OSPF routes should be considered, but it
seems IOS satisfies with any route) before installing the actual prefix into the RIB. If the FA
is not accessible, the corresponding external prefix is not installed into the global routing
table. We will discuss this type of filtering a bit later, when we’ll be looking into type-7 LSAs.
However, keep in mind that FA is non mandatory for type-5 LSA and is only assigned to a
type-5 LSA under special conditions, outlined in the following document Common Routing
Problem with OSPF Forwarding Address. Here is the list of the conditions:
OSPF is enabled on the ASBR’s next hop interface AND
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
5 of 25 12/22/2011 11:26 AM
Page 6
ASBR’s next hop interface is non-passive under OSPF AND
ASBR’s next hop interface is not point-to-point AND
ASBR’s next hop interface is not point-to-multipoint AND
ASBR’s next hop interface address falls under the network range specified in the
router ospf command.
Please refer to the URL provided for more epxplanations.
There is only one more type of OSPF LSAs to discuss.
Type 7 LSA
These only exist at NSSA areas and have the flooding scope of a single area, as opposed to
the whole domain for type-5 LSAs. The type-7 LSAs reaching ABRs are used to populate
the local routing table and re-generate the new type-5 LSAs, originated now by the ABR.
This is important – since the ABR becomes an ASBR and re-originates the routes, you may
use the command summary-address ADDR MASK no-advertise to block the type-5 LSA
generation. There is another, less obvious way to do things:
When an ABR generates type-5 LSAs, it adds the forwarding-address (FA) based on the
information learned in the type-7 LSA. This information is originally inserted by the ASBR to
help in optimal exit point selection. The use of forwarding-address with the type-7 LSAs is
mandatory per the RFC, since there is just one translator, and it may lie on the sub-optimal
path to the ASBR. Thus all routers in the OSPF autonomous system are supposed to rely
on the FA for optimal routing to the translated prefixes. And here is the trick: if you filter the
forward-address IP from the routing table in the ABR, using the command distribute-list in
the type-5 LSA will not be generated!. Look at the following output, where R2 is an ABR for
NSSA area 27:
Rack1R2#show ip ospf database nssa-external
OSPF Router with ID (150.1.2.2) (Process ID 1)
Type-7 AS External Link States (Area 27)
Routing Bit Set on this LSA LS age: 11
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link Link State ID: 162.1.7.0 (External Network Number )
Advertising Router: 162.1.7.7
LS Seq Number: 80000001 Checksum: 0xDEB5
Length: 36
Network Mask: /24Metric Type: 2 (Larger than any link state path)
TOS: 0Metric: 20
Forward Address: 150.1.7.7
External Route Tag: 0
Routing Bit Set on this LSA
LS age: 11 Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 162.1.10.0 (External Network Number ) Advertising Router: 162.1.7.7
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
6 of 25 12/22/2011 11:26 AM
Page 7
LS Seq Number: 80000001 Checksum: 0xBDD3
Length: 36
Network Mask: /24Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20Forward Address: 150.1.7.7
External Route Tag: 0
Rack1R2#show ip ospf database external
OSPF Router with ID (150.1.2.2) (Process ID 1)
Type-5 AS External Link States
...
LS age: 26 Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 162.1.7.0 (External Network Number ) Advertising Router: 150.1.2.2
LS Seq Number: 80000001
Checksum: 0x2193 Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)TOS: 0
Metric: 20
Forward Address: 150.1.7.7External Route Tag: 0
LS age: 26 Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 162.1.10.0 (External Network Number ) Advertising Router: 150.1.2.2
LS Seq Number: 80000001
Checksum: 0xFFB1 Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)TOS: 0
Metric: 20
Forward Address: 150.1.7.7External Route Tag: 0
As you can see, R2 generates type-5 LSA with the same forwarding address found in type-7
LSA – “150.1.7.7”. Now we filter this IP address from entering R2′s routing table:
R2:
access-list 1 deny 150.1.7.7access-list 1 permit any
!
router ospf 1 distribute-list 1 in
And apply our verification once again:
Rack1R2#show ip ospf database nssa-external
OSPF Router with ID (150.1.2.2) (Process ID 1)
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
7 of 25 12/22/2011 11:26 AM
Page 8
Type-7 AS External Link States (Area 27)
LS age: 222 Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 162.1.7.0 (External Network Number ) Advertising Router: 162.1.7.7
LS Seq Number: 80000001
Checksum: 0xDEB5 Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)TOS: 0
Metric: 20Forward Address: 150.1.7.7
External Route Tag: 0
LS age: 222
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link Link State ID: 162.1.10.0 (External Network Number )
Advertising Router: 162.1.7.7
LS Seq Number: 80000001 Checksum: 0xBDD3
Length: 36
Network Mask: /24Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20Forward Address: 150.1.7.7
External Route Tag: 0
Rack1R2#show ip ospf database external
OSPF Router with ID (150.1.2.2) (Process ID 1)
Type-5 AS External Link States
And we can see that Type-7 to Type-5 translation is not working anymore, as the forwarding
address is no longer reachable in the RIB. Notice that forwarding address should be
accessible via the main RIB, not the routers routing table of OSPF. This special behavior is
unique to the routes learned by processing the type-7 LSAs. Now what if you have to
following topology:
And R3 is filtering the forwarding address for the type-5 LSAs originated at R4 using say
area X range no-advertise or area X filer-list prefix {in|out} commands, so that R1 has
no FA IP in its RIB. In this situation, R3 will have the route to the redistributed prefixes
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
8 of 25 12/22/2011 11:26 AM
Page 9
installed (it sees the FA!), but all other routers in the domain with the exception of the NSSA
area internal routers will not. Even though they will receive the type-5 LSA, they will not be
able to process them and use the information for routing – the forwarding address will be
unreachable. One way to overcome this issue is by using the command area X nssa
suppress-fa to instruct R3 on setting the FA to itself.
Summary of the post
We went over almost all of the important route-filtering scenarios for OSPF. The key thing
you should remember is that non-local route filtering for OSPF is only available at ABRs and
ASBRs, the points where OSPF behaves as a distance-vector protocol with respect to
inter-area routing information. Here is the list of points you need to remember:
1) You cannot filter LSAs directly, you can only manipulate the routing information used to
generate LSAs.
2) The above routing information is taken from local router’s RIB directly.
2.1) In the case of intra-area routes, RIB filters are applied after the type-3 LSAs are
generated (intra-area routes are summarizable).
2.2) In the case of inter-area routes, RIB filters are applied prior to type-3 LSA generation
(inter-area routes are not summarizable).
3) External AS routes can only be filtered at the ASBR.
4) NSSA routes can be filtered at an ASBR and the ABR performing the translation.
5) If the FA for an external prefix is NOT reachable, the router will NOT install it into the
route table nor will it translate type-7 LSAs to type-5.
Futher Reading
1) RFC 2328. Dont skip this if you are serious about understanding OSPF
2) OSPF Design Guide by Sam Halabi. Excellent introductory reading on OSPF.
3) Cisco IP Routing by Alex Zinin. A must read to anyone who wants in-depth understanding
of IP Routing internals.
Tags: ccie, filtering, lsa, ospf
Download this page as a PDF
About Petr Lapukhov, 4xCCIE/CCDE:
Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and
progressed into networking with his first exposure to Novell NetWare in 1991. Initially
involved with Kazan State University's campus network support and UNIX system
administration, he went through the path of becoming a networking consultant, taking part in
many network deployment projects. Petr currently has over 12 years of experience working
in the Cisco networking field, and is the only person in the world to have obtained four
CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in
that he has been working with all of the technologies covered in his four CCIE tracks (R&S,
Security, SP, and Voice) on a daily basis for many years. When not actively teaching
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
9 of 25 12/22/2011 11:26 AM
Page 10
classes, developing self-paced products, studying for the CCDE Practical & the CCIE
Storage Lab Exam, and completing his PhD in Applied Mathematics.
Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website
You can leave a response, or trackback from your own site.
51 Responses to “OSPF Route Filtering Demystified”
Yandy Ramirez says:
August 17, 2009 at 4:02 pm
very cool post! thanks for the info
Reply
1.
Rizzo says:
August 17, 2009 at 5:36 pm
Really Nice one
Thanks
Reply
2.
Lejoe says:
August 17, 2009 at 6:06 pm
Excellent Article Petr. I guess we can call it manipulation of OSPF prefixes to suppress
generation of certain types of LSAs.
Reply
3.
Marcos Umino says:
August 17, 2009 at 7:33 pm
Wow, incredible explanation on OSPF. If anyone ever asks me for an OSPF article, I
know now where to point.
Reply
4.
Stan I says:
August 17, 2009 at 7:44 pm
Anthony, thanks for the very insightful document and the form it has been presented in.
I enjoyed reading it twice and I don’t particularly like re-reading stuffOcall meOenergy
efficient (or part of the “green initiative:).
5.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
10 of 25 12/22/2011 11:26 AM
Page 11
Cheers!
Stan
Reply
Anthony Sequeira, #15626 says:
August 17, 2009 at 8:17 pm
Hi Stan!!!
Thanks so much for following our blog! This was Petr’s brilliant work. He is
amazing for sure.
Reply
saj says:
August 17, 2009 at 8:19 pm
Thank you Petr,Very useful post
Reply
6.
Stan I says:
August 17, 2009 at 9:08 pm
Oops, I apologize to Petr, I guess I was so much in a hurry to read the article that I just
assumed it was part of the OSPF series. Thank you for pointing it out Anthony!
Stan
Reply
7.
Arwin Erasga says:
August 17, 2009 at 9:46 pm
Thanks Petr!
Reply
8.
sarge says:
August 18, 2009 at 12:01 am
Great post. Thanks to Petr. It would be nice if anyone corrected the typos. They are
obvious but sometimes look bad.
Reply
Anthony Sequeira, #15626 says:
August 18, 2009 at 9:00 am
Fixing those now – thanks!
9.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
11 of 25 12/22/2011 11:26 AM
Page 12
Reply
Mohamed Zaki says:
August 18, 2009 at 1:27 am
Amazing article, thanks Petr, you are awesome.
Reply
10.
Amit Chopra says:
August 18, 2009 at 3:38 am
More reason to have COD of this bootcamp after reading this OSPF explanation
Reply
11.
John Spaulding says:
August 18, 2009 at 6:28 am
Awesome work!!! I always feel stupid after reading his blogs
Reply
12.
Chirag says:
August 18, 2009 at 8:15 am
Mr Petr Lapukhov
can I ask my are you so clever
Reply
13.
Chirag says:
August 18, 2009 at 8:15 am
There is only one Petr :0)
Reply
14.
Wouter Prins says:
August 18, 2009 at 11:16 am
hi Petr,
You are the man of the bits at INE, shouldnt you mention something about the P-bit in
the article?
Reply
Petr Lapukhov, CCIE #16379 says:
August 18, 2009 at 11:28 am
Hmm i think I did, but apparently I missed that Here is the thing related to
filtering – like i mentioned, type-7 LSAs with P-bit set MUST have a non-zero FA
15.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
12 of 25 12/22/2011 11:26 AM
Page 13
value. This is needed to ensure optimal routing as there is only one translator in
potentially multi-exit area. This allows for filtering based on “hiding” the FA
address.
Reply
andy jordan says:
August 18, 2009 at 12:47 pm
so in order to get to an external ( nssa) destination , does a remote router in some other
area use the metric to the FA or the metric to the network itself ?
Reply
Petr Lapukhov, CCIE #16379 says:
August 18, 2009 at 3:13 pm
To: Andy Jordan
If the FA field is non-zero, it is used to calculate the routing metric and the route
itself. If the FA is zero, the path cost to reach the respective ABR/ASBR is used
instead.
Reply
16.
Narbik Kocharians says:
August 18, 2009 at 2:05 pm
Based on what i hear from my students, Why do you have LSA type 3 Filtering all over
your work books?
Reply
Petr Lapukhov, CCIE #16379 says:
August 18, 2009 at 4:20 pm
To: Narbik
Appreciate your interest in our products. The reason is mainly that Cisco uses this
term in their documentation. Although the term is not entirely correct as I tried to
show in this post, it became commonly used around. A more correct way of saying
would be “Inter-Area Route Filtering”.
Reply
17.
Narbik Kocharians says:
August 18, 2009 at 5:21 pm
HAHAHAHAHA
So its NOT a misunderstanding like you mentioned? Is it? You need to stop and think
before you write.
Reply
18.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
13 of 25 12/22/2011 11:26 AM
Page 14
Petr Lapukhov, CCIE #16379 says:
August 18, 2009 at 5:49 pm
To: Narbik
Posting non-sense and pointless comments really does not make you look any
smarter. Please, try being more constructive and consider using your own advice
next time.
Reply
Chris Gray says:
August 19, 2009 at 5:30 am
The article actually starts by saying
To begin with, I would have to ask everyone – please, avoid using the term “LSA
filtering” with OSPF You cannot really filter LSAs – with the exception of one special
case
Reply
Petr Lapukhov, CCIE #16379 says:
August 19, 2009 at 7:58 am
To: Chris
Yeah, this message goes to Cisco as well Their terminology is confusing, as
filtering means blocking something transit to the device and make you think type-3
LSAs are flooded through the ABR. I wish they use more consistent wording, as
this is misleading. We were using the same terminology in the past to follow
Cisco’s documentation, but that does not mean LSAs could be filtered in general.
Even if Cisco says that. Even if John Chambers calls you at night and yells that.
LSAs are flooded and every type has its own flooding domain. Network
Reachability information is filtered The whole point of my post was showing the
difference between LSA (topological) and NLRI (reachability) concepts.
Reply
19.
Chirag says:
August 19, 2009 at 5:36 am
Narbik
Why you spoiling things .. if you want to make silly comments please do not here
Regards
Chirag
Reply
20.
Chris Gray says:21.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
14 of 25 12/22/2011 11:26 AM
Page 15
August 19, 2009 at 9:58 am
I wish John Chambers would stop doing that, he’s just confusing me man.
Reply
Darby Weaver says:
August 22, 2009 at 12:07 pm
When is Petr going to be teaching classes?
His articles are excellent and amazingly clear, love to hear everything he has to offer
over a 1 or even 2 week class.
Reply
22.
Ted says:
August 22, 2009 at 11:49 pm
Outstanding work, that’s a good read.
Reply
23.
Olu says:
August 23, 2009 at 6:18 am
Excellent and very clear post Petr
Thanks for this.
- Olu
Reply
24.
Daniel Spatig says:
August 23, 2009 at 12:51 pm
I wanted to add this, because as I get a little mixed up with this also. The statement
“The OSPF metric for the summarized route is taken as the minimal among all
intra-area routes” is only valid for RFC 1583 they changed the metric calculation in
RFC2328 page 136 to be the cost equal to the largest of any of the component
networks. to have the metric calculate based on RF2328 you need to have “no
compatible rfc1583″ because for some reason cisco defaults to rfc1583, or it does for
me in ver 12.4
Reply
25.
Jorge says:
September 7, 2009 at 3:49 pm
Great post Petr. Thank you for being so thorough about clarifying LSA vs route filtering.
Super helpful!
26.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
15 of 25 12/22/2011 11:26 AM
Page 16
Reply
Ananth Kumar says:
September 9, 2009 at 2:59 am
Much much appreciated Petr, for helping us to fill the gapsO I have used these
methods and thought that I understood the filtering, but some point I was not clear
about the difference between them.
Once again thanks a lotO
at last is that a typo , acl name “rip”?
Method 1:
router ospf 1
distribute-list 10 out rip
!
access-list 1 deny 1.1.1.0
access-list 1 permit any
Reply
Petr Lapukhov, CCIE #16379 says:
September 9, 2009 at 7:34 am
To: Ananth,
no, the ACL# is 10, and “rip” here is the “source” protocol, the protocol that is
being redistributed into OSPF
Reply
27.
A question says:
September 13, 2009 at 3:12 am
Hi,
I didnt understand the ospf type 3 lsa section..
Can you please tell me the follwoing things-
1- How does the ABR sends the intra area routes (area 0 routes) to non backbone
areas
2- How does the ABR sends the inter area routes (area X routes) to non backnone
areas (area Y)
3- If i have 2 ABR’s (ABR1 and ABR2)connecting area 0 and area X..
a)Is there a possibility that routes learned from area X on ABR1 will be sent back to
ABR2 into area X
b)Is there a possibility that routes learned from area 0 on ABR1 will be sent back to
28.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
16 of 25 12/22/2011 11:26 AM
Page 17
ABR2 into area 0.
Thanx a tonn in advanceO
Reply
Petr Lapukhov, CCIE #16379 says:
September 13, 2009 at 6:28 pm
> 1- How does the ABR sends the intra area routes (area 0 routes) to non
backbone areas
Walks over the routing table looking for area 0 routes, generates type 3 LSAs,
performs summarization prior to this if needed according to area-range table.
> 2- How does the ABR sends the inter area routes (area X routes) to non
backnone areas (area Y)
It walks over the area X routes and generates type-3 LSAs. However, no
summarization is performed. Other routers by default ignore type-3 LSAs for
non-area 0 to prevent routing loops. However, it is possible to consider them if the
area is transit (I’ll make a separate blog post on that).
> 3- If i have 2 ABR’s (ABR1 and ABR2)connecting area 0 and area X..
> a)Is there a possibility that routes learned from area X on ABR1 will be sent back
to ABR2 into area X
No, as ABRs do not consider non-area 0 inter-area routes when calculating
best-paths.
> b)Is there a possibility that routes learned from area 0 on ABR1 will be sent back
to ABR2 into area 0.
No due to the same reason: only inter-area routes from Area 0 are considered in
best-path computations with the special exception to transit area. I’m going to blog
about it soon, as this topic seems to be confusing to many.
Thanx a tonn in advanceO
Reply
A question says:
September 13, 2009 at 10:11 pm
Thanx for your answerO still a little confused on the below.
> 1- How does the ABR sends the intra area routes (area 0 routes) to non backbone
areas
Walks over the routing table looking for area 0 routes, generates type 3 LSAs, performs
summarization prior to this if needed according to area-range table.
Q- So it summarizes only if the area range is configured or by default.
29.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
17 of 25 12/22/2011 11:26 AM
Page 18
> 2- How does the ABR sends the inter area routes (area X routes) to non backnone
areas (area Y)
It walks over the area X routes and generates type-3 LSAs. However, no
summarization is performed.
Are these LSA’s summaries or specific?
Question 3 and 4 – If i change the words route to LSAO what would happen thenO
would the LSA’s be fed back in case of 2 ABR’s, If yes how would the recieving router
react to it and if no, why so?
Reply
Alexei Monastyrnyi says:
September 30, 2009 at 10:01 pm
Just a quick one, Petr. If we have say a router with Ethernet interface in UP/UP state
advertised into OSPF with network statement but the link it represents is not a transit
network, i.e. there is no other OSPF neighbour on that link (it is just connected to L2
dumb device). Which LSA type that link would be advertised with?
Reply
Petr Lapukhov, CCIE #16379 says:
October 1, 2009 at 1:21 pm
@Alexei
OSPF LSA Type 1 (router LSA);
Router LSA Link type 3 (Stub network);
Router Link ID – Network Number;
Router Link Data – Network Mask
Reply
30.
Alexei Monastyrnyi says:
October 1, 2009 at 2:20 pm
Right, thanks Petr. Kind of lost it in LSDB.
Link connected to: a Stub Network
(Link ID) Network/subnet number: 11.11.11.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 1
Reply
31.
OSPF Prefix Filtering using Forwarding Address - CCIE Blog says:
November 24, 2009 at 7:53 am
[...] at the ABR(s) of the area containing the ASBR. You may use any of the methods
described in the post OSPF Route Filtering Demystified to prevent type-3 LSA
32.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
18 of 25 12/22/2011 11:26 AM
Page 19
generation, e.g. use the inter-area route [...]
Reply
Net_OG says:
November 24, 2009 at 8:29 pm
Wow Petr,
this is a classic post. I love that you have a little reading list at the bottom.
Great job putting so much in one post. Part of the problem is: we see these situations in
various contexts at different times in labs or even in Cisco Documents and it is hard to
tie them all together into a coherent procedure.
I really appreciate your posts.
Reply
33.
Net_OG says:
November 25, 2009 at 9:34 am
Petr,
“The type-7 LSAs reaching ABRs are used to populate the local routing table and
re-generate the new type-5 LSAs, originated now by the ABR. This is important – since
the ABR becomes an ASBR and re-originates the routes, you may use the command
summary-address ADDR MASK no-advertise to block the type-5 LSA generation.”
The above quote is pretty significant because when reading the documentation it states
that you do this summarizing on the ASBR, but if you didn’t think of the ABR as an
ASBR you might get confused as to why you are applying the “summary-address
ADDR MASK no-advertise” command on the ABR.
Here is the link tot he cisco config guide entry: http://www.cisco.com/en/US/partner
/docs/ios/iproute/configuration/guide
/irp_ospf_cfg_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1054417
Reply
34.
James Huang says:
January 8, 2010 at 11:19 pm
Hi Petr,
Thanks for such a clear post. It really demystifies some of the blur area in OSPF.
You mentioned that for type-3 LSA origination by intra-area routes, “area filter-list prefix
out” is applied after all summarizaion is done. I tested this and found what you said
does not seem to be correct. Here is the quote from Cisco’s document titled “OSPF
ABR Type 3 LSA Filtering”: For “area filter-list out” command, if an area-range
command has been configured for the area, type 3 LSAs that correspond to the area
range are sent to all other areas only if at least one prefix in the area range matches an
35.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
19 of 25 12/22/2011 11:26 AM
Page 20
entry in the prefix list.”
Can you verify again?
Thanks,
James Huang
Reply
Petr Lapukhov, CCIE #16379 says:
January 9, 2010 at 9:20 am
@James
I don’t see a contradiction here: the documentation says that type 3 LSA is
generated is there is at least one entry in the prefix-list matching one of the area
ranges (this behavior is valid for outgoing LSA advertisements). Thus, the routing
process performs route summarization, and then the prefix-list filters the
summarized prefixes.
Reply
James Huang says:
January 9, 2010 at 12:30 pm
HiPetr,
Here are the tests I did to reach the conclusion that “area filter-list out” is executed
BEFORE “area range” for intra-area routes.
Topology:
area 0: R1’s loopback 0, IP 1.1.1.1/32
R1’ f1/0, ip 12.0.0.1/24
R2’s f1/0, ip 12.0.0.2/24
area 1: R2’s f1/1, ip 23.0.0.2/24
R3’s f1/0, ip 23.0.0.3/24
area 2: R1’s loopback 1, ip 11.11.11.11/32
Test 1:
At R2, add “area-range” and “area filter-list out”:
Router#sh running-config | sec ospf
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
area 0 range 1.1.0.0 255.255.0.0
area 0 filter-list prefix area0out out
network 12.0.0.0 0.0.0.255 area 0
network 23.0.0.0 0.0.0.255 area 1
Router#
Router#sh ip prefix-list area0out
36.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
20 of 25 12/22/2011 11:26 AM
Page 21
ip prefix-list area0out: 3 entries
seq 5 deny 1.1.1.1/32
seq 10 deny 11.11.11.11/32
seq 15 permit 0.0.0.0/0 le 32
Verify at R3:
Router#sh ip route
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route, + – replicated route
Gateway of last resort is not set
12.0.0.0/24 is subnetted, 1 subnets
O IA 12.0.0.0 [110/2] via 23.0.0.2, 00:06:33, FastEthernet1/0
23.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 23.0.0.0/24 is directly connected, FastEthernet1/0
L 23.0.0.3/32 is directly connected, FastEthernet1/0
At R2, the 1.1.1.1/32 intra-area route was filtered out first and “area range” did not find
anything in the range to summarize. So R3 did not learn 1.1.1.1/32 or 1.1.0.0/16 route.
Test 2:
At R2, modify area0out prefix-list as follows:
Router#sh ip prefix-list area0out
ip prefix-list area0out: 3 entries
seq 5 deny 1.1.0.0/16
seq 10 deny 11.11.11.11/32
seq 15 permit 0.0.0.0/0 le 32
The OSPF configuration is the same as test 1.
Verify at R3,
Router#sh ip route
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route, + – replicated route
Gateway of last resort is not set
1.0.0.0/16 is subnetted, 1 subnets
O IA 1.1.0.0 [110/3] via 23.0.0.2, 00:00:32, FastEthernet1/0
12.0.0.0/24 is subnetted, 1 subnets
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
21 of 25 12/22/2011 11:26 AM
Page 22
O IA 12.0.0.0 [110/2] via 23.0.0.2, 00:19:31, FastEthernet1/0
23.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 23.0.0.0/24 is directly connected, FastEthernet1/0
L 23.0.0.3/32 is directly connected, FastEthernet1/0
In this test, R2 will filter out 1.1.0.0/16 intra-area route. If R2 were to perform “area
range’ first and then “area filter-list out”, R2 would not have advertised 1.1.0.0/16 type-3
LSA to R3. But R3’s route table shows that R2 did advertise 1.1.0.0/16 to R3. A dump
of the OSPF database at R3 confirms that again:
At R3:
Router#sh ip ospf database summary 1.1.0.0
OSPF Router with ID (3.3.3.3) (Process ID 1)
Summary Net Link States (Area 1)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 333
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 1.1.0.0 (summary Network Number)
Advertising Router: 2.2.2.2
LS Seq Number: 80000001
Checksum: 0x48E8
Length: 28
Network Mask: /16
MTID: 0 Metric: 2
– James Huang
Reply
Al says:
September 12, 2010 at 9:46 pm
Question:
If based on area address range, two routes are summarized in one summary LSA and
at some point, the topology changes and one of the mentioned routes is removed,
would the summary LSA be flushed? or will it not change given it still covers one
reachable route?
Thanks in advance,
Al.
Reply
37.
OSPF Filtering « Toward The Triumph says:
June 7, 2011 at 3:07 am
[...] OSPF Route Filtering Demystified [...]
Reply
38.
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
22 of 25 12/22/2011 11:26 AM
Page 23
David Chosrova says:
August 24, 2011 at 3:18 am
Thanks for this very good post
Reply
39.
Denis Mikhailov says:
September 7, 2011 at 10:19 am
Hi Petr,
Hope you are doing well ! Thanks for the good article! I met this today since I’m on the
R&S bootcamp now. The qustion arised is it possible to filter intra-area OSPF route by
any other method then distribute list ? There are tons of examples in the Internet but all
of them describe the same construction: “distribute-list in” in the OSPF process. As we
know it is not a “cultural” method to do it. Is where any other method ?
Thank you !
Best Regards,
Denis Mikhailov.
Reply
40.
Leave a Reply
Name (required)
Mail (will not be published) (required)
Search
Categories
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
23 of 25 12/22/2011 11:26 AM
Page 24
CCIE Bloggers
Brian Dennis CCIE #2210
Routing & Switching
ISP Dial
Security
Service Provider
Voice
Brian McGahan CCIE #8593
Routing & Switching
Security
Service Provider
Petr Lapukhov CCIE #16379
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
24 of 25 12/22/2011 11:26 AM
Page 25
Routing & Switching
Security
Service Provider
Voice
Mark Snow CCIE #14073
Voice
Security
Popular Posts
Update on CCIE Success Story Polo Shirts
CCNA Voice and CCNP Voice Bootcamps Now Online
Updated CCIE R&S Written Exam Bootcamp Videos Now Available
twitter.com/inetraining
Follow
© 2011 INE, Inc., All Rights Reserved
OSPF Route Filtering Demystified http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
25 of 25 12/22/2011 11:26 AM