Date: Tue, 25 Sep 2001 21:24:48 -0400 (EDT) From: Darren Henderson <darren@bmv.state.me.us> To: freebsd-stable@FreeBSD.ORG Subject: Re: 4.4 arp problem Message-ID: <Pine.A41.4.21.0109252115260.15514-100000@katahdin.bmv.state.me.us> In-Reply-To: <Pine.A41.4.21.0109251620020.25940-100000@katahdin.bmv.state.me.us>
next in thread | previous in thread | raw e-mail | index | archive | help
NOTE: I goofed when I put out this question, trying to obscure the addresses
a bit I picked a range that wasn't representative of the values in actual
use. The result was that address ranges were incorrect. They are correct
below.
I upgraded a system from 4.3-STABLE to 4.4-STABLE using cvs on 9/23.
Everything was fine before the upgrade, upgrade went smoothly with the
exeption of the MAKEDEV problem thats been reported on the list recently.
This is a dual homed box (multi homed actually but only two interfaces are
in the kernel and active). Typical set up with ipfw/natd.
The system is apparently running just fine. However, I am seeing "/kernel:
arp_rtrequest: bad gateway value" messages which were never there before.
Anyone have an idea what may be causing them?
Searching the archives and the web turns up precious little. This is
apparently generated in netinet/if_ether and relates to aliases. I do have
several aliases defined on one interface. They are configured in
/etc/rc.conf as (x.y.z being numeric of course) ...
ifconfig_dc0="inet 10.0.0.1 netmask 255.255.255.0"
ifconfig_dc1="inet x.y.z.162 netmask 255.255.255.240"
ifconfig_dc1_alias0="inet x.y.z.163 netmask 255.255.255.255"
ifconfig_dc1_alias1="inet x.y.z.166 netmask 255.255.255.255"
ifconfig_dc1_alias2="inet x.y.z.174 netmask 255.255.255.255"
gateway_enable="YES"
router_enable="YES"
defaultrouter="x.y.z.161"
And from netstat -rn we see (in part, lo0 & dc0 routes excluded)....
default x.y.z.161 UGSc 29 541559 dc1
x.y.z.160/28 link#2 UC 2 0 dc1
x.y.z.161 (nic of gateway) UHLW 3 0 dc1 1183
x.y.z.163 x.y.z.23 UHLW 0 4 lo0 =>
x.y.z.163/32 link#2 UC 1 0 dc1
x.y.z.166 x.y.z.26 UHLW 0 10 lo0 =>
x.y.z.166/32 link#2 UC 1 0 dc1
x.y.z.174 (nic of link#2) UHLW 0 6 lo0 =>
x.y.z.174/32 link#2 UC 0 0 dc1
I believe 174 looks different then 163 and 166 becuase those two addresses
are redirected via ipfw/natd to internal addresses.
Something changed in the way interface aliases are handled? Am I looking at
the wrong things? Any thoughts appreciated.
________________________________________________________________________
Darren Henderson darren@bmv.state.me.us
darren.henderson@state.me.us
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.A41.4.21.0109252115260.15514-100000>