Multiple routes to the same destination

['Claudio Jeker']

On Sat, Jun 24, 2006 at 12:04:25AM +1000, Christopher Martin wrote:
> 
> > 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.
> 

Most implementation do a per source/dst IP address hashing which should
result in a similar distribution.

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

OpenOSPFD will learn to cope with multipath routes in the next few weeks
but it will only work on OpenBSD.

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

Multipath setups are harder to debug as packets may flow differently.
Often it is easier to use a layer 2 trunk to aggregate links. It depends
on your network layout, etc.

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

I hope that we can get more routing stuff done in the next few weeks but
the way routing is implemented in BSD makes it harder then necessary.
I bet andre@ will start to port features to FreeBSD as soon as the
stabilised in OpenBSD.

-- 
:wq Claudio