gratuitous arp

gratuitous arp

[dean gaudet]

hi...

i ran into some problems recently which would have been avoided if my box 
did a gratuitous arp as it brought up all interfaces (the router took 
forever to timeout the ARP entries for interface aliases).  so i set about 
looking to see why that wasn't happening.

i either missed it, or there's no code in the kernel to do it -- but 
that's cool, because it's easy enough to do from userland.  i'm guessing 
this is the intention.

however my debian and ubuntu boxes aren't doing grat arp and don't seem to 
have options to do it (i do know about using various other tools such as 
arping, send_arp, garp to do it manually).

before i go opening bugs with the distribution folks, could someone chime 
in as to what is the recommended approach these days?  did grat arp fall 
out of favour, or is it just a case of userland not keeping up?

thanks
-dean

Re: gratuitous arp

[James Courtier-Dutton]

dean gaudet wrote:
> hi...
> 
> i ran into some problems recently which would have been avoided if my box 
> did a gratuitous arp as it brought up all interfaces (the router took 
> forever to timeout the ARP entries for interface aliases).  so i set about 
> looking to see why that wasn't happening.
> 
> i either missed it, or there's no code in the kernel to do it -- but 
> that's cool, because it's easy enough to do from userland.  i'm guessing 
> this is the intention.
> 
> however my debian and ubuntu boxes aren't doing grat arp and don't seem to 
> have options to do it (i do know about using various other tools such as 
> arping, send_arp, garp to do it manually).
> 
> before i go opening bugs with the distribution folks, could someone chime 
> in as to what is the recommended approach these days?  did grat arp fall 
> out of favour, or is it just a case of userland not keeping up?
> 
> thanks
> -dean

Are you 100% sure about this?
Have you done a packet sniff on the network?
A lot of routers ignore gratuitous arp for security reasons.

James

Re: gratuitous arp

[dean gaudet]

On Sun, 26 Nov 2006, James Courtier-Dutton wrote:

> dean gaudet wrote:
> > hi...
> > 
> > i ran into some problems recently which would have been avoided if my box
> > did a gratuitous arp as it brought up all interfaces (the router took
> > forever to timeout the ARP entries for interface aliases).  so i set about
> > looking to see why that wasn't happening.
...
> 
> Are you 100% sure about this?
> Have you done a packet sniff on the network?
> A lot of routers ignore gratuitous arp for security reasons.

yeah i've done some packet sniffing to verify this.

here's what happened (twice now):  i upgraded a (normally busy) box, so 
the MAC address changed.  the router is a cisco (not managed by me).

debian reboot sequence at some point brings up the primary eth0 address 
and very soon thereafter there will be an arp "who-has $default_gw tell 
$primary_addr".  that's sufficient to get the cisco to update its ARP 
cache for $primary_addr.  this isn't gratuitous arp, but does the trick 
for the $primary_addr.

but there's no gratuitous arp for any eth0:N aliased interfaces... and the 
cisco ARP cache on this ISP router seems to be set to a long timeout.  i 
could reach eth0:N from local net, but couldn't get outside local net from 
eth0:N.

issuing "arping -I eth0 -s $secondary_addr $default_gw" for each secondary 
address updated the cisco ARP cache and i could then reach eth0:N 
remotely.

so... that may not be exactly gratuitous arp, but basically i was stuck 
until i forced the cisco to update its ARP cache for each of the secondary 
addrs...

it seems to me it'd be nice for the init sequence to take care of this, so 
that other folks don't have to spend time debugging similar problems.  i 
just wanted to ask if i'm missing something obvious before i go open a 
debian bug.  (i'm tempted to see if fedora does anything differently.)

thanks
-dean

Re: gratuitous arp

[Martin Josefsson]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

On Sat, 2006-11-25 at 18:31 -0800, dean gaudet wrote:

> but there's no gratuitous arp for any eth0:N aliased interfaces... and the 
> cisco ARP cache on this ISP router seems to be set to a long timeout.  i 
> could reach eth0:N from local net, but couldn't get outside local net from 
> eth0:N.

Cisco IOS has a default arp timeout of 4 hours.

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: gratuitous arp

[James Courtier-Dutton]

dean gaudet wrote:
> On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
> 
>> dean gaudet wrote:
>>> hi...
>>>
>>> i ran into some problems recently which would have been avoided if my box
>>> did a gratuitous arp as it brought up all interfaces (the router took
>>> forever to timeout the ARP entries for interface aliases).  so i set about
>>> looking to see why that wasn't happening.
> ...
>> Are you 100% sure about this?
>> Have you done a packet sniff on the network?
>> A lot of routers ignore gratuitous arp for security reasons.
> 
> yeah i've done some packet sniffing to verify this.
> 
> here's what happened (twice now):  i upgraded a (normally busy) box, so 
> the MAC address changed.  the router is a cisco (not managed by me).
> 
> debian reboot sequence at some point brings up the primary eth0 address 
> and very soon thereafter there will be an arp "who-has $default_gw tell 
> $primary_addr".  that's sufficient to get the cisco to update its ARP 
> cache for $primary_addr.  this isn't gratuitous arp, but does the trick 
> for the $primary_addr.
> 
> but there's no gratuitous arp for any eth0:N aliased interfaces... and the 
> cisco ARP cache on this ISP router seems to be set to a long timeout.  i 
> could reach eth0:N from local net, but couldn't get outside local net from 
> eth0:N.
> 
> issuing "arping -I eth0 -s $secondary_addr $default_gw" for each secondary 
> address updated the cisco ARP cache and i could then reach eth0:N 
> remotely.
> 
> so... that may not be exactly gratuitous arp, but basically i was stuck 
> until i forced the cisco to update its ARP cache for each of the secondary 
> addrs...
> 
> it seems to me it'd be nice for the init sequence to take care of this, so 
> that other folks don't have to spend time debugging similar problems.  i 
> just wanted to ask if i'm missing something obvious before i go open a 
> debian bug.  (i'm tempted to see if fedora does anything differently.)
> 
> thanks
> -dean

Ok, I think it is better to just do gratuitous arp on the primary interface.
If one starts doing it on secondary interfaces, one would then have to 
also do it for all proxy-arp addresses(if used), and thinks could start 
getting rather messy.

James

Re: gratuitous arp

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2740 bytes --]



On Sun, 26 Nov 2006, James Courtier-Dutton wrote:

> dean gaudet wrote:
>> On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
>> 
>>> dean gaudet wrote:
>>>> hi...
>>>> 
>>>> i ran into some problems recently which would have been avoided if my box
>>>> did a gratuitous arp as it brought up all interfaces (the router took
>>>> forever to timeout the ARP entries for interface aliases).  so i set 
>>>> about
>>>> looking to see why that wasn't happening.
>> ...
>>> Are you 100% sure about this?
>>> Have you done a packet sniff on the network?
>>> A lot of routers ignore gratuitous arp for security reasons.
>> 
>> yeah i've done some packet sniffing to verify this.
>> 
>> here's what happened (twice now):  i upgraded a (normally busy) box, so the 
>> MAC address changed.  the router is a cisco (not managed by me).
>> 
>> debian reboot sequence at some point brings up the primary eth0 address and 
>> very soon thereafter there will be an arp "who-has $default_gw tell 
>> $primary_addr".  that's sufficient to get the cisco to update its ARP cache 
>> for $primary_addr.  this isn't gratuitous arp, but does the trick for the 
>> $primary_addr.
>> 
>> but there's no gratuitous arp for any eth0:N aliased interfaces... and the 
>> cisco ARP cache on this ISP router seems to be set to a long timeout.  i 
>> could reach eth0:N from local net, but couldn't get outside local net from 
>> eth0:N.
>> 
>> issuing "arping -I eth0 -s $secondary_addr $default_gw" for each secondary 
>> address updated the cisco ARP cache and i could then reach eth0:N remotely.
>> 
>> so... that may not be exactly gratuitous arp, but basically i was stuck 
>> until i forced the cisco to update its ARP cache for each of the secondary 
>> addrs...
>> 
>> it seems to me it'd be nice for the init sequence to take care of this, so 
>> that other folks don't have to spend time debugging similar problems.  i 
>> just wanted to ask if i'm missing something obvious before i go open a 
>> debian bug.  (i'm tempted to see if fedora does anything differently.)
>> 
>> thanks
>> -dean
>
> Ok, I think it is better to just do gratuitous arp on the primary interface.
> If one starts doing it on secondary interfaces, one would then have to also 
> do it for all proxy-arp addresses(if used), and thinks could start getting 
> rather messy.

BTW: There is no such thing like secondary interfaces. What you use 
(ethX:X) is emulation of interface aliases that was necessary for linux 
2.2.x, more than 5 yers ago. Currently (2.4/2.6) it is possible to add 
many addressess to one interface - all you need is the iproute2 package 
and utility called "ip".

Best regards,

 				Krzysztof Olędzki

Re: gratuitous arp

[dean gaudet]

On Sun, 26 Nov 2006, James Courtier-Dutton wrote:

> dean gaudet wrote:
> > On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
> > 
> > > dean gaudet wrote:
> > > > hi...
> > > > 
> > > > i ran into some problems recently which would have been avoided if my
> > > > box
> > > > did a gratuitous arp as it brought up all interfaces (the router took
> > > > forever to timeout the ARP entries for interface aliases).  so i set
> > > > about
> > > > looking to see why that wasn't happening.
> > ...
> > > Are you 100% sure about this?
> > > Have you done a packet sniff on the network?
> > > A lot of routers ignore gratuitous arp for security reasons.
> > 
> > yeah i've done some packet sniffing to verify this.
> > 
> > here's what happened (twice now):  i upgraded a (normally busy) box, so the
> > MAC address changed.  the router is a cisco (not managed by me).
> > 
> > debian reboot sequence at some point brings up the primary eth0 address and
> > very soon thereafter there will be an arp "who-has $default_gw tell
> > $primary_addr".  that's sufficient to get the cisco to update its ARP cache
> > for $primary_addr.  this isn't gratuitous arp, but does the trick for the
> > $primary_addr.
> > 
> > but there's no gratuitous arp for any eth0:N aliased interfaces... and the
> > cisco ARP cache on this ISP router seems to be set to a long timeout.  i
> > could reach eth0:N from local net, but couldn't get outside local net from
> > eth0:N.
> > 
> > issuing "arping -I eth0 -s $secondary_addr $default_gw" for each secondary
> > address updated the cisco ARP cache and i could then reach eth0:N remotely.
> > 
> > so... that may not be exactly gratuitous arp, but basically i was stuck
> > until i forced the cisco to update its ARP cache for each of the secondary
> > addrs...
> > 
> > it seems to me it'd be nice for the init sequence to take care of this, so
> > that other folks don't have to spend time debugging similar problems.  i
> > just wanted to ask if i'm missing something obvious before i go open a
> > debian bug.  (i'm tempted to see if fedora does anything differently.)
> > 
> > thanks
> > -dean
> 
> Ok, I think it is better to just do gratuitous arp on the primary interface.
> If one starts doing it on secondary interfaces, one would then have to also do
> it for all proxy-arp addresses(if used), and thinks could start getting rather
> messy.

the "primary" address (the address which is used as the source address for 
all ARP packets) didn't need a gratuitous ARP because it sent a real ARP 
request to find the default gateway's MAC addr.

it was all the rest of the addresses which were screwed (which i'll call 
secondary just because they're not the ones which are used in ARP 
requests, and aren't the ones used as default addresses for IN_ADDR_ANY 
sockets).

but yeah, i can see an ARP storm nightmare if every address does it at the 
same time at boot... with the likely result of the cisco dropping some 
(especially because i'm sure ARP is on the slow path through the generally 
weak cpu in a cisco router).

ugh, this does seem a rather specialized problem, and manually fixing it 
with arping/garp/send_arp seems most appropriate.

i pondered a daemon which would use libpcap to observe traffic for a while 
and look at outbound packets which aren't seeing inbound responses and 
then try to help with a directed ARP... and would stop after a few 
minutes... but it's so special purpose it's just silly.  it's useful only 
for a machine upgrade in the presence of silly default 4h ARP cache 
timeouts or for IP failover without MAC failover and in the presence of 
boxes which ignore grat arp.

-dean

Re: gratuitous arp

[Andi Kleen]

> before i go opening bugs with the distribution folks, could someone chime 
> in as to what is the recommended approach these days?  did grat arp fall 
> out of favour, or is it just a case of userland not keeping up?

The ifup script in iproute2 does it in user land, but nobody uses it
directly

-Andi

Gratuitous ARP

[Krishna Kumar]

Hi,

I am trying to find out why gratuitous ARP isn't implemented for IPv4
duplicate address detection, though a comment is present in the
arp.c that it was added. Was it removed for any reason ? I went
through netdev archives and found some threads relating to this, but
no comments were there on why this feature is absent or removed.
Could it be to avoid a flood arp attack ? If so, any reason why it cannot
be implemented under a configuration param ?

I would appreciate if someone can throw any light on this.

Thanks,

- KK