VRRP - Multiple Masters Question

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: VRRP - Multiple Masters Question

I agree with you that protocols should be resilient to configuration 
differences between nodes,
and I think the ideal solution is what you suggested (use the timer as 
advertised by the master)
rather than what's in the spec (discard messages that disagree with your 
setting, so that
multiple masters will be elected, ignoring each others' messages). 
Especially in conjunction with
bridges, multiple masters are dangerous.

This was brought up on the mailing list before I was watching this 
group, and somehow
the discussion fizzled out. I think the subsecond timer draft is a good 
excuse to revisit this,
and make sure, if the WG really wants to keep the behavior as it is, 
that it is doing it
consciously.

So please, people, speak up about which behavior you prefer:

a) discard (and log an error) if the value advertised in the VRRP 
message disagrees with your
configured value for hello timer....this is what is currently specified
b) use the interval advertised by the master, for as long as it is master

If we switch to b), then another decision is whether that is configured 
misconfiguration or not,
i.e., if an error should be logged.

Radia

Hott, Robert W CIV B35-Branch wrote:

> I am in the process of updating a draft for sub-second timers for VRRP 
> for IPv4. An area that I have struggled with has been how to deal with 
> legacy devices that might be on a network with devices that use 
> sub-second timers. In thinking out this issue for this new draft, I 
> noticed something that seems to a problem with the current RFC. The 
> interesting area in RFC 3768 is section 7.1 on receiving VRRP packets.
>
> The issue is this. Suppose that I have a master router configured with 
> an advertisement interval of 1 second. I have two more routers 
> configured as backups. One is configured with an advertisement 
> interval of 2 seconds and another is configured with an advertisement 
> interval of 3 seconds.
>
> I know that this is problematic but it could happen. Anyway, the 
> master would send an advertisement. Based upon section 7.1, both of 
> the backups would discard this advertisement and would report the 
> misconfiguration. Since the advertisement would be discarded, both 
> would eventually transition to masters. The end result would be three 
> masters, since the state machine would not act on the advertisement.
>
> Did I interpret this correctly? I would think that you would not want 
> to discard the advertisement because of the wrong setting. I would 
> think you would want to use the interval of the master, at least until 
> you assume the role of the master.
>
> Bob Hott
>
> *Robert (Bob) W. Hott*
> *NSWC-DD*
> *Code B35, Bldg. 1500A/122A*
> *17320 Dahlgren Road*
> *Dahlgren, VA 22448-5100*
> *540-653-1497 (W)*
> *540-653-8673 (FAX)*
> *robert.hott <at> navy.mil (E-mail)*
>
>------------------------------------------------------------------------
>
>_______________________________________________
>vrrp mailing list
>vrrp <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/vrrp
>  
>

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

RE: VRRP - Multiple Masters Question

Here are the comments I put in my implementation. The summary is
that I slow down my timer if I hear from a higher priority system
with a slower interval. All other cases (I claim) aren't an issue.
This is the last step in packet validation:

 /* MUST verify that the Adver Interval in the packet is the same as
 ** the locally configured for this virtual router */
 /* OK, that's what the spec says, but actually it makes very
  * little sense: all it does is insure the two routers with
  * different times argue over the MAC address, etc., while
  * ignoring each other's packets. Notice that this would
  * happen while the time was being reconfigured on multiple
  * systems. So I ignore that requirement, and instead take his
  * timer value if it's larger than mine and he has higher
  * priority. (If I have higher priority, I continue using my
  * own time: I shouldn't have heard from him, anyway.) note
  * that we're checking against our configured interval, not
  * this entry's interval: this entry could have been
  * previously slowed down, only to be speeded up again
  * (possibly already the way to our configured interval, hence
  * the greater than *or equal to*).
  */
 vrrp_interval = VRRP_TIME_TO_MS( vrrp->adver_int );
 if ( ( vrrp_interval != entry->adver_int )
      && ( vrrp_interval >= vrrpd_adver_int )
      && ( vrrp->priority > entry->priority ) )
 { /* he's better than me, so just use his advertisement
    * interval, automatically changing the down interval.
    * (if he's running faster than us, it's not an issue,
    * which is good because we don't want to change our
    * scheduling rate. if he ever gets set to a lower
    * value, we'll see it and adjust again, possibly
    * making it back down to our own value (although
    * we'll never explicitly notice that.)
    */
   entry->adver_int = vrrp_interval;
 }

