Re: VRRPv3 Implementation Report

Thanks for the info. That's just what I was looking for.

I think the management issues are a matter of taste, so we don't
need to go over that any more: I say management operations using
the VR IP address tend to obscure reality and other approaches
give a clearer picture, but you find using the VR IP address for
managing/monitoring the network is useful.

The part about tunneling brings up a different point for us to
consider: should VR IP addresses be used as service end points?
I've never given that any thought. What's the group wisdom about
that? Does it matter whether the service is part of the routing
infrastructure, as in this case? In this use of the VR IP
address valid, and, if so, is it important enough to force
implementations to support or even, as Lin is suggesting, always
do ACCEPT_MODE?

-don

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Lin Tao
> Sent: Tuesday, October 21, 2008 7:50 PM
> To: don provan; 'Mukesh Gupta'
> Cc: [email protected]; [email protected]
> Subject: Re: [VRRP] VRRPv3 Implementation Report
> 
> 
> Don,
> 
> The simplest requirement is "PING" that used to test the connectivity 
> of the gateway by the end user or network operator.
> 
> When the VRRP is implemented, the network is mostly stable, the 
> VR switchover is short and unusually. So the operator can take VRRP
>  IP when he only need a simply operator such as looking at routing
>  table or cpu usage of the Master router.
> 
> A new requirement of VRRP IP is TUNNEL. We can use the VRRP
> IP as the source of TUNNEL, so that the peer node couldn't see the 
> switchover. We also know that the packet must be sent to the IP Stack
> in TUNNEL forward for encapsulation or decapsulation.
> 
> Lin.
> 
> ----- Original Message ----- 
> From: "don provan" <[email protected]>
> To: "'Lin Tao'" <[email protected]>; "'Mukesh Gupta'" 
> <[email protected]>
> Cc: <[email protected]>; <[email protected]>
> Sent: Tuesday, October 21, 2008 2:45 AM
> Subject: RE: [VRRP] VRRPv3 Implementation Report
> 
> 
> >> FYI: The requirement of VRRP IP's operation is really offered 
> >> by our customer. There are layers management of network.
> > 
> > Lin,
> > 
> > Perhaps you should tell us more about this requirement, then.
> > The management techniques I've seen over the years always
> > involve managing physical nodes to insure they are operating
> > as expected or accessing services to make sure they are
> > performing correctly. In VRRP, the former is accomplished
> > by using an address actually owned by the box, and the latter
> > is accomplished by confirming that packet forwarding is
> > operating *through* the box, perhaps by pinging or otherwise
> > accessing *an external* address.
> > 
> > You apparently are seeing a third possibility revealed by
> > VRRP that involves accessing a virtual node for reasons
> > *other* than using the virtual service it is providing,
> > so I think it's important for us to all understand the
> > requirement that calls for that.
> > 
> > -don
> _______________________________________________
> vrrp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp