[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [VRRP] ??: Re: vrrp faster backup
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: vrrp-bounces at ietf.org [mailto:vrrp-bounces at ietf.org] On
Behalf Of Karthik
Sent: Wednesday, July 08, 2009 3:59 AM
To: vrrp at ietf.org
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, <vrrp-request at ietf.org> 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
vrrp at ietf.org
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
vrrp-request at ietf.org
You can reach the person managing the list at
vrrp-owner at ietf.org
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" <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
<mailto:Email%3Aliu.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>
<mailto:Email%3Aliu.zhiwei1 at zte.com.cn
<mailto:Email%253Aliu.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
***********************************