|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Gigabit Linux Routers
> Dear Joe,
> > Several different traffic shaping strategies are available, and I think
> > all of them go far beyond "simple".
>
> ipfw 100 add pipe 1 all from 192.168.0.0/24 to any xmit vlan1
> ipfw pipe 1 config bw 95Mbit/s queue 200Kbytes
>
> thats simple.
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. ;-)
> >> cons: only 1 route for each network, vrrp failover is not easy to
> >> implement with quagga and ospf, no multipath routing
> >
> > carp seems easy to implement, even with quagga and ospf. At least, it's
> > set up on a lab setup here and everything appears to work as expected.
>
> example setup:
>
> A----(ospf)---B
> \ /
> \ /
> \ /
> \ /
> \ /
> lan1
>
> A and B share 1 virtual ip for lan1 (192.168.0.1/24).
> problems:
> *) only 1 ip-net supported (no aliases)
So, you want, what, like multiple aliases on the network? I just tried
adding an alias with the normal alias syntax, and it looks to work.
rtr0# ifconfig vlan20; ifconfig carp20
vlan20: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether 00:04:23:b7:8e:08
inet 206.55.68.194 netmask 0xffffffe0 broadcast 206.55.68.223
media: Ethernet autoselect
status: active
vlan: 20 parent interface: lagg0
carp20: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
inet 206.55.68.193 netmask 0xffffffe0
inet 206.55.68.196 netmask 0xffffffff
carp: BACKUP vhid 1 advbase 1 advskew 0
rtr1# ifconfig vlan20; ifconfig carp20
vlan20: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:80:c8:cd:43:1d
inet 206.55.68.195 netmask 0xffffffe0 broadcast 206.55.68.223
media: Ethernet autoselect
status: active
vlan: 20 parent interface: lagg1
carp20: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
inet 206.55.68.193 netmask 0xffffffe0
inet 206.55.68.196 netmask 0xffffffff
carp: MASTER vhid 1 advbase 1 advskew 0
switch20> ping 206.55.68.193
Pinging 206.55.68.193 with 56 bytes of data:
56 bytes from 206.55.68.193: icmp_seq=1. time=0 ms
56 bytes from 206.55.68.193: icmp_seq=2. time=0 ms
56 bytes from 206.55.68.193: icmp_seq=3. time=0 ms
56 bytes from 206.55.68.193: icmp_seq=4. time=0 ms
----206.55.68.193 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
switch20> ping 206.55.68.194
Pinging 206.55.68.194 with 56 bytes of data:
56 bytes from 206.55.68.194: icmp_seq=1. time=0 ms
56 bytes from 206.55.68.194: icmp_seq=2. time=0 ms
56 bytes from 206.55.68.194: icmp_seq=3. time=0 ms
56 bytes from 206.55.68.194: icmp_seq=4. time=0 ms
----206.55.68.194 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
switch20> ping 206.55.68.195
Pinging 206.55.68.195 with 56 bytes of data:
56 bytes from 206.55.68.195: icmp_seq=1. time=0 ms
56 bytes from 206.55.68.195: icmp_seq=2. time=0 ms
56 bytes from 206.55.68.195: icmp_seq=3. time=0 ms
56 bytes from 206.55.68.195: icmp_seq=4. time=0 ms
----206.55.68.195 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
switch20> ping 206.55.68.196
Pinging 206.55.68.196 with 56 bytes of data:
56 bytes from 206.55.68.196: icmp_seq=1. time=0 ms
56 bytes from 206.55.68.196: icmp_seq=2. time=0 ms
56 bytes from 206.55.68.196: icmp_seq=3. time=0 ms
56 bytes from 206.55.68.196: icmp_seq=4. time=0 ms
----206.55.68.196 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
switch20>
Mmm, generally, it looks to me like it works, but the above is the
entirety of my testing, so I could easily be wrong.
> *) 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?
> *) 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.
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:
# ifconfig vlan20 up
# route delete -net 206.55.68.192
# ifconfig vlan20 inet 206.55.68.195 netmask 0xffffffe0
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.
... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.
|