[VRRP] VRRP groups and complying with RFC 3768

Martin Visser <martinvisser99@gmail.com> Mon, 01 February 2010 00:48 UTC

Return-Path: <martinvisser99@gmail.com>
X-Original-To: vrrp@core3.amsl.com
Delivered-To: vrrp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE7B3A69F6 for <vrrp@core3.amsl.com>; Sun, 31 Jan 2010 16:48:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.739
X-Spam-Level:
X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9LPNmWuchXo for <vrrp@core3.amsl.com>; Sun, 31 Jan 2010 16:48:25 -0800 (PST)
Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id EB0773A68DA for <vrrp@ietf.org>; Sun, 31 Jan 2010 16:48:24 -0800 (PST)
Received: by pzk36 with SMTP id 36so4538973pzk.5 for <vrrp@ietf.org>; Sun, 31 Jan 2010 16:48:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=r03Lcxter7vdPz/e7f9iaYb3fL5nopq0bgAm6qMZ96I=; b=iZNLWiLu2bddf45w1IXOs29j5cRMSPCeCWThX45sxpEdf2YXrB+Tuaf3R12Tmp2hAn jNq+2s7FvkxVg8HMs4kYEpsaP4CY5xcjZNmxWuUc2ZK231UX69oMh1U9+tH5PnYjGNKh VziUsty/GrzedkLxCXpL1eJGIfyc2W5WDUYsI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FCxFft3Et4UM7t5NPlTpyJT2FnpQp1MtwgbSc/SUYu/OBp52C4S8lWf0JdHITjvGrl zSOoBt24b3oehdl3FmuDwF9KRw0N8lMhRfZtfxnRJF79QrNZn4RSbtYpf9kmBTUF7KHH /2PCWEkLKYHjHu4LVXr9Dstp1H+FXN3/MlZzk=
MIME-Version: 1.0
Received: by 10.114.6.2 with SMTP id 2mr2625476waf.124.1264985334581; Sun, 31 Jan 2010 16:48:54 -0800 (PST)
Date: Mon, 01 Feb 2010 11:48:54 +1100
Message-ID: <b3739b0c1001311648q2c374b31t28f8f767cf255abb@mail.gmail.com>
From: Martin Visser <martinvisser99@gmail.com>
To: vrrp@ietf.org
Content-Type: multipart/alternative; boundary="0016e6480ebe838ac0047e7f59fe"
Subject: [VRRP] VRRP groups and complying with RFC 3768
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Feb 2010 00:53:28 -0000

Hi,

I have a question related to a problem that took a lot of time to solve. My
customer has a set of firewalls and a set of load-balancers that use VRRP to
provide redundancy for the gateway addresses and the virtual IPs they serve
up. The vendor (the same for both, but each have a different OS platform)
has a concept of a VRRP group. All of the virtual routers are advertised
thus in the one VRRP advertisement (at least on this one VLAN 22) - the
firewall is configured to use VRID 255 and the load-balancer uses VRID 79.

What I found is curious is that the the source MAC address for the VRRP
advertisements does not match that of the configured group VRID. Instead
they use the VRID 122 as the basis of the MAC address. This is derived from
two of the individual virtual routers - 111.111.234.129 on the firewall,
and 172.26.22.122 on the load-balancer. (Note that 111.111.xxx.xxx is my
obfuscation of the real address). Using the same VRID 122 on the two
heterogeneous platforms on the one VLAN is of course a misconfiguration,
which we now recognise. However the question remains is that the actual VRID
122 is never mentioned on the wire in any of the VRRP advertisements so why
is the derived MAC address, 00:00:5e:00:01:7a, used instead
of 00:00:5e:00:01:ff and 00:00:5e:00:01:45 (for VRIDs 255 and 79 ) not used?
Is the vendor actually complying with RFC 3768 or not. I am sort of guessing
that the vendor has done this to prevent using the same VLAN accross
multiple VLANs, as it appears they do use the same VRRP group VRID accross
multiple VLANs. Thus if they used the configured group VRID for deriving MAC
addresses it might cause confusion on some switches (if they don't maintain
a per VLAN forwarding table). However because we weren't seeing conflicting
VRRP VRIDs in the actual advertisements, we hadn't found the problem. It was
only chancing upon the fact that the firewalls were using the same source
MAC as the load-balancer that we found a problem. (We found it when we were
trying to install a switch between the firewall and load-balancer pairs and
were experiencing high packet loss. Having the same source MAC swapping
between interfaces, tied to different virtual router IPs, of course was the
cause).

So again, my question is

