Hi
I’m having trouble setting the right filter to remove E2 prefixes from being advertised to the backbone. I have multiple ASBRs within an area all injecting a static /24 prefix into OSPF as E2. The ABR for the area is injecting a static summary for all these E2 prefixes as E1 to the backbone. How can I suppress the more specific prefixes (E2) from being sent to the backbone? The filter I have only works for the static-OSPF redistribution, but any learned by OSPF neighbours are passed on.
Or, is there a way to suppress the translation of NSSA to type 5 at the ABR for specific prefixes?
Essentially, I’m after the equivalent of Cisco summary-address command.
That’s not true. Cisco also has area range, and it works the same in both ROS / Cisco as far as I can tell.
summary-address has no direct equivalent in ROS.
In Cisco, summary-address only works on an ASBR to filter what routes it injects into OSPF. Once there, they’re pretty hard to filter out except by using stub/nssa areas. The equivalent configuration in RouterOS is to make a routing filter which blocks all longer subprefixes of the summary prefix. E.g. to make a summary-prefix of 192.168.64.0/18 you would create a rule such as this:
/routing filter add chain=SumaryPrefix prefix=192.168.64.0/18 prefix-length=19-32 action=discard
Then set this as the ospf-out filter on your OSPF instance. Finally, you will need to create the blackhole route for the prefix itself (which Cisco does automatically whenever a subprefix of the summary prefix is found) - /ip route add dst=192.168.64.0/18 type=blackhole
The Area Range mentioned by Mrz is functionally Identical to the area range command in Cisco as far as I’ve ever seen. It is used on ABR routers to summarize area prefixes - but only works for interior routes - external routes breeze right on through ABRs even when area ranges are defined.
I designed this using Cisco routers and discovered that the summary-address command only filters more specific prefixes if it matches a type 7 LSA - all type 5 LSAs pass into the backbone even if they match the summary-address prefix. So it only works with NSSAs.
However, when I tried this using CCRs using the same filter you posted and NSSA, the routing filter did not prevent the type 7 to type 5 conversion, and all more specific summaries were sent along with the summary itself. If the NSSA ABR is also an ASBR (which it is by redistributing the blackhole route) then any other matched redistributed routes are filtered, but none of the type 7 LSAs are stopped. In other words, it seems you can only filter at the point of redistribution in RouterOS. It’s a shame because the design looked so good on paper XD
Assume no static routes are created yet in this router.
At this point, nothing really happens due to the summary-address. If you were to create a static route to 192.0.2.0/24 then that would create a type 5 LSA in area 0, and all standard areas, and it would create a type7 LSA in an NSSA.
Okay - so far so good. Now you create another static route to 192.168.64.0/22. This prefix matches the summary-address, so it will NOT create a type5/type7 LSA for .64.0/22 - instead it will create a an OSPF route to Null0 for 192.168.0.0/16 redistribute THAT prefix as a type5/type7 LSA. As long as any sub-prefix of this summary-address is being redistributed into OSPF, the sumary-address will be routed to Null0 and announced as an external OSPF route. All sub-prefixes redistributed into OSPF will be suppressed from redistribution into OSPF.
Note that internal OSPF routes (i.e. not type5 or type7) will NOT trigger this behavior. Also, sub-prefixes which exist in other protocols (such as connected, RIP, etc) will not be affected / will not trigger the black-holing + advertisement of the summary prefix. Finally, type5/type7 LSAs from other routers will NOT trigger this - that is to say it will NOT aggregate the redistributed prefixes from other routers.
So:
You can aggregate your redistributed routes, but ONLY at the router where they are being injected (at the ASBR).
You can NOT aggregate redistributed routes anywhere else - such as at ABR routers.
And as my earlier reply to this thread indicates, you can perform this same behavior in OSPF with ROS using a routing filter rule on ASBR routers, but you must manually create the blackhole static route yourself.
OSPF treats external routes (types 5 & 7) almost completely differently than it treats interior routes. Understanding this is key to OSPF design, and is the reason why you can find many threads where I chime in and beg people to stop being lazy with OSPF by simply using redistribute static + redistribute connected. It works, but there are ramifications to this methodology that aren’t apparent to novice OSPF administrators.
The ONLY filter which blocks external routes is from area 0 → NSSA/STUB areas, and this is an all-or-nothing proposition. You either get ALL external routes, or you get none. (except for NSSA where you do have the ones generated within the NSSA itself). Going the other way - ALL external routes are propagated into the backbone area without exception.
Now one final issue to cover: The area range configuration mentioned by Mrz. This is similar to summary-address but it deals exclusively with INTERIOR routes, and ONLY works on ABR routers. Area range WILL aggregate LSAs that were originated by other routers. If you want to do route aggregation at ABRs, then you really need to figure out how to get rid of your external routes as much as possible, or else do as much aggregation as you can at every single ASBR - because that’s the only location where it can be done.
EDIT: Having said all of this, I have not actually attempted to replicate placing a summary-address onto an ABR for an NSSA area, so I’ll lab that up and post my results.
Well, I learned something today - summary-address DOES in fact aggregate routes during the tpye7 → type5 translation process.
Re-reading your post actually made me think for a moment and it made sense to me that this would work, which is why I tried it. Thanks for the knowledge boost.
Furthermore, I can see why a route filter would not work on ROS in the same scenario because it’s not quite the same thing as summary-address. Summary-address causes certain automatic behaviors in Cisco, such as the automatic creation of the blackhole aggregate route. Route filters don’t do that. The Cisco way is modifying the router’s treatement of the process of creating type 5 LSAs. Thus it affects their creation whether by redistribution OR by conversion from type 7. In Mikrotik, the filter is simply that - a filter which blocks the creation of type 5 (and I would also assume type 7) LSAs. This filter can only be placed between the redistribution directive and the routing process itself. The 7->5 conversion happens within OSPF - i.e. it doesn’t go through the filter.
You could work around this by breaking your NSSA off from the master OSPF topology. Run two OSPF processes on your ABR, one communicating with the backbone area, and a second one communicating with the former-NSSA - all of those routers would need to be converted to treat it as their own backbone area. So the “abr” would redistribute from “branch area process” into “master process”, at which point you could filter anything you like using filter rules.
Final note: I decided to see whether summary-address on an NSSA-ABR would aggregate an aggregated prefix from one of the NSSA area routers. It does this as well. Cool.
Thanks again. You’ve pretty much confirmed everything I had got to when I wrote the first post. I’m not going to comment on the points you made on your penultimate post as I think you now understand where I was coming from, so I’ll just confirm what it is I was trying to achieve.
Inside each NSSA is a number of routers that each have a single IP pool of /24 subnet size. In order to prevent adding each PPPoE interface into the OSPF domain, I have created a blackhole route for these pools and redistributed them into OSPF (prefix is always advertised, fewer routing flaps). On the ABR (which is also an ASBR due to having an IP pool) I create an aggregate blackhole route that captures all of the /24 subnets into one summary, and redistribute that to area 0. Each NSSA ABR also injects summary prefixes, so all internal OSPF prefixes flood all areas, but external routes are not and the automatic default route takes care of this.
So now I have a backbone with aggregated addresses along with their more specific /24 subnets. This then gets redistributed into BGP for propagation to the core, where I can filter as required. This is going to work just right for me I think, I was just hoping there was a way to clean up the area 0 routing table in the same way I could if it were Cisco. But no big deal, it’ll work. I had considered using multiple OSPF domains but I’d prefer not to redistribute where it can be helped, especially if that means mutually.