From owner-freebsd-questions  Tue Nov 25 19:39:37 1997
Return-Path: <owner-freebsd-questions>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA10769
          for questions-outgoing; Tue, 25 Nov 1997 19:39:37 -0800 (PST)
          (envelope-from owner-freebsd-questions)
Received: from kjsl.com (Limpia.KJSL.COM [198.137.202.3])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA10763
          for <freebsd-questions@freebsd.org>; Tue, 25 Nov 1997 19:39:35 -0800 (PST)
          (envelope-from javier@kjsl.com)
Received: (from javier@localhost)
	by kjsl.com (8.8.5/8.8.5) id TAA08302;
	Tue, 25 Nov 1997 19:39:33 -0800 (PST)
Date: Tue, 25 Nov 1997 19:39:33 -0800 (PST)
Message-Id: <199711260339.TAA08302@kjsl.com>
From: Javier Henderson <javier@kjsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: freebsd-questions@freebsd.org
Subject: IP aliasing
X-Mailer: VM 6.33 under Emacs 19.34.1
Sender: owner-freebsd-questions@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Greetings,

	I'm running FreeBSD 2.2.5-RELEASE, and I recently configured several
IP alias addresses on the single Ethernet interface on the system.

	The first several addresses were all on the same subnet. Recently,
I added a new alias address on a different subnet, running on the same
wire. This new subnet has a different default gateway as the original
subnet, of course.

	If a packet comes out of the Ethernet interface with a source
IP address of the new IP address, which has to be routed, I get a
kernel message on the console about the default gateway for the
secondary subnet not being on the same subnet.

	Since that's all the message says, I'm assuming the kernel is
first ARP'ing for the default gateway of the second subnet through the
wrong interface.

	To make things a bit clearer:

	lnc1 is on 198.137.202.16/28.

	The new IP alias address is on 198.137.202.32/28. The default
gateway for this address is 198.137.202.33. The error message reads:

Nov 25 08:03:09 mate /kernel.MATE: arplookup 198.137.202.33 failed: host is not
on local network

	The packets do flow as expected, so presumably the kernel manages
to arp through the right subinterface, but I'm wondering if anyone else
has noticed this behavior.

-jav