Filtering Out Routes

GRANT3779 · ‎09-13-2013

Hi,

Example below..

O E2 10.44.240.0/20 [110/0] via 172.27.4.50,

O 10.44.240.0/24 [110/4] via 172.27.4.50,

I want to filter out the 10.44.240.0 /24 - but keep the /20.

I have my access-list denying the routes, then my distribute list under OSPF but it always denies all the 10.44.240.0 networks. Am I unable to achieve this?

John Blakley · ‎09-13-2013

Hi again

Create an acl that matches on your mask as well and then apply that:

access-list 10 deny 10.44.240.0 0.0.0.255

access-list 10 permit any

router ospf

distribute-list 10 in

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

GRANT3779 · ‎09-13-2013

Hey John!

Yeah I did try that initially, but then both routes dissapeared. I just tried again to check, and when I use

access-list xx deny 10.44.240.0 0.0.0.255

access-list xx permit any

both the

10.44.240.0/20
10.44.240.0/24

dissapear :-(

I'm using ip access-list rather that access-list just so it's easier for me to edit, but I'm sure this won't be the problem?

Rolf Fischer · ‎09-13-2013

Hi,

to avoid undesired filtering by the limitations of ACLs, you should use a prefix-list:

ip prefix-list TEST deny 10.44.240.0/24

ip prefix-list TEST permit 0.0.0.0/0 le 32

Useful Link: Understanding IP Prefix-Lists

Hope that helps

Rolf

John Blakley · ‎09-13-2013

Yeah, you're going to need to use a prefix list. I labbed this up and it simply doesn't work, but a prefix-list will.

ip prefix-list AllowedRoute deny 10.44.240.0/24

ip prefix-list AllowedRoute permit 0.0.0.0/0 le 32

router ospf 1

distribute-list prefix AllowedRoute in

This does work...

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

GRANT3779 · ‎09-14-2013

Hi Again!

I've been reading up on the forums here regarding some other routing info and came across this from Scott Morris..

"

Another thing to note in OSPF... Everyone in an area must have the same database. So you CANNOT do "distribute-list out" like you can in other protocols to permit/deny certain routes from particular interfaces. Otherwise you break the rules of the RFC and threaten to end the universe as we know it."

So..am I causing issues by filtering routes from appearing in one routers RIB? Does this make the databases different, causing the end of the universe...? :-)

Rolf Fischer · ‎09-14-2013

Hi,

 So you CANNOT do "distribute-list out" like you can in other protocols (...)

This is key to link-state RPs, I didn't mention it because I thougt you already knew.

The LSDBs have to be the same within an Area to avoid routing loops and blackholing, so the only thing you can manipulate is what LSDB information will appear in the local routing table. This is the purpose of the distribute-list in command in OSPF.

One scenario for doing this is a OSPF-to-OSPF redistribution (2 different OSPF processes).

At area- or AS-borders things are different. A couple of weeks ago I posted some general information about OSPF hierarchy and manipulation (filtering, summarization) here, perhaps it's helpful:

https://supportforums.cisco.com/message/4025616#4025616

Feel free to ask further!

Hope that helps

Rolf

Rolf Fischer · ‎09-14-2013

So..am I causing issues by filtering routes from appearing in one routers RIB? Does this make the databases different ...?

No, it doesn't. Filtering out prefixes from the local forwarding table doesn't affect the LSDB.

R1#show ip prefix-list

ip prefix-list TEST: 2 entries

seq 5 deny 10.44.240.0/24

seq 10 permit 0.0.0.0/0 le 32

R1#show run | sect ^router

router ospf 1

router-id 1.1.1.1

network 10.44.240.0 0.0.0.255 area 0

distribute-list prefix TEST out (*)

distribute-list prefix TEST in

R1#show ip ospf database router | i Advert|\(Link

Advertising Router: 1.1.1.1

(Link ID) Network/subnet number: 10.44.240.0

(Link Data) Network Mask: 255.255.255.0

But depending on the next-best route which is used to forward traffic to reach the locally filtered network prefix (e.g. the default route), you could end up in a routing loop.

In the example you've posted, both routes have the same next-hop, so in this case you're safe.

Regards

Rolf

[EDIT]:

(*): I expected to receive some kind of error message when applying the distribute-list out but there wasn't. So IOS let you apply it but it doesn't affect the LSDB at all.

Richard Burts · ‎09-15-2013

Perhaps it will clarify the issue a bit if we understand that a distribute list or a prefix list will filter routes but can not filter Link State Advertisements. So a distribute list or a prefix list applied inbound can prevent routes from entering the RIB from OSPF but can not prevent the advertisement to other neighbors.

Also note that if you do use distribute list or prefix list inbound that it affects the local routing table. But it does not prevent advertising those filtered routes to other neighbors.

HTH

Rick

HTH

Rick

Jose Jara · ‎09-16-2013

A distribute-list out only works, as far as I know, in OSPF in one situation and this is to filter out external prefixes at the ASBR that is injecting this external information.

A distribute-list in, as others said in this post, behavior works filtering the routes from the RIB but it will maintain the LSA's in the LSDB and therefore it will still send them to other routers in the area. However, there are two exceptions and these are for LSA type 3 in the ABR, it will filter prefixes in the RIB and LSA's in the LSDB. The same for type 7 LSA at the ABR/ASBR which is doing the translation between type 7 and type 5 LSA's.