1. Is the vendor in violation of the RFC by choosing a source MAC based on a
VRID not actually in the advertisement
2. Do other vendors using a similar arrangement when send VRRP group
advertisements. (The exact algorithm in this case isn't clear to me).

The two packets below (using the Wireshark summary) are from the firewall
first and the load-balancer second. It is clear they use the same source MAC
but different VRIDs. I have annotating the virtual router IP address from
which the used source MAC address is derived.



No.     Time        Len   Source                Destination
Protocol Info
   4723 2.375135    122   111.111.234.130        224.0.0.18            VRRP
    Announcement (v2)

Frame 4723 (122 bytes on wire, 122 bytes captured)
Ethernet II, Src: IETF-VRRP-virtual-router-VRID_7a (00:00:5e:00:01:7a), Dst:
IPv4mcast_00:00:12 (01:00:5e:00:00:12)
Internet Protocol, Src: 111.111.234.130 (111.111.234.130), Dst: 224.0.0.18
(224.0.0.18)
Virtual Router Redundancy Protocol
    Version 2, Packet type 1 (Advertisement)
    Virtual Rtr ID: 255
    Priority: 118 (Non-default backup priority)
    Count IP Addrs: 18
    Auth Type: Simple Text Authentication [RFC 2338] / Reserved [RFC 3768]
(1)
    Adver Int: 1
    Checksum: 0xd785 [correct]
    IP Address: 172.26.18.30 (172.26.18.30)
    IP Address: 172.26.30.10 (172.26.30.10)
    IP Address: 111.111.234.129 (111.111.234.129)  *** VRID 122 ***
    IP Address: 172.26.22.1 (172.26.22.1)
    IP Address: 111.111.234.65 (111.111.234.65)
    IP Address: 172.26.20.1 (172.26.20.1)
    IP Address: 111.111.234.225 (111.111.234.225)
    IP Address: 172.26.32.1 (172.26.32.1)
    IP Address: 111.111.234.25 (111.111.234.25)
    IP Address: 172.26.21.1 (172.26.21.1)
    IP Address: 111.111.234.209 (111.111.234.209)
    IP Address: 172.26.33.1 (172.26.33.1)
    IP Address: 111.111.234.193 (111.111.234.193)
    IP Address: 172.26.39.1 (172.26.39.1)
    IP Address: 172.26.15.1 (172.26.15.1)
    IP Address: 172.26.99.1 (172.26.99.1)
    IP Address: 172.26.41.1 (172.26.41.1)
    IP Address: 111.111.234.241 (111.111.234.241)
    Authentication string: `xxxxx'

No.     Time        Len   Source                Destination
Protocol Info
   6020 2.455066    210   172.26.22.12          224.0.0.18            VRRP
  Announcement (v2)

Frame 6020 (210 bytes on wire, 210 bytes captured)
Ethernet II, Src: IETF-VRRP-virtual-router-VRID_7a (00:00:5e:00:01:7a), Dst:
IPv4mcast_00:00:12 (01:00:5e:00:00:12)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 22
Internet Protocol, Src: 172.26.22.12 (172.26.22.12), Dst: 224.0.0.18
(224.0.0.18)
Virtual Router Redundancy Protocol
    Version 2, Packet type 1 (Advertisement)
    Virtual Rtr ID: 79
    Priority: 101 (Non-default backup priority)
    Count IP Addrs: 39
    Auth Type: No Authentication (0)
    Adver Int: 1
    Checksum: 0x1e7a [correct]
    IP Address: 111.111.234.190 (111.111.234.190)
    IP Address: 172.26.22.11 (172.26.22.11)
    IP Address: 111.111.234.196 (111.111.234.196)
    IP Address: 172.26.39.11 (172.26.39.11)
    IP Address: 111.111.234.212 (111.111.234.212)
    IP Address: 172.26.33.11 (172.26.33.11)
    IP Address: 111.111.234.132 (111.111.234.132)
    IP Address: 172.26.22.123 (172.26.22.123)
    IP Address: 111.111.234.133 (111.111.234.133)
    IP Address: 111.111.234.134 (111.111.234.134)
    IP Address: 111.111.234.136 (111.111.234.136)
    IP Address: 111.111.234.137 (111.111.234.137)
    IP Address: 172.26.22.124 (172.26.22.124)
    IP Address: 111.111.234.138 (111.111.234.138)
    IP Address: 111.111.234.139 (111.111.234.139)
    IP Address: 111.111.234.140 (111.111.234.140)
    IP Address: 111.111.234.141 (111.111.234.141)
    IP Address: 111.111.234.142 (111.111.234.142)
    IP Address: 172.26.22.122 (172.26.22.122) *** VRID 122 ***
    IP Address: 172.26.22.125 (172.26.22.125)
    IP Address: 172.26.22.126 (172.26.22.126)
    IP Address: 111.111.234.143 (111.111.234.143)
    IP Address: 111.111.234.146 (111.111.234.146)
    IP Address: 111.111.234.150 (111.111.234.150)
    IP Address: 111.111.234.152 (111.111.234.152)
    IP Address: 111.111.234.153 (111.111.234.153)
    IP Address: 172.26.22.154 (172.26.22.154)
    IP Address: 172.26.22.155 (172.26.22.155)
    IP Address: 111.111.234.144 (111.111.234.144)
    IP Address: 111.111.234.161 (111.111.234.161)
    IP Address: 111.111.234.162 (111.111.234.162)
    IP Address: 111.111.234.163 (111.111.234.163)
    IP Address: 111.111.234.164 (111.111.234.164)
    IP Address: 111.111.234.165 (111.111.234.165)
    IP Address: 111.111.234.166 (111.111.234.166)
    IP Address: 111.111.234.167 (111.111.234.167)
    IP Address: 111.111.234.168 (111.111.234.168)
    IP Address: 172.26.22.181 (172.26.22.181)
    IP Address: 111.111.234.155 (111.111.234.155)



Regards, Martin

MartinVisser99@gmail.com