headers
Lior Ronen | 3 Nov 2002 16:00

Virtual Routers With Multiple Ip Addresses

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 associated IP 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?
 
 
Regards,
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
Permalink | Reply | 0 comments |
headers
ashish thakur | 4 Nov 2002 11:51
Favicon

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
Permalink | Reply | 0 comments |
headers
Lior Ronen | 4 Nov 2002 15:24

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
 
Permalink | Reply | 1 comment |
headers
Thomas Dalton | 4 Nov 2002 15:32
Picon
Favicon

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
Permalink | Reply | 0 comments |
headers
Vikram Pendharkar | 4 Nov 2002 15:35
Picon
Favicon

Re: VRRP RFC

Lior,

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.

Vikram

 


----
NO sense being pessimistic. It wouldnt work anyway


Do you Yahoo!?
HotJobs - Search new jobs daily now
Permalink | Reply | 0 comments |
headers
Vikram Pendharkar | 4 Nov 2002 15:51
Picon
Favicon

RE: VRRP RFC

Yeah. My bad. Sorry

Vikram

 Lior Ronen <LiorR <at> radlan.com> wrote:

Yes, I see that now.
 
But why do you say that it is true whether or not pre-empt mode is set to true ?
==>If Preempt_mode is False we do reset the Master_Down_Timer.
 
Thank you very much for you answer. 
Regards,
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
-----Original Message-----
From: Vikram Pendharkar [mailto:philosopher203 <at> yahoo.com]
Sent: Mon, November 04, 2002 4:36 PM
To: Lior Ronen
Cc: vrrp <at> ietf.org
Subject: Re: [VRRP] VRRP RFC

Lior,

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.

Vikram

 


----
NO sense being pessimistic. It wouldnt work anyway


Do you Yahoo!?
HotJobs - Search new jobs daily now


----
NO sense being pessimistic. It wouldnt work anyway


Do you Yahoo!?
HotJobs - Search new jobs daily now
Permalink | Reply | 1 comment |
headers
Bill Fenner | 5 Nov 2002 04:13
Picon

Re: ARP REPLY IN VRRP


>...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
Permalink | Reply | 0 comments |
headers
ashish thakur | 5 Nov 2002 05:52
Favicon

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
Permalink | Reply | 501 comments |
headers
Mark Smith | 5 Nov 2002 07:48

Re: Re: ARP REPLY IN VRRP

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
Permalink | Reply | 501 comments |
headers
ashish thakur | 5 Nov 2002 08:58
Favicon

(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
Permalink | Reply | 0 comments |

Gmane