--pgp-sign-Multipart_Fri_Feb_18_01:00:14_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "jk" == John Klos <john@ziaspace.com> writes:

    jk> I'm still not clear about what to do to tell the system, "use
    jk> ex0 for communicating with the default route"

That's funny.  we were just talking about DSL ``load balancing''
elsewhere.  I don't really understand your DSL scenario.  The same
subnet is assigned to both modems?

You can do some very weird things with the route flags subject to some
odd frustration.  For example, if I do this:

route -n add -inet -net 192.168.4.14 192.168.4.14 -netmask 0xfffffffe -cloning -iface -ifp tlp0

then the machine will arp for 192.168.4.15 on tlp0, even if tlp0 has
no address ``alias'' assigned that falls within that subnet.

Unfortunately, I can't get it to work for a /32, only for a /31.  If
the -cloning route is /32, then the -llinfo arpcache route's spot is
already taken by the cloning route, and the kernel prints console
messages,

arpresolve: can't allocate llinfo on tlp0 for 192.168.4.15

So, yes, you can force things out an interface with -ifp, but there
can be odd limitations.

Also there might be some equal-cost multipath stuff in KAME-SNAP, but
I think it is not some kind of imagineable ideal byte-counting
balancing that makes sure two routes to the same destination are
getting equal use during the last subsecond interval.  Rather I think
it chooses an interface just by hashing the destination IP.  I've
never tried to use it and could be so wrong.

--pgp-sign-Multipart_Fri_Feb_18_01:00:14_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQCVAwUAQhWEbonCBbTaW/4dAQJZcAP/VroOOaZplAke+um6nGpuOze+970FBYVJ
lMnIzkYP9wbWYjd0jUVy6jGayEyItwnlE43/ApTlUlbsHzUih8oeadhp/XCF73ug
EzKEM9K5o/OlvMQTqHEgkkPkk1eEH6Mm92Q10JbINYtEfSZaEJxrArS/JcbLh6xC
8/0i9vxlnUA=
=CkXq
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Fri_Feb_18_01:00:14_2005-1--