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
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
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)
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)
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)
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)
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
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
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)
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
RSS Feed1 | |
|---|---|
4 | |
19 | |
1 | |
5 | |
2 | |
7 | |
2 | |
3 | |
3 | |
1 | |
1 | |
5 | |
9 | |
1 | |
4 | |
8 | |
1 | |
4 | |
4 | |
1 | |
7 | |
4 | |
1 | |
9 | |
2 | |
3 | |
5 | |
5 | |
20 | |
25 | |
5 | |
6 | |
2 | |
1 | |
3 | |
45 | |
18 | |
3 | |
10 | |
12 | |
6 | |
4 | |
7 | |
23 | |
4 | |
6 | |
14 | |
3 | |
15 | |
10 | |
5 | |
3 | |
30 | |
23 | |
11 | |
5 | |
1 | |
10 | |
10 | |
8 | |
6 | |
4 | |
2 | |
12 | |
5 | |
7 | |
11 | |
13 | |
4 | |
1 | |
10 | |
4 | |
10 | |
13 | |
10 | |
31 | |
12 | |
2 | |
6 | |
8 | |
1 | |
8 | |
12 | |
14 | |
11 | |
1 | |
13 | |
1 | |
5 | |
35 | |
20 | |
42 | |
38 | |
22 | |
9 | |
28 | |
4 | |
17 | |
15 | |
7 | |
35 | |
30 | |
19 | |
12 | |
10 | |
4 | |
5 | |
1 |
