Re: vrrp Digest, Vol 53, Issue 4

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" <[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] <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] <Email%[email protected]> <mailto:
> Email%[email protected] <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