The only way to filter prefixes and LSA's inside one area it would be to use a flooding filter ( ip ospf database-filter all out). However, this apply to ALL the LSA's from the Database. Another way would be to Max-Age all of them, but again it will apply to all the LSA's.

Best Regards,

Jose.

Rolf Fischer · ‎09-16-2013

Hi Jose,

A distribute-list out only works, as far as I know, in OSPF in one situation and this is to filter out external prefixes at the ASBR that is injecting this external information.

you're right - I totally forgot about that...

You can use it at ASBRs as an alternative to a route-map in the distribute-command.

However, there are two exceptions and these are for LSA type 3 in the ABR, it will filter prefixes in the RIB and LSA's in the LSDB.

Not sure if I understand that correctly: You mean in the way the area filter-list command works? Never heard that before, are you sure about that?

Best Regards

Rolf

Jose Jara · ‎09-16-2013

Hi Fischer,

yes, the way OSPF works in IOS for the IA is that before sending the type 3 LSA's to another Area it checks the RIB. If the prefix does not exist in the RIB it will not send the LSA to the other Area. A distribute-list in or distance 255 or just a route with a better AD could be used to test this behavior. It works the same as the redistribution process.

An example: R1- Area 1- R2 - Area 0 - R3 - Area 2 - R4

R1 is sending 1/32 and R3 RIB sees the prefix as IA:

O IA 1.1.1.1 [110/3] via 10.1.23.2, 00:02:52, FastEthernet1/0

Router3(config)#access-list 1 deny host 1.1.1.1

Router3(config)#access-list 1 permit any

Router3#debug ip ospf flood

OSPF flooding debugging is on

Router3(config)#router ospf 1

Router3(config-router)#distribute-list 1 in

*Sep 16 15:15:40.775: OSPF: Add Type 3 LSA ID 1.1.1.1 Adv rtr 10.1.34.3 Seq 80000002 to FastEthernet1/1 10.1.34.4 retransmission list

*Sep 16 15:15:40.779: OSPF: Add Type 3 LSA ID 1.1.1.1 Adv rtr 10.1.34.3 Seq 80000002 to FastEthernet1/1 flood list

*Sep 16 15:15:40.779: OSPF: Sending update over FastEthernet1/1 without pacing

*Sep 16 15:15:40.779: OSPF: Flooding update on FastEthernet1/1 to 224.0.0.5 Area 2

*Sep 16 15:15:40.783: OSPF: Send Type 3, LSID 1.1.1.1, Adv rtr 10.1.34.3, age 3600, seq 0x80000002 (0)

*Sep 16 15:15:40.783: OSPF: Remove Type 3 LSA ID 1.1.1.1 Adv rtr 10.1.34.3 Seq 80000002 from FastEthernet1/1 flood list

Router3(config-router)#no distribute-list 1 in

Router3(config-router)#

*Sep 16 15:28:58.815: OSPF: Add Type 3 LSA ID 1.1.1.1 Adv rtr 10.1.34.3 Seq 80000001 to FastEthernet1/1 10.1.34.4 retransmission list

*Sep 16 15:28:58.815: OSPF: Add Type 3 LSA ID 1.1.1.1 Adv rtr 10.1.34.3 Seq 80000001 to FastEthernet1/1 flood list

*Sep 16 15:28:58.815: OSPF: Sending update over FastEthernet1/1 without pacing

*Sep 16 15:28:58.819: OSPF: Flooding update on FastEthernet1/1 to 224.0.0.5 Area 2

*Sep 16 15:28:58.819: OSPF: Send Type 3, LSID 1.1.1.1, Adv rtr 10.1.34.3, age 1, seq 0x80000001 (0)

Another test with a static route:

Router3(config)#ip route 1.1.1.1 255.255.255.255 null 0

*Sep 16 15:30:18.599: OSPF: Add Type 3 LSA ID 1.1.1.1 Adv rtr 10.1.34.3 Seq 80000002 to FastEthernet1/1 10.1.34.4 retransmission list

*Sep 16 15:30:18.603: OSPF: Add Type 3 LSA ID 1.1.1.1 Adv rtr 10.1.34.3 Seq 80000002 to FastEthernet1/1 flood list

*Sep 16 15:30:18.603: OSPF: Sending update over FastEthernet1/1 without pacing

*Sep 16 15:30:18.603: OSPF: Flooding update on FastEthernet1/1 to 224.0.0.5 Area 2

*Sep 16 15:30:18.603: OSPF: Send Type 3, LSID 1.1.1.1, Adv rtr 10.1.34.3, age 3600, seq 0x80000002 (0)

*Sep 16 15:30:18.607: OSPF: Remove Type 3 LSA ID 1.1.1.1 Adv rtr 10.1.34.3 Seq 80000002 from FastEthernet1/1 flood list

Router3(config)#

*Sep 16 15:30:18.607: OSPF: Stop FastEthernet1/1 flood timer

Router3(config)#

*Sep 16 15:30:21.159: OSPF: Received ACK from 10.1.34.4 on FastEthernet1/1

You can see that after filtering the prefix from the RIB or configuring a route with a better AD the router Max-Age the LSA to the Area attached to the Backbone.

Best Regards,

Jose.

Rolf Fischer · ‎09-16-2013

Hi Jose,

so it has to be Type-3 already - it doesn't work that way on the ABR which originates the the Type-3 in the first place (which is a difference to the area filter-list command).

I didn't know that, thank you very much !!

Best regards

Rolf