headers
Kalyan.Tata | 11 Mar 2009 01:15
Picon

draft-ietf-vrrp-unified-mib-07 - deprecating vrrpTrapNewMaster

Hi,
	I started working on the new draft for the unified VRRP MIB. 
	One of the todo items was to change the vrrpTrapNewMaster. 
	Following is the mail I sent some time back - Resending this to
	see if I get any input before I change this in version 7 of the
draft:

I would like some working group opinion on deprecating vrrpTrapNewMaster
and adding vrrpStateChange notification.

Request from Carl Kalbfleisch  :
--------
 is it possible to add a vrrpStateChange notification or a notification
for each state. Our requirements require notification from a device when
it EXITS master state. Currently the vrrpTrapNewMaster only indicates
when the system goes into the master state. Having an indication of
backup and initialization states as notifications allows the management
station to correlate when the state changes without polling. 

Proposed :
--
vrrpStateChange NOTIFICATION-TYPE

OBJECTS { vrrpOperationsMasterIpAddr, vrrpOperationsState,
vrrpStateChangeReason }

STATUS current

DESCRIPTION
(Continue reading)

Permalink | Reply | 3 comments |
headers
DingYe | 13 Mar 2009 01:54
Picon
Favicon

question on VRRP

Just curious how does following topology work with VRRP?
Ra/Rb are two routers using VRRP; Sa/Sb are two switches; host a, b c.
initially both a and b communites to c through Ra; then how does VRRP know if Sa failed, Rb will take over; if Sb failed, Ra will still carry the traffic. If Ra does not receive any ack from Rb, how can it figure out if it is Sa or Sb that has problem? Thanks, Ye.
         c
      /      \
    Ra      Rb
    |         |
    Sa----Sb
     |\      /|
     a b    a b         
   
把MSN装进手机，更多聊天乐趣等你挖掘！ 立刻下载！ 
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 1 comment |
headers
Joan Cucchiara | 13 Mar 2009 14:32
Picon

Re: draft-ietf-vrrp-unified-mib-07 - deprecatingvrrpTrapNewMaster


----- Original Message ----- 
From: <Kalyan.Tata <at> nokia.com>
To: <vrrp <at> ietf.org>
Sent: Tuesday, March 10, 2009 7:15 PM
Subject: [VRRP] draft-ietf-vrrp-unified-mib-07 - 
deprecatingvrrpTrapNewMaster

> Hi,
> I started working on the new draft for the unified VRRP MIB.
> One of the todo items was to change the vrrpTrapNewMaster.
> Following is the mail I sent some time back - Resending this to
> see if I get any input before I change this in version 7 of the
> draft:
>
>
> I would like some working group opinion on deprecating vrrpTrapNewMaster
> and adding vrrpStateChange notification.

I would be in favor of this.  As Carl states below, being able to correlate 
the state
changes would  be beneficial.

>
> Request from Carl Kalbfleisch  :
> --------
> is it possible to add a vrrpStateChange notification or a notification
> for each state. Our requirements require notification from a device when
> it EXITS master state. Currently the vrrpTrapNewMaster only indicates
> when the system goes into the master state. Having an indication of
> backup and initialization states as notifications allows the management
> station to correlate when the state changes without polling.
>
> Proposed :
> --
> vrrpStateChange NOTIFICATION-TYPE
>
> OBJECTS { vrrpOperationsMasterIpAddr, vrrpOperationsState,
> vrrpStateChangeReason }
>
> STATUS current
>
> DESCRIPTION
>
> "Notification of VRRP state change."
>
> ::= { vrrpNotifications 4 }
> --
>
> Will it be useful to include a previous state in the notification?
>

If the NMS missed one notification (i.e. a state change) then this
might be useful, but if more than one notification (i.e. few state changes) 
were
missed, then this might be more confusing.

The alternative is that informs be used instead of notifications, or that 
the NMS
poll for the info, or that the NMS be smart enough to deal with missed state 
change within the
its correlation (which it probably needs to do even if using informs or 
polling).

So, I would say sending the previous state doesn't hurt, but may not help 
too much.

Thanks,
   -Joan

> ===
>
> Thanks,
> Kalyan
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp 

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 2 comments |
headers
Kalyan.Tata | 16 Mar 2009 23:08
Picon

Re: draft-ietf-vrrp-unified-mib-07 - deprecatingvrrpTrapNewMaster

Thanks Joan. I deprecated vrrpTrapNewMaster in favor of vrrpStateChange
notification.

>>
>> Will it be useful to include a previous state in the notification?
>>
>
>If the NMS missed one notification (i.e. a state change) then this
>might be useful, but if more than one notification (i.e. few 
>state changes) 
>were
>missed, then this might be more confusing.
>
>The alternative is that informs be used instead of 
>notifications, or that 
>the NMS
>poll for the info, or that the NMS be smart enough to deal 
>with missed state 
>change within the
>its correlation (which it probably needs to do even if using 
>informs or 
>polling).
>
>So, I would say sending the previous state doesn't hurt, but 
>may not help 
>too much.

I agree, previous state may not be useful. 
I will send a separate email regarding VRRPstateChangeReason that should
be included in the notification.

Thanks
Kalyan
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Kalyan.Tata | 17 Mar 2009 01:33
Picon

draft-ietf-vrrp-unified-mib-07 - vrrpOperationsStateChangeReason


Hi,
	Following are the enumerations for the
vrrpOperationsStateChangeReason.

Prev State  New State   Reason
==================================

Initialize  Master      addressOwner (0)
Initialize  Backup      notAddressOwner (1) 

Master      Backup      higherPriorityAdvtRcvd (2)  higherPrimeryAddress
(3)
Master      Initialize  shutdownReceived 	(5)

Backup      Master      masterDownTimerExpired (4)
Backup      Initialize  shutdownReceived 	(5)

Please let me know if I missed something.	

Thanks,
Kalyan

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Mukesh Gupta | 22 Mar 2009 01:08
Favicon

Re: question on VRRP

Hi,

 

I don’t understand why a and b are connected to Sa and Sb in your picture.

 

If Sa failed, Rb, which should be operating in the Backup state before the failure of Sa, will stop getting the VRRP advertisements from Ra and after the Master_Down_Timer fires, Rb will take over as the Master. Note that Rb does not require any ack from Ra.

 

- Mukesh

 

From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of DingYe
Sent: Thursday, March 12, 2009 5:55 PM
To: vrrp <at> ietf.org
Subject: [VRRP] question on VRRP

 

Just curious how does following topology work with VRRP?
Ra/Rb are two routers using VRRP; Sa/Sb are two switches; host a, b c.
initially both a and b communites to c through Ra; then how does VRRP know if Sa failed, Rb will take over; if Sb failed, Ra will still carry the traffic. If Ra does not receive any ack from Rb, how can it figure out if it is Sa or Sb that has problem? Thanks, Ye.
         c
      /      \
    Ra      Rb
    |         |
    Sa----Sb
     |\      /|
     a b    a b         
   

把MSN装进手机，更多聊天乐趣等你挖掘！ 立刻下载！

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |

Gmane