Date: Sun, 17 May 2009 16:40:51 -0400 From: Chris Buechler <cbuechler@gmail.com> To: Steven Hartland <killing@multiplay.co.uk> Cc: net@freebsd.org Subject: Re: multi-homed systems stop answering ARP on local addresses w/ifconfig aliases Message-ID: <d64aa1760905171340j4df0daa6yb34db4202daf687@mail.gmail.com> In-Reply-To: <C9FFD553E47B40BEA6F85F3126E9A692@multiplay.co.uk> References: <4A106EB1.1070709@chrisbuechler.com> <C9FFD553E47B40BEA6F85F3126E9A692@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 17, 2009 at 4:35 PM, Steven Hartland <killing@multiplay.co.uk> 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" > <freebsd@chrisbuechler.com> > To: <net@freebsd.org> > 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu = 1500 >> =A0 =A0 =A0 options=3D8<VLAN_MTU> >> =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 <full-duplex> >> =A0 =A0 =A0 status: active >> em0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1= 500 >> =A0 =A0 =A0 options=3D9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCS= UM> >> =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 <full-duplex>) >> =A0 =A0 =A0 status: active >> fxp1: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu = 1500 >> =A0 =A0 =A0 options=3D8<VLAN_MTU> >> =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 <full-duplex>) >> =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. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d64aa1760905171340j4df0daa6yb34db4202daf687>