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

["Stephen Nadas" <[e-mail]>]

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