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