OSPF not broadcasting specific connected route

RouterOS Forwarding Protocols
1

My company just installed a PowerRouter v4 (http://www.linktechs.net/productcart/pc/viewPrd.asp?idproduct=2046) to replace 4 CCR routers. It is functioning properly except it is not broadcasting a route over OSPF.

This router is an edge router, so we have our main IPv4 blocks null-routed by giving them static routes to an inaccessible IP address on the loopback bridge:

/ip address
add address=10.30.255.245/30 interface=lo network=10.30.255.244
/ip route
add distance=1 dst-address=208.X.X.0/21 gateway=10.30.255.246

This static route is broadcast just fine throughout the network. Attached to a different bridge on this router is a smaller subnet from this primary range:

/ip address
add address=208.X.X.1/25 interface=bridge2 network=208.X.X.0

Where the second and third octets are the same as the route previously mentioned. This route is not broadcast through OSPF (or not showing up in any of the other routers this router is connected to).

Previously these two routes (the null and the IP range) were hosted on separate routers (both CCR-1036 models) and it worked fine on the separate routers. So my questions are:

  1. Since the /25 is a more specific range, shouldn’t it be broadcast along with the /21 to the other routers?
  2. Is there a workaround I can use to force this route to propagate along with the other remaining in place?
  3. As a test, I disabled the static route in this router and the connected route did not propagate through as expected. Any ideas as to why this would be?

Here is my ospf instance config:

/routing ospf instance
set [ find default=yes ] distribute-default=if-installed-as-type-1 \
    redistribute-connected=as-type-1 redistribute-static=as-type-1 router-id=\
    10.30.0.64
/routing ospf network
add area=backbone network=162.Y.Y.0/24
/routing filter
add action=discard chain=ospf-out prefix=10.1.1.0/24 prefix-length=24-30
add action=discard chain=ospf-out prefix=169.254.0.0/16 prefix-length=16-30
add action=discard chain=ospf-out prefix=192.168.0.0/16 prefix-length=16-30

The router was shipped to us with 6.34.6 and I downgraded it to 6.34.2 as a test of the issue since the other routers it connects to are currently running 6.34.2. The downgrade did not change the issue.

2

Redistributing everyting into OSPF is a very common bad habit.

Add a network to your OSPF instance:
/routing ospf network add area=backbone network=208.x.x.0/25

Of course this makes the interface become an active OSPF interface, and it will start sending hellos, and may form adjacencies, etc.
If you don’t want that, then you can either specify the interface as passive:
/routing ospf interface add interface=bridge2 passive=yes

Best practice is to make all interfaces passive by default, and then specify the ones where you actually want adjacencies to form:
/routing ospf interface
set [ find where interface=all ] passive=yes
add interface=ether4 passive=no
add interface=ether5 passive=no
…
obviously, you’d want to set the appropriate costs on these, etc.

Once you have the passive/active definitions set to your needs, you can easily add a network that covers all of your space, and it will have the exact same effect as “redistribute connected”
network=208.x.x.0/22 (or whatever your master prefix is)
you can even add private IP networks too-
network=192.168.0.0/16
network=10.0.0.0/8
network=172.16.0.0/12

Personally, I prefer to add specific networks as needed because if you have a blanket network like 208.x.x.0/22 and there’s some interface that you really need to just create but not advertise into routing, you’re stuck. (and you’re also stuck with redistribute connected, unless you have a route filter in place)

The reason you don’t want OSPF to just be filled with injected (external) routes is that they behave differently than natural OSPF routes - they’re inferior to natural routes, which always take precedence over redistributed routes; they’re immune to areas (except stub areas which don’t support external routes at all); they don’t aggregate with area prefixes; more reasons I can’t think of right now, I’m sure…

If you have a growing network and it’s filled with E1/E2 routes, and you need to start partitioning into areas, you’ll have a LOT of cleanup to do.

EDIT- redistributing static is much more useful than redistributing connected, but I like to set up a filter that allows some control over WHICH static routes get injected, and which ones don’t. In Cisco, I use a route map that only redistributes static routes with a certain tag. When I make a static route, if I want it to be redistributed into OSPF, I add “tag 101” to the command, and if I just want that router alone to use this route, then I omit the “tag 101”.

– I just checked in my 2011 router that’s running the latest 6.36 ROS, and apparently route filters chains allow you to match on Route Tag, and static routes let you specify a Route Tag - so you could do the same thing in ROS. (I swear this wasn’t available in previous versions, but maybe I’m just going crazy)

EDIT 2:
I just tried to use the tag to filter static routes because I was sure it didn’t work - well, it didn’t. Whenever I try to actually SET the route-tag on a route, it just gets ignored. I was able to set my filter using scopes, though. I made the filter accept scope=29 but discard statics that weren’t set to scope 29, and that works perfectly. (FYI)