Subject: [VRRP] ARP Reply or Request

From: "St�phane" Monnier <[email-masked]>
Date: Wed, 12 May 2004 01:44:50 -0700 (PDT)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "William StanisLaus" <[email-masked]>
Date: Wed, 12 May 2004 14:53:37 +0530

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: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stiphane Monnier
> Sent: Wednesday, May 12, 2004 2:15 PM
> To: [email-masked]
> Subject: [VRRP] ARP Reply or Request
>
>
> Hi,
>

---

From: "St�phane" Monnier <[email-masked]>
Date: Wed, 12 May 2004 03:04:15 -0700 (PDT)

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

---

From: "William StanisLaus" <[email-masked]>
Date: Wed, 12 May 2004 16:06:47 +0530

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.

> Sent: Wednesday, May 12, 2004 3:34 PM
> To: [email-masked]
> Subject: RE: [VRRP] ARP Reply or Request
>
>
> Hi,
>

---

From: "St�phane" Monnier <[email-masked]>
Date: Wed, 12 May 2004 09:09:28 -0700 (PDT)

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 <[email-masked]> wrote:
> > > 	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
> > > MASTER still holds the virutal IP address, then
> he
> > > will respond to the GARP
> > > > The paragraph 6.4.2 of the RFC 2338 and 3768
> says
> > > the
> > > > Is there a problem to send an ARP reply
> instead of
> > > an
> > > > ARP request ?
> > > >
> > > > Best Regards,
> > > > Stephane
> > > >
> > > >
> > > >
> > > >

---

From: "Don Provan" <[email-masked]>
Date: Wed, 12 May 2004 10:21:17 -0700

