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 sendi
>
> 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.
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 i
>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 matt
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: ar
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
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.
Conne