> I doubt that. Doing a per packet round robin over different pathes will > kill your tcp performance because of out of order packets.
Noted. That's a very good reason. Maybe if there was a may to round robin on a session basis to mitigate this. Not really going to be an easy fix, however, so your point is very valid. > > > > It would seem that you are assuming that I want to load balance two > internet > > connections which are NATed, in which case round robin might have issues > > with lost TCP sessions and weird reactions from servers as the apparent > > source address changes from packet to packet, but in a routed internal > > network the source address will not be changed by the router, thus > negating > > that issue. > > > > It did seem at some stage someone was going to include it in OpenBSD: > > http://undeadly.org/cgi?action=article&sid=20040425183024&mode=expanded > > > > That's just part of the it. The rest was added in the last couple of days > because multipath routing and accepting more than one route per > destination is a scary thing. Additionally dead nexthop detection is not > available. I would have thought OSPF would have provided your dead hop issues, however it does not resolve your point above, so we still seem out of luck. > > To quote: > > "...OSPF also supports multipath equal cost routing". > > > > Yes it does but often you try to avoid that. Because of your point above? Besides that, can you provide a couple of examples of why we would try and avoid it? > > It's more of a case where we would like to use BSD as a router/packet > > filtering firewall for sites with multiple WAN links between each site, > of > > equal size, and not have one site idle until the other fails over. Round > > robin is better than what we have: nothing. > > OpenBSD is on the way to support this but it is still a long journey till > all issues are resolved. Btw. OpenBSD uses a hash-threshold mechanism to > select paths based on source/destination IP address pairs (round robin > will never be supported). Again, another good point. And it also answers the other query as to the level of work involved in making it work. Thanks Claudio! _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