SSdtIG5vdCBzdXJlIHdoYXQgdGhlIFZSUlAgc3BlYyBhY3R1YWxseSBzYXlzIGFib3V0IHRoaXMsDQpidXQgdGhlIEFSUCByZXF1aXJlbWVudCBpcyBhY3R1YWxseSBhIHJlcXVpcmVtZW50IGZvciBHQVJQLg0KSSBkb24ndCBrbm93IHdoYXQgdGhlICpHQVJQKiBzcGVjIHNheXMsIGVpdGhlciAoY2FuJ3QgZXZlbg0KcmVtZW1iZXIgaWYgdGhlcmUgaXMgYWN0dWFsbHkgYSBHQVJQIHNwZWMsIGJ1dCBpZiB0aGVyZSBpcywNCkknbSBzdXJlIGl0IGRvZXNuJ3QgY2FsbCBpdHNlbGYgIEdBUlApLCBidXQgd2hhdCBJJ3ZlIHJlYWQNCmluIHZhcmlvdXMgR0FSUCBpbXBsZW1lbnRhdGlvbnMgaXMgdGhhdCBzb21lIHN5c3RlbXMgdXBkYXRlDQp0aGVpciBjYWNoZSBpZiB5b3UgYnJvYWRjYXN0IGFuIEFSUCByZXF1ZXN0LCBidXQgbm90IGlmIHlvdQ0KYnJvYWRjYXN0IGFuIEFSUCByZXBseSwgYW5kIHZpY2UgdmVyc2EsIHNvIG15IFZSUlAgaW1wbGVtZW50YXRpb24NCihhbmQgdGhlIEdBUlAgaW1wbGVtZW50YXRpb24gSSBzdG9sZSBteSBjb2RlIGZyb20pIGJyb2FkY2FzdHMNCmJvdGggYSByZXF1ZXN0ICphbmQqIGEgcmVwbHkuDQoNCkluIGFueSBjYXNlLCBJIGRvbid0IHRoaW5rIHRoaXMgaGFzIGFueXRoaW5nIHRvIGRvIHdpdGggVlJSUC4NCkknbSBub3Qgc2F5aW5nIHlvdSdyZSBhc2tpbmcgaW4gdGhlIHdyb25nIHBsYWNlLCBJJ20ganVzdA0Kc2F5aW5nIHRoZSBlbnN1aW5nIHByb3RvY29sIGRpc2N1c3Npb24gYWJvdXQgaG93IFZSUlAgbWFzdGVycw0KcmVzcG9uZCB0byBHQVJQIG1lc3NhZ2VzIGlzIG9mZiB0aGUgbWFyay4gVlJSUCBoYXMgdXR0ZXJseQ0KYW5kIGNvbXBsZXRlbHkgZmFpbGVkIGlmIG9uZSBWUlJQIG1hc3RlciByZWNlaXZlcyBhIEdBUlANCm1lc3NhZ2UgZnJvbSBvbmUgb2YgaXRzIFZSUlAgcGVlcnMuIEEgR0FSUCBtZXNzYWdlIGNvdWxkDQoqb25seSogY29tZSBmcm9tIGFuICJ1bnJlbGF0ZWQiIG5vZGUsIGFsdGhvdWdoLCBhbGFzLCBmb3INClZSUlAsICJ1bnJlbGF0ZWQiIHNvbWV0aW1lcyBtZWFucyBhbm90aGVyIFZSUlAgbm9kZSB3aXRoDQphIHNsaWdodGx5IGRpZmZlcmVudCBjb25maWd1cmF0aW9uLi4uLg0KDQotZG9uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdnJycC1hZG1pbkBpZXRmLm9yZyBbbWFpbHRvOnZycnAtYWRtaW5AaWV0Zi5vcmddT24gQmVoYWxmIE9mDQo+IFN0aXBoYW5lIE1vbm5pZXINCj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMTIsIDIwMDQgMTo0NSBBTQ0KPiBUbzogdnJycEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbVlJSUF0gQVJQIFJlcGx5IG9yIFJlcXVlc3QNCj4gDQo+IA0KPiBIaSwNCj4gDQo+IFRoZSBwYXJhZ3JhcGggNi40LjIgb2YgdGhlIFJGQyAyMzM4IGFuZCAzNzY4IHNheXMgdGhlDQo+IHJvdXRlciB3aGljaCBiZWNvbWVzIE1hc3RlciBtdXN0IHNlbmQgYW4gQVJQIHJlcXVlc3QuDQo+IA0KPiBSZWNlbnRseSwgSSBoYXZlIHRlc3RlZCB0d28gaW1wbGVtZW50YXRpb25zIDogb25lDQo+IHNlbmRzIGFuIEFSUCByZXF1ZXN0IGFuZCB0aGUgb3RoZXIgYW4gQVJQIHJlcGx5Lg0KPiBUaGUgdHdvIGltcGxlbWVudGF0aW9ucyBpbnRlcm9wZXJhdGUgd2VsbCBlYWNoIG90aGVyLg0KPiANCj4gSXMgdGhlcmUgYSBwcm9ibGVtIHRvIHNlbmQgYW4gQVJQIHJlcGx5IGluc3RlYWQgb2YgYW4NCj4gQVJQIHJlcXVlc3QgPw0KPiANCj4gQmVzdCBSZWdhcmRzLA0KPiBTdGVwaGFuZSANCj4gDQo+IA0KPiAJDQo+IAkJDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG8geW91IFlhaG9vIT8NCj4gWWFob28hIE1vdmllcyAtIEJ1eSBhZHZhbmNlIHRpY2tldHMgZm9yICdTaHJlayAyJw0KPiBodHRwOi8vbW92aWVzLnlhaG9vLmNvbS9zaG93dGltZXMvbW92aWU/bWlkPTE4MDg0MDU4NjEgDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2cnJwIG1haWxpbmcgbGlzdA0KPiB2cnJwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3ZycnA=_______________________________________________vrrp mailing [email-masked]://www1.ietf.org/mailman/listinfo/vrrp

---

From: danny mitzel <[email-masked]>
Date: Wed, 12 May 2004 10:53:27 -0700 (PDT)

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.

---

From: "William StanisLaus" <[email-masked]>
Date: Thu, 13 May 2004 19:42:31 +0530

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.

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of danny
> mitzel
> Sent: Wednesday, May 12, 2004 11:23 PM
> To: Stiphane Monnier; [email-masked]
> Cc: [email-masked]

---

From: "Don Provan" <[email-masked]>
Date: Wed, 12 May 2004 13:01:28 -0700

First, good summary of the relation with VRRP.

>    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
somewhat dubious "defensive" measures), but I've encountered
both of them personally. So to support these known faulty
implementations, I recommend sending both a request *and* a
reply.

