Imitation is the highest form of flattery. ;)
Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Steve Clark <scl...@netwolves.com> Date: 04/22/2014 11:48 AM (GMT-07:00) To: Paul WALL <pauldotw...@gmail.com> Cc: nanog@nanog.org Subject: Re: US patent 5473599 On 04/22/2014 01:30 PM, Paul WALL wrote: > On Tuesday, April 22, 2014, Henning Brauer <hb-na...@bsws.de> wrote: > >> I won't waste time on your uninformed ramblings, you have the facts >> plain wrong. There is enough material on the net for everybody to read >> up on what happened. >> >> "carp causing outages" however is nothing short of a lie. carp >> announces itself as vrrp version 3. anything trying to parse it as >> vrrp2 without checking the version number in the header is buggy as >> hell and that is ITS fault, not carps. affected cisco 3600, afair. > > I wasn't talking about CARP's announcements causing outages due to > bugs in VRRP implementations, I was talking about CARP's intentional > use of another organization's OUI and deliberately constructing its > bits in the host section to conflict with established practice for > VRRP. That was childish, and causes outages. This design choice > should be documented in CARP's man page. It is not. > > In response to Ryan Shea, here's the way it breaks down: > > Both CARP and VRRP use virtual router MAC addresses that start with > 00:00:5e. This organizational unique identifier (OUI) is assigned to > IANA, not OpenBSD or a related project. The CARP authors could have > gotten their own from IEEE. OUIs are not free but the cost is quite > reasonable (and was even more reasonable years ago when this > unfortunate decision was made). > > The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, > the CARP folks *also* decided to use 00:01 after they got upset at the > IETF for dissing their slide deck. > > If either of these decisions had not been made, we would not be having > this discussion today. > > The last octet is the VRID for both CARP and VRRP. If you don't have > the same VRID configured, the protocols should peacefully coexist, > assuming no bugs in the software listening to the multicast > advertisements (which Henning mentioned above - a legitimate concern > to be sure, but not the big one). > > So yes, the problem only exists if you are running VRRP and CARP on > the same subnet (say, a pair of routers speaking VRRP and a pair of > firewalls backing each other with CARP and pfsync, which is actually > fairly common) and happen to have a host identifier conflict. In a > completely random world the likelihood of this is 1 in 256. > Unfortunately, human nature and a plethora of examples on the > intarwebs makes "interface GigabitEthernet 0/3 // vrrp 1 ip blah" > reasonably likely. The same human nature causes the out of the box > configuration on many products, e.g. pfSense, to be "ifconfig carp0 > vhid 1". Presto - outage for everyone on the subnet. > > Soapbox time. There are some people who decide that they will only > run FOSS software because of how they feel about software patents. In > my case, I will not run CARP because of how I feel about folks > deliberately violating the interoperability maxim ("be conservative in > what you send and liberal in what you accept") and causing *me* to be > the collateral damage. I think we all have enough on our plates > dealing with legitimate software bugs without having rogue protocols > deliberately interfering with our networks because of a grudge. Is > CARP malware? A trojan? I'm not sure I'd go that far, but it seems > to meet some of the definitions. > > Nothing personal Henning (and I like what you did with OpenBGPd and > OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a > bunch of other people's, if you publicly admitted the CARP OUI > decision was a huge mistake. If your lawyers have advised you not to > apologize because of liability concerns (despite that "no warranty" > bit in the BSD license) it's OK - I completely understand. > > Drive Slow, > Paul > I think there is also the issue it uses the same protocol number - 112. From /etc/protocolsvrrp 112 VRRP # Virtual Router Redundancy Protocol -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com