On 06/08/2010 03:00 PM, Stephen Clark wrote:
On 06/08/2010 02:49 PM, Peter C. Lai wrote:
On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote:
On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote:
On 06/08/2010 02:05 PM, Jeremy Chadwick wrote:
On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote:
Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when
4.9 didn't?
The following output would help:
- ifconfig -a
- netstat -rn
- Contents of /etc/rc.conf
Also, be aware that RELENG_6 is to be EOL'd at the end of this year:
http://security.freebsd.org/
Hi Jeremy,
I am not sure that information is relevant. We have two systems
configured
identically one using 4.9 the other 6.3.
My concern was that someone had botched something up in rc.conf or
during the OS upgrade/migration, resulting in there being no loopback
interface. I also wanted to verify that your routing table looked
correct for what ifconfig showed.
Other users pointed you to RFC 3927. Wikipedia has this to say:
http://en.wikipedia.org/wiki/Link-local_address
"Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses.
However, the first and last /24 subnet (256 addresses each) in this
block have been excluded from use and are reserved by the standard.[1]"
I read this to mean 169.254.0.0/24 and 169.254.255.0/24.
Your previous ifconfig statement shows:
$ ifconfig rl0
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=8<VLAN_MTU>
inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255
inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255
ether 00:30:18:ae:7c:77
media: Ethernet autoselect (100baseTX<full-duplex>)
status: active
With this configuration, you're using both the first and last /24
netblocks -- 169.254.0.0 for your network address, and 169.254.255.255
for your broadcast address.
You should be able to avoid this by using 169.254.1.0/24.
RFC 3927 also has complicated rules involving when one can or should not
use a link-local address on the same interface as a routable IP, so at
best your configuration may not be supported anyway. One should not use
a link-local address as if it were under RFC 1918 rules, in particular
because link-local involves self-assigned addresses and internal
conflict mitigation.
Again what happened we had a box in the field that was running 4.9 being
used as a router/nat/vpn/firewall device. It was handing out ip addresses
to the internal lan using the range 169.254.202.0/24, who knows why this
address range was picked. It worked great but
the hardware died, so we were replacing it with our current SW which is
based on 6.3 we duplicated the configuration and have been struggling
trying to
get it to work for the customer since Saturday with no luck. Today I
finally
tried to ping the internal address from the box itself and it wouldn't
ping,
so I started trying using other addresses on the internal interface and
they
worked but not 169.254.202.1. In googling I discovered that 169.254/16
was supposed to be assigned if a box couldn't obtain an ip but saw
nothing about
an OS dropping them.
So anyway I know the reason behind the change now.
One final comment - I still don't understand why FreeBSD "won't" respond to
pings
when it has an address like 169.254.1.1. I can ssh to the unit but it won't
respond to pings. I tried setting up a linux box with an address like
169.254.1.2 and it "would" respond to pings.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
