OSPF filtering Not working

Answered Question
Nov 2nd, 2013
User Badges:

Hi


I have 2 cisco switches acting as ospf routers.


they have 1 leg in area 0 the back bone and in area 10.172.0.0 (nssa) via 6 connected vlan interfaces.


I also have 2 more ospf routers, that also talk BGP to a 3rd party and redistribute the routes from BGP back into OSPF for area 10.172.0.0


I want to stop any non 10.172.0.0 routes leaving area 10.172.0.0 and making their way into area 0


I have tried to follow this http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080531fd2.shtml#prefixadmin  with the route-map tag, but it didn't work


!! in list into router ospf 2 from ospf 1

no route-map filter_ospf1

route-map filter_ospf1 deny 10

match tag 1

route-map filter_ospf1 permit 20




ip prefix-list FilterOut seq 10 permit 10.172.0.0/16 le 32



!! in list into router ospf 1 from ospf 2

no route-map filter_ospf2

route-map filter_ospf2 deny 10

match tag 2

route-map filter_ospf2 permit 20

match ip  address prefix-list FilterOut

route-map filter_ospf2 deny 30




no router ospf 1

no router ospf 2

router ospf 1

router-id 10.31.19.253

log-adjacency-changes

area 0.0.0.0 authentication message-digest

network 10.31.19.0 0.0.0.255 area 0.0.0.0

redistribute ospf 2 subnet tag 1

distribute-list route-map filter_ospf2 in




router ospf 2

router-id 10.172.255.2

log-adjacency-changes

area 10.172.0.0 authentication message-digest

area 10.172.0.0 range 10.172.0.0 255.255.0.0 advertise

network 10.172.201.0 0.0.0.255 area 10.172.0.0

network 10.172.202.0 0.0.0.255 area 10.172.0.0

network 10.172.203.0 0.0.0.255 area 10.172.0.0

network 10.172.204.0 0.0.0.255 area 10.172.0.0

network 10.172.205.0 0.0.0.255 area 10.172.0.0

network 10.172.207.0 0.0.0.255 area 10.172.0.0

network 10.172.208.0 0.0.0.255 area 10.172.0.0

network 10.172.212.0 0.0.0.255 area 10.172.0.0

network 10.172.213.0 0.0.0.255 area 10.172.0.0

network 10.172.250.0 0.0.0.255 area 10.172.0.0

network 10.172.255.2 0.0.0.0 area 10.172.0.0

redistribute ospf 1 subnet tag 2

distribute-list route-map filter_ospf1 in



I also tried


no router ospf 1

no router ospf 2

no ip prefix-list FilterOut

!!ip prefix-list FilterOut seq 10 permit 10.172.0.0/16 le 32

router ospf 1

router-id 10.172.255.2

log-adjacency-changes

area 0.0.0.0 authentication message-digest

!!area 0.0.0.0 filter-list prefix FilterOut in

area 10.172.0.0 authentication message-digest

area 10.172.0.0 nssa

area 10.172.0.0 filter-list prefix FilterOut out

area 10.172.0.0 range 10.172.0.0 255.255.0.0 advertise

redistribute connected subnets

network 10.31.19.0 0.0.0.255 area 0.0.0.0

network 10.172.201.0 0.0.0.255 area 10.172.0.0

network 10.172.202.0 0.0.0.255 area 10.172.0.0

network 10.172.203.0 0.0.0.255 area 10.172.0.0

network 10.172.204.0 0.0.0.255 area 10.172.0.0

network 10.172.205.0 0.0.0.255 area 10.172.0.0

network 10.172.207.0 0.0.0.255 area 10.172.0.0

network 10.172.208.0 0.0.0.255 area 10.172.0.0

network 10.172.212.0 0.0.0.255 area 10.172.0.0

network 10.172.213.0 0.0.0.255 area 10.172.0.0

network 10.172.250.0 0.0.0.255 area 10.172.0.0

network 10.172.255.2 0.0.0.0 area 10.172.0.0


again didn't work ...  when i check other routers on area 0 they have all the non 10.172.0.0/24 address



thanks

Correct Answer by Rolf Fischer about 3 years 9 months ago

Hi,


but all the directly attached ones are not there.

I have tried redistribute connected in router ospf 2 but that didn't help.


