Re: NM removes default route installed by zebra

[Glen Turner <gdt gdt id au>]

Greg Oliver wrote:
> ​That is exactly why METRICS exist in routing.​

Hi Greg

I was imprecise in my choice of words. I should have written "surest way" 
rather than "simplest way".

It's common when using dynamic routing protocols to separate the 
management plane and the forwarding plane, because metrics may not be 
sufficient to maintain access to management services in some scenarios 
when dynamic routing protocols misbehave.

For example, consider OSPF hearing a more-specific route -- but with a 
non-viable path beyond the next-hop -- and installing that route into the 
host forwarding table. If that route covers the source address of, say, 
the ssh client then communication from the server back to that ssh client 
may not be possible, and thus starting the TCP connection for the ssh 
service may not be possible. The "gateway of last resort" default route 
with a high metric is never consulted, and thus does not function as 
intended.

Another example is where a OSPF-learned lower metric default route with a 
differing next-hop is continually installed and removed from the 
forwarding table. This is commonly seen with routing loops in dynamic 
routing protocols. The flapping between the two next-hops may not allow a 
TCP connection to the server to be maintained for long enough to correct 
this fault.

I'll readily accept that servers have a wider range of management plane 
options than purpose-built routers. I should have alluded to the 
requirement rather than suggesting a mechanism.

My apologies for intruding upon your mailing list.

Regards, glen

-- 
 Glen Turner
 Web: <http://www.gdt.id.au/~gdt/>