I've also encountered systems that don't update their
caches based on a receiving a *request*. I suppose you
could make the same arguments for that -- although the
air gets *quite* thin there -- but the cases I know
about, the *real* explanation was just that they
were broken... Still, they were in production. In fact,
a handful of them talk to my VRRP implementation even
as we speak.

-don
��陨��x%��o��bz��m��?�0�'�~���f��f��X��)ߣ��

---

From: jamal <[email-masked]>
Date: 14 May 2004 06:56:07 -0400

On Wed, 2004-05-12 at 13:21, Don Provan wrote:
> 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), 

ive been getting the chills seeing grat ARP being reffered to as GARP.
You almost stopped the abuse above Don but didnt go far enough ;->
GARP is infact a well known IEEE 802.1P extension to its 802.1D
(spanning tree) specification. I beleive GARP stands for Generic
Attribute Registration Protocol (specs available at IEEE website). 
I have seen some glossy magazines refering to grat ARP as the "GARP
protocol" and it has irritated me there as well (unfortunately if i sent
an email to the editor theyd probably never publish it - so i dont
bother).
 
I guess i have to say something useful now to ease my guilt of going off
topic.
One valuable thing with grat ARPs is ability to update middle device
caches such as L2 switches with a new port where it makes sense i.e
cause a station movement. 

Consider a VRRP capable L3 device pair connected to ports Y and Z of an
L2 device. On port X of L2 switch is a sender. On port B of both L3
devices is a hub connection to a passive receiver. 
Traffic direction is from sender to receiver (unidirectional) most of
the time. 
Should the backup of the L3 devices take over and not send a grat ARP,
then sender will continue sending to the switch as it was; swithc will
be sending to the wrong port (i.e to old L3 device). Recovery will
happen when the arp cache on the sender expires and it(sender) issues an
ARP request. 
Of course all that was needed was a way to enforce a station movement.
So it could have been a unicast packet of any sort. It could also have
been a bcast address of any sort incase you have multiple L2 devices.
So why not something sensible like a bcast grat ARP which could be used
by hosts (OS sensitive) as well to update their caches? 

cheers,
jamal

---

From: danny mitzel <[email-masked]>
Date: Fri, 14 May 2004 11:01:01 -0700 (PDT)

--- jamal <[email-masked]> wrote:
> One valuable thing with grat ARPs is ability to
> update middle device caches such as L2 switches with
> a new port where it makes sense i.e cause a station 
> movement. 

if your example was just intended to explain how L2 
bridge/switch station learning functions then I agree
that any unicast or broadcast packet can trigger a
cache update.

if your example is implying that vrrp relies on
gratuitous arp in any way for updating L2 bridge/
switch station learning then I disagree.  as far as
I remember the vrrp protocol specification makes no
mandates on the L2 source MAC if/when a vrrp router
sends gratuitous arp (or regular arp, or forwarding
packets, or send/receive any non-vrrp protocol
packet).
what the vrrp specification mandates is that the vrrp 
Advertisement L2 source MAC must be VMAC and that is 
how vrrp ensures proper update of L2 bridge/switch 
station learning caches.

cheers,danny

		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/

---

From: "William StanisLaus" <[email-masked]>
Date: Tue, 18 May 2004 15:51:36 +0530

I have a quick question, What if any HOST/ROUTER in the SUBNET replys to
Gratuitous ARP?? does the ROUTER boardcasting Gratuitous ARP (REQUEST) will
not take the IP (VRRP Virtual IP)  and will not become MASTER ??

-William.

> Sent: Friday, May 14, 2004 11:31 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: danny mitzel <[email-masked]>
Date: Tue, 18 May 2004 11:11:13 -0700 (PDT)

--- William StanisLaus <[email-masked]> wrote:
> I have a quick question, What if any HOST/ROUTER in
> the SUBNET replys to Gratuitous ARP?? does the 
> ROUTER boardcasting Gratuitous ARP (REQUEST) will

I don't think the protocol specification mandates
any specific behavior.  any vrrp protocol issues that 
can lead to multiple vrrp routers adopting an 
address should be detected and reported at the vrrp 
level.  these are supposed to be covered in the 
vrrp message processing rules, error reporting 
requirements, and network management/snmp mib.

I think the more general problem of reliably detecting

and reporting any combination or host or router or
vrrp-enabled router on a subnet with duplicate 
addresses is outside the scope of vrrp.