Is OSPF enabled on the IP-interfaces of those connected networks (show ip ospf interface )?

If they belong to OSPF 2 and you want to redistribute them to OSPF 1 too, are they in the range 10.172/16 (route-map 10_172_ONLY)?

Correct Answer by Rolf Fischer about 3 years 9 months ago

Sorry for the delay, I really had to think for a while what I would do to solve that.

Actually, your first attempt wasn't bad at all, and I'd try to do some modifications:


1. Basic config to avoid loops between the 2 processes when redistributing:


route-map filter_ospf1 deny 10

match tag 1

route-map filter_ospf1 permit 20

!

route-map filter_ospf2 deny 10

match tag 2

route-map filter_ospf2 permit 20

!

router ospf 1 ! Area 0

! (redistribute ospf 2 subnet tag 1)

distribute-list route-map filter_ospf2 in

!

router ospf 2 ! Area 10.172.0.0

redistribute ospf 1 subnet tag 2

distribute-list route-map filter_ospf1 in

!


2. So far, so good. Now we'll need an extra route-map to filter out the unwanted routes when redistributing the NSSA-Routes into Area 0:


ip prefix-list FilterOut seq 10 permit 10.172.0.0/16 le 32

!

route-map 10_172_ONLY permit 10

match ip address prefix-list FilterOut

!

router ospf 1 ! Area 0

redistribute ospf 2 subnet route-map 10_172_ONLY tag 1 ! don't forget the tag!

distribute-list route-map filter_ospf2 in


Unfortunately I couldn't test it but I think it should work.


HTH

Rolf

Endorsed by cisco_admin1
Rolf Fischer about 3 years 9 months ago

Hi Alex,


maybe there is a easier and better (more robust) solution.

If my understanding is correct, you have 2 NSSASBRs that inject BGP prefixes into the NSSA and you want to keep those external prefixes only within the NSSA?

If so, you could use the nssa-only option:

area nssa [nssa-only]


I have to admit that I didn't try it so far but avoiding the 7-to-5 translation at the NSSABRs sounds like the perfect solution. A robust OSPF-to-OSPF redistribution with more than one redistribution point can really be a challenge, I personally would consider it as a last-resort.



HTH

Rolf


[EDIT]: I noticed that the nssa-only keywork was fisrt added in 15.0(1)M, so it may no be applicable on your routers.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.8 (2 ratings)
Loading.
Rolf Fischer Sun, 11/03/2013 - 00:47
User Badges:
  • Blue, 1500 points or more

Hi Alex,


maybe there is a easier and better (more robust) solution.

If my understanding is correct, you have 2 NSSASBRs that inject BGP prefixes into the NSSA and you want to keep those external prefixes only within the NSSA?

If so, you could use the nssa-only option:

area nssa [nssa-only]


I have to admit that I didn't try it so far but avoiding the 7-to-5 translation at the NSSABRs sounds like the perfect solution. A robust OSPF-to-OSPF redistribution with more than one redistribution point can really be a challenge, I personally would consider it as a last-resort.



HTH

Rolf


[EDIT]: I noticed that the nssa-only keywork was fisrt added in 15.0(1)M, so it may no be applicable on your routers.

Rolf Fischer Sun, 11/03/2013 - 01:55
User Badges:
  • Blue, 1500 points or more

Alex,


I re-read the config-parts in your posting and have two more annotations:


1. The "Filtering routes based on tags" section in the document you linked is an example how to aviod routing loops when redistribute between two OSPF processes. It is not used to filtering in terms of redistribute only certain prefixes.


2. The area filter-list command only works for Type-3 LSAs. The flooding scope of external routes is AS-wide and you cannot filter Type-5 LSAs with the area filter-list command.


What would work for filtering out external prefixes is the distribute-list in command. You can define which prefixes from one process will be installed in the local routing table and only those routes will be redistributed into the other process.

But like mentioned in my first posting, I wouldn't recommend to do so. The document you linked describes the problems you can run into and how to solve them; so I'd watch for another solution, if possible. What about another routing protocol (e.g. EIGRP) for distributing the BGP prefixes within the NSSA?


Best regards

Rolf

Alex Samad Sun, 11/03/2013 - 12:43
User Badges:

Hi


Firstly the cisco switches are

WS-C3560G-24PS     12.2(53)SE            C3560-IPSERVICESK9-M



