On Thu, 2006-01-19 at 14:06 -0800, John Sechrest wrote: > Do you have any iptables that might be in the way? Nope iptables -L give the three basics with the right permissions. Both tunnels work when I test them one at a time. So the routes are there and functional. > > Have you built any load balance routes with > > ip route add $X scope global nexthop via > $Y weight 1 nexthop via $z weight 1 Nope. I don't want to do that. Simply do destination routing and let my packet generator send the packets to 2 different places. I'm wondering if the problem exists because the tester switches to multicast and the Linux box is having trouble routing that. The simple routing table I sent "should" be all I need I think.
> > > > > Mike Cherba <[EMAIL PROTECTED]> writes: > > % Hoping someone might have some ideas for me. I'm working on testing an > % SSL based VPN client right now. Single tunnel tests work fine. I'm now > % trying to verify multi-tunnel numbers. I've set up 2 tunnels ppp0 and > % ppp1. When I send traffic through either tunnel independantly it works > % fine. however, when I try to send traffic from a single originating > % address to 2 different destinations, no Packets get through. I've run > % tcpdump on each of the 4 involved ports, eth0,eth1, ppp0, & ppp1 and > % verified that when I do this traffic is recieved on eth0 and not > % forwarded on out any interface. My routing table is below. I keep > % feeling like I'm missing something incredibly simple. Traffic is coming > % from 192.168.1.11 and should be going to 10.0.0.3 and 10.0.0.4. Traffic > % through either interface alone works, but through both simultaneously > % doesn't. > % -Mike > % > % Kernel IP routing table > % Destination Gateway Genmask Flags Metric Ref Use > Iface > % 10.0.0.4 * 255.255.255.255 UH 0 0 0 > ppp1 > % 10.0.0.100 * 255.255.255.255 UH 0 0 0 > ppp0 > % 10.0.0.100 * 255.255.255.255 UH 0 0 0 > ppp1 > % 10.0.0.3 * 255.255.255.255 UH 0 0 0 > ppp0 > % 192.168.1.0 * 255.255.255.0 U 0 0 0 > eth0 > % 15.0.0.0 * 255.0.0.0 U 0 0 0 > eth1 > % > % eth0 192.168.1.51 > % eth1 15.0.0.20 > % > % > % > % Another effective [debugging] technique is to explain your code to > % someone else. This will often cause you to explain the bug to yourself. > % Sometimes it takes no more than a few sentences, followed by an > % embarrassed "Never mind. I see what's wrong. Sorry to bother you." This > % works remarkbly well; you can even use non-programmers as listeners. One > % university computer center kept a teddy bear near the help desk. > % Students with mysterious bugs were required to explain them to the bear > % before they could speak to a human counselor. --- Kernighan & Pike "The > % Practice of Programming" > % _______________________________________________ > % EUGLUG mailing list > % [email protected] > % http://www.euglug.org/mailman/listinfo/euglug > > ----- > John Sechrest . Helping people use > . computers and the Internet > . more effectively > . > . Internet: [EMAIL PROTECTED] > . > . http://www.peak.org/~sechrest > _______________________________________________ > EUGLUG mailing list > [email protected] > http://www.euglug.org/mailman/listinfo/euglug -- Mike Cherba Cavium Networks 883 Brookside Dr Eugene, OR 97405 phone: (541) 684-3820 Cell: (541) 914-2188 [EMAIL PROTECTED] www.caviumnetworks.com _______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
