Slashdot Mirror
VRRP
Protocols that allow for automatic failover to a backup router have been around for a while, but they are proprietary, including Digital's IP Standby Protocol (IPSTB) and Cisco's more well known Hot Standby Routing Protocol (HSRP). These protocols have been used successfully for years, but as with all proprietary protocols, they lock users into one vendor. Plus, the test of time has shown there are ways in which they can be improved upon. VRRP has been developed in response.
VRRP lets you set up groups of routers to cover for each other, with each group acting like one virtual router with it's own MAC and IP addresses. If the main router in a group should go down, the others will quickly (in under 3-4s, typically) notice and one of them will be elected to take over. VRRP makes it easy to set up multiple routers with multiple WAN connections and make sure that WAN connectivity won't be lost if a router goes down.
As the open alternative to HSRP, you can count on VRRP being widely supported by the router vendors. Even Cisco is shipping it now. If you design, build or install routed networks of any size, VRRP is something you probably need to learn about.
Read This Book!
Let me just say up front that I think this is a very good book, and worth the read. As the title says, it is all about how to increase the reliability and failover capability of your network. VRRP is its subject, but it is treated with a thoroughness and attention to context I have rarely seen in a protocol text. Perhaps that follows from the fact that reliability and availability are only of concern due to economics; few protocols are developed to meet a business need, so most books on them never need to get beyond defining where they fit in their protocol family. Despite the context material, I found it easy to jump to the low-level technical details, yet was somewhat surprised to find myself actively enjoying the extensive introductory material.
Srikanth and Onart have put a wealth of background into the book. The first chapter treats network availability from a theoretical perspective, but does it so clearly and enjoyably that I read it straight through and felt I had learned some valuable new concepts. It also gave me all the context necessary to easily follow their discussion of the need for, conceptual operation of, and benefits from VRRP in Chapter 2.
Part II, comprising Chapters 3-6, presents the protocol, discussing its messages, state machine and issues with different LAN technologies, firewalls, tunnels and VPNs. I found this a useful complement to the RFC. Here is where I found the details I always look for first when confronting a new protocol: how many messages are there, how many states, what kind of implementation trade offs are going to be necessary? I particularly appreciated the abundance of clear, annotated diagrams in this part of the book, though they aren't confined to these chapters alone.
The chapters of Part III concern themselves with managing VRRP, and what is noteworthy here are the numerous examples of how you can configure and manage realistic scenarios. Juniper and Nortel routers are used in the examples, and you are given step by step instructions on using SNMP, the CLIs and a GUI (HP Openview). If I had to set a customer up with a redundant router configuration tomorrow, I would grab these chapters first thing.
Part IV may be the most useful part of the book for the experienced network engineer. Chapter 10 presents an excellent discussion of the pros and cons of VRRP vs HSRP and IPSBP, and includes some nice summary tables. Chapter 11 discusses the future of VRRP, and answered many of the niggling "How would it handle this scenario?" questions which had popped up as I read how the current VRRP works.
The final section of the book is comprised of 200 pages of appendices. They start with a moderately brief but well done overview of TCP/IP and IP networks. That is followed by the complete VRRP MIB. Then we are given Linux source from http://w3.arobas.net/~jetienne/vrrpd/ and a nice commentary on it. Next is a thorough explanation of the SDL (Specification and Description Language) and flowcharts which were used to define the state machine in Part II. And if this isn't enough rigor for you, you'll be pleased that the following appendix using first-order predicate calculus to specify VRRP yet more clearly. (If you don't know what first-order predicate calculus is, just feel lucky and skip that part...) The final appendix covers UML, the Unified Modeling Language, which also is used in Part II to show how VRRP state transitions occur.
What's Not to Like?
There is very little to object to about this book. If it has a fault, it may be that it is a bit too comprehensive. VRRP is actually a fairly simple protocol, and I write that as someone who has designed and implemented protocol stacks for over 8 years. The level of rigor and detail put into VRRP in this book are worthy of something as hairy as OSPF or BGP4. I found myself getting lost in the notational details of their examples at times, they were so exactingly detailed, but I found that if I just looked at the diagram and skipped to the last paragraph, I'd get what I needed. This book would actually make a pretty good reference book on networking in general, there's so much here!
FAQs
What level of experience is needed to make good use of the information in the book?
This book has all the intro material a novice to networking could want, yet has it all so well organized that it is easy for the advanced reader to find the interesting details.
Who will find it most useful? Is there an existing, canonical book that already covers the same ground?
I think this book would be most useful for enterprise network designers, implementers and operations people, no matter what their current skill level. I couldn't find another book on VRRP, so it's good that the only game in town right now is a good book.
Is the book readable as well as technically accurate? Is the language stilted, or natural? Are examples easy to follow?
The book is very readable - unusually so. As for accuracy, I didn't notice anything amiss, and I used to QA stuff like this. Good use of language, and a ton of excellent examples.
Is the depth appropriate?
This book dives deep, but not without plenty of warning and acclimatization first for people not quite ready for the open ocean.
Are the illustrations appropriate and well executed?
Excellent, clear illustrations.
Do any extras come with the book, like a CD-ROM of additional information or code samples?
You get a full printout of the VRRP MIB, as well as commented source code.
What's missing from the book? Would it benefit from illustrations, a better index, a final chapter on practical applications?
Nothing significant.
You can purchase VRRP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
And honestly, if you're having significant problems due to router misconfiguration, you should really consider replacing your network staff. A few glitches are to be expected, but if they're causing more downtime than your hardware, perhaps they need to study up before they're allowed near your production kit.
Home Web page of the VRRP working group :: http://www.ietf.org/html.charters/vrrp-charter.htm l
:: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-spec-v2-06.txt
:: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-ipv6-spec-03.txt
:: http://www.ietf.org/rfc/rfc2338.txt
:: mailto:Mukesh.Gupta@nokia.com
:: ftp://ftp.ietf.org/ietf-mail-archive/vrrp/*
VRRP Internet draft
VRRP for IPv6
VRRP RFC
Email the chair of VRRP
Mailing list archive
If you celebrate Xmas, befriend me (538
For FreeBSD
For Linux
Wackamole (www.wackamole.org) can be used to do this for routers running Linux, Solaris, or FreeBSD. Its open sourced, and freely available.
I am *not* an Atomic Playboy, but I *am* a cheese-eating surrender-monkey!
www.keepalived.org provide its own internal way to deal with monitored-circuit like... (called vrrp synchronized group)
Easy solution:
Firewall Load Balancing
Alteon switches (in a sandwiched pair) maintain persistency across firewalls while load balancing and health checking all the way though clean and dirty sides to ensure redundancy.
Yes, the Internet is very reliable in the big picture, but things like BGP routes can take about 5 minutes to update. Just think how irritated we are when Slashdot is "off the map" for five minutes while the routers update their tables? That is reliability at work. What the VRRP tries to accomplis is to take that from 5 minutes to less than 5 SECONDS or sub-second.
Side note: When your service providor says that they have "99.999%" uptime to the Internet, ask them if their up-stream providors ever have routing/router problems... Since "Five Nines" a year equates to "five minutes" of downtime per year, a single BGP route update is five minutes. In the real world, if an ISP is up >99.9% of the time (99.9% == 8.8 hours) using a simplistic monitoring (pinging their outside routers, pinging the firewall I am behind, etc) then I am happy.
I've run into countless failure scenarios where VRRP ends up being mostly useless. Scenario one where the gateway segment and server segements don't both fail simultaneously is one, where the primary stays up on the front end, but the server segment fails over.
Also, there's the issue of the L2 packets being broadcast, so that when the switch you're connected to stops forwarding unicast (oh, but broadcast and multicast still work just fine, thank you very much), VRRP is pretty much useless. It'll never realize that something's gone horribly wrong, and that failing over is necessary.
I guess my point is that most of the "automated failover" solutions out there either are or have been pretty much worthless given the failures I've seen, and that VRRP, for all it's good points, only covers about ten percent of failure situations. For straight up gateway reachability, it does just fine (in fact, it's a nearly complete rip of Cisco's HSRP, altho I'm not exactly sure of the timeline for each protocol), and in fact it's a superior solution in that regard, but for anything else other than L3 gateway services where all you're doing is plain-vanilla IP routing, it's pretty lousy.
What I'd like to see is a unicast-based, fully-configurable hot-standby solution. Something where you're forced to enter the IP of the other partners in the redundancy group. Simply sticking to broadcast- or multicast-based solutions isn't going to cut it in a fully switched environment. Granted, the above is going to require a bit more configurationbut come on, it would add what, one, maybe two lines to each configured group? Hell, my environment has two hundred configured interfaces like this, and I'd put up w/ the extra work if it would have saved me from some of the failures I've had.