Mukesh.Gupta | 7 Nov 01:46 2003
Picon

Scribes for the meeting..

Hi,

The chairs are looking for volunteer scribes for the
meeting minutes and for jabber.

Please send a mail if you would like to be "The One" :)

Regards
Mukesh

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

Mukesh.Gupta | 11 Nov 18:33 2003
Picon

CARP..

Folks,

Do we have anyone in the WG or routing-discussion list who 
knows about CARP (Common Address Redundancy Protocol) and 
can explain it to the WG (or just the chairs in person) in 
the WG meeting on Thursday.

Please send me a mail asap. Your help will be highly
appreciated.

Regards
Mukesh

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

PC Drew | 11 Nov 19:33 2003

Re: CARP..

The man page is located here:

http://www.openbsd.org/cgi-bin/man.cgi? 
query=carp&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format= 
html

The original post to the mailing list is here:

http://marc.theaimsgroup.com/?l=openbsd-misc&m=106642790513590&w=2

I would recommend contacting the following people for more information:

Ryan McBride: mcbride <at> openbsd.org
Theo de Raadt: deraadt <at> openbsd.org

On Nov 11, 2003, at 10:33 AM, Mukesh.Gupta <at> nokia.com wrote:

> Folks,
>
> Do we have anyone in the WG or routing-discussion list who
> knows about CARP (Common Address Redundancy Protocol) and
> can explain it to the WG (or just the chairs in person) in
> the WG meeting on Thursday.
>
> Please send me a mail asap. Your help will be highly
> appreciated.
>
> Regards
> Mukesh
>
(Continue reading)

M. T. Hollinger | 12 Nov 00:08 2003
Picon

Scope of Valid VRRP Configurations

Consider the following configuration:

Rtr0 is a big, beefy router with a couple of T3 upstream connections.  When
Rtr0 is up and running, the site administrator wants it to handle all
non-local traffic.  Thus, it gets configured as the Master Router (MR) for
both VRID=1 and VRID=2 on some particular link, where Rtr0 has only one line
card connected.

Rtr1 and Rtr2 are wimpy older boxes with only T1 connections.  Each is the
Backup Router (BR) for only one VRID.  When Rtr0 is shut down, Rtr1 becomes
the new master for VRID=1, and Rtr2 becomes the new master for VRID=2.

Is this setup within the scope of VRRPv3?  It isn't explicitly prohibited,
but we may run into trouble because the current draft says:

> IPv6 Routers running VRRP MUST create their Interface Identifiers in
> the normal manner (e.g., RFC2464 "Transmission of IPv6 Packets over
> Ethernet").

If Rtr0 generates its link-local address in this way, and it becomes the
IPv6 address associated with both VRID's, then what happens when Rtr0 fails?
Both Rtr1 and Rtr2 will try to use that same link-local address at the same
time.

It's funny how carefully one has to read a draft while preparing an analysis
of proposed changes.  I'm noticing things today which I breezed right past
earlier.  For example, the term "backup" is overloaded, leading to confusion
when saying something like, "when the Backup Router is in Master state", as
there is also a Backup state.  I would have changed one "Backup" to
Secondary, Standby, Contingency, or the like, but that's a nit.  I have a
(Continue reading)

M. T. Hollinger | 12 Nov 00:55 2003
Picon

Changing Adver Interval

Suppose an administrator initially deploys 3 VRRP routers for a single VRID,
sending advertisements at 2 second intervals.  At some point in the future,
he decides to change back to the default 1 second interval, but one of the
Backup Routers doesn't get changed.  Maybe it was down for maintenance at
the time and didn't return until the following week.

The VRRPv3 draft says that upon receiving a VRRP packet, a router:

>   - MUST verify that the Adver Interval in the packet is the same as
>     the locally configured for this virtual router
>
> If the above check fails, the receiver MUST discard the packet,

This would appear to mean that once the BR does come back, it will ignore
all the VRRP packets and enter Master state.  The network will then limp
along with two MR's until the administrator figures out the problem and
manually corrects it.  Is that what we intend?

Other options would be to:

  Have the BR log the discrepancy but accept the packet anyway

  Have the BR enter Initialize state (awaiting manual startup)

  Have the BR adjust its own interval and continue (see below)

If the Backup Rouer's interval is already greater than the one in the
received packet, then there is no danger in just accepting the packet.  The
BR expects a packet every 2 seconds, but the MR is sending one every second.
On the other hand, if the received interval is larger than the BR's own
(Continue reading)

M. T. Hollinger | 11 Nov 21:55 2003
Picon

Re: newbie vrrp question

On October 22, 2003, Bob Hinden wrote:
> The reason for not accepting packets addressed to the IP address of the
> owner, if not the owner, is to make it easier to detect that one of the
> routers is down.  People have had problems with other redundancy protocols
> that did not have the behavior that their network management systems would
> not detect that one of the routers had failed because the IP address still
> responded to pings, SNMP queries, etc.  It is also confusing for routing
> protocols.  The desired behavior when one of the routers fails is to have
> user traffic keep flowing, but to have all network management bells start
> ringing.

Please, think of the poor end-user!  I know that when I visit a new network
(such as the flaky wireless LAN here at the IETF), and I am having trouble
communicating, one of the first things I do is try to PING the default
router.  If the default router doesn't respond to PINGs, I will assume it is
down and either report the problem to local network management folks or give
up on connecting and just try later.

Some hosts may use ICMP ECHO_REQUEST messages in the context of a network
troubleshooting wizard, essentially automating the same interactive
procedure I use to figure out whether my network connection is any good.

Although as you know, I like the idea of making router failure visible to
interested hosts, having the Backup Router not respond to PINGs is not a
good way to provide such visibility.  Surely, we can find some way to let
VRRP-aware network management stations detect and report failures without
causing the router to appear dead to non-VRRP-aware troubleshooting
procedures.  I disagree with that provision of the current VRRPv3 draft and
suggest that it be removed.

(Continue reading)

Mukesh.Gupta | 12 Nov 01:50 2003
Picon

source email address for VRRP mailing list..

Mark,

You probably are subscribed to VRRP mailing list with myth <at> ucx.lkg.dec.com.

Sending a mail from myth <at> hp.com would required my approval. So please
use myth <at> ucx.lkg.dec.com for further communication.

I have approved 2 mail sent from myth <at> hp.com for now.

Regards
Mukesh

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

Mukesh.Gupta | 12 Nov 01:52 2003
Picon

FW: source email address for VRRP mailing list..

Didn't mean to copy this mail to the WG :(

My bad !! Sorry !!

-----Original Message-----
From: Gupta Mukesh (IPRG/MtView) 
Sent: Tuesday, November 11, 2003 6:50 PM
To: 'ext M. T. Hollinger'; vrrp <at> ietf.org
Subject: source email address for VRRP mailing list..

Mark,

You probably are subscribed to VRRP mailing list with myth <at> ucx.lkg.dec.com.

Sending a mail from myth <at> hp.com would required my approval. So please
use myth <at> ucx.lkg.dec.com for further communication.

I have approved 2 mail sent from myth <at> hp.com for now.

Regards
Mukesh

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

M. T. Hollinger | 12 Nov 06:11 2003
Picon

Re: newbie vrrp question

Hi, Don.  Thanks for the response!

> Does the end user want to detect whether he has outside
> connectivity? Then he pings something outside to see if
> he has outside connectivity.

Sure, but what?  For the first 10 years I was out of college, I always used
to ping one of the servers back at school.  I couldn't ping any of the
systems at work from out on the open Internet because of our firewall, and I
wanted to ping something whose IP address I had memorized in order to take
DNS out of the equation (troubleshoot one thing at a time).

An automated diagnostic tool might do the same: try pinging a few hard-coded
addresses out on the net.  But if you just want to find out how well your
local link (e.g. wireless) is working, it's hard to match a quick 10-packet
ping of the default router to get statistics on loss and latency.

> So I think it's a case where you decide whether to continue
> to support what the end user learned to do back when he had
> one rickety router that failed all the time, or do you move
> on into the brave new world and let him discover new techniques.

Well, I think that depends.on how widely deployed VRRP becomes.  If VRRPv3
retains this behavior and becomes ubiquitous, then users (and automated
wizards) will eventually develop new techniques.  If VRRP remains a relative
rarity, then users (especially mobile users) won't learn.  When they visit a
network that does use VRRP, and a Backup Router happens to be active,
they'll think the network is really flaky.

            - M
(Continue reading)

Kalyan.Tata | 12 Nov 20:01 2003
Picon

VRRP MIB

hi,
   I had a couple of personal discussions with various SNMP and MIB experts and the 
   consensus is that we should go with a unified VRRP MIB. I am planning to 
   propose going with the unified MIB at the WG meeting.
   As you are aware - Unified VRRP MIB means that existing implementations will 
   have to change. I would strongly suggest any one having concerns with this 
   approach to voice their opinion either in the mailing list or at the working 
   group meeting. 

	One of the reasons against a unified MIB is the loss of backward compatibility 
 	with the existing VRRP MIB implementation. Could everyone having an existing 
      VRRP MIB implementation respond so that we will have an idea of how many 
      implementations are present.

  Thanks
  kalyan

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


Gmane