Virtual Routers With Multiple Ip Addresses

Lior Ronen <LiorR <at> radlan.com>
2002-11-03 15:00:35 GMT

Hello All,

MY name is Lior and I'm new to
VRRP.

If someone could advise on the following I would
appreciate it:

1.In case that a non-owner VRRP router receive a start
up event, and while checking its interfaces it discovers that he does not have a
direct route to all the VRID's associatedIP address
( in case of multinetting), should it transition to "backup" state or
should it reject the start up event ?

2.
In case that he can no longer backup only one of the VRID associated IP
addresses - should it transition to state "Initialize" or stay in backup despite
the fact that it can no longer support al the associated IP
addresses?

ARP REPLY IN VRRP

Hi ,
I have a doubt related to virtual router respone for ARP request .
Consider two routers R1 and R2 as shown :
IF1 ---- IF2
------| R1 |---------
| ---- |
---- | | ----
| H1 |--------| |----| H2 |
---- | | ----
| IF1 ---- IF2 |
------| R2 |---------
----
R1 and R2 are the routers.
H1 is a host in private network
H2 is a host in public network
IF1 and IF2 are the interface numbers.
R1 and R2 are connected through both the interfaces.
Virtual router is configured such that R1 is made address owner
and R2 as backup. If an ARP request is send to the virtual ip
address (which is now same as the
R1 interface address) , Master (R1) will respond back with source
harware address in ARP packet as the virtual router MAC address .
If a Shutdown event is received, then R1 will :
o Cancel the Master_Down_Timer
o Transition to the {Initialize} state
This will make R2 to become Master . If we now send an ARP request
to the virtual ip address, then R2 will respond back with source
hardware address in ARP reply packet as the virtual router MAC
address and also R1 will reply back with source hardware address
in ARP reply as the physical MAC address of the IF1 interface .
This leads to duplication of MAC address and most probably
duplication of packets .
To avoid this phenomena i think that in the initialise stage the
virtual router MUST NOT respond to ARP requests for the IP
address(s) associated with the virtual router .
Any suggestions/comments if i am missing something out here ? or
really some modification is required in the VRRP Initialize
stage
Thanks,
Ashish Thakur
__________________________________________________________
Give your Company an email address like
ravi <at> ravi-exports.com. Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

RE: VRRP RFC

<snip>
In the last if statement, in case Preempt_Mode is TRUE
and the Priority in the ADVERTISEMENT is smaller than
the local Priority, then:
Why do we Discard the ADVERTISEMENT ?
Why not transition to MASTER and preempt the lower priority Master?
</snip>
We discard the advertisement as a way of preempting, the key thing here is
that we do not reset the Master_Down_Timer. By ignoring the advertisement
the Master_Down_Timer will fire and we will transition to MASTER.
Cheers,
Tom.
-----Original Message-----
From: Lior Ronen [mailto:LiorR <at> radlan.com]
Sent: Monday, November 04, 2002 2:24 PM
To: Vrrp (E-mail)
Subject: [VRRP] VRRP RFC
Hello,
Please help me understand the following issue:
In the VRRP RFC there is the following algorithm for backup state:
- If an ADVERTISEMENT is received, then:
If the Priority in the ADVERTISEMENT is Zero, then:
o Set the Master_Down_Timer to Skew_Time
else:
If Preempt_Mode is False, or If the Priority in the
ADVERTISEMENT is greater than or equal to the local
Priority, then:
o Reset the Master_Down_Timer to Master_Down_Interval
else:
o Discard the ADVERTISEMENT
endif
endif
endif
In the last if statement, in case Preempt_Mode is TRUE
and the Priority in the ADVERTISEMENT is smaller than
the local Priority, then:
Why do we Discard the ADVERTISEMENT ?
Why not transition to MASTER and preempt the lower priority Master?
Thank you for your time,
Lior
______________________________________
Lior Ronen
RADLAN Computer Communications Ltd.
ATIDIM TECHNOLOGICAL PARK,
BLDG #4,
TEL-AVIV , ISRAEL.
TEL: 972-3-7658964
FAX: 972-3-6458544
EMAIL: Liorr <at> RADLAN.COM
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: VRRP RFC

If the advertisement is discarded the master down timer will not be reset. Thus eventually a master down event will be triggered and the backup will transition to master state. This is true whether or not pre-empt mode is set to true.

If the advertisement is discarded the master down timer will not be reset. Thus eventually a master down event will be triggered and the backup will transition to master state. This is true whether or not pre-empt mode is set to true.

Re: ARP REPLY IN VRRP

Bill Fenner <fenner <at> research.att.com>
2002-11-05 03:13:05 GMT

>...If we now send an ARP request
>to the virtual ip address, then R2 will respond back with source
>hardware address in ARP reply packet as the virtual router MAC
>address and also R1 will reply back with source hardware address
>in ARP reply as the physical MAC address of the IF1 interface .
Section 8.2 says:
When a VRRP router restarts or boots, it SHOULD not send any ARP
messages with its physical MAC address for the IP address it owns, it
should only send ARP messages that include Virtual MAC addresses.
This seems to preclude R1 replying with its physical MAC address.
Bill
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: Re: ARP REPLY IN VRRP

