Re: gratuituous arp for multiple IP addresses
By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de Rahul That won't achieve the desired result, which is to complain if someone _else_ replies to the arp request that we send. The above is achieved by virtue of sending the ARP request (anyone watching ARP messages will learn that we are the address in the "tell x.x.x.x" field). What we're trying to provoke is someone else saying x.x.x.x is-at xx.xx.xx.xx.xx.xx, which will result in a console message on our system informing the administrator that someone else is already using that IP address. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
I stand corrected again, as needed. The gratuituous arp should be formatted in whatever the correct way is. The machine that encountered loss of connectivity due to interface IPs being swapped is running 3.4-STABLE that was cvsup'd on January 7, 2000. If in fact some change was made in the sending of gratuituous arp since them to correct the problem, then nothing more needs to be done. Perhaps it would be useful for 'ifconfig' to have an option to send a gratuituous arp upon request by the user, without having to reconfigure any IP address. Rahul On Mon, 8 May 2000, Mike Smith wrote: By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de Rahul That won't achieve the desired result, which is to complain if someone _else_ replies to the arp request that we send. The above is achieved by virtue of sending the ARP request (anyone watching ARP messages will learn that we are the address in the "tell x.x.x.x" field). What we're trying to provoke is someone else saying x.x.x.x is-at xx.xx.xx.xx.xx.xx, which will result in a console message on our system informing the administrator that someone else is already using that IP address. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
FreeBSD 4.0-RELEASE does the gratuitous ARP when ifconfig'ing an alias: fenestro# ifconfig de1 1.2.3.5 alias 18:35:47.269471 0:40:5:42:d6:de Broadcast arp 42: arp who-has 1.2.3.5 tell 1.2.3.5 FreeBSD 3.4-STABLE also does: mango# ifconfig xl0 135.197.2.250 netmask 255.255.255.255 alias 18:39:12.509125 0:10:4b:cc:83:5f Broadcast arp 42: arp who-has 135.197.2.250 tell 135.197.2.250 I'm not sure what this says; it's entirely possible that there are conditions under which it doesn't or it fails for some reason. For example, there was a certain failure mode with sending multicast leave messages; the packet would be sent to the chip to be sent and then the multicast filter would be changed causing the chip to reset and lose the packet that's currently being transmitted. Adding an alias shouldn't cause the chip to be reset so that's not likely to be the exact problem, but perhaps something similar is happening. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de Rahul On Sun, 7 May 2000, Bill Fenner wrote: fenestro# ifconfig de1 1.2.3.5 alias 18:35:47.269471 0:40:5:42:d6:de Broadcast arp 42: arp who-has 1.2.3.5 tell 1.2.3.5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de The ARP processing specified in RFC 826 says that if you have an entry for the source IP address you update the hardware address no matter what the opcode is (i.e. you can update your tables due to a request). Every IP stack I've seen implements gratuitous ARP by sending a broadcast request for itself. In normal ARP operation, replies are unicast so conceivably an implementation that doesn't expect a broadcast reply might drop it. Requests are normally broadcasted, and the ARP processing rules cause broadcasted requests to update existing tables, so a broadcasted request is a better choice for a gratuitous arp. tcpdump hides too much information in an attempt to make things look pretty; it doesn't show the fact that the MAC information is included in a gratuitous ARP. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
Ok, I stand corrected. Rahul On Sun, 7 May 2000, Bill Fenner wrote: By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de The ARP processing specified in RFC 826 says that if you have an entry for the source IP address you update the hardware address no matter what the opcode is (i.e. you can update your tables due to a request). Every IP stack I've seen implements gratuitous ARP by sending a broadcast request for itself. In normal ARP operation, replies are unicast so conceivably an implementation that doesn't expect a broadcast reply might drop it. Requests are normally broadcasted, and the ARP processing rules cause broadcasted requests to update existing tables, so a broadcasted request is a better choice for a gratuitous arp. tcpdump hides too much information in an attempt to make things look pretty; it doesn't show the fact that the MAC information is included in a gratuitous ARP. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
gratuituous arp for multiple IP addresses
I was recently struck by this problem: Machine running 3.4-STABLE has multiple IP addresses on each of two network interfaces. IP addresses on network interfaces are exchanged for debugging. (de0 gets the IP addresses that de1 had, and vice versa). Machine is rebooted. Connectivity is now lost to secondary IP addresses on each interface, presumably because upstream router's arp cache still has old entries. Said router's arp timeout is long and said router is not under my control. Router administrator eventually forces a cache flush some time later, which restores connectivity. I think a possible solution would be for some future release of FreeBSD-CURRENT to send a gratuituous arp packet, at boot time, for each IP address on each interface. (It appears that FreeBSD does send a gratuituous arp but only for the primary IP address on each interface -- connectivity to the primary IP addresses was observed to be intact after the reboot.) Please correct me if I am making any wrong assumptions. -- Rahul Dhesi [EMAIL PROTECTED] (spam-filtered with RSS and ORBS) See my ORBS faq: http://www.rahul.net/dhesi/orbs.faq.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
