Multiple routes to the same destination

[Christopher Martin]

> 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!