[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-vrrp
Subject: Re: [VRRP] vrrp Digest, Vol 53, Issue 4
From: Karthik <rkarthik.ietf () gmail ! com>
Date: 2009-07-08 7:51:37
Message-ID: 608deed0907080051m10f2e791y32d77a8f0742fb29 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi,
If the router supports BFD (Bidirectional Forwarding Detection), then with
the help of BFD configured for VRRP, when master fails,
the backup can become master in few milliseconds than in seconds.
Regards,
Karthik
----------------------------------------------------------------------
> Message: 1
> Date: Tue, 7 Jul 2009 11:02:58 -0500
> From: "Stephen Nadas" <stephen.nadas@ericsson.com>
> Subject: Re: [VRRP] ??: Re: vrrp faster backup
> To: <liu.zhiwei1@zte.com.cn>, "Arnab Bakshi" <arnab.bakshi@gmail.com>
> Cc: vrrp@ietf.org
> Message-ID:
> <
> DF78BDF6956FDD4780D5DAD88A073CF4025C71B7@eusrcmw720.eamcs.ericsson.se>
>
> Content-Type: text/plain; charset="gb2312"
>
> Hi,
>
> If I understand the original question properly, the question is how, under
> expected failure scenarios, can backup take over of the master in less than
> 3 seconds. This has been discussed at some length on the mailing list
> (which you may wish to review) and please see also latest draft:
> draft-ietf-vrrp-unified-spec-03 which should appear in the repository soon.
> The draft discusses this issue.
>
> Regards,
> Steve
>
>
> ________________________________
>
> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On
> Behalf Of liu.zhiwei1@zte.com.cn
> Sent: Tuesday, July 07, 2009 11:16 AM
> To: Arnab Bakshi
> Cc: vrrp@ietf.org
> Subject: [VRRP] ??: Re: vrrp faster backup
>
>
>
> Dear Arnab
>
> Thanks for your feedback.
> Then when the priority value isn't zero, the Backup Router should
> waiting the Master Router time out.
> Are they any other way when priority isn't zero?
>
> Best Regards
>
>
>
>
> Dash Liu???????ID: 183475
> Chief Engineer Office, Standard Development and Industry Relations
> Product Marketing System
> ??????
> D206, 889, Bibo Road,ZhangJiang, Pudong District, ShangHai P.R.China,
> 210023
> Tel:+86-21-68896823/ 13701767991
> Mobile:+86-13828760990
> Email:liu.zhiwei1@zte.com.cn <Email%3Aliu.zhiwei1@zte.com.cn>
>
>
>
>
>
> Arnab Bakshi <arnab.bakshi@gmail.com>
>
> 2009-07-06 20:52
>
> ???
> liu.zhiwei1@zte.com.cn, vrrp@ietf.org
> ??
> ??
> Re: [VRRP] vrrp faster backup
>
>
>
>
>
>
> Hi Liu,
>
> As per RFC 3768, section 5.3.4 page 12:
> The priority value zero (0) has special meaning indicating that
> the
> current Master has stopped participating in VRRP. This is used
> to
> trigger Backup routers to quickly transition to Master without
> having
> to wait for the current Master to timeout.
>
> This is one way I think if the master router gracefully indicates
> the other routers in the network.
>
> Regards
> Arnab
>
> 2009/7/6 <liu.zhiwei1@zte.com.cn <mailto:liu.zhiwei1@zte.com.cn> >
>
>
> Dear All
>
> I'm a new comer in IETF.
>
> VRRP [RFC 3768] specifies an election protocol that dynamically
> assigns responsibility for a virtual router to one of the VRRP routers on a
> LAN.
> This election process provides dynamic fail over in the forwarding
> responsibility should the Master become unavailable.
>
> The router survivability capability provided by the Virtual Router
> Redundancy Protocol requirement: (3 * Master_Adver_Interval) + Skew_timer
> for Backup Router to declare Masterdown in the VRRP [RFC 3768].
> It will be more than 3 second when the Master_Adver_Interval was 1
> second.
> In some LAN environments, the Backup Router needs faster method to
> declare the Master Router is fail.
> As if (2 * Master_Adver_Interval) + Skew_timer or (1 *
> Master_Adver_Interval) + Skew_timer.
> Are there a message type which permits the Backup Router could
> backup faster?
>
> Best Regards
>
>
>
> Dash Liu???????ID: 183475
> Chief Engineer Office, Standard Development and Industry Relations
> Product Marketing System
> ??????
> D206, 889, Bibo Road,ZhangJiang, Pudong District, ShangHai P.R.China,
> 210023
> Tel:+86-21-68896823/ 13701767991
> Mobile:+86-13828760990
> Email:liu.zhiwei1@zte.com.cn <Email%3Aliu.zhiwei1@zte.com.cn> <mailto:
> Email%3Aliu.zhiwei1@zte.com.cn <Email%253Aliu.zhiwei1@zte.com.cn>>
>
>
>
>
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org <mailto:vrrp@ietf.org>
> https://www.ietf.org/mailman/listinfo/vrrp <
> https://www.ietf.org/mailman/listinfo/vrrp>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment.htm
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/jpeg
> Size: 5863 bytes
> Desc: ATT2437946.jpg
> Url : <
> http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment.jpeg
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/jpeg
> Size: 2476 bytes
> Desc: ATT2437947.jpg
> Url : <
> http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment-0001.jpeg
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/jpeg
> Size: 5863 bytes
> Desc: ATT2437948.jpg
> Url : <
> http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment-0002.jpeg
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/jpeg
> Size: 2476 bytes
> Desc: ATT2437949.jpg
> Url : <
> http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment-0003.jpeg
> >
>
> ------------------------------
>
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
>
>
> End of vrrp Digest, Vol 53, Issue 4
> ***********************************
>
[Attachment #5 (text/html)]
<div class="gmail_quote"><div>Hi,<br><br>If the router supports BFD (Bidirectional \
Forwarding Detection), then with the help of BFD configured for VRRP, when master \
fails,<br> the backup can become master in few milliseconds than in \
seconds.<br><br>Regards,<br>Karthik<br><br><br></div><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;">
----------------------------------------------------------------------
<br>
Message: 1<br>
Date: Tue, 7 Jul 2009 11:02:58 -0500<br>
From: "Stephen Nadas" <<a \
href="mailto:stephen.nadas@ericsson.com">stephen.nadas@ericsson.com</a>><br>
Subject: Re: [VRRP] ??: Re: vrrp faster backup<br>
To: <<a href="mailto:liu.zhiwei1@zte.com.cn">liu.zhiwei1@zte.com.cn</a>>, \
"Arnab Bakshi" <<a \
href="mailto:arnab.bakshi@gmail.com">arnab.bakshi@gmail.com</a>><br>
Cc: <a href="mailto:vrrp@ietf.org">vrrp@ietf.org</a><br>
Message-ID:<br>
<<a href="mailto:DF78BDF6956FDD4780D5DAD88A073CF4025C71B7@eusrcmw720.eamcs. \
ericsson.se">DF78BDF6956FDD4780D5DAD88A073CF4025C71B7@eusrcmw720.eamcs.ericsson.se</a>><br>
<br>
Content-Type: text/plain; charset="gb2312"<br>
<br>
Hi,<br>
<br>
If I understand the original question properly, the question is how, under expected \
failure scenarios, can backup take over of the master in less than 3 seconds. This \
has been discussed at some length on the mailing list (which you may wish to review) \
and please see also latest draft: draft-ietf-vrrp-unified-spec-03 which should \
appear in the repository soon. The draft discusses this issue.<br>
<br>
Regards,<br>
Steve<br>
<br>
<br>
________________________________<br>
<br>
From: <a href="mailto:vrrp-bounces@ietf.org">vrrp-bounces@ietf.org</a> \
[mailto:<a href="mailto:vrrp-bounces@ietf.org">vrrp-bounces@ietf.org</a>] On Behalf \
Of <a href="mailto:liu.zhiwei1@zte.com.cn">liu.zhiwei1@zte.com.cn</a><br>
Sent: Tuesday, July 07, 2009 11:16 AM<br>
To: Arnab Bakshi<br>
Cc: <a href="mailto:vrrp@ietf.org">vrrp@ietf.org</a><br>
Subject: [VRRP] ??: Re: vrrp faster backup<br>
<br>
<br>
<br>
Dear Arnab<br>
<br>
Thanks for your feedback.<br>
Then when the priority value isn't zero, the Backup Router should waiting \
the Master Router time out.<br> Are they any other way when priority isn't \
zero?<br> <br>
Best Regards<br>
<br>
<br>
<br>
<br>
Dash Liu???????ID: 183475<br>
Chief Engineer Office, Standard Development and Industry Relations<br>
Product Marketing System<br>
??????<br>
D206, 889, Bibo Road,ZhangJiang, Pudong District, ShangHai P.R.China, 210023<br>
Tel:+86-21-68896823/ 13701767991<br>
Mobile:+86-13828760990<br>
<a href="mailto:Email%3Aliu.zhiwei1@zte.com.cn">Email:liu.zhiwei1@zte.com.cn</a><br>
<br>
<br>
<br>
<br>
<br>
Arnab Bakshi <<a href="mailto:arnab.bakshi@gmail.com">arnab.bakshi@gmail.com</a>><br>
<br>
2009-07-06 20:52<br>
<br>
???<br>
<a href="mailto:liu.zhiwei1@zte.com.cn">liu.zhiwei1@zte.com.cn</a>, <a \
href="mailto:vrrp@ietf.org">vrrp@ietf.org</a><br> ??<br>
??<br>
Re: [VRRP] vrrp faster backup<br>
<br>
<br>
<br>
<br>
<br>
<br>
Hi Liu,<br>
<br>
As per RFC 3768, section 5.3.4 page 12:<br>
The priority value zero (0) has special meaning indicating that the<br>
current Master has stopped participating in VRRP. This is used to<br>
trigger Backup routers to quickly transition to Master without having<br>
to wait for the current Master to timeout.<br>
<br>
This is one way I think if the master router gracefully indicates the other \
routers in the network.<br> <br>
Regards<br>
Arnab<br>
<br>
2009/7/6 <<a \
href="mailto:liu.zhiwei1@zte.com.cn">liu.zhiwei1@zte.com.cn</a> <mailto:<a \
href="mailto:liu.zhiwei1@zte.com.cn">liu.zhiwei1@zte.com.cn</a>> ><br> <br>
<br>
Dear All<br>
<br>
I'm a new comer in IETF.<br>
<br>
VRRP [RFC 3768] specifies an election protocol that dynamically assigns \
responsibility for a virtual router to one of the VRRP routers on a \
LAN.<br>
This election process provides dynamic fail over in the forwarding \
responsibility should the Master become unavailable.<br> <br>
The router survivability capability provided by the Virtual Router Redundancy \
Protocol requirement: (3 * Master_Adver_Interval) + Skew_timer for Backup Router to \
declare Masterdown in the VRRP [RFC 3768].<br>
It will be more than 3 second when the Master_Adver_Interval was 1 \
second.<br>
In some LAN environments, the Backup Router needs faster method to declare \
the Master Router is fail.<br>
As if (2 * Master_Adver_Interval) + Skew_timer or (1 * Master_Adver_Interval) \
+ Skew_timer.<br>
Are there a message type which permits the Backup Router could backup \
faster?<br> <br>
Best Regards<br>
<br>
<br>
<br>
Dash Liu???????ID: 183475<br>
Chief Engineer Office, Standard Development and Industry Relations<br>
Product Marketing System<br>
??????<br>
D206, 889, Bibo Road,ZhangJiang, Pudong District, ShangHai P.R.China, 210023<br>
Tel:+86-21-68896823/ 13701767991<br>
Mobile:+86-13828760990<br>
<a href="mailto:Email%3Aliu.zhiwei1@zte.com.cn">Email:liu.zhiwei1@zte.com.cn</a> \
<mailto:<a href="mailto:Email%253Aliu.zhiwei1@zte.com.cn">Email%3Aliu.zhiwei1@zte.com.cn</a>><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
vrrp mailing list<br>
<a href="mailto:vrrp@ietf.org">vrrp@ietf.org</a> <mailto:<a \
href="mailto:vrrp@ietf.org">vrrp@ietf.org</a>><br> <a \
href="https://www.ietf.org/mailman/listinfo/vrrp" \
target="_blank">https://www.ietf.org/mailman/listinfo/vrrp</a> <<a \
href="https://www.ietf.org/mailman/listinfo/vrrp" \
target="_blank">https://www.ietf.org/mailman/listinfo/vrrp</a>><br>
<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment.htm" \
target="_blank">http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment.htm</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: image/jpeg<br>
Size: 5863 bytes<br>
Desc: ATT2437946.jpg<br>
Url : <<a href="http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment.jpeg" \
target="_blank">http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment.jpeg</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: image/jpeg<br>
Size: 2476 bytes<br>
Desc: ATT2437947.jpg<br>
Url : <<a href="http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment-0001.jpeg" \
target="_blank">http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment-0001.jpeg</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: image/jpeg<br>
Size: 5863 bytes<br>
Desc: ATT2437948.jpg<br>
Url : <<a href="http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment-0002.jpeg" \
target="_blank">http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment-0002.jpeg</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: image/jpeg<br>
Size: 2476 bytes<br>
Desc: ATT2437949.jpg<br>
Url : <<a href="http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment-0003.jpeg" \
target="_blank">http://www.ietf.org/mail-archive/web/vrrp/attachments/20090707/1a92030d/attachment-0003.jpeg</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
vrrp mailing list<br>
<a href="mailto:vrrp@ietf.org">vrrp@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/vrrp" \
target="_blank">https://www.ietf.org/mailman/listinfo/vrrp</a><br> <br>
<br>
End of vrrp Digest, Vol 53, Issue 4<br>
***********************************<br>
</blockquote></div><br>
_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic