do we need number of retries in VRRP3?
2005-02-01 00:03:29 GMT
Hi all,
Although I’m quite familiar with VRRPv2 but new to VRRPv3 because there is no such demand till recently. We had implemented VRRP like protocol in our product for long time and have added lots of enhancements to the basic protocol. VRRP is a simple protocol working well for a simple network topology, which it is designed for. But it has some significant drawbacks in any production network with some level of complexity.
After reading the draft <draft-ietf-vrrp-ipv6-spec-07.txt>, I have some questions and post here one by one hoping they can get answered.
1) The draft changes the advertisement interval from unit of second in VRRPv2 to centi-second. This is great improvement. Thanks for the change. One of the big operation issues with VRRPv2 is the minimum 3 seconds fail-over time while our customers are asking sub-second failover. But the operational experience tells us that if we shorten the interval (say 200ms), we may want to increase the number of retries (say from 3 to 4 or even 5) to compensate the potential delay or loss. So the fixed retry of 3 times (as defined in master_down_time) sometimes may not be good. Is it possible to use the 4-bit rsvd field to carry this info?
2) In section 6.4.3 it states the master
- MUST respond to ND Router Solicitation message for the virtualBut in section 6.4.2 it does not state the backup- MUST NOT respond to ND Router Solicitation message for the virtual Has the author left that out for any good reason? Otherwise, developers may get confused because everything else is kind of opposite in the two sections. 3) In section 7.4 for the interface ID, there is one restriction about using the virtual MAC to derive the interface ID. But it dose not state the reason. I was thinking exactly to derive the interface ID from the VMAC. This is to leave the interface ID derived in the normal manner for addresses of local management. What is the harm of this approach? Thanks in advance.
Changming Liu
_______________________________________________ vrrp mailing list vrrp <at> ietf.org https://www1.ietf.org/mailman/listinfo/vrrp
I'll offer some food for thought:
What happens when you run ospf in your implementation on an interface
that contains VRs?
What hapens if you were to configure OSPF such that it uses a VR
address? (This is different than "should you".)
Given that OSPF is uses layer-3 transport and can be configured
in a non-multicast environment (as could RIP), what happens if you
use the VR address as the target of your adjacency?
Many of these would fall into a section that's unwritten in many manuals
called "Things you could do, but probably shouldn't." While testing
the interop of these "shouldn't do" situations, you'll probably fine
that the results are unexpected and provide some entertaining fault
scenarios for OSPF. 
RSS Feed