Ospf Route Filtering Demystified

7/18/2019 Ospf Route Filtering Demystified

http://slidepdf.com/reader/full/ospf-route-filtering-demystified-56d41042bc79d 1/1

pdfcrowd.com

Aug

17 53 Comments

OSPF Route Filtering DemystifiedPosted by Petr Lapukhov, 4xCCIE/CCDE in IGP

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 w ith a focus on c omputer programming, and progres sed into netw orking

w ith his f irst exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network

support and UNIX sys tem administration, he w ent through the path of bec oming a netw orking consultant, taking part in

many netw ork deployment projects. Petr currently has over 12 years of experience working in the Cisco networ king

field, and is the only person in the wor ld to have obtained four CCIEs in under tw o years, passing each on his firs t

attempt. Petr is an exceptional case in that he has been w orking w ith all of the technologies cov ered in his four CCIE

tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching 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

Yandy Ramirez

August 17, 2 009 at 4:02 p m

Rizzo

August 17, 2 009 at 5:36 p m

Lejoe

August 17, 2 009 at 6:06 p m

Marcos Umino

August 17, 2 009 at 7:33 p m

Stan I

August 17, 2 009 at 7:44 p m

Anthony Sequeira, #15626

August 17, 2 009 at 8:17 p m

saj

August 17, 2 009 at 8:19 p m

Stan I

August 17, 2 009 at 9:08 p m

Arwin Erasga

August 17, 2 009 at 9:46 p m

sarge

August 18, 2 009 at 12:01 am

Anthony Sequeira, #15626

August 18, 2 009 at 9:00 a m

Mohamed Zaki

August 18, 2 009 at 1:27 a m

Amit Chopra August 18, 2 009 at 3:38 a m

John Spaulding

August 18, 2 009 at 6:28 a m

Chirag

August 18, 2 009 at 8:15 a m

Chirag

August 18, 2 009 at 8:15 a m

Wouter Prins

August 18, 2 009 at 11:16 am

Petr Lapukhov, CCIE #16379

August 18, 2 009 at 11:28 am

andy jordan

August 18, 2 009 at 12:47 pm


August 18, 2 009 at 3:13 p m

Narbik Kocharians

August 18, 2 009 at 2:05 p m


August 18, 2 009 at 4:20 p m

Narbik Kocharians

August 18, 2 009 at 5:21 p m


August 18, 2 009 at 5:49 p m

Chris Gray August 19, 2 009 at 5:30 a m


August 19, 2 009 at 7:58 a m

Chirag

August 19, 2 009 at 5:36 a m

Chris Gray

August 19, 2 009 at 9:58 a m

Darby Weaver

August 22, 2 009 at 12:07 pm

Ted

August 22, 2 009 at 11:49 pm

Olu

August 23, 2 009 at 6:18 a m

Daniel Spatig

August 23, 2 009 at 12:51 pm

Jorge

September 7, 2009 at 3:49 pm

Ananth Ku mar

September 9, 2009 at 2:59 am



A question




A question


Alexei Monastyrnyi



October 1, 2009 at 1:21 pm

Alexei Monastyrnyi

October 1, 2009 at 2:20 pm

OSPF Prefix Filtering using Forwarding Address - CCIE Blog

November 24, 2009 at 7:53 am

Net_OG

November 24, 2009 at 8:29 pm

Net_OG

November 25, 2009 at 9:34 am

James Huang

January 8, 2010 at 11:19 pm


January 9, 2010 at 9:20 am

James Huang

January 9, 2010 at 12:30 pm

Al


OSPF Filtering « Toward The Tr iumph

June 7, 2011 at 3:07 am

David Chosrova

August 24, 2 011 at 3:18 a m

Denis Mikhailov


Fulvio Allegretti

May 18, 2013 at 11:58 am

Roman Shilenko

August 21, 2 013 at 2:54 p m

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 wrongfullyunderstanding 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 is used to populate the routing table – i.e. the RIB.