-don

> -----Original Message-----
> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org]On Behalf Of
> Radia Perlman
> Sent: Friday, December 02, 2005 1:05 PM
> To: Hott, Robert W CIV B35-Branch
> Cc: Chappell, Brett L CIV B35-Branch; Odonoghue,Karen F CIV 
> B35-Branch;
> Plunkett,Timothy R CIV B35-Branch; vrrp <at> ietf.org
> Subject: Re: [VRRP] VRRP - Multiple Masters Question
> 
> 
> I agree with you that protocols should be resilient to configuration 
> differences between nodes,
> and I think the ideal solution is what you suggested (use the 
> timer as 
> advertised by the master)
> rather than what's in the spec (discard messages that 
> disagree with your 
> setting, so that
> multiple masters will be elected, ignoring each others' messages). 
> Especially in conjunction with
> bridges, multiple masters are dangerous.
> 
> This was brought up on the mailing list before I was watching this 
> group, and somehow
> the discussion fizzled out. I think the subsecond timer draft 
> is a good 
> excuse to revisit this,
> and make sure, if the WG really wants to keep the behavior as it is, 
> that it is doing it
> consciously.
> 
> So please, people, speak up about which behavior you prefer:
> 
> a) discard (and log an error) if the value advertised in the VRRP 
> message disagrees with your
> configured value for hello timer....this is what is currently 
> specified
> b) use the interval advertised by the master, for as long as 
> it is master
> 
> If we switch to b), then another decision is whether that is 
> configured 
> misconfiguration or not,
> i.e., if an error should be logged.
> 
> Radia
> 
> 
> 
> 
> 
> Hott, Robert W CIV B35-Branch wrote:
> 
> > I am in the process of updating a draft for sub-second 
> timers for VRRP 
> > for IPv4. An area that I have struggled with has been how 
> to deal with 
> > legacy devices that might be on a network with devices that use 
> > sub-second timers. In thinking out this issue for this new draft, I 
> > noticed something that seems to a problem with the current RFC. The 
> > interesting area in RFC 3768 is section 7.1 on receiving 
> VRRP packets.
> >
> > The issue is this. Suppose that I have a master router 
> configured with 
> > an advertisement interval of 1 second. I have two more routers 
> > configured as backups. One is configured with an advertisement 
> > interval of 2 seconds and another is configured with an 
> advertisement 
> > interval of 3 seconds.
> >
> > I know that this is problematic but it could happen. Anyway, the 
> > master would send an advertisement. Based upon section 7.1, both of 
> > the backups would discard this advertisement and would report the 
> > misconfiguration. Since the advertisement would be discarded, both 
> > would eventually transition to masters. The end result 
> would be three 
> > masters, since the state machine would not act on the advertisement.
> >
> > Did I interpret this correctly? I would think that you 
> would not want 
> > to discard the advertisement because of the wrong setting. I would 
> > think you would want to use the interval of the master, at 
> least until 
> > you assume the role of the master.
> >
> > Bob Hott
> >
> > *Robert (Bob) W. Hott*
> > *NSWC-DD*
> > *Code B35, Bldg. 1500A/122A*
> > *17320 Dahlgren Road*
> > *Dahlgren, VA 22448-5100*
> > *540-653-1497 (W)*
> > *540-653-8673 (FAX)*
> > *robert.hott <at> navy.mil (E-mail)*
> >
> >-------------------------------------------------------------
> -----------
> >
> >_______________________________________________
> >vrrp mailing list
> >vrrp <at> ietf.org
> >https://www1.ietf.org/mailman/listinfo/vrrp

