Gigabit Linux Routers

Fri Dec 19 22:28:58 UTC 2008

Dear Joe,

> Yes, but the point was that the feature was listed as "simple traffic
> shaping."  You can do *complicated* traffic shaping too, which was the
> reason I commented on that.  Usually the ability to do complicated
> traffic shaping means you can do simple traffic shaping too.  ;-)

with linux?
really?

> Mmm, generally, it looks to me like it works, but the above is the
> entirety of my testing, so I could easily be wrong.

you have ospf between this 2 boxes?
show me them routing table.
do a failover and show the routing table again,

>> *) carp is i bound, carp-dev line openbsd is in development
>>  	(not shure if already stable)
>
> You mean inbound?  Well, yes.  That's reasonably practical.  It isn't
> entirely clear what other paradigms would look like (i.e. if the host
> system didn't have a native address on the wire), though several ideas
> spring to mind.
>
> Am I correct in assuming that you mean to have no native interface on
> the network in question, and only a CARP interface?  Or am I reading in
> between the lines incorrectly?

only carp-int has the ip's.

>> *) if carp switch over:
>>  	t=0: A is master, has route 192.168.0.1/24
>>  	     B has route 192.168.0.1/24 via ospf
>>  	t=1: A goes down, route disappear (need linkstate in ospf)
>>  	t=2: B carp takes over 192.168.0.1/24
>>  		B can not add 192.168.0.1/24 route as it is still
>>  		known via ospf
>>  	t=3: B gets update to remove route 192.168.0.1/24 via ospf
>>  	t=4: 192.168.0.1/24 route has disappeared, failover broken.
>>
>> with ucarp, some special scripts and source code changed I was able
>> to handle this situation, but not with carp and ospf (at least at
>> freebsd 6.3)
>
> I agree that this is a problematic scenario.  FreeBSD 5.* and 6.* are
> pretty worthless to us, so we've pretty much jumped from 4 to 7, and
> so my knowledge of the networking improvements in between are limited.

I have not yet tested freebsd 7, as the multicast kernel interface 
changed and quagge ospf breaked. also I need(ed) a stable platform.

> Under FreeBSD 4, there is indeed a great deal of pain associated with
> routes coming in via a routing protocol that are also theoretically
> available on a directly-attached interface.
>
> I just tried downing rtr1: vlan20 on the above (which is FreeBSD 7,
> obviously) and from rtr1's PoV the network did move correctly to an
> alternate route via OSPF, but upon re-enabling the vlan20 interface,
> the OSPF route remained.  Now, it seemed to "all work again" when I
> did the following:

yes, thats the problem.

> # ifconfig vlan20 up
> # route delete -net 206.55.68.192
> # ifconfig vlan20 inet 206.55.68.195 netmask 0xffffffe0

I have changed ucarp todo so, but you also need
gratious arp and such stuff to get a real, flawless failover.

> which re-established the local link.  That's not ideal, but it is a lot
> better than FreeBSD 4, where things were just breaking all over if you
> did "strange" things like this.
>
> For most important things around here, we use OSPF with stub routes so
> the failure of a particular ethernet is not necessarily of great concern,
> but it would be nice to see things like this know how to DTRT.

DTRT?

Kind regards,
 	Ingo Flaschberger