I got no replies with other ideas. I tried Casper's ipfilter trick and it works -- packets route through the correct cards now. Alas, the combination of the IPsec tunnel and ipfilter are now causing kernel stack overflows, even with lwp_default_stksize set to 0x8000. Additionally, Sunsolve has conflicting information on what it should be set to: infodoc 20151 says "increasing stack sizes above 16k is a wholesale waste of memory" yet infodoc 40722 recommends increasing "the value to the next higher setting...If it is currently 16k, make it 24k." Based on the description of rpcmod:svc_run_stksize it would seem to have no impact on this setup, but I will try adding that anyway. Thanks to Casper Dik for having posted his ipfilter trick. ----- Original Message ----- From: "bsd unix" <bsdunix@mail.com> Date: Sat, 22 Feb 2003 19:41:49 -0500 To: sunmanagers@sunmanagers.org Subject: 2 default routes and vpn > I have a system which has 2 default routes and is one end of a vpn. > Snoop shows that sometimes the system sends packets with the source > address of one card out the other. There is one network per card and > one default route per card. > > What I am reading suggests that Solaris is using round-robin when > sending the packets out. However, this causes some vpn packets to go > out the wrong interface, and thus the vpn has intermittent outages. > I saw a SUMMARY where Casper gave an example of using ipfilter to > force routing of the right network traffic out of the right card, but > was hoping there would be some kernel parameter or tweak to do this > natively. > > Apparently ip_strict_dst_multihoming is of no help because that only > works on inbound connections. > > Thanks in advance for any help or pointers. -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Tue Feb 25 10:54:11 2003
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:03 EST