> >  
> >
> 
> 
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: VRRP - Multiple Masters Question

I like Don's interpretation, and his implementation should be compatible 
with stations
that follow the spec, but it seems better to have the spec reflect what 
the WG wants
rather than implementations diverging from the spec. So I'd hope, if the 
WG likes
this interpretation, that we change the spec.

Also, I suppose there's another choice to be made:

If an implementation "uses" the master's interval, does that mean it 
overwrites what it has
been configured with? I assume not...i.e., if you temporarily bring up a 
master with
a short timer, once that master goes away, the other nodes will revert 
to their old value, right?

Radia

Don Provan wrote:

>Here are the comments I put in my implementation. The summary is
>that I slow down my timer if I hear from a higher priority system
>with a slower interval. All other cases (I claim) aren't an issue.
>This is the last step in packet validation:
>
> /* MUST verify that the Adver Interval in the packet is the same as
> ** the locally configured for this virtual router */
> /* OK, that's what the spec says, but actually it makes very
>  * little sense: all it does is insure the two routers with
>  * different times argue over the MAC address, etc., while
>  * ignoring each other's packets. Notice that this would
>  * happen while the time was being reconfigured on multiple
>  * systems. So I ignore that requirement, and instead take his
>  * timer value if it's larger than mine and he has higher
>  * priority. (If I have higher priority, I continue using my
>  * own time: I shouldn't have heard from him, anyway.) note
>  * that we're checking against our configured interval, not
>  * this entry's interval: this entry could have been
>  * previously slowed down, only to be speeded up again
>  * (possibly already the way to our configured interval, hence
>  * the greater than *or equal to*).
>  */
> vrrp_interval = VRRP_TIME_TO_MS( vrrp->adver_int );
> if ( ( vrrp_interval != entry->adver_int )
>      && ( vrrp_interval >= vrrpd_adver_int )
>      && ( vrrp->priority > entry->priority ) )
> { /* he's better than me, so just use his advertisement
>    * interval, automatically changing the down interval.
>    * (if he's running faster than us, it's not an issue,
>    * which is good because we don't want to change our
>    * scheduling rate. if he ever gets set to a lower
>    * value, we'll see it and adjust again, possibly
>    * making it back down to our own value (although
>    * we'll never explicitly notice that.)
>    */
>   entry->adver_int = vrrp_interval;
> }
>
>-don
>
>  
>
>>-----Original Message-----
>>From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org]On Behalf Of
>>Radia Perlman
>>Sent: Friday, December 02, 2005 1:05 PM
>>To: Hott, Robert W CIV B35-Branch
>>Cc: Chappell, Brett L CIV B35-Branch; Odonoghue,Karen F CIV 
>>B35-Branch;
>>Plunkett,Timothy R CIV B35-Branch; vrrp <at> ietf.org
>>Subject: Re: [VRRP] VRRP - Multiple Masters Question
>>
>>
>>I agree with you that protocols should be resilient to configuration 
>>differences between nodes,
>>and I think the ideal solution is what you suggested (use the 
>>timer as 
>>advertised by the master)
>>rather than what's in the spec (discard messages that 
>>disagree with your 
>>setting, so that
>>multiple masters will be elected, ignoring each others' messages). 
>>Especially in conjunction with
>>bridges, multiple masters are dangerous.
>>
>>This was brought up on the mailing list before I was watching this 
>>group, and somehow
>>the discussion fizzled out. I think the subsecond timer draft 
>>is a good 
>>excuse to revisit this,
>>and make sure, if the WG really wants to keep the behavior as it is, 
>>that it is doing it
>>consciously.
>>
>>So please, people, speak up about which behavior you prefer:
>>
>>a) discard (and log an error) if the value advertised in the VRRP 
>>message disagrees with your
>>configured value for hello timer....this is what is currently 
>>specified
>>b) use the interval advertised by the master, for as long as 
>>it is master
>>
>>If we switch to b), then another decision is whether that is 
>>configured 
>>misconfiguration or not,
>>i.e., if an error should be logged.
>>
>>Radia
>>
>>
>>
>>
>>
>>Hott, Robert W CIV B35-Branch wrote:
>>
>>    
>>
>>>I am in the process of updating a draft for sub-second 
>>>      
>>>
>>timers for VRRP 
>>    
>>
>>>for IPv4. An area that I have struggled with has been how 
>>>      
>>>
>>to deal with 
>>    
>>
>>>legacy devices that might be on a network with devices that use 
>>>sub-second timers. In thinking out this issue for this new draft, I 
>>>noticed something that seems to a problem with the current RFC. The 
>>>interesting area in RFC 3768 is section 7.1 on receiving 
>>>      
>>>
>>VRRP packets.
>>    
>>
>>>The issue is this. Suppose that I have a master router 
>>>      
>>>
>>configured with 
>>    
>>
>>>an advertisement interval of 1 second. I have two more routers 
>>>configured as backups. One is configured with an advertisement 
>>>interval of 2 seconds and another is configured with an 
>>>      
>>>
>>advertisement 
>>    
>>
>>>interval of 3 seconds.
>>>
>>>I know that this is problematic but it could happen. Anyway, the 
>>>master would send an advertisement. Based upon section 7.1, both of 
>>>the backups would discard this advertisement and would report the 
>>>misconfiguration. Since the advertisement would be discarded, both 
>>>would eventually transition to masters. The end result 
>>>      
>>>
>>would be three 
>>    
>>
>>>masters, since the state machine would not act on the advertisement.
>>>
>>>Did I interpret this correctly? I would think that you 
>>>      
>>>
>>would not want 
>>    
>>
>>>to discard the advertisement because of the wrong setting. I would 
>>>think you would want to use the interval of the master, at 
>>>      
>>>
>>least until 
>>    
>>
>>>you assume the role of the master.
>>>
>>>Bob Hott
>>>
>>>*Robert (Bob) W. Hott*
>>>*NSWC-DD*
>>>*Code B35, Bldg. 1500A/122A*
>>>*17320 Dahlgren Road*
>>>*Dahlgren, VA 22448-5100*
>>>*540-653-1497 (W)*
>>>*540-653-8673 (FAX)*
>>>*robert.hott <at> navy.mil (E-mail)*
>>>
>>>-------------------------------------------------------------
>>>      
>>>
>>-----------
>>    
>>
>>>_______________________________________________
>>>vrrp mailing list
>>>vrrp <at> ietf.org
>>>https://www1.ietf.org/mailman/listinfo/vrrp
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>vrrp mailing list
>>vrrp <at> ietf.org
>>https://www1.ietf.org/mailman/listinfo/vrrp
>>    
>>

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: VRRP - Multiple Masters Question

