OSPF filter not working

ibm · Sat Nov 25, 2017 11:18 am

Hello,
I'm encoutering a problem with OSPF filters. I’ve the following OSPF configuration and the routing filter applied to the instance ospf-wan-area does not work, the routerboard sends all the prefixes of the other ospf instance, anyone had same problem?

/ip address
add address=10.240.0.1 interface=loopback network=10.240.0.1
add address=10.254.0.3/29 interface=VLAN-WAN network=10.254.0.0
add address=10.20.0.1/26 interface=VLAN-BACKBONE network=10.20.0.0
add address=185.X.Y.1/28 interface=BRIDGE-WAN network=185.X.Y.0
/routing ospf instance
set [ find default=yes ] distribute-default=always-as-type-1 router-id=10.240.0.1
add in-filter=ospf-wan-in name=ospf-wan out-filter=ospf-wan-out redistribute-other-ospf=as-type-1 router-id=10.254.0.3
/routing ospf area
add area-id=0.0.0.1 instance=ospf-wan name=area-wan
/routing filter
add action=accept chain=ospf-wan-out prefix=185.X.Y.0/22 prefix-length=22
add action=discard chain=ospf-wan-out
add action=accept chain=ospf-wan-in prefix=0.0.0.0/0
add action=discard chain=ospf-wan-in
/routing ospf interface
add network-type=broadcast passive=yes
add interface=loopback network-type=broadcast passive=yes
add authentication=md5 authentication-key=X interface=VLAN-BACKBONE network-type=broadcast
add authentication=md5 authentication-key=X interface=VLAN-WAN network-type=broadcast
/routing ospf network
add area=backbone network=10.20.0.0/26
add area=backbone network=185.X.Y.0/28
add area=backbone network=10.240.0.1/32
add area=area-wan network=185.X.Y.0/28
add area=area-wan network=10.254.0.0/29

[admin@X] > routing ospf lsa print 
AREA                                  TYPE         ID             ORIGINATOR     SEQUENCE-NUMBER        AGE
area-wan                              router       10.254.0.1     10.254.0.1          0x800000B3         48
area-wan                              router       10.254.0.2     10.254.0.2          0x8000002B        458
area-wan                              router       10.254.0.3     10.254.0.3          0x800000D0       1551
area-wan                              network      10.254.0.2     10.254.0.2          0x80000028       1202
external                              as-external  185.X.Y.0      10.254.0.3          0x8000001F        326
backbone                              router       10.240.0.1     10.240.0.1          0x8000063F        849
backbone                              router       10.240.0.2     10.240.0.2          0x80000CE4        863
backbone                              router       10.240.1.1     10.240.1.1          0x80000C89       1460
backbone                              network      10.20.0.2      10.240.0.2          0x80000026        863
backbone                              network      10.20.10.6     10.240.1.1          0x80000C27       1460
backbone                              summary-n... 10.20.10.8     10.240.1.1          0x800005D4        802
backbone                              summary-n... 10.20.10.16    10.240.1.1          0x800007DF        474
backbone                              summary-n... 10.30.0.0      10.240.1.1          0x800007DF        739

Vooray · Sat Nov 25, 2017 11:41 am

Hey!

Ospf is link state protocol and it operates link states not prefixes. Route filtering applies to ospf to RIB communication.
Convert your wan area to nssa, and set nssa no-summary on ABR - you will get nssa routes in backbone, and 0/0 in nssa area.

ibm · Sat Nov 25, 2017 12:45 pm

Thanks for the answer, I have to study this details as soon as possible.
By the way I think about these steps:
- area-wan become nssa with unticked "Inject summary LSAs"
- ospf-wan-out filter will be deleted since the filtering seems to be unuseful
- put in the ospf network area-wan the entire /22 announce (?)

So with this changes I can get into wan-area the 0.0.0.0/0 and put to the wan-area routers my 185.X.Y.0/22 ? correct?

Vooray · Sat Nov 25, 2017 3:07 pm

Yes, you can have area-range on wan ABR to summarize 185.X.Y.0/22 and split it to your routers in this area.

I dont know what your final goal is, but i would not mess with areas until some specific circumstances. It is pretty ok to have hundred routers and thousand routes in area 0.

ibm · Sat Nov 25, 2017 7:06 pm

I wanted to separate the wan area because in this area there are only other 2 cisco router that runs bgp so they have to send me the default route (2 for redoundancy) and I have to send them the public /22.

Vooray · Sat Nov 25, 2017 7:50 pm

Basicly it is ok to have two default routes in network but may depend on your security devices. Anyway you can originate em with different metrics.
I would set /22 to static on border routers to prevent prefix dumpening on internet.

ibm · Sat Nov 25, 2017 8:36 pm

I would set /22 to static on border routers to prevent prefix dumpening on internet.

What do you mean?

Tue Nov 28, 2017 8:32 am

I would set /22 to static on border routers to prevent prefix dumpening on internet.
What do you mean?

What he means is that if you have some border router (BR1) which advertises your prefix based on reachability via IGP (as you're doing with OSPF) then what can happen is that if your internal network has flaps such that BR1 loses connectivity to the /22 in OSPF, and gains it back - over and over, then many networks will dampen your route advertisements from BR1. This is to reduce resource load caused by re-computing routes over and over on their side every time your announcements change. Suppose BR2 is stable, but is just a backup router. If BR1 flaps and asserts/withdraws your prefix repeatedly, then when the internet dampens prefixes from BR1, those will be ignored - even after BR1's internal connectivity stabalizes. So what you'll have is link1 being up, but being ignored by the Internet, so you're still on your backup for a while.

The way to prevent this is to create a "nailed up" route in each BGP router - so in BR1, instead of learning 192.0.2.0/24 from OSPF and originating it "if reachable" - you will create a static blackhole route to 192.0.2.0/24 (perhaps a floating static route with distance=254) so that this route is NEVER not available to BR1, thus it will never flap its advertisements.

However, I tend to prefer your method - using some internal router to originate my prefixes. This is because the opposite scenario can be worse - suppose BR1 loses internal connectivity but remains connected to its BGP peer(s). If BR1 has a static nail-up route internal to itself, then it will continue to advertise your prefixes - but this will be a black hole and will break your customers' connectivity as well.

In general, if your BGP routers are a part of your network, then you probably don't need a dedicated OSPF process to communicate with them. My network has a "DFZ" of BGP routers with full routing tables - but they also participate fully in my network's OSPF. The BGP routers are the ones that originate 0.0.0.0/0 into OSPF "if-available" as type 2.

However, I would think that the route filters DO filter the redistributed routes from other OSPF. I think OSPF only uses the OSPF-IN filter (or maybe it's OSPF-Out) because I _know_ it can be used to filter the redistributed static routes. The way to filter your routes would be on the target process's in filter (even if it's called "out" - I recall there being something strange here but I'm not sure and it's late and I don't have my lab to check my work here right now)
So if you only want your filter to apply to OSPF1 -> OSPF2 redistribution, then what you'd do is on OSPF2's filter, have rules about what's allowed and what's not - and anything that applies specifically to OSPF1, you can specify the source protocol as OSPF in the filter rules of your chain.

OSPF filter not working

OSPF filter not working

Re: OSPF filter not working

Re: OSPF filter not working

Re: OSPF filter not working

Re: OSPF filter not working

Re: OSPF filter not working

Re: OSPF filter not working

Re: OSPF filter not working

Who is online