area nssa [nssa-only] doesn't seem to be available for me.  But I believe your assesment in the first reply is correct


area 0

area 1  + 2 bgp routers injecting routes in to the nssa


the aim is to keep those routes out of area 0 and any other area !


"Filtering routes based on tags"  i thought this also included a section on how to filter out unwanted routes


To quote from there


There can be several reasons for redistribution between multiple processes. These are a few examples:

  • To filter an OSPF route from part of the domain
  • To separate different OSPF domains
  • To migrate between separate domains



the first option is what I am after, I believe that when I create my route-map not only can I add in my deny tag, but I should be able to have a allow prefix filter... and then deny the rest !



as for using eigrp I have other devices that don't do eigrp


I guess the other option i could do is add more to its distance/metric for specific routes




What would work for filtering out external prefixes is the distribute-list in command. You can define which prefixes from one process will be installed in the local routing table and only those routes will be redistributed into the other process.


the other problem with this is that router is the dgw for a lot of machines that need access to those routes ...

Rolf Fischer Sun, 11/03/2013 - 23:04
User Badges:
  • Blue, 1500 points or more

Alex,


"Filtering routes based on tags"  i thought this also included a section on how to filter out unwanted routes


of course you can filter out unwanted routes between two OSPF processes based on tags, but this is not what the document describes. The document deals with making the OSPF-to-OSPF redistribution more robust, since you can run into some very special problems when implementing this.

You could tag the BGP routes when redistributing them into OSPF and filter based on those tags (deny them).

But again, you'll have to add some configuration in order to achieve a stable and predictable solution.

