Re: ??: Re: vrrp faster backup
"Stephen Nadas" <[email protected]> Wed, 8 Jul 2009 06:34:44 -0500
| Newsgroups | gmane.ietf.vrrp |
|---|---|
| Message-ID | <DF78BDF6956FDD4780D5DAD88A073CF402600F25@eusrcmw720.eamcs.ericsson.se> |
Hi Karthik, Yes, I believe this is possible in some implementation. However, I think what you describe depends on implementation of functionality that is outside the standardized functionality. YMMV. Thanks, Steve ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Karthik Sent: Wednesday, July 08, 2009 3:59 AM To: [email protected] Subject: Re: [VRRP] ??: Re: vrrp faster backup sent with subject changed 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 On Tue, Jul 7, 2009 at 9:34 PM, <[email protected]> wrote: If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/vrrp Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send vrrp mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/vrrp or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of vrrp digest..." Today's Topics: 1. Re: ??: Re: vrrp faster backup (Stephen Nadas) ---------------------------------------------------------------------- Message: 1 Date: Tue, 7 Jul 2009 11:02:58 -0500 From: "Stephen Nadas" <[email protected]> Subject: Re: [VRRP] ??: Re: vrrp faster backup To: <[email protected]>, "Arnab Bakshi" <[email protected]> Cc: [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, July 07, 2009 11:16 AM To: Arnab Bakshi Cc: [email protected] 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:[email protected] <mailto:Email%[email protected]> Arnab Bakshi <[email protected]> 2009-07-06 20:52 ??? [email protected], [email protected] ?? ?? 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 <[email protected] <mailto:[email protected]> > 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:[email protected] <mailto:Email%[email protected]> <mailto:Email%[email protected] <mailto:Email%[email protected]> > _______________________________________________ vrrp mailing list [email protected] <mailto:[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/vrrp End of vrrp Digest, Vol 53, Issue 4 *********************************** _______________________________________________ vrrp mailing list [email protected] https://www.ietf.org/mailman/listinfo/vrrp