From owner-freebsd-net@FreeBSD.ORG Sun May 17 21:04:02 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82076106566B for ; Sun, 17 May 2009 21:04:02 +0000 (UTC) (envelope-from cbuechler@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 3D5718FC1E for ; Sun, 17 May 2009 21:04:02 +0000 (UTC) (envelope-from cbuechler@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1756994ywe.13 for ; Sun, 17 May 2009 14:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Zklvi7f3Dmt2j9QFVO5b5689D5+KNqjUR7PNclqQOIw=; b=rh0Di5Ss9qsm1JeUDo5vHkgL1CwsdL59BthrJmAs2jH7xPfJ1m458RAvi7NAktQHQ4 Meo4eC0LgEtTxRTg7BoZcsMO69cxpJGVETgURix1pBssMc9lamIOmE6eZ06OPgdbXGM7 RvpfzthR85TUFV/cQhMbK/eEy7XP5oxNsfKj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RJwsHOhqd2PsXkZJHlrcT+DOcTAjsGVZ4G5aZChF6uUi0ZJ4iYaQBnj66ci8z6PUrg ONmERb25Hirpl2uMOPMNADcDWCX7aIIATkwA/RoK5GgjAl8rBuF1urPba6MKeDnTOOTs uR+TeinSAu48IWM7rmDsN6+VzJdwJhFa5XrYQ= MIME-Version: 1.0 Received: by 10.150.136.15 with SMTP id j15mr10927189ybd.257.1242592851331; Sun, 17 May 2009 13:40:51 -0700 (PDT) In-Reply-To: References: <4A106EB1.1070709@chrisbuechler.com> Date: Sun, 17 May 2009 16:40:51 -0400 Message-ID: From: Chris Buechler To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: multi-homed systems stop answering ARP on local addresses w/ifconfig aliases X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 21:04:02 -0000 On Sun, May 17, 2009 at 4:35 PM, Steven Hartland wrote: > Silly question but something else on the network isn't doing a arp spoof > attack is it? > No, there isn't any ARP at all on that address on the network when this is a problem, verified with tcpdump. That also shouldn't impact the system's ability to talk to its own IPs. thanks for the response though! > ----- Original Message ----- From: "Chris Buechler" > > To: > Sent: Sunday, May 17, 2009 9:08 PM > Subject: multi-homed systems stop answering ARP on local addresses > w/ifconfig aliases > > >> There seems to be a regression between 6.x and 7.0 and 7.1 related to >> ifconfig aliases on multi-homed hosts. Not sure on anything newer than 7= .1 >> (this is pfSense, we're just starting to test 7.2 builds). For periods o= f >> time, the system will stop answering ARP on some of its own addresses an= d >> hence anything on that network completely stops functioning. The same se= tup >> worked fine on 6.2. >> >> The particular system illustrated here is a router on part of an ISP's >> network. IPs are all public, in the info provided here they've been repl= aced >> with 10. IPs. The subnets on the inside interfaces are routed to the out= side >> interface. When this problem occurs, the IPs assigned locally on the sys= tem >> will still respond from the Internet, but the system itself loses all >> connectivity with that subnet and nothing on that subnet can communicate >> with the host due to the lack of ARP. That makes some sense, I presume w= hen >> routing to a locally assigned address via another interface, the system >> doesn't need ARP on the address to respond. But while it still responds = from >> the Internet, even the host itself can't initiate a ping to that IP. It >> behaves the same whether pf is enabled or disabled. >> >> I see two similar issues in the past, one with a PR: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D121437&cat=3D >> that's exactly the same issue, it's not limited to VLANs, any multi-home= d >> host is affected. >> >> And another: >> http://thread.gmane.org/gmane.os.freebsd.stable/57125 >> >> fxp0 is the outside interface. It doesn't make any difference whether th= e >> ifconfig aliases are on the em0 or fxp1 interfaces, they both behave the >> same if they have any ifconfig aliases assigned. >> >> # ifconfig >> fxp0: flags=3D8843 metric 0 mtu = 1500 >> =A0 =A0 =A0 options=3D8 >> =A0 =A0 =A0 ether 00:90:27:86:8b:9d >> =A0 =A0 =A0 inet6 fe80::290:27ff:fe86:8b9d%fxp0 prefixlen 64 scopeid 0x1 >> =A0 =A0 =A0 inet 10.11.185.146 netmask 0xfffffff8 broadcast 10.11.185.15= 1 >> =A0 =A0 =A0 media: Ethernet 100baseTX >> =A0 =A0 =A0 status: active >> em0: flags=3D8843 metric 0 mtu 1= 500 >> =A0 =A0 =A0 options=3D9b >> =A0 =A0 =A0 ether 00:11:43:2c:62:03 >> =A0 =A0 =A0 inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255 >> =A0 =A0 =A0 inet6 fe80::211:43ff:fe2c:6203%em0 prefixlen 64 scopeid 0x2 >> =A0 =A0 =A0 inet 10.13.40.1 netmask 0xffffff00 broadcast 10.13.40.255 >> =A0 =A0 =A0 inet 10.13.41.1 netmask 0xffffff00 broadcast 10.13.41.255 >> =A0 =A0 =A0 inet 10.13.42.1 netmask 0xffffff00 broadcast 10.13.42.255 >> =A0 =A0 =A0 inet 10.13.43.1 netmask 0xffffff00 broadcast 10.13.43.255 >> =A0 =A0 =A0 inet 10.13.44.1 netmask 0xffffff00 broadcast 10.13.44.255 >> =A0 =A0 =A0 inet 10.13.45.1 netmask 0xffffff00 broadcast 10.13.45.255 >> =A0 =A0 =A0 inet 10.13.46.1 netmask 0xffffff00 broadcast 10.13.46.255 >> =A0 =A0 =A0 inet 10.13.47.1 netmask 0xffffff00 broadcast 10.13.47.255 >> =A0 =A0 =A0 media: Ethernet autoselect (100baseTX ) >> =A0 =A0 =A0 status: active >> fxp1: flags=3D8843 metric 0 mtu = 1500 >> =A0 =A0 =A0 options=3D8 >> =A0 =A0 =A0 ether 00:d0:b7:5d:25:9f >> =A0 =A0 =A0 inet 10.1.242.1 netmask 0xffffff00 broadcast 10.1.242.255 >> =A0 =A0 =A0 inet6 fe80::2d0:b7ff:fe5d:259f%fxp1 prefixlen 64 scopeid 0x3 >> =A0 =A0 =A0 inet 10.1.243.1 netmask 0xffffff00 broadcast 10.1.243.255 >> =A0 =A0 =A0 media: Ethernet autoselect (100baseTX ) >> =A0 =A0 =A0 status: active >> >> >> >> When the problem is occurring, you can't even ping the affected locally >> assigned addresses from the box itself: >> # ping 10.10.0.1 >> PING 10.10.0.1 (10.10.0.1): 56 data bytes >> ping: sendto: Network is unreachable >> ping: sendto: Network is unreachable >> ping: sendto: Network is unreachable >> >> And when trying to ping something on one of the affected attached subnet= s, >> you get: >> # ping 10.10.0.30 >> PING 10.10.0.30 (10.10.0.30): 56 data bytes >> ping: sendto: Invalid argument >> ping: sendto: Invalid argument >> >> >> In the logs, you get a flood of these messages: >> May 14 02:55:12 =A0 =A0kernel: arpresolve: can't allocate route for 10.1= 0.0.1 >> May 14 02:55:12 =A0 =A0kernel: arplookup 10.10.0.1 failed: host is not o= n >> local network >> May 14 02:55:12 =A0 =A0kernel: arpresolve: can't allocate route for 10.1= 0.0.1 >> May 14 02:55:12 =A0 =A0kernel: arplookup 10.10.0.1 failed: host is not o= n >> local network >> >> >> It happens both with the primary IP assigned to the interface, and the >> aliases assigned, but not all at once. Some of the addresses will contin= ue >> to work when others are failing. Somehow it thinks IPs that are locally >> assigned are not on a local network... after a couple minutes, it just >> starts working again without making any changes or even touching the sys= tem. >> >> If I can provide any additional information, please let me know. >> >> thanks, >> Chris >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and t= he > person or entity to whom it is addressed. In the event of misdirection, t= he > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > >