Gigabit Linux Routers
if at xip.at
Fri Dec 19 16:28:58 CST 2008
> 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. ;-)
> 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 220.127.116.11
> # ifconfig vlan20 inet 18.104.22.168 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.
More information about the NANOG