Subject: Re: [VRRP] ??: Re: vrrp faster backup

From: Karthik <[email-masked]>
Date: Wed, 8 Jul 2009 13:29:04 +0530

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-masked]> 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-masked]
>
> 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-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> 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-masked]>
> Subject: Re: [VRRP] ??: Re:  vrrp faster backup
> To: <[email-masked]>, "Arnab Bakshi" <[email-masked]>
> Cc: [email-masked]
> Message-ID:
>        <
> [email-masked]>
>
> 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-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
>        Sent: Tuesday, July 07, 2009 11:16 AM
>        To: Arnab Bakshi
>        Cc: [email-masked]
>        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-masked] <[email-masked]>
>
>
>
>
>
> Arnab Bakshi <[email-masked]>
>
> 2009-07-06 20:52
>
> ???
> [email-masked], [email-masked]
> ??
> ??
> 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-masked] <mailto:[email-masked]> >
>
>
>        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-masked] <[email-masked]> <mailto:
> [email-masked] <[email-masked]>>
>
>
>
>
>        _______________________________________________
>        vrrp mailing list
>        [email-masked] <mailto:[email-masked]>
>        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-masked]
> https://www.ietf.org/mailman/listinfo/vrrp
>
>
> End of vrrp Digest, Vol 53, Issue 4
> ***********************************
>

---

From: "Stephen Nadas" <[email-masked]>
Date: Wed, 8 Jul 2009 06:34:44 -0500

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-masked] [mailto:[email-masked]] On
Behalf Of Karthik
	Sent: Wednesday, July 08, 2009 3:59 AM
	To: [email-masked]
	Subject: Re: [VRRP] ??: Re: vrrp faster backup

	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

		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

		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.

		
		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-masked]

		When replying, please edit your Subject line so it is
more specific
		than "Re: Contents of vrrp digest..."

		Today's Topics:

	
		
		Message: 1
		Date: Tue, 7 Jul 2009 11:02:58 -0500
		From: "Stephen Nadas" <[email-masked]>
		Subject: Re: [VRRP] ??: Re:  vrrp faster backup
		To: <[email-masked]>, "Arnab Bakshi"
<[email-masked]>
		Cc: [email-masked]
		Message-ID:
	
<[email-masked]>

		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-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
		       Sent: Tuesday, July 07, 2009 11:16 AM
		       To: Arnab Bakshi
		       Cc: [email-masked]
		       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-masked]
<mailto:[email-masked]> 

		
		2009-07-06 20:52
		
		???

		
		       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-masked]
<mailto:[email-masked]> >

		       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-masked]
<mailto:[email-masked]>
<mailto:[email-masked]
<mailto:[email-masked]> >

		
		       _______________________________________________
		       vrrp mailing list
		       [email-masked] <mailto:[email-masked]>
		       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>