On Tue, Nov 29, 2005 at 11:26:49PM -0700, andrew fresh wrote: > Hijacking this thread, cuZ now I am worried . . . . > > > On Mon, Nov 28, 2005 at 11:46:56PM -0800, David Ulevitch wrote: > > > I'd like to hear how people are using OpenOSPFd > > I will prbly use OpenOSPFd in the future, but at the moment, my question > is about using OpenBGPd and multiple lines from the same provider. > > I am getting 4 T1s from a single provider. Issues with local telco > "facilities" for T3's and other things are causing me problems with > getting anything different. > > I am going to end up with something like this: > san0-\ > san1-\\ all connected to a single provider > san2-// > san3-/ > > Now, I assume I will have a single BGP session with them. (I have very > little information for lines that are supposed to be installed tomorrow > morning at 9am). > > Right now I have a cisco 3640 that has 2 T1's from AT&T and 2 from > Sprint, it has enough trouble with those which is why I want to replace > it with an OpenBSD box. I am going to have an iBGP session with the > 3640 and an eBGP session with my new provider. > > I will be adding 20Mb over ethernet at some point in the fairly near future > (if they can ever get it installed) and will hopefully be getting rid of > the 3640 at that point. > > The OpenBSD router will not be doing any NAT, it will be passing public IPs. > > > This is what has me worried: > On Tue, Nov 29, 2005 at 03:33:07PM +0100, Claudio Jeker wrote: > > There is no kernel support for multipath routing. > > > I want to load balancing across those 4 T1s and it is sounding like I > will not be able to do that and will have to figure out how to get these > 4 new lines into my old cisco router. > > Unfortunately trunk(4) doesn't work with san interfaces :-( and that is > how it looked possible to do the bonding/inverse muxing that I was going > for. > > $ ifconfig trunk0 trunkport san0 trunkport san1 > ifconfig: SIOCSTRUNKPORT: Protocol not supported >
It could be possible to use trunk with sppp but that needs some patching. At least a round-robin trunk should be possible. > It would be really kewl to use the trunk(4) interface for the BGP > peer address, since it now does failover, it would be up as long as any > individual lines were up. It would be even kewler if it would be able > to change the weighting on that interface depending on the number of > lines in the trunk, but I guess I am dreaming again. > Jep. > I guess I am looking for something like 'ip load-sharing per-packet' in > cisco terms. But my real question is: How do I get OpenBSD to treat > those 4 T1s as a single line and share the load across them? > > or, how do I get a reasonable approximation from OpenBSD? > Currently I think you can only do it with pf and route-to. > > Also, with those 4 T1s, I want to make sure that in case any of the 4 go down, > the BGP session will stay up. With a cisco box, I just bind the session > to a loopback address, add routes for each interface and it will choose > one of the interfaces that is up to get to the destination. How do I do > this with OpenBSD? > Using a loopback interface is no porblem with OpenBSD. Having 4 routes in the routing table and choosing the right one is a problem. Currently this is not possible. > Will the BGP session just work when I solve the load balancing issue? > I would guess so. > or do I have to do weird things with ifstated(8) (like 16 states for the > 4 lines and lots of route add/delete statements)? > You most probably need ifstated to make sure that failed routes get removed (if link is down). > or something with 'route-to' in pf? > http://marc.theaimsgroup.com/?l=openbsd-misc&m=112831360613745&w=2 > > This seems to work in my test environment: > # t1s is an interface group containing all of the links to that provider > pass out on t1s route-to { \ > (san0 10.35.0.2) \ > (san1 10.35.1.2) \ > (san2 10.35.2.2) \ > (san3 10.35.3.2) \ > } round-robin keep state > pass in on san0 reply-to (san0 10.35.0.2) keep state > pass in on san1 reply-to (san1 10.35.1.2) keep state > pass in on san2 reply-to (san2 10.35.2.2) keep state > pass in on san3 reply-to (san3 10.35.3.2) keep state > I would probably do it the same way. I'm not sure if pf pays attetion to the link state of route-to interfaces. -- :wq Claudio