We also use OSPF as IGP and once in a while we have to redistribute beween OSPF processes too (but regular areas) because we have to interconnect OSPF routers outside our administrative domain. We experienced some of the problems described in the document (like routing loops; something you don't expect when using a link-state routing protocol), that's why I'm emphazising that.


I think it would really help if you could provide a simple network diagram only with the relevant part including the router/switch-platforms, areas and router roles.


Regards

Rolf

Alex Samad Mon, 11/04/2013 - 01:35
User Badges:

Hi


hope that helps the cut out in the bottom right is inside office, there are multiple vlans and the dgw is the 2 OSPF routers, using hsrp (the cisco's can't be stacked so I have to use HSRP).  the man is the backbone and I am in the process of bringing up dc2... so I am testing ospf between the office routers and the dc2 routers.  so its the dc2 routers I can check whats been publish as well as looking on the office routers.

the 3rd party has connetions at each of the locations. the office one is only very small pipe compared to all the other connection and would rather have the connection die then fall back over the office one. But we need the office one for office stuff !


I am thinking I might just run 2 opsf processes and publish 10.172.0.0 as a summerised network out to the backbone and not do anything dynamic from area 10.172.0.0 into the rest of the network ..


but now its a challenge to see if I can get it working.


So the other reason to do the filtering is if I attach anything else into office I don't want the routers flowing in to the DC's

Correct Answer
Rolf Fischer Mon, 11/04/2013 - 10:11
User Badges:
  • Blue, 1500 points or more

Sorry for the delay, I really had to think for a while what I would do to solve that.

Actually, your first attempt wasn't bad at all, and I'd try to do some modifications:


1. Basic config to avoid loops between the 2 processes when redistributing:


route-map filter_ospf1 deny 10

match tag 1

route-map filter_ospf1 permit 20

!

route-map filter_ospf2 deny 10

match tag 2

route-map filter_ospf2 permit 20

!

router ospf 1 ! Area 0

! (redistribute ospf 2 subnet tag 1)

distribute-list route-map filter_ospf2 in

!

router ospf 2 ! Area 10.172.0.0

redistribute ospf 1 subnet tag 2

distribute-list route-map filter_ospf1 in

!


2. So far, so good. Now we'll need an extra route-map to filter out the unwanted routes when redistributing the NSSA-Routes into Area 0:


ip prefix-list FilterOut seq 10 permit 10.172.0.0/16 le 32

!

route-map 10_172_ONLY permit 10

match ip address prefix-list FilterOut

!

router ospf 1 ! Area 0

redistribute ospf 2 subnet route-map 10_172_ONLY tag 1 ! don't forget the tag!

distribute-list route-map filter_ospf2 in


Unfortunately I couldn't test it but I think it should work.


HTH

Rolf

Alex Samad Tue, 11/05/2013 - 20:51
User Badges:

Hi


Thanks looks like I am nearly there

this is what i used


no ip prefix-list FilterOut seq 10

ip prefix-list FilterOut seq 10 permit 10.172.0.0/16 le 32



no route-map 10_172_ONLY

route-map 10_172_ONLY permit 10

match ip address prefix-list FilterOut





no route-map filter_ospf1

route-map filter_ospf1 deny 10

match tag 1

route-map filter_ospf1 permit 20





no route-map filter_ospf2

route-map filter_ospf2 deny 10

match tag 2

route-map filter_ospf2 permit 20





no router ospf 1

router ospf 1

router-id 10.31.19.253

log-adjacency-changes

area 0.0.0.0 authentication message-digest

redistribute ospf 2 subnets tag 1 route-map 10_172_ONLY

network 10.31.19.0 0.0.0.255 area 0.0.0.0

distribute-list route-map filter_ospf2 in









no router ospf 2

router ospf 2

router-id 10.172.255.2

log-adjacency-changes

area 10.172.0.0 authentication message-digest

area 10.172.0.0 nssa

redistribute connected

redistribute ospf 1 subnets tag 2

network 10.172.201.0 0.0.0.255 area 10.172.0.0

network 10.172.202.0 0.0.0.255 area 10.172.0.0

network 10.172.203.0 0.0.0.255 area 10.172.0.0

network 10.172.204.0 0.0.0.255 area 10.172.0.0

network 10.172.205.0 0.0.0.255 area 10.172.0.0

network 10.172.207.0 0.0.0.255 area 10.172.0.0

network 10.172.208.0 0.0.0.255 area 10.172.0.0

network 10.172.212.0 0.0.0.255 area 10.172.0.0

network 10.172.213.0 0.0.0.255 area 10.172.0.0

network 10.172.250.0 0.0.0.255 area 10.172.0.0

network 10.172.255.2 0.0.0.0 area 10.172.0.0

distribute-list route-map filter_ospf1 in



problem !

sh ip ospf 1 database only shows me

10.172.209.0    10.31.19.252    15          0x80000001 0x003AAC 1

10.172.209.0    10.31.19.253    34          0x80000001 0x0034B1 1

10.172.255.2    10.31.19.252    15          0x80000001 0x00CFEF 1

10.172.255.3    10.31.19.253    34          0x80000001 0x00BFFD 1

10.172.255.6    10.31.19.252    15          0x80000001 0x0002B0 1

10.172.255.6    10.31.19.253    34          0x80000001 0x00FBB5 1

10.172.255.7    10.31.19.252    15          0x80000001 0x00F7B9 1

10.172.255.7    10.31.19.253    34          0x80000001 0x00F1BE 1


so .6 .7 .2 .3 are routerid, 209 is the network not directly attached to this switch, but all the directly attached ones are not there


I have tried redistribute connected in router ospf 2 but that didn't help ..

Correct Answer
Rolf Fischer Tue, 11/05/2013 - 21:46
User Badges:
  • Blue, 1500 points or more

Hi,


but all the directly attached ones are not there.

I have tried redistribute connected in router ospf 2 but that didn't help.


Is OSPF enabled on the IP-interfaces of those connected networks (show ip ospf interface )?

If they belong to OSPF 2 and you want to redistribute them to OSPF 1 too, are they in the range 10.172/16 (route-map 10_172_ONLY)?

Alex Samad Tue, 11/05/2013 - 21:49
User Badges:

No they are not, should I have an entry in the interface for them


so i was reading that there is 2 ways to do it.


1) with the network commen in the router ospf statement

or

2) ip ospf in the interface definition


I think 2 is the prefered way yes ?

Alex Samad Tue, 11/05/2013 - 22:03
User Badges:

OKay, so I applied the configuration to each interface and remove the network command from the router ospf 2 config


then i added in a

area 10.172.0.0 range 10.172.0.0 255.255.0


to ospf 1


and now only the summary address is being broadcast back to the backbone



Thanks

Alex Samad Tue, 11/05/2013 - 21:47
User Badges:

I re entered the network statements in ospf2 and it worked so !

Actions

This Discussion