3) Main routing table. This is the router’s RIB. 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 f inally 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 filter ing” 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 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 dif ferent 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 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 preventionmechanism 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 pre fix {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 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 r outer 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

r outer 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 thatonly 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

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: /24

Metric Type: 2 (Larger than any link state path)

TOS: 0

Metric: 20

Forward Address: 150.1.7.7

External Route Tag: 0

Routing Bit Set on this LSA

LS age: 11






Checksum: 0xBDD3

Length: 36

Network Mask: /24


TOS: 0

Metric: 20



Rack1R2#show ip ospf database external


Type-5 AS External Link States

...

LS age: 26

Options: (No TOS-capability, DC)





Checksum: 0x2193

Length: 36

Network Mask: /24


TOS: 0

Metric: 20



LS age: 26

Options: (No TOS-capability, DC)





Checksum: 0xFFB1

Length: 36

Network Mask: /24


TOS: 0

Metric: 20



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:



!

router ospf 1

distribute-list 1 in

And apply our ver ification once again:

Rack1R2#show ip ospf database nssa-external


Type-7 AS External Link States (Area 27)

LS age: 222






Checksum: 0xDEB5

Length: 36

Network Mask: /24


TOS: 0

Metric: 20



LS age: 222






Checksum: 0xBDD3

Length: 36

Network Mask: /24


TOS: 0

Metric: 20



Rack1R2#show ip ospf database external


Type-5 AS External Link States

And we can see that Type-7 to Type-5 tr anslation 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 origina ted at R4 using say area X range no-

advertise or area X filer-list pre fix {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 installed (it sees the FA!), but all other routers in the domain withthe 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

You can leave a response, or trackback from your own site.

53 Responses to “OSPF Route Filtering Demystified”

very cool post! thanks for the info

Reply

Really Nice one

Thanks

Reply

Excellent Article Petr. I guess we can call it manipulation of OSPF prefixes to suppres s gen eration of certain types of LSAs.

Reply

Wow, incredible explanation on OSPF. If anyone ever asks me for an OSPF article, I know now where to point.

Reply

Anthony, thanks fo r the very insi ghtful document and the form it has been presen ted in. I enjoyed readi ng it twice and I don’ t

particularly like re-reading stuff…call me…energy efficient (or part of the “green initiative:).

Cheers!

Stan

Reply

Hi Stan!!!

Thanks so much for following our blog! This was Petr’s brilliant work. He is amazing for sure.

Reply

Thank you Petr,Very useful post

Reply

Oops, I apologize to Petr, I guess I was s o 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

Thanks Petr!

Reply

Great post. Thanks to Petr. It would be nice if anyone corrected the typos. They are obvious but s ometimes look bad.

Reply

Fixing those now – thanks!

Reply

Amazing article, thanks Pe tr, you are awesom e.

Reply

More reaso n to have COD of this bootcamp after reading this OSPF explanation

Reply

Awesome w ork!!! I always feel stupi d after reading his b logs

Reply

Mr Petr Lapukhov

can I ask m y are you so clever

Reply

There is only one Petr :0)

Reply

hi Petr,

You are the man of the bits at INE, shouldnt you mention something abo ut the P-bit in the article?

Reply

Hmm i think I did, but apparently I miss ed that Here is the thing related to filtering – like i mentioned, type-7 LSAs with P-

bit set MUST have a non-zero FA value. This is needed to ens ure optimal routing as there is only one translator in potentially

multi-exit area. This allows for filtering based on “hiding” the FA address.

Reply

so in order to get to an external ( nssa) des tination , does a remote router in som e other area use the me tric to the FA or the metric to

the network itself ?

Reply

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 reachthe respective ABR/ASBR is used instead.

Reply

Based on what i hear from my students, Why do you have LSA type 3 Filtering all over your work books?

Reply

To: Narbik

Appreciate your interes t in our products. The reas on is m ainly that Cisco uses this term in their documentatio n. Although the

term is not e ntirely correct as I tried to show in this pos t, it became commonly used around. A more correct way of saying

would be “Inter-Area Route Filtering”.

Reply

HAHAHAHAHA

So its NOT a mis understanding like you mentioned? Is it? You need to stop and think before you write.

Reply

To: Narbik

Posting non-sense and pointless comments really does not ma ke you look any smarter. Please, try being more cons tructive

and consider using your own advice next time.

Reply

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 s pecial case

Reply

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 mis leading. We were using the sam e 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

Narbik

Why you spoiling things .. if you want to make silly comments please do not here

Regards

Chirag

Reply

I wish John Chambers would s top doing that, he’s just confusing me m an.

Reply

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

Outstanding work, that’s a good read.

Reply

Excellent and very clear post Petr

Thanks for this.

- Olu

Reply

I wanted to add this, becaus e as I get a little mixed up with this als o. The statement “The OSPF metric for the summarized route is

taken as the m inimal amo ng 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 larges t of any of the component networks. to have the metric calculate based on RF2328 you need to

have “no compatible rfc1583″ because for som e reason cisco defaults to rfc1583, or it does for me in ver 12.4

Reply

Great post Petr. Thank you for being s o thorough about clarifying LSA vs route filtering. Super helpful!

Reply

Much much appreciated Petr, for helping us to fill the gaps… 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 lot…

at last is that a typo , acl name “rip”?

Method 1:

router ospf 1

distribute-list 10 out rip

!



Reply

To: Ananth,

no, the ACL# is 10, and “rip” h ere is the “source” protocol, the protocol that is being redis tributed into OSPF

Reply

Hi,

I didnt understand the os pf type 3 ls a 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 pos sibility that routes learned from area X on ABR1 will be sen t back to ABR2 into area X

b)Is there a pos sibility that routes learned from area 0 o n ABR1 will be sent back to ABR2 into area 0.