Thanks bill , section 8.2 speaks when VRRP router restarts and on
configuring and initializing interfaces .
I am not able to trace anywhere in the RFC , about ARP response
from VRRP router being an address owner in Initialize state .
Either he should not respond or if so should respond with Virtual
Router Mac Address .
8.3 speaks of Proxy ARP , but whether it is applicable for router
in Initialize state . I think it would have been much clear if the
response to ARP request is also mentioned in the Initialize
state.
thanks
ashish thakur
On Tue, 05 Nov 2002 Bill Fenner wrote :
>
> >...If we now send an ARP request
> >to the virtual ip address, then R2 will respond back with
>source
> >hardware address in ARP reply packet as the virtual router
>MAC
> >address and also R1 will reply back with source hardware
>address
> >in ARP reply as the physical MAC address of the IF1 interface
>.
>
>Section 8.2 says:
>
> When a VRRP router restarts or boots, it SHOULD not send any
>ARP
> messages with its physical MAC address for the IP address it
>owns, it
> should only send ARP messages that include Virtual MAC
>addresses.
>
>This seems to preclude R1 replying with its physical MAC
>address.
>
> Bill
>_______________________________________________
>vrrp mailing list
>vrrp <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/vrrp
__________________________________________________________
Give your Company an email address like
ravi <at> ravi-exports.com. Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: Re: ARP REPLY IN VRRP

Mark Smith <vrrp <at> nosense.org>
2002-11-05 06:48:21 GMT

There is a ARP related issue here which isn't clearly covered by the RFC
- when the Master router comes up, there is a chance that it will ARP
for the host, before the host ARPs for it. Eg external traffic targetted
at one of the end hosts as the first packet exchange with the devices
being protected by VRRP.
In this case, it is also important that the router use the Virtual MAC
address in the ARP request it makes, as the target host will cache MAC
address of the VRRP router, in addition to replying to the VRRP router
with an ARP reply.
This section of the RFC is a bit confusing. The title is "Host ARP
Requests", so it doesn't appear to apply to ARP requests made by the
VRRP router.
On the other hand, the text Bill quoted says "ARP messages" from the
VRRP master router, rather than requests or replies, so the text does
specify the behaviour I mentioned in paragraph two.
I've read this section quite a number of times, as I've been bitten by
the fault I describe in the first paragraph. Upon reading Bill's quote,
with out having the seen the section title, I read it correctly, and now
realise the VRRP ARP request / reply behaviour is specified correctly.
It looks like the vendor of the equipment I was using fell into the same
trap I did when they implemented VRRP.
There probably would be value in changing the title of this section in a
future revision of this RFC, and possibly expanding the different ARP
request / reply behaviours.
Regards,
Mark.
On Tue, 2002-11-05 at 15:52, ashish thakur wrote:
> Thanks bill , section 8.2 speaks when VRRP router restarts and on
> configuring and initializing interfaces .
> I am not able to trace anywhere in the RFC , about ARP response
> from VRRP router being an address owner in Initialize state .
> Either he should not respond or if so should respond with Virtual
> Router Mac Address .
> 8.3 speaks of Proxy ARP , but whether it is applicable for router
> in Initialize state . I think it would have been much clear if the
> response to ARP request is also mentioned in the Initialize
> state.
>
> thanks
> ashish thakur
>
>
> On Tue, 05 Nov 2002 Bill Fenner wrote :
> >
> > >...If we now send an ARP request
> > >to the virtual ip address, then R2 will respond back with
> >source
> > >hardware address in ARP reply packet as the virtual router
> >MAC
> > >address and also R1 will reply back with source hardware
> >address
> > >in ARP reply as the physical MAC address of the IF1 interface
> >.
> >
> >Section 8.2 says:
> >
> > When a VRRP router restarts or boots, it SHOULD not send any
> >ARP
> > messages with its physical MAC address for the IP address it
> >owns, it
> > should only send ARP messages that include Virtual MAC
> >addresses.
> >
> >This seems to preclude R1 replying with its physical MAC
> >address.
> >
> > Bill
> >_______________________________________________
> >vrrp mailing list
> >vrrp <at> ietf.org
> >https://www1.ietf.org/mailman/listinfo/vrrp
>
> __________________________________________________________
> Give your Company an email address like
> ravi <at> ravi-exports.com. Sign up for Rediffmail Pro today!
> Know more. http://www.rediffmailpro.com/signup/
>
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

(no subject)

If somebody could help me understanding the following
part of Section 7.1 Receiving VRRP Packets :
"If the packet was not generated by the address owner(Priority
does not equal 255(decimal)), the receiver MUST drop the packet,
otherwise continue processing"
To my undersatnding it means that discard all the VRRP packets
which are not sent by an address owner, and if so the whole
purpose of VRRP will be lost . I think i am missing something out
here or their is something else ?
If virtual router is configured such that their is no VRRP address
owner then as per as above , every VRRP router will discard the
advertisements and become Master.
__________________________________________________________
Give your Company an email address like
ravi <at> ravi-exports.com. Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp