headers
"Stéphane" Monnier | 12 May 2004 10:44
Picon
Favicon

ARP Reply or Request

Hi,

The paragraph 6.4.2 of the RFC 2338 and 3768 says the
router which becomes Master must send an ARP request.

Recently, I have tested two implementations : one
sends an ARP request and the other an ARP reply.
The two implementations interoperate well each other.

Is there a problem to send an ARP reply instead of an
ARP request ?

Best Regards,
Stephane 

	
		
__________________________________
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861 

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 13 comments |
headers
William StanisLaus | 12 May 2004 11:23
Picon

RE: ARP Reply or Request

Hi,
	If i am not wrong it should be GARP which you are talking. i.e. ARP request
with its own ip address, sent when router becomes MASTER. This is used to
flush the HOST ARP cache information for the NEW MASTER. But if the OLD
MASTER still holds the virutal IP address, then he will respond to the GARP
(ARP request) as a ARP reply, in that case, he SHOULDNOT become as MASTER.

Best Regards,
William.

> -----Original Message-----
> From: vrrp-admin <at> ietf.org [mailto:vrrp-admin <at> ietf.org]On Behalf Of
> Stiphane Monnier
> Sent: Wednesday, May 12, 2004 2:15 PM
> To: vrrp <at> ietf.org
> Subject: [VRRP] ARP Reply or Request
>
>
> Hi,
>
> The paragraph 6.4.2 of the RFC 2338 and 3768 says the
> router which becomes Master must send an ARP request.
>
> Recently, I have tested two implementations : one
> sends an ARP request and the other an ARP reply.
> The two implementations interoperate well each other.
>
> Is there a problem to send an ARP reply instead of an
> ARP request ?
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
"Stéphane" Monnier | 12 May 2004 12:04
Picon
Favicon

RE: ARP Reply or Request

Hi,

Just to clarify my remarks.

The ARP request and reply are not send in the same
time by the two routers.

Let's say I have two routers (A and B) with VRRP
enabled.
A is master and B is backup. 
When B becomes master, he sends an ARP request (OK
with the RFC). But when A becomes master, he sends an
ARP reply ( KO with the RFC).

For my Linux Laptop, an ARP reply or request is not a
problem, he updates his ARP cache. But I don't know if
in certain cases, it could be a problem.

Best Regards,
Stephane

--- William StanisLaus <williams <at> calsoft.co.in> wrote:
> Hi,
> 	If i am not wrong it should be GARP which you are
> talking. i.e. ARP request
> with its own ip address, sent when router becomes
> MASTER. This is used to
> flush the HOST ARP cache information for the NEW
> MASTER. But if the OLD
> MASTER still holds the virutal IP address, then he
(Continue reading)

Permalink | Reply | 6 comments |
headers
William StanisLaus | 12 May 2004 12:36
Picon

RE: ARP Reply or Request

Hi Stephane,
  I wonder, how can ARP reply is sent from Router A when it take over
MASTER. i.e Switch back.
Because
1. ARP reply is a unicast.
2. For such unicast reply there should be a request.

now i have a quick question, to whom router A sending ARP reply??

Does any HOST update ARP cache from ARP reply <Unicast Packet>.....

Best Regards,
William.

> -----Original Message-----
> From: vrrp-admin <at> ietf.org [mailto:vrrp-admin <at> ietf.org]On Behalf Of
> Stiphane Monnier
> Sent: Wednesday, May 12, 2004 3:34 PM
> To: vrrp <at> ietf.org
> Subject: RE: [VRRP] ARP Reply or Request
>
>
> Hi,
>
> Just to clarify my remarks.
>
> The ARP request and reply are not send in the same
> time by the two routers.
>
> Let's say I have two routers (A and B) with VRRP
(Continue reading)

Permalink | Reply | 2 comments |
headers
"Stéphane" Monnier | 12 May 2004 18:09
Picon
Favicon

RE: ARP Reply or Request

Hi,

In fact, I agree with you. But when I inspect the ARP
reply, I show this :

Ethernet
    MAC source      : 00:00:5e:00:01:01
    MAC Destination : ff:ff:ff:ff:ff:ff
ARP
    Hard Type  : 0x0001
    Proto Type : Ox0800
    Hard size  : 6
    Proto size : 4
    OpCode     : 2 (Reply)
    Sender MAC : 00:00:5e:00:01:01
    Sender IP  : 10.10.10.254
    Target MAC : ff:ff:ff:ff:ff:ff
    Target IP  : 10.10.10.254

It is strange to have a "broadcast" ARP reply.

Best Regards,
Stephane

--- William StanisLaus <williams <at> calsoft.co.in> wrote:
> Hi Stephane,
>   I wonder, how can ARP reply is sent from Router A
> when it take over
> MASTER. i.e Switch back.
> Because
(Continue reading)

Permalink | Reply | 1 comment |
headers
William StanisLaus | 12 May 2004 19:52
Picon

Re: ARP Reply or Request

Hi,
    It perfectly looks like a GARP (gratuitous ARP) message. But i wonder
how come it has the OpCode as reply. It should be Request.
-William.
----- Original Message -----
From: "Stéphane Monnier" <stephane_monnier <at> yahoo.com>
To: <vrrp <at> ietf.org>
Sent: Wednesday, May 12, 2004 9:39 PM
Subject: RE: [VRRP] ARP Reply or Request

> Hi,
>
> In fact, I agree with you. But when I inspect the ARP
> reply, I show this :
>
> Ethernet
>     MAC source      : 00:00:5e:00:01:01
>     MAC Destination : ff:ff:ff:ff:ff:ff
> ARP
>     Hard Type  : 0x0001
>     Proto Type : Ox0800
>     Hard size  : 6
>     Proto size : 4
>     OpCode     : 2 (Reply)
>     Sender MAC : 00:00:5e:00:01:01
>     Sender IP  : 10.10.10.254
>     Target MAC : ff:ff:ff:ff:ff:ff
>     Target IP  : 10.10.10.254
>
> It is strange to have a "broadcast" ARP reply.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Provan | 12 May 2004 19:21
Favicon

RE: ARP Reply or Request

I'm not sure what the VRRP spec actually says about this,
but the ARP requirement is actually a requirement for GARP.
I don't know what the *GARP* spec says, either (can't even
remember if there is actually a GARP spec, but if there is,
I'm sure it doesn't call itself  GARP), but what I've read
in various GARP implementations is that some systems update
their cache if you broadcast an ARP request, but not if you
broadcast an ARP reply, and vice versa, so my VRRP implementation
(and the GARP implementation I stole my code from) broadcasts
both a request *and* a reply.

In any case, I don't think this has anything to do with VRRP.
I'm not saying you're asking in the wrong place, I'm just
saying the ensuing protocol discussion about how VRRP masters
respond to GARP messages is off the mark. VRRP has utterly
and completely failed if one VRRP master receives a GARP
message from one of its VRRP peers. A GARP message could
*only* come from an "unrelated" node, although, alas, for
VRRP, "unrelated" sometimes means another VRRP node with
a slightly different configuration....

-don

> -----Original Message-----
> From: vrrp-admin <at> ietf.org [mailto:vrrp-admin <at> ietf.org]On Behalf Of
> Stiphane Monnier
> Sent: Wednesday, May 12, 2004 1:45 AM
> To: vrrp <at> ietf.org
> Subject: [VRRP] ARP Reply or Request
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
danny mitzel | 12 May 2004 19:53
Picon
Favicon

RE: ARP Reply or Request

out of curiosity I'd find the answers to williams 
questions of interest.  i.e. is arp reply L2 bcast or
unicast, and what are all of arp payload fields:
sender hardware/protocol address, target hardware/
protocol address.

in reality the answers to those questions are mostly
inconsequential relating to vrrp protocol operation.
1. I've mentioned on this list before that vrrp usage
   of arp is typically not critical to the protocol
   operation.  it's mostly used as a mechanism to
   hopefully speed adoption of VMAC/VIP when vrrp is
   first enabled.  once vrrp is running and all
endhost
   are using VMAC/VIP then it really doesn't matter
   much whether an arp request, reply or nothing is
   sent because the net effect is no change in the
   VMAC/VIP mapping.
2. I'll assume the implementation you're investigating
   is sending the arp reply as L2 bcast.  in that case
   as long as the arp payload sender hardware/protocol
   address is VMAC/VIP then in theory it should be
   just as effective as an arp request.  any
   implementation that follows the recommended arp
   processing algorithm (rfc826) will perform the
   update of an existing sender hardware/protocol
   mapping before it even looks at the opcode.
(Continue reading)

Permalink | Reply | 2 comments |
headers
William StanisLaus | 13 May 2004 16:12
Picon

RE: ARP Reply or Request

I have a concern there, Might be VRRP doesn't have any issue with GRAP.
Actually GARP is used to update the HOST ARP cache entry within the subnet,
ALSO to check if there is any other HOST/ROUTER is configured with that
BROADCASTED IP ADDRESS. If the advertiser (one who sends the GARP) gets
response i.e. ARP reply, then it implies that there is some one in the
SUBNET holds the IP which SHOULD NOT be assigned to the ROUTER.

Regarding Point 2 by Danny, I doubt, unless otherwise the ARP packet is
completely validated no action is taken on the packet. Moreover any
operation is based on the opcode, if we receive wrong opcode we may endup in
wrong processing.

-William.

> -----Original Message-----
> From: vrrp-admin <at> ietf.org [mailto:vrrp-admin <at> ietf.org]On
> Behalf Of danny
> mitzel
> Sent: Wednesday, May 12, 2004 11:23 PM
> To: Stiphane Monnier; vrrp <at> ietf.org
> Cc: mitzel <at> acm.org
> Subject: RE: [VRRP] ARP Reply or Request
>
>
> out of curiosity I'd find the answers to williams
> questions of interest.  i.e. is arp reply L2 bcast or
> unicast, and what are all of arp payload fields:
> sender hardware/protocol address, target hardware/
> protocol address.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Provan | 12 May 2004 22:01
Favicon

RE: ARP Reply or Request

First, good summary of the relation with VRRP.
Now on with the GARP tangent:

> 2. I'll assume the implementation you're investigating
>    is sending the arp reply as L2 bcast.  in that case
>    as long as the arp payload sender hardware/protocol
>    address is VMAC/VIP then in theory it should be
>    just as effective as an arp request.  any
>    implementation that follows the recommended arp
>    processing algorithm (rfc826) will perform the
>    update of an existing sender hardware/protocol
>    mapping before it even looks at the opcode.

Yeah, but in practice some implementations ignore broadcast
ARP replies for one of two reasons:

1. ARP replies "should not" be broadcast (not in the
protocol sense of SHOULD NOT, but in the implementer's
mind), so this ARP message is obviously just an attempt to
break security. And, actually, I recall there was an
attack developed that used this step, but, of course, it's
easy enough for someone that can send such a reply to
disrupt an ARP cache using more subtle methods.

2. The ARP reply couldn't be to a request the implementation
sent, so it ignores them.

I'm not defending these implementations (although, at the
same time, I'm not sure there haven't been subsequent RFCs
that recommended one or the other of these techniques as
(Continue reading)

Permalink | Reply | 0 comments |

Gmane