Thanx a tonn in advance…

Reply

> 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, gene rates type 3 LSAs, performs s ummarization 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 gene rates type-3 LSAs. However, no su mmarization is performed. Other routers by default

ignore type-3 LSAs for non-area 0 to prevent routing loops. However, it is poss ible to consider them if the area is transit (I’ll

make a sep arate blog post on that).

> 3- If i have 2 ABR’s (ABR1 and ABR2)connecting area 0 and area X..

> a)Is there a pos sibility that routes learned from area X on ABR1 will be se nt back to ABR2 into area X

No, as ABRs do not consider non-area 0 inter-area routes when calculating bes t-paths.

> b)Is there a pos sibility that routes learned from area 0 o n 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 advance…

Reply

Thanx for your answer… 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, gen erates type 3 LSAs, performs s ummarization prior to this if needed

according to area-range table.

Q- So it summarizes only if the area range is configured or b y default.

> 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 sum marization is performed.

Are these LSA’s summa ries or s pecific?

Question 3 and 4 – If i change the words route to LSA… what would happen then… 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

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 dum b

device). Which LSA type that link would be advertised with?

Reply

@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

Right, thanks Petr. Kind of lost it in LSDB.

Link connected to: a Stub Network

(Link ID) Network/subnet numbe r: 11.11.11.0

(Link Data) Network Mask: 255.255.255.0

Number of TOS metrics: 0

TOS 0 Metrics: 1

Reply

[...] 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 generation, e.g. use the inter-area route [...]

Reply

Wow Petr,

this is a class ic post. I love that you have a little reading list at the bottom.

Great job putting so m uch in one pos t. Part of the problem is: we se e 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

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 im portant – since the ABR becomes an ASBR and re-originates the routes, you may use the comm and

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 s ummarizing 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” com mand 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

Hi Petr,

Thanks for such a clear post. It really demystifies som e of the blur area in OSPF.

You mentioned that for type-3 LSA origination by intra-area routes, “area filter-list prefix out” is a pplied after all s ummarizaion is done.

I tested this and found what you said does not seem to be correct. Here is the quote from Cisco’s do cument titled “OSPF ABR Type 3

LSA Filtering”: For “area filter-list out” command, if an area-range command h as been configured for the area, type 3 LSAs that

correspond to the area range are s ent to all other areas only if at least one prefix in the area range m atches an entry in the prefix list.”

Can you verify again?

Thanks,

James Huang

Reply

@James

I don’t see a contradiction here: the documentation sa ys that type 3 LSA is g enerated is there is at least one entry in the

prefix-list matching one o f the area ranges (this behavior is valid for outgoing LSA advertisements). Thus, the routing process

performs route s ummarization, and then the prefix-list filters the sum marized prefixes.

Reply

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 fil ter-lis t 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

ip prefix-list area0out: 3 entries

seq 5 deny 1.1.1.1/32

seq 10 deny 11.11.11.11/32

seq 15 perm it 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 routeo – ODR, P – periodic downloaded s tatic 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 mas ks

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 rou te was filtered out first and “a rea range” did not find anything in the range to sum marize. So R3 did

not learn 1.1.1.1/32 or 1.1.0.0/16 route.

Test 2:

At R2, modi fy 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 perm it 0.0.0.0/0 le 32

The OSPF configuration is the sam e 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 s tatic route, + – replicated route

Gateway of last resort is not set

1.0.0.0/16 is s ubnetted, 1 subnets


12.0.0.0/24 is subnetted, 1 subnets


23.0.0.0/8 is variably subnetted, 2 subnets , 2 mas ks

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 databas e summ ary 1.1.0.0


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 (sum mary Network Number)

Advertisi ng Router: 2.2.2.2


