Is there any way around this?

On our network we plan on using an ADSL line as a failover to a main fibre circuit (terminating as a CAT5 on the RB obviously). We've got it all sorted such that OSPF provides the failover on the main connection and the ADSL has a default floating route. BUT, the directly-connected route stays in the routing table even if the link goes down. This could be an issue as at some sites we have several sites' external addresses on the same IP segment -- so when the line goes down the ADSL can see the outside world but not the remainder of the segment that the main connection has lost access to.

This seems to be a bug, as with other devices we use (Cisco, Juniper, Riverstone, Alcatel and Allied Telesis) the connected routes go down when the line protocol fails, which is what I'd expect. The OSPF session fails over immediately so the box clearly recognises when L1 goes down.

Is there any way around this (different version, tracking on the connected route) that anyone knows?

are you talking about ethernet is down, or adsl line is down?..

Ethernet.

The ADSL side actually does work -- it's on a PPPoE interface and when the link is not made, the PPPoE virtual interface is down and the route is made inactive (along with the NAT rules and firewall filters -- a good feature).

However the main ethernet interface on the LAN connection (a straightforward ethernet port with public IP address) is the one with the problem -- when the cable is removed (for example) the OSPF adjacencies are immediately terminated (good -- it's actually particularly quick at this part, much better than a Cisco) but the connected route remains active (bad -- it means that the subnet that the ethernet port is connected to cannot be accessed through the ADSL instead because an active but dead route exists to that destination and is obviously chosen by the routing engine over the default route to the DSL side).

Just seems a bit strange that an otherwise well-thought out routing process should be spoiled by a simple thing like this.

This is on 4.0beta3 (on an RB433UAH), and I wonder if a release version would be any different?

omg! beta?!? try 3.28, then if it's broken only in beta - send a mail to support@mikrotik.com =)

afair, works perfectly in v3

That is how it's made. Connected route will always be in routing table even if link is down. If you disable interface on which ip address is added, then it will be removed from routing table.

Is that wise though mrz?

Just because a router's connection to a network fails doesn't mean that the network itself is down, nor does it mean that there isn't another possible way of getting there.

I accept that Mikrotik's way probably helps to safeguard against loops, but is it not possible to switch this "feature" off?

What ?!

Well I use check-gateway=ping on all core/border/edge/w/e for the static routes over a certain interface, if the ping to the nexthop IP ADDRESS! fails due some reason, RouterOS by specification Should invalidate those routes, their status becomes Not Active (blue colour in WinBox) and the next best route is selected for that traffic! The distance also plays role here.

MikroTik team SHOULD DOUBLE CHECK how well and how FAST this works!

@jasejames And I could very quickly check your config - contact me with login details.

NetworkPro
You misunderstood something, the guy is talking about connected routes, not static ones.

Oh I see Well, how do you intend to fix it, MikroTik ?

We can offer following solution.
When interface is not active scope of connected route is changed. Next version (routing-tes) will have feature that in routing filters you will be able to disable connected route by following rule:
/routing filter add chain=connected-in scope=!10 set-disabled=yes

Will it change back to the working not disabled scope state when we plug the cable back in?

The MT customers need fast dynamic routing decisions being made - a line goes down - packets get routed to backup line - a link is flapping - clients dont really notice it - thats the whole point of the Internet as a network - complete realtime fail-over.

I am thankful that with MikroTik routers we can achieve this goal and I will be happy if you make our task of deploying the MikroTik routers easier!

Will it change back to the working not disabled scope state when we plug the cable back in?

ROS is already changing scopes whenever interface is active or not. We just added ability to disabe connected routes in routing filters.

Brilliant, thanks for the speedy resolution to this query.

Doesn't really what mechanism is used to kill bad connected routes, as long as it is possible.

In fact, ROS now has a distinct advantage over some other systems in that you can elect to keep a connected route up -- particularly with things like RIP this can keep a routing table stable. But at the same time, for other scenarios the link can be held down if needs be.