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