> a) discard (and log an error) if the value advertised 
>    in the VRRP message disagrees with your configured 
>    value for hello timer.... this is what is currently
>    specified
> 
> b) use the interval advertised by the master, for as long 
>    as it is master

I would vote for option b.

> If we switch to b), then another decision is whether that 
> is configured misconfiguration or not, i.e., if an error 
> should be logged.

Yes !

Is there any case where having different advertisement intervals
on different nodes will be useful?  If not, it should be considered
a misconfiguration but handled gracefully !

We are waiting for another update of the VRRP for IPv6 draft
to address IESG's comments.  We still have some time to pitch
in this change if the WG agrees to do this !

- Mukesh

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: VRRP - Multiple Masters Question

Radia,

On Fri, 2005-12-02 at 15:12 -0800, Radia Perlman wrote:
> I like Don's interpretation, and his implementation should be compatible 
> with stations
> that follow the spec, but it seems better to have the spec reflect what 
> the WG wants
> rather than implementations diverging from the spec. So I'd hope, if the 
> WG likes
> this interpretation, that we change the spec.

I agree !

> Also, I suppose there's another choice to be made:
> 
> If an implementation "uses" the master's interval, does that mean it 
> overwrites what it has
> been configured with? I assume not...i.e., if you temporarily bring up a 
> master with
> a short timer, once that master goes away, the other nodes will revert 
> to their old value, right?

No it does not make sense to overwrite what it has been configured with.
The node should keep using the master's interval till it
keeps hearing the master.  As soon as the master disappears, they
start using their configured advertisement interval.

Don, I am curious about why you didn't raise the issue and got
the spec fixed instead of deviating your implementation from
the spec :)

Regards
Mukesh

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

RE: VRRP - Multiple Masters Question

For the first point, the observation is that *nothing* can
make an implementation that follows the spec reasonable: it's
just *going* to fight. My implementation works fine with an
implementation following the spec if the other implementation
is higher priority, but it ignores the case where the other
implementation is lower priority because there's basically
nothing to be done about it.

But that really just reinforces the observation that the
spec should be changed (assuming we all agree this is
the correct approach).

As to the second choice, I actually decided to stay with
the slower tick rate even after I'm in charge just because
the worst that can happen is a subordinate ticking faster
than a master, and we know there's at least one master
ticking slower. But I'm not sure there are any specific
problems with going to our faster configured rate once
we're in charge, so I'm ok with that if no one else sees
any problems.

-don

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman <at> sun.com]
> Sent: Friday, December 02, 2005 3:13 PM
> To: Don Provan
> Cc: 'Hott, Robert W CIV B35-Branch'; 'Chappell, Brett L CIV 
> B35-Branch';
> 'Odonoghue,Karen F CIV B35-Branch'; 'Plunkett,Timothy R CIV 
> B35-Branch';
> vrrp <at> ietf.org
> Subject: Re: [VRRP] VRRP - Multiple Masters Question
> 
> 
> I like Don's interpretation, and his implementation should be 
> compatible 
> with stations
> that follow the spec, but it seems better to have the spec 
> reflect what 
> the WG wants
> rather than implementations diverging from the spec. So I'd 
> hope, if the 
> WG likes
> this interpretation, that we change the spec.
> 
> Also, I suppose there's another choice to be made:
> 
> If an implementation "uses" the master's interval, does that mean it 
> overwrites what it has
> been configured with? I assume not...i.e., if you temporarily 
> bring up a 
> master with
> a short timer, once that master goes away, the other nodes 
> will revert 
> to their old value, right?
> 
> Radia
> 
> Don Provan wrote:
> 
> >Here are the comments I put in my implementation. The summary is
> >that I slow down my timer if I hear from a higher priority system
> >with a slower interval. All other cases (I claim) aren't an issue.
> >This is the last step in packet validation:
> >
> > /* MUST verify that the Adver Interval in the packet is the same as
> > ** the locally configured for this virtual router */
> > /* OK, that's what the spec says, but actually it makes very
> >  * little sense: all it does is insure the two routers with
> >  * different times argue over the MAC address, etc., while
> >  * ignoring each other's packets. Notice that this would
> >  * happen while the time was being reconfigured on multiple
> >  * systems. So I ignore that requirement, and instead take his
> >  * timer value if it's larger than mine and he has higher
> >  * priority. (If I have higher priority, I continue using my
> >  * own time: I shouldn't have heard from him, anyway.) note
> >  * that we're checking against our configured interval, not
> >  * this entry's interval: this entry could have been
> >  * previously slowed down, only to be speeded up again
> >  * (possibly already the way to our configured interval, hence
> >  * the greater than *or equal to*).
> >  */
> > vrrp_interval = VRRP_TIME_TO_MS( vrrp->adver_int );
> > if ( ( vrrp_interval != entry->adver_int )
> >      && ( vrrp_interval >= vrrpd_adver_int )
> >      && ( vrrp->priority > entry->priority ) )
> > { /* he's better than me, so just use his advertisement
> >    * interval, automatically changing the down interval.
> >    * (if he's running faster than us, it's not an issue,
> >    * which is good because we don't want to change our
> >    * scheduling rate. if he ever gets set to a lower
> >    * value, we'll see it and adjust again, possibly
> >    * making it back down to our own value (although
> >    * we'll never explicitly notice that.)
> >    */
> >   entry->adver_int = vrrp_interval;
> > }
> >
> >-don
> >
> >  
> >
> >>-----Original Message-----
> >>From: vrrp-bounces <at> ietf.org 
> [mailto:vrrp-bounces <at> ietf.org]On Behalf Of
> >>Radia Perlman
> >>Sent: Friday, December 02, 2005 1:05 PM
> >>To: Hott, Robert W CIV B35-Branch
> >>Cc: Chappell, Brett L CIV B35-Branch; Odonoghue,Karen F CIV 
> >>B35-Branch;
> >>Plunkett,Timothy R CIV B35-Branch; vrrp <at> ietf.org
> >>Subject: Re: [VRRP] VRRP - Multiple Masters Question
> >>
> >>
> >>I agree with you that protocols should be resilient to 
> configuration 
> >>differences between nodes,
> >>and I think the ideal solution is what you suggested (use the 
> >>timer as 
> >>advertised by the master)
> >>rather than what's in the spec (discard messages that 
> >>disagree with your 
> >>setting, so that
> >>multiple masters will be elected, ignoring each others' messages). 
> >>Especially in conjunction with
> >>bridges, multiple masters are dangerous.
> >>
> >>This was brought up on the mailing list before I was watching this 
> >>group, and somehow
> >>the discussion fizzled out. I think the subsecond timer draft 
> >>is a good 
> >>excuse to revisit this,
> >>and make sure, if the WG really wants to keep the behavior 
> as it is, 
> >>that it is doing it
> >>consciously.
> >>
> >>So please, people, speak up about which behavior you prefer:
> >>
> >>a) discard (and log an error) if the value advertised in the VRRP 
> >>message disagrees with your
> >>configured value for hello timer....this is what is currently 
> >>specified
> >>b) use the interval advertised by the master, for as long as 
> >>it is master
> >>
> >>If we switch to b), then another decision is whether that is 
> >>configured 
> >>misconfiguration or not,
> >>i.e., if an error should be logged.
> >>
> >>Radia
> >>
> >>
> >>
> >>
> >>
> >>Hott, Robert W CIV B35-Branch wrote:
> >>
> >>    
> >>
> >>>I am in the process of updating a draft for sub-second 
> >>>      
> >>>
> >>timers for VRRP 
> >>    
> >>
> >>>for IPv4. An area that I have struggled with has been how 
> >>>      
> >>>
> >>to deal with 
> >>    
> >>
> >>>legacy devices that might be on a network with devices that use 
> >>>sub-second timers. In thinking out this issue for this new 
> draft, I 
> >>>noticed something that seems to a problem with the current 
> RFC. The 
> >>>interesting area in RFC 3768 is section 7.1 on receiving 
> >>>      
> >>>
> >>VRRP packets.
> >>    
> >>
> >>>The issue is this. Suppose that I have a master router 
> >>>      
> >>>
> >>configured with 
> >>    
> >>
> >>>an advertisement interval of 1 second. I have two more routers 
> >>>configured as backups. One is configured with an advertisement 
> >>>interval of 2 seconds and another is configured with an 
> >>>      
> >>>
> >>advertisement 
> >>    
> >>
> >>>interval of 3 seconds.
> >>>
> >>>I know that this is problematic but it could happen. Anyway, the 
> >>>master would send an advertisement. Based upon section 
> 7.1, both of 
> >>>the backups would discard this advertisement and would report the 
> >>>misconfiguration. Since the advertisement would be discarded, both 
> >>>would eventually transition to masters. The end result 
> >>>      
> >>>
> >>would be three 
> >>    
> >>
> >>>masters, since the state machine would not act on the 
> advertisement.
> >>>
> >>>Did I interpret this correctly? I would think that you 
> >>>      
> >>>
> >>would not want 
> >>    
> >>
> >>>to discard the advertisement because of the wrong setting. I would 
> >>>think you would want to use the interval of the master, at 
> >>>      
> >>>
> >>least until 
> >>    
> >>
> >>>you assume the role of the master.
> >>>
> >>>Bob Hott
> >>>
> >>>*Robert (Bob) W. Hott*
> >>>*NSWC-DD*
> >>>*Code B35, Bldg. 1500A/122A*
> >>>*17320 Dahlgren Road*
> >>>*Dahlgren, VA 22448-5100*
> >>>*540-653-1497 (W)*
> >>>*540-653-8673 (FAX)*
> >>>*robert.hott <at> navy.mil (E-mail)*
> >>>
> >>>-------------------------------------------------------------
> >>>      
> >>>
> >>-----------
> >>    
> >>
> >>>_______________________________________________
> >>>vrrp mailing list
> >>>vrrp <at> ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/vrrp

> >>> 
> >>>
> >>>      
> >>>
> >>_______________________________________________
> >>vrrp mailing list
> >>vrrp <at> ietf.org
> >>https://www1.ietf.org/mailman/listinfo/vrrp

> >>    
> >>

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

RE: Vrrp Implementation issue over LinuxIp

> Well, sometimes you want to be able to ping, traceroute or
> do SNMP queries to the system using the virtual address. So
> having the virtual address installed allows that pretty easily.

Did the spec change? Last I checked, it specifically forbids
the non-owner system from responding to the owner address,
and after working with VRRP for a while, I've come to the
conclusion that that's really a very good idea.

-don

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

RE: VRRP - Multiple Masters Question

> Don, I am curious about why you didn't raise the issue and got
> the spec fixed instead of deviating your implementation from
> the spec :)

I have raised it a couple of times. I even suggested
that this behavior be specified in the IPv4 timers
spec when I commented on it last March. But I guess
it was lost because I cast it as specifically a solution
to the backwards compatibility issue between subsecond
implementations and second-based implementations rather
than as the more general solution I actually implemented
in my own code.

And I wasn't too worried about deviating from the spec
since there don't appear to be any cases where this
behavior is worse than the spec's suggested behavior.

-don

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

RE: VRRP - Multiple Masters Question

Hi,

   Don's interpretation and Mukesh's comments over that are fine.

   I feel that the Administrators should ensure that there is no mismatch in
these critical parameters like advertisement Interval.

   If the problem is the the `Mater State`, Why can't the State can be
retained in INIT/BACKUP when there is a mismatch in Such Parameter Values?

   We have similar hello Interaval Parameter in OSPF .There also,the
adjacency won't form if any mismatch in Hello Interval.

   I think there should be some valid reasons behind the Advertisement
Interval.Can Authuors of RFC please give their comments on the same?

Thanks & Regards
Venkatesan S.

-----Original Message-----
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org]On Behalf Of
Mukesh Gupta
Sent: Saturday, 3 December 2005 3:34 AM
To: Radia Perlman
Cc: Chappell, Brett L CIV B35-Branch; Hott,Robert W CIV B35-Branch;
vrrp <at> ietf.org; Plunkett, Timothy R CIV B35-Branch; Odonoghue, Karen F
CIV B35-Branch
Subject: Re: [VRRP] VRRP - Multiple Masters Question

> a) discard (and log an error) if the value advertised
>    in the VRRP message disagrees with your configured
>    value for hello timer.... this is what is currently
>    specified
>
> b) use the interval advertised by the master, for as long
>    as it is master

I would vote for option b.

> If we switch to b), then another decision is whether that
> is configured misconfiguration or not, i.e., if an error
> should be logged.

Yes !

Is there any case where having different advertisement intervals
on different nodes will be useful?  If not, it should be considered
a misconfiguration but handled gracefully !

We are waiting for another update of the VRRP for IPv6 draft
to address IESG's comments.  We still have some time to pitch
in this change if the WG agrees to do this !

- Mukesh

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp