SSL VPN Conference

RFC 3768 on Virtual Router Redundancy Protocol (VRRP)

A new Request for Comments is now available in online RFC libraries.

        RFC 3768

        Title:      Virtual Router Redundancy Protocol (VRRP)
        Author(s):  R. Hinden, Ed.
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    bob.hinden <at> nokia.com
        Pages:      27
        Characters: 59969
        Obsoletes:  2338

        I-D Tag:    draft-ietf-vrrp-spec-v2-10.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3768.txt

This memo defines the Virtual Router Redundancy Protocol (VRRP).
VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a
LAN.  The VRRP router controlling the IP address(es) associated with
a virtual router is called the Master, and forwards packets sent to
these IP addresses.  The election process provides dynamic fail over
in the forwarding responsibility should the Master become
unavailable.  This allows any of the virtual router IP addresses on
the LAN to be used as the default first hop router by end-hosts.  The
advantage gained from using VRRP is a higher availability default
path without requiring configuration of dynamic routing or router
discovery protocols on every end-host.

This document is a product of the Virtual Router Redundancy Protocol
Working Group of the IETF.

This is now a Draft Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

GARP in draft-ietf-vrrp-spec-v2-10.txt

Hi,
	I've a clarification with VRRP-GRAP usage.

When a VRRP Master comes up, Section 6.4.1 Initialize,
       o Broadcast a gratuitous ARP request containing the virtual
         router MAC address for each IP address associated with the
         virtual router.

Also Section 6.4.2 Backup
    - If the Master_Down_Timer fires, then:
       o Send an ADVERTISEMENT
       o Broadcast a gratuitous ARP request containing the virtual
         router MAC address for each IP address associated with the
         virtual router

- Is it the MAC braodcasted is Virtual MAC associated with the Virtual IP
address ?? or Physical MAC associated with Virtual IP physical interface .

If the Client host is holding Virtual MAC associated with the Virtual IP..
there is no need to send the GARP message in the first place. I beleive the
virtual MAC is calculated from the Virtual IP address, something similar to
Multicast MAC calculation form multicast address.

During ARP form the Client Host to the Router on virtual IP, ARP replies
with the virtual MAC for the virtual IP and not the physical MAC associated
with the virtual ip address.

In that case, we needn't bother about the GARP and any intermediate routers
between the VRRP router and client host. Because, some cases routers will
block boardcast packets to get propagated on other subnet, here GARP is a
broadcast packet.

Best Regards,
William StanisLaus.

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: GARP in draft-ietf-vrrp-spec-v2-10.txt

--- William StanisLaus <williams <at> calsoft.co.in> wrote:
> When a VRRP Master comes up, Section 6.4.1
> Initialize,
>        o Broadcast a gratuitous ARP request
> containing the virtual
>          router MAC address for each IP address
> associated with the
>          virtual router.
> 
> Also Section 6.4.2 Backup
>     - If the Master_Down_Timer fires, then:
>        o Send an ADVERTISEMENT
>        o Broadcast a gratuitous ARP request
> containing the virtual
>          router MAC address for each IP address
> associated with the
>          virtual router
> 
> - Is it the MAC braodcasted is Virtual MAC
> associated with the Virtual IP
> address ?? or Physical MAC associated with Virtual
> IP physical interface .

in the references above where it says 'virtual
router MAC address' it means VMAC.  I guess we
should have been more consistent in using the term
VMAC throughout the spec since that's well defined
and less ambiguous.

so ARP packet 'sender harware address' = VMAC and
'sender protocol address' = VIP.

> If the Client host is holding Virtual MAC associated
> with the Virtual IP..
> there is no need to send the GARP message in the
> first place. 

your interpretation is correct; within the vrrp
protocol there is absolutely no requirement /
reliance on ARP.  that was part of the [often
controversial] design decision to go with VMAC.
the whole gratuitous ARP thing is more related
to smoothing initial transition from non-VRRP
operation to VRRP.  if you've deployed your network
and have hosts with the default router physical 
IP+MAC mapping in place and then you switch on
VRRP operation the gratuitous ARP is to hopefully
speed the switchover of those hosts.  within the
VRRP spec it was just easier to say 'always send
gratuitous ARP when a Master comes up' than to
try and figure out some robust mechanism to detect
just the case of the first Master transition when
VRRP is first enabled on the LAN.

cheers,danny

	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

RE: GARP in draft-ietf-vrrp-spec-v2-10.txt

> 
> first place. I beleive the virtual MAC is calculated from the 
> Virtual IP address, something similar to Multicast MAC 
> calculation form multicast address.
> 

Wrong.

The virtual MAC is calculated from the configured VRRP VRID.

Regards,

Renwei

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

RE: GARP in draft-ietf-vrrp-spec-v2-10.txt

Thanks for all :)

but this reponse puzzles me ;)

what if ??

 +-------+   +-------+         +-------+   +-------+
 | Rtr1  |   | Rtr2  |         | Rtr3  |   | Rtr4  |
 |(MR    |   |(BR    |         |(MR    |   |(BR    |
 |VRID=1)|   |VRID=1 |         |VRID=1)|   |VRID=1 |
 +-------+   +-------+         +-------+   +-------+
 ---->*        *<- IP B      IP C->*       *<- IP D
 IP A |        |                   |       |
      |        |(Subnet 1)         |       |(Subnet 2)
 -----+--------+---------+      ---+----+--+-----+--
      ^        ^         |              ^        ^
      |        |         |              |        |
    (IP A)   (IP A)      |            (IP C)   (IP C)
      |        |         |              |        |
   +--+--+  +--+--+      |          +--+--+  +--+--+
   |  H1 |  |  H2 |      +----------|  H3 |  |  H4 |
   +-----+  +-----+         (IP A)  +--+--+  +--+--+ 

This is case, i assume VMAC calculation from VRID also consider's VRIP or
physical IP address.

otherwise, H3 will have same MAC configuration for both IP A and IP C

Best Regards,
William.

> -----Original Message-----
> From: Renwei Li [mailto:renwei <at> procket.com]
> Sent: Thursday, April 22, 2004 5:48 AM
> To: williams <at> calsoft.co.in; vrrp <at> ietf.org
> Subject: RE: [VRRP] GARP in draft-ietf-vrrp-spec-v2-10.txt
> 
> 
> 
> 
> > 
> > first place. I beleive the virtual MAC is calculated from the 
> > Virtual IP address, something similar to Multicast MAC 
> > calculation form multicast address.
> > 
> 
> Wrong.
> 
> The virtual MAC is calculated from the configured VRRP VRID.
>  
> 
> Regards,
> 
> Renwei
> 

RE: GARP in draft-ietf-vrrp-spec-v2-10.txt

--- William StanisLaus <williams <at> calsoft.co.in> wrote:
<snip picture>
> This is case, i assume VMAC calculation from VRID
> also consider's VRIP or physical IP address.
> 
> otherwise, H3 will have same MAC configuration for
> both IP A and IP C

the VRRP VMAC is not required to identify a globally 
(world wide) unique piece of hardware.  for proper 
VRRP (and LAN) operation a MAC is only required to be
unique within a LAN/broadcast domain.  that's the
scoping of the VMAC.

you're right that H3 would have IP A and IP C that
both map to the same VMAC1.  in normal host and
ARP table operation this is a non-issue because the
ARP table lookup key is the IP address.  if there's a 
state table or MIB with MAC as the key this could
raise an issue.

the one scenario I've seen fairly common where 
this VMAC LAN scoping raises problems is with some
L2 VLAN switches.  L2 switches that partition 
station learning cache and other state per-VLAN
have no issues.  L2 switches that use a global
station learning cache across all VLAN don't like
this VRRP feature.  in those deployment the
administrator needs to assign a different VRID to
virtual routers across all VLANs.

	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

RE: GARP in draft-ietf-vrrp-spec-v2-10.txt

when you have L2 Switch inbetween, there is always a problem,
hence i thought it will be good idea to use VRIP for calculating VMAC.

Best Regards,
William.

> -----Original Message-----
> From: danny mitzel [mailto:danny_j_mitzel <at> yahoo.com]
> Sent: Thursday, April 22, 2004 11:23 PM
> To: williams <at> calsoft.co.in; vrrp <at> ietf.org
> Subject: RE: [VRRP] GARP in draft-ietf-vrrp-spec-v2-10.txt
> 
> 
> 
> --- William StanisLaus <williams <at> calsoft.co.in> wrote:
> <snip picture>
> > This is case, i assume VMAC calculation from VRID
> > also consider's VRIP or physical IP address.
> > 
> > otherwise, H3 will have same MAC configuration for
> > both IP A and IP C
> 
> the VRRP VMAC is not required to identify a globally 
> (world wide) unique piece of hardware.  for proper 
> VRRP (and LAN) operation a MAC is only required to be
> unique within a LAN/broadcast domain.  that's the
> scoping of the VMAC.
> 
> you're right that H3 would have IP A and IP C that
> both map to the same VMAC1.  in normal host and
> ARP table operation this is a non-issue because the
> ARP table lookup key is the IP address.  if there's a 
> state table or MIB with MAC as the key this could
> raise an issue.
> 
> the one scenario I've seen fairly common where 
> this VMAC LAN scoping raises problems is with some
> L2 VLAN switches.  L2 switches that partition 
> station learning cache and other state per-VLAN
> have no issues.  L2 switches that use a global
> station learning cache across all VLAN don't like
> this VRRP feature.  in those deployment the
> administrator needs to assign a different VRID to
> virtual routers across all VLANs.
> 
> 
> 
> 	
> 		
> __________________________________
> Do you Yahoo!?
> Yahoo! Photos: High-quality 4x6 digital prints for 25"
> http://photos.yahoo.com/ph/print_splash
> 

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

RE: GARP in draft-ietf-vrrp-spec-v2-10.txt

The MAC associated with the VR's IP address is always the VR's MAC.
(The virtual MAC is derived from the VR's ID, not from the VR's IP
address.)

The reasons the gratuitous ARP is necessary is that the system
becoming master cannot be sure whether the VR's IP address was
previous associated with some other MAC address. Yes, in a perfect
world, with this IP address having been used only for VRRP supported
VR's, the gratuitous ARP is redundant. But in the real world where
IP addresses are moved around and not all VRRP implementations are
perfect, the gratuitous ARP is important for the much same reasons
it is important for any node coming on line to send gratuitous ARPs
for its own IP address.

-don provan
dprovan <at> bivio.net

> -----Original Message-----
> From: vrrp-admin <at> ietf.org [mailto:vrrp-admin <at> ietf.org]On Behalf Of
> William StanisLaus
> Sent: Wednesday, April 21, 2004 5:22 AM
> To: vrrp <at> ietf.org
> Subject: [VRRP] GARP in draft-ietf-vrrp-spec-v2-10.txt
> 
> 
> Hi,
> 	I've a clarification with VRRP-GRAP usage.
> 
> When a VRRP Master comes up, Section 6.4.1 Initialize,
>        o Broadcast a gratuitous ARP request containing the virtual
>          router MAC address for each IP address associated with the
>          virtual router.
> 
> Also Section 6.4.2 Backup
>     - If the Master_Down_Timer fires, then:
>        o Send an ADVERTISEMENT
>        o Broadcast a gratuitous ARP request containing the virtual
>          router MAC address for each IP address associated with the
>          virtual router
> 
> - Is it the MAC braodcasted is Virtual MAC associated with 
> the Virtual IP
> address ?? or Physical MAC associated with Virtual IP 
> physical interface .
> 
> If the Client host is holding Virtual MAC associated with the 
> Virtual IP..
> there is no need to send the GARP message in the first place. 
> I beleive the
> virtual MAC is calculated from the Virtual IP address, 
> something similar to
> Multicast MAC calculation form multicast address.
> 
> During ARP form the Client Host to the Router on virtual IP, 
> ARP replies
> with the virtual MAC for the virtual IP and not the physical 
> MAC associated
> with the virtual ip address.
> 
> In that case, we needn't bother about the GARP and any 
> intermediate routers
> between the VRRP router and client host. Because, some cases 
> routers will
> block boardcast packets to get propagated on other subnet, 
> here GARP is a
> broadcast packet.
> 
> Best Regards,
> William StanisLaus.
> 
> 
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/vrrp

RE: GARP in draft-ietf-vrrp-spec-v2-10.txt

--- William StanisLaus <williams <at> calsoft.co.in> wrote:
> when you have L2 Switch inbetween, there is always a
> problem, hence i thought it will be good idea to use
> VRIP for calculating VMAC.

I'm not sure what you mean by 'there is always a
problem' when vrrp is deployed with L2 switch/bridge?

I did mention the one confirmed problem I've heard of 
related to L2 switch implementing multiple logical L2 
(VLANs) within a single switch.  but for the standard 
L2 switch/bridge implementing a single LAN across all 
ports there should be no significant issues and
correct protocol operation has been demonstrated in
many real deployments.  there is an
interaction with station learning cache on vrrp 
master failover if the routers are connected to
different ports.  but that update is covered by the 
vrrp protocol (via heartbeat using MAC.src=VMAC) and
I wouldn't classify it as a 'problem'.  

I've heard rumors of issues/interactions related to
mostly non-standardized vendor 'value added features'.

e.g. locking a port down to a specific MAC address for

security/access control.  some rumors about 
interactions with spanning tree loop detection when a 
MAC changes port. etc.  but I'm not sure if those
have been confirmed/documented?

	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp