DragonFly users List (threaded) for 2005-03
Re: DragonFlyBSD not in compliance with RFC 1122
Matthew Dillon wrote:
:I ran into a problem today. I administer a machine that needs to sit on
:two separate networks 192.168.2.2/24 and 192.168.15.2/24. The network
:card is configured as:
:xl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
: inet 192.168.15.2 netmask 0xffffff00 broadcast 192.168.15.255
: inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255
: ether 00:10:5a:f7:6e:71
: media: Ethernet autoselect (100baseTX <full-duplex>)
: status: active
:The machine has a default route of 192.168.15.1.
:(Public IP addresses replaced with private.)
:All is well except that 192.168.2.2 is inaccessible from the Internet. A
:quick RTFM reveals that I need to add a second default gateway but it
:appears that this is not supported under FreeBSD 4 or DragonFly.
We definitely do not support multiple default gateways, but having two
internet-routable nets on the same interface ought to work as long as
your default router can deal with it. Make sure that
net.inet.ip.forwarding is set to 1 (via sysctl) and then you need to
run some tcpdump's on that interface and check:
(1) that the machine is receiving the ARP request to resolve 192.168.2.2.
(2) that the machine is responding to the ARP request.
(3) that the machine is receiving the packet meant for 192.168.2.2.
(4) then see if the machine is replying to it (e.g. assuming it's a ping
or something). The reply should be going out your default route.
(tell tcpdump to dump the MAC header too so you can be sure it is
being sent to the box defined by your default route).
There are several issues involved here.
The router in question is a Cisco and is dropping the packets from
192.168.2.0/24 that arrive on 192.168.15.1 due to anti-spoofing rules. I
was just hoping for an elegant solution. As I've mentioned I added a
work-around with IPFW but I'm not pleased with it.
I was quite surprised that FreeBSD doesn't support this even in 5.3. I
would have thought that the Zebra problem alone would be reason enough
to implement it. DragonFly is obviously affected too.
(The Debian machines I administer would just require a "route add
0.0.0.0 gw 192.168.2.1" to add the second default route.)
It's a problem that has gone unresolved in FreeBSD for over 18 months so
I guess it doesn't affect enough people to be a priority. I was just
wondering if it was planned for the ongoing DragonFly routing overhaul.