Hi

on solaris how long does it take for processes to see (and use) a
change in the default route(or any other route change?) accomplished
using the route change command

Thanks

"social" <mail4ashok@gmail.com> writes:
> on solaris how long does it take for processes to see (and use) a
> change in the default route(or any other route change?) accomplished
> using the route change command

'Processes' don't see the change, but IP does.  The effect should be
nearly instantaneous.

Why exactly are you asking?

In general, Solaris uses "route cache" entries to send packets.  When
sending to a given destination, IP looks for a route cache entry
first.  If one is found, it's used.  If not found, then the normal
forwarding table (the one you see with "netstat -nr") is scanned for
the best (longest netmask) match, and a cache entry is formed.

Cache entries are exact match -- from one IP address to the exact
output interface and next-hop address.  You can see these entries by
doing "netstat -nar | grep UHA".  They're timed out by the kernel to
avoid bloat and stale data, and they're flushed when routes are
changed that affect a given address+mask range.

Note that "route change" is basically broken as designed; it relies on
looking up routes merely by destination match, and you can have
multiple routes to the same destination that differ in either next hop
or interface.  It's better to use 'delete' and then 'add' to achieve
the desired effect.

-- 
James Carlson, KISS Network                    <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

James Carlson wrote:
[... snip ...]
> 
> Note that "route change" is basically broken as designed; it relies on
> looking up routes merely by destination match, and you can have
> multiple routes to the same destination that differ in either next hop
> or interface.  It's better to use 'delete' and then 'add' to achieve
> the desired effect.
> 

I think "broken as designed" is a bit harsh.  In fact, I recall using
this characteristic of "route change" to adjust tcp parameters
(like recvpipe and sendpipe) for specific IP ranges that were situated
at the far end of a "long-fat" pipe, where next hop or interface were
of no consequence, only destination mattered.

Robert Lawhead <news0000.5.unixguru@spamgourmet.com> writes:
> James Carlson wrote:
> [... snip ...]
> > Note that "route change" is basically broken as designed; it relies
> > on
> > looking up routes merely by destination match, and you can have
> > multiple routes to the same destination that differ in either next hop
> > or interface.  It's better to use 'delete' and then 'add' to achieve
> > the desired effect.
> >
> 
> I think "broken as designed" is a bit harsh.  In fact, I recall using
> this characteristic of "route change" to adjust tcp parameters
> (like recvpipe and sendpipe) for specific IP ranges that were situated
> at the far end of a "long-fat" pipe, where next hop or interface were
> of no consequence, only destination mattered.

The broken part is that for manipulating a forwarding table, it uses
insufficient information to locate the routes to be changed.

I agree it "sometimes" works.  That's not really a good
characteristic, though.

-- 
James Carlson, KISS Network                    <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677