Checksum: 0x48E8

Length: 28Network Mask: /16

MTID: 0 Metric: 2

– James Huang

Reply

Question:

If based on area addres s range, two routes are su mmarized in one sum mary LSA and at some point, the topology changes and one

of the mentioned routes is removed, would the summa ry LSA be flushed? o r will it not change given it still covers one reachable

route?

Thanks in ad vance,

Al.

Reply

[...] OSPF Route Filtering Demystified [...]

Reply

Thanks for this very good pos t

Reply

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 itpossible 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

Method 1:

router ospf 1


!



Should that not be


Fulvio

Reply

I know years have pass ed, but since this article is s till actual and useful:

> 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.

No, *any* route doesn’t work. I gathered a topology described in the m entioned article “Common Routing Problem with OSPF

Forwarding Address” and made a static route towards FA:ip route 3.3.4.4 255.255.255.255 1.1.1.2

OSPF process did NOT make a route for 200.1.1.0/24 out of LSA type-5, because “Fail to find route to forwarding addr 3.3.4.4″.

Cisco 3725, 12.3(22).

Reply

Leave a Reply

Name (required)

Mail (will not be published) (required)

Submit Comment

Search

Search

Submit

Categories

Select Category

CCIE Bloggers

Brian Dennis, CCIEx5 #2210

Routing & Sw itching

Voice

Security

Service Provider

ISP Dial

Brian McGahan, CCIEx4 #8593,

CCDE #2013::13

Design

Data Center


Security

Service Provider

Mark Snow, CCIEx4 #14073

Data Center Collaboration

Security

Voice

Petr Lapukhov, CCIEx4 #16379,

CCDE #2010::7

Design


Security

Service Provider

Voice

Popular Posts

CCIE RSv5 Lab Cram Session &

New CCIE RSv5 Mock Labs Now

Available

twitter.com/ine

Blog Home | INE Home | Members | Contact Us | Subscribe

© 2011 INE, Inc., All Rights Reserved

Free Resources View Archives All Access Pass CCIE Bloggers

http://blog.ine.com/

http://www.ine.com/about-us.htm

http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/?replytocom=397997#respond




http://www.internetworkexpert.com/



http://blog.internetworkexpert.com/2009/11/13/ospf-prefix-filtering-using-forwarding-address/

















http://blog.internetworkexpert.com/






http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml

http://www.ine.com/about-us.htm#bd

http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/



http://www.ine.com/

http://members.ine.com/

http://www.ine.com/contact.htm

http://feeds.feedburner.com/ine/

http://twitter.com/ine

http://pdfcrowd.com/


http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/

http://blog.ine.com/?author=5

http://blog.ine.com/category/ccie-routing-switching/interior-gateway-routing/

http://twitter.com/share?url=http%3A%2F%2Fblog.ine.com%2F2009%2F08%2F17%2Fospf-route-filtering-demystified%2F&via=ine&text=OSPF%20Route%20Filtering%20Demystified&related=&lang=en&count=vertical










http://sesano.wordpress.com/




http://blog.internetworkexpert.com/2009/11/13/ospf-prefix-filtering-using-forwarding-address/


http://dialta.wordpress.com/2011/06/07/ospf-filtering/

http://www.cisco.com/

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009405a.shtml

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml

http://www.amazon.com/Cisco-Routing-Forwarding-Intra-domain-Protocols/dp/0201604736

http://blog.ine.com/tag/ccie/

http://blog.ine.com/tag/filtering/

http://blog.ine.com/tag/lsa/

http://blog.ine.com/tag/ospf/

http://pdfcrowd.com/url_to_pdf/?height=-1

http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/trackback/























































http://www.ine.com/about-us.htm#bd

http://www.ine.com/about-us.htm#bm

http://www.ine.com/about-us.htm#ms

http://www.ine.com/about-us.htm#ms

http://blog.ine.com/2015/06/30/ccie-rsv5-lab-cram-session-new-ccie-rsv5-mock-labs-now-available/





http://www.facebook.com/inetraining

http://www.youtube.com/INEtraining


http://www.linkedin.com/companies/144650


http://www.ine.com/

http://members.ine.com/

http://www.ine.com/contact.htm



http://www.ine.com/resources/

http://blog.ine.com/archives

http://www.ine.com/all-access-pass-subscription.htm

http://www.ine.com/about-us.htm

Date post:	29-Feb-2016
Category:	Documents
Upload:	dborsan
View:	9 times
Download:	2 times