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 at ericsson.com>
Subject: Re: [VRRP] ??: Re: vrrp faster backup
To: <liu.zhiwei1 at zte.com.cn>, "Arnab Bakshi" <arnab.bakshi at gmail.com>
Cc: vrrp at ietf.org
Message-ID:
<DF78BDF6956FDD4780D5DAD88A073CF4025C71B7 at 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 at ietf.org [mailto:vrrp-bounces at ietf.org] On Behalf Of liu.zhiwei1 at zte.com.cn
Sent: Tuesday, July 07, 2009 11:16 AM
To: Arnab Bakshi
Cc: vrrp at 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 at zte.com.cn
Arnab Bakshi <arnab.bakshi at gmail.com>
2009-07-06 20:52
???
liu.zhiwei1 at zte.com.cn, vrrp at 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 at zte.com.cn <mailto:liu.zhiwei1 at 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 at zte.com.cn <mailto:Email%3Aliu.zhiwei1 at zte.com.cn>
_______________________________________________
vrrp mailing list
vrrp at ietf.org <mailto:vrrp at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
End of vrrp Digest, Vol 53, Issue 4
***********************************