Date: Thu, 8 May 2014 17:32:28 +0400 From: Eygene Ryabinkin <rea@freebsd.org> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: net@freebsd.org Subject: Re: Allowing CARP to use arbitrary OUI prefix and allocating block from FreeBSD's OUI space assignment for that Message-ID: <jFzRD2Y/x/4vgSDdS1CPQw/Hudo@dHhGgwofm7uNfL6/X5%2BbGIkDUYs> In-Reply-To: <1B71A1AC-8A85-415D-A413-CD01635B3123@lists.zabbadoz.net> References: <Nlrr646yWAdJ7EfNj9z5ymwq5ZQ@dHhGgwofm7uNfL6/X5%2BbGIkDUYs> <97B3C7CB-3E64-4FE0-81C8-F1FE6FB456A2@lists.zabbadoz.net> <ht5ioSVMkYjTNaadctX3apO0nWQ@dHhGgwofm7uNfL6/X5%2BbGIkDUYs> <1B71A1AC-8A85-415D-A413-CD01635B3123@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--DiL7RhKs8rK9YGuF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thu, May 08, 2014 at 12:08:28PM +0000, Bjoern A. Zeeb wrote: > On 08 May 2014, at 09:50 , Eygene Ryabinkin <rea@freebsd.org> wrote: >=20 > > No, we're conflicting with VRRP on the MAC address space. > >=20 > > And, as I understand, CARP in 10 hadn't changed protocol in any way, > > it just refurbished now CARP instances are configured and attached to > > the interfaces. Could be wrong here, though. >=20 > Yes, that is why the problem remains. >=20 > http://svnweb.freebsd.org/base/head/sys/netinet/ip_carp.h?annotate=3D2530= 87#l86 > #define CARP_VERSION 2 >=20 > vs. >=20 > RFC 3768, Virtual Router Redundancy Protocol (VRRP), 5.3.1. Version >=20 > The version field specifies the VRRP protocol version of this packet. > This document defines version 2. >=20 > *boom* >=20 > And the world is moving on ... >=20 > RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 an= d IPv6, 5.2.1. Version >=20 > The version field specifies the VRRP protocol version of this packet. > This document defines version 3. Oh, shit :( > So, document CARP as Version 4 and then you have your own version of > the protocol and a good reason to change the EUI-48 assignment > within the IANA OUI maybe, maybe not. >=20 > http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#e= thernet-numbers-1 >=20 > 00-01-00 to 00-01-FF VRRP (Virtual Router Redundancy Protocol) [RFC5798] > 00-02-00 to 00-02-FF VRRP IPv6 (Virtual Router Redundancy Protocol IPv6) = [RFC5798] >=20 >=20 >=20 > Currently we are on Version 2 and VRRP (3768) is Version 2 and we > share the OUI but speak a different language. *boom* More properly, we're on v2, VRRP 3768 is v2 and we share protocol number (112). And our data planes share the same OUI, but that's has nothing to do with being on version X or Y on any side, that's a different problem. > Currently you are worried that =E2=80=9CCARP" !=3D =E2=80=9CVRRP" and sti= ll uses the > same EUI-64. But that=E2=80=99s a management problem. Server guys run > Solaris and VRRP[1] in the Solaris group, and Linux and VRRP in the > Linux Group, or FreeBSD and VRRP (yes people do) in the group that > tries to talk to the other two. If they don=E2=80=99t talk to each other > and the networking guys put the servers in the same subnet, they > probably conflict. *boom* Needless to say that if they don=E2=80=99t t= ell > the networking guys they conflict with the routers as well > *boom*boom* >=20 > Two different networking groups do redundancy failover and years > later connect their routers; 4 routers run VRRP, same VRID by > default. *boom* >=20 > The samples you can find are plenty. Multiple deployments of the same protocol need coordination, but that's expected. Multiple deployments of a different protocols might (and as our case shows, do) need coordination, but that's an unexpected thing. Change of used OUI space for CARP will prevent at least the part of the breakage, the most unexpected part of the whole drama. > People need to talk. The fact that your server guys use a > non-unique Ethernet address for CARP without talking to their local > authority who=E2=80=99s in charge of the network first is nothing you can > fix changing the number. The fact that multiple deployments on the > same subnet might exist is nothing a number change will fix. I > think the RFC uses the word =E2=80=9Ccoordinate=E2=80=9D. People need to talk, yes. But do BGP heads will announce the technical details of what they are doing to the Squid cluster guys (picking protocol and software names arbitrary)? Not sure. Hell, I am sure they won't. And if we speak about RFCs: we need protocol specifications at all not only because people should know how they work, but also to avoid messing (perhaps unintentionally) some technical details of the protocols making different ones to bring havoc if used together. That's why VRRP for IPv6 has its own OUI space and that's why CARP needs its own OUI space: it is a different protocol from VRRP, so we should minimize clashes at all levels. IANA/IETF could have said "oh dear, L2 domain admins must coordinate their IPv4 and IPv6 VRRP things, so let's reuse 00-00-5E-00-01 space". But they minimised confusion where they could and that's a good thing to do. What you're saying is that "all involved people must be educated enough to grok all details and share them with others". What I am saying is that "when we can eliminate potential for breakage, we should". My assertion doesn't contradict with your, but it tries to make already complicated networking world to be slightly more error-prone (at least, I hope so and that's my intention here). > The thing you can change is to fix the version number for CARP, > document the protocol (so your network guys become more aware of it > though they probably won=E2=80=99t anyway); then you can make sure it > doesn=E2=80=99t conflict on as much as is possible with it---just that you > cannot always (as described above) without talking. So it=E2=80=99s ab= out > minimising the impact, reading your log files, and talking to > people. That is also a good thing to do, but it is a longer-term goal, because putting CARP into RFC is, well, a loooong story. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --DiL7RhKs8rK9YGuF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iL4EABEKAGYFAlNrh2xfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDgyRkUwNkJDRDQ5N0MwREU0OUVDNEZGMDE2 QUY5RUFFODE1MkVDRkIACgkQFq+eroFS7PtwCwD/QZ0rn6QgOqY/uEOKyB6E7N5w 4UIhfemhOPo9gbDg3HYBAIy4lbJDabPVj5zVIevudvx46ntWClmA3LUIgJBTQUfH =VSIJ -----END PGP SIGNATURE----- --DiL7RhKs8rK9YGuF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?jFzRD2Y/x/4vgSDdS1CPQw/Hudo>