OSPF - stop 'connected' lte1 address from being distributed

RouterOS Forwarding Protocols
1

I’ve been running OSPF for a while, but something bit me today and I wanted to sanity check it and ask for help to solve it.

I have a Chateau LTE running v7.8 which creates an interface ‘lte1’ with a dynamically allocated /32 address on it when mobile data is running.

I’m running Wireguard to connect back to another of my routers and running OSPF over the link. I’m distributing only ‘connected’ routes (and never the default route).

On the Chateau I have a /24 network on one of the Ethernet interfaces. This /24 network is distributed correctly and is routes successfully.

The problem is, though, that the /32 address on the lte1 interface is also a ‘connected’ route and is also therefore distributed. This is bad.

My feeling is that this is a bug - surely any routes associated with lte1 should be of type ‘modem’ and not ‘connected’ (or if not ‘modem’, then perhaps ‘dhcp’?) and then choosing whether to distribute this route is just a simple matter of ticking or unticking a box.

So, the question is, how do I stop the dynamically allocated /32 IP address of lte1 being distributed over OSPF? I may be having a brain-fart, but I simply cannot work it out.

Your help would be very much appreciated.

Nicholas.

2

Hi all,

An update.

If I create a set of ‘accept’ route filter rules for networks which can be distributed and reject everything else by default, it works and the lte1 /32 is not distributed. In the current case, this solves the immediate problem.

However, the reason it works is because I know, broadly, which networks I should be distributing and (luckily) the lte1 /32 address is allocated from outside this range. Where I want to distribute everything except the lte1 address, this isn’t a possible solution (i.e. I can’t filter by IP address when I don’t know what those IP addresses are or I can’t filter out a single unknown IP from within a valid network address).

So are route filter rules the only way to achieve this?

Nicholas.

3

OK. A solution, of sorts.

The more I look at this, the more I think lte routes should be type ‘modem’ and not ‘connected’, but in the absence of that behaviour…

I knew I was having a brain fart.

Problem solved by:

/routing filter rule add chain=OSPF_Out disabled=no rule="if (dst-len == 32) {reject} else {accept}"
/routing/ospf/instance/set out-filter-chain=OSPF_Out [find]

Nicholas.

4

hello

The problem is, though, that the /32 address on the lte1 interface is also a ‘connected’ route and is also therefore distributed. This is bad.

…

So are route filter rules the only way to achieve this?

well, many ways to single destination.

but, just a simple thought:

why did you prefer to distribute connected when you know you will have to filter them out at the end?

and, just aside from that, network statement would be much granular in controlling advertisement?

anyway, well done with the ospf Tunnel :+1:t2:

5

I am unclear what question you are asking.
I am distributing connected routes because that’s what I need to do.
What I don’t want to do is distribute just one of those routes.

and, just aside from that, network statement would be much granular in controlling advertisement?

You’re right, it would be. However, without knowing in advance what those networks are, this isn’t possible.

Nicholas.

6

hi.

I am distributing connected routes because that’s what I need to do.
What I don’t want to do is distribute just one of those routes.

well, you already have your own answer.

My feeling is that this is a bug - surely any routes associated with lte1 should be of type ‘modem’ and not ‘connected’ (or if not ‘modem’, then perhaps ‘dhcp’?) and then choosing whether to distribute this route is just a simple matter of ticking or unticking a box.

that lte1 plain interface itself has nothing to do with connected or not connected.

any kind of interface shows up is a good one. it means they are available and ready to setup. ready to use.

and, when you put ip subnet on it, then that ip subnet dictate the system that it is connected to any network it belongs to.

You’re right, it would be. > However, without knowing in advance what those networks are, this isn’t possible.

you are the contractor. you design the network. then your first step before entering the data center is absolutely a fine approved assessment :+1:t2:

7

well, you already have your own answer.

I know I do. I was just pointing out that you clearly hadn’t read my original post.

that lte1 plain interface itself has nothing to do with connected or not connected.

It shows as a connected route. It has everything to do with being connected or not connected.

and, when you put ip subnet on it, then that ip subnet dictate the system that it is connected to any network it belongs to.

Again, you clearly didn’t read my post.

you are the contractor. you design the network. then your first step before entering the data center is absolutely a fine approved assessment > :+1:t2:

Oh dear.