Tom Matthews writes:
> Thankyou Alex for the thorough correction on the specifics of IPMP failure 
> detection, I had completely forgotten about the better practice of using 
> host-routes.
> I was merely suggesting one use for multiple default routes in response to 
> the question posed "So what's the purpose (or semantics) of 'multiple default 
> routers?' "

For that original question (not related to IPMP), the system will use
all of the configured default routes in an unspecified way.

Currently, when we attempt to contact a remote (off-link) IP address
that we either have never contacted before or that we haven't talked
to in a "while," we'll use a round-robin policy to select the next
default route to use.  If we've talked to a remote address recently,
then we'll use the same default route again, until the route is
deleted, TCP reports retransmissions, or we go idle for a "while."

By specifying multiple default routes, you're saying that there are
multiple equivalent ways to leave your local subnet and that each of
these next-hop routers is exactly equivalent for reaching all remote
destinations.  If any of that is not true, then don't configure your
routes like that.  (Be especially careful not to specify something as
a "default router" if it cannot forward to all remote IP destinations
-- you'll end up with unreliable connections, black holes, and
excessive ICMP redirect traffic.)

More generally, future releases of OpenSolaris may use other criteria
for choosing among multiple routes of any kind (not just default
routes).  One obvious (but not currently implemented) way to do this
is with a flow-identifying hash.  This is a nice stateless mechanism
that works well with ECMP (Equal-Cost Multi-Path) routing and
minimizes reordering.

-- 
James Carlson, Solaris Networking              <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to