From stephen.nadas@ericsson.com Mon Jan 11 05:07:56 2010 Return-Path: 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 9863F3A69B9 for ; Mon, 11 Jan 2010 05:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 cH7A0PRjJu1f for ; Mon, 11 Jan 2010 05:07:55 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B5F803A67A1 for ; Mon, 11 Jan 2010 05:07:55 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o0BD7wJY006130; Mon, 11 Jan 2010 07:07:59 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.164]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 11 Jan 2010 08:07:51 -0500 From: Stephen Nadas To: Felix Lin Date: Mon, 11 Jan 2010 08:07:50 -0500 Thread-Topic: Question on IPv6 VRRPv3 Advertisement packet's MAC address Thread-Index: AcqQxVSV0xd7zxkbR0iEJXjer/0fyQB9wu1Q Message-ID: <450AE4BEC513614F96969DDA34F359340D1D40C6A6@EUSAACMS0701.eamcs.ericsson.se> References: <0A90A9E77DCAA343A585A34B324909510685B5F18E@HQ-EXCH-7.corp.brocade.com> In-Reply-To: <0A90A9E77DCAA343A585A34B324909510685B5F18E@HQ-EXCH-7.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_450AE4BEC513614F96969DDA34F359340D1D40C6A6EUSAACMS0701e_" MIME-Version: 1.0 Cc: "vrrp@ietf.org" Subject: Re: [VRRP] Question on IPv6 VRRPv3 Advertisement packet's MAC address X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 13:07:56 -0000 --_000_450AE4BEC513614F96969DDA34F359340D1D40C6A6EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Felix, It's better to such a question to vrrp list. Thanks, Steve ________________________________ From: Felix Lin [mailto:flin@brocade.com] Sent: Friday, January 08, 2010 7:48 PM To: Stephen Nadas Subject: Question on IPv6 VRRPv3 Advertisement packet's MAC address Hi Stephen, We are implementing IPv6 VRRPv3 right now. Should the destination MAC addre= ss (on Ethernet) of VRRPv3 Advertisement packets be 33-33-00-00-00-12 (in H= EX)? Thanks, Felix --_000_450AE4BEC513614F96969DDA34F359340D1D40C6A6EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Felix,

It's better to such a question to vrrp list.=20

Thanks,

Steve

From: Felix Lin [mailto:flin@brocade.= com]=20
Sent: Friday, January 08, 2010 7:48 PM
To: Stephen=20 Nadas
Subject: Question on IPv6 VRRPv3 Advertisement packet's M= AC=20 address

Hi Stephen,

We are implementing IPv6 VRRPv3 right now. Should th= e=20 destination MAC address (on Ethernet) of VRRPv3 Advertisement packets be= =20 33-33-00-00-00-12 (in HEX)?

Thanks,

Felix

--_000_450AE4BEC513614F96969DDA34F359340D1D40C6A6EUSAACMS0701e_-- From flin@brocade.com Fri Jan 15 11:37:17 2010 Return-Path: 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 EF8C63A67D1 for ; Fri, 15 Jan 2010 11:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.873, BAYES_00=-2.599, 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 Sl5z+NX+Waob for ; Fri, 15 Jan 2010 11:37:17 -0800 (PST) Received: from hq-exedge.brocade.com (hq-exedge.brocade.com [66.243.153.82]) by core3.amsl.com (Postfix) with ESMTP id 419E93A67A3 for ; Fri, 15 Jan 2010 11:37:17 -0800 (PST) Received: from hq-exchfe-4.corp.brocade.com (192.168.39.133) by HQ-EXEDGE-1.corp.brocade.com (192.168.39.207) with Microsoft SMTP Server (TLS) id 8.2.213.0; Fri, 15 Jan 2010 11:37:11 -0800 Received: from HQ-EXCH-7.corp.brocade.com ([fe80::7100:82a1:1c93:b398]) by hq-exchfe-4.corp.brocade.com ([192.168.39.133]) with mapi; Fri, 15 Jan 2010 11:37:14 -0800 From: Felix Lin To: "vrrp@ietf.org" Date: Fri, 15 Jan 2010 11:37:12 -0800 Thread-Topic: Any known IPv6 VRRPv3 implementation? Thread-Index: AcqWGSiTv8eH6eEQRZO8Bdiea5p7cgAAOgOA Message-ID: <0A90A9E77DCAA343A585A34B324909510685D9398D@HQ-EXCH-7.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0A90A9E77DCAA343A585A34B324909510685D9398DHQEXCH7corpbr_" MIME-Version: 1.0 Subject: [VRRP] Any known IPv6 VRRPv3 implementation? X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 19:38:35 -0000 --_000_0A90A9E77DCAA343A585A34B324909510685D9398DHQEXCH7corpbr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Do anyone know of any IPv6 VRRPv3 implementation currently in the market ? Thanks, Felix --_000_0A90A9E77DCAA343A585A34B324909510685D9398DHQEXCH7corpbr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Do anyone know of any IPv6 VRRPv3 implementation curre= ntly in the market ?

Thanks,

Felix

--_000_0A90A9E77DCAA343A585A34B324909510685D9398DHQEXCH7corpbr_-- From johcruz@cisco.com Fri Jan 15 11:46:33 2010 Return-Path: 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 583E23A6925 for ; Fri, 15 Jan 2010 11:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 umO0MCbfTzaq for ; Fri, 15 Jan 2010 11:46:32 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 946EA3A676A for ; Fri, 15 Jan 2010 11:46:32 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAMZUUEurR7Hu/2dsb2JhbACCFcNOlRaEMQQ X-IronPort-AV: E=Sophos;i="4.49,284,1262563200"; d="scan'208,217";a="233258207" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 15 Jan 2010 19:46:29 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0FJkTpP022541; Fri, 15 Jan 2010 19:46:29 GMT Received: from xmb-sjc-22a.amer.cisco.com ([128.107.191.81]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 11:46:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA961B.6DD7E793" Date: Fri, 15 Jan 2010 11:46:27 -0800 Message-ID: <9D0602B62D632D499E0A26CBCDA74A7D06BE39AD@xmb-sjc-22a.amer.cisco.com> In-Reply-To: <0A90A9E77DCAA343A585A34B324909510685D9398D@HQ-EXCH-7.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [VRRP] Any known IPv6 VRRPv3 implementation? Thread-Index: AcqWGSiTv8eH6eEQRZO8Bdiea5p7cgAAOgOAAABS9fA= References: <0A90A9E77DCAA343A585A34B324909510685D9398D@HQ-EXCH-7.corp.brocade.com> From: "John Cruz (johcruz)" To: "Felix Lin" , X-OriginalArrivalTime: 15 Jan 2010 19:46:29.0733 (UTC) FILETIME=[6E99B150:01CA961B] Subject: Re: [VRRP] Any known IPv6 VRRPv3 implementation? X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 19:46:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA961B.6DD7E793 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nokia had an implementation back in 2005. =20 John =20 From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Felix Lin Sent: Friday, January 15, 2010 11:37 AM To: vrrp@ietf.org Subject: [VRRP] Any known IPv6 VRRPv3 implementation? =20 Hi, =20 Do anyone know of any IPv6 VRRPv3 implementation currently in the market ? =20 Thanks, =20 Felix =20 ------_=_NextPart_001_01CA961B.6DD7E793 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nokia had an = implementation back in 2005.

John

From:= vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of = Felix Lin
Sent: Friday, January 15, 2010 11:37 AM
To: vrrp@ietf.org
Subject: [VRRP] Any known IPv6 VRRPv3 = implementation?

Hi,

Do anyone know of any IPv6 VRRPv3 implementation = currently in the market ?

Thanks,

Felix

------_=_NextPart_001_01CA961B.6DD7E793-- From martinvisser99@gmail.com Sun Jan 31 16:48:26 2010 Return-Path: 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 ; 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 ; 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 ; Sun, 31 Jan 2010 16:48:24 -0800 (PST) Received: by pzk36 with SMTP id 36so4538973pzk.5 for ; 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, 1 Feb 2010 11:48:54 +1100 Message-ID: From: Martin Visser 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 00:53:28 -0000 --0016e6480ebe838ac0047e7f59fe Content-Type: text/plain; charset=UTF-8 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 --0016e6480ebe838ac0047e7f59fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

I have a question related to a problem th= at took a lot of time to solve. My customer has a set of firewalls and a se= t of load-balancers that use VRRP to provide redundancy for the gateway add= resses and the virtual IPs they serve up. The vendor (the same for both, bu= t 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 l= east on this one VLAN 22) - the firewall is configured to use VRID 255 and = the load-balancer uses VRID 79.=C2=A0

What I found is curious is that the the source MAC addr= ess 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 -=C2=A0111.111.234.12= 9 on the firewall, and=C2=A0172.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=C2= =A0misconfiguration, which we now recognise. However the question remains i= s that the actual VRID 122 is never mentioned on the wire in any of the VRR= P advertisements so why is the derived MAC address,=C2=A000:00:5e:00:01:7a,= used instead of=C2=A000:00:5e:00:01:ff and=C2=A000:00:5e:00:01:45 (for VRI= Ds 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 VR= RP group VRID accross multiple VLANs. Thus if they used the configured grou= p 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 th= e firewalls were using the same source MAC as the load-balancer that we fou= nd 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=C2=A0

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 usi= ng a similar arrangement when send VRRP group advertisements. (The exact al= gorithm 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 rou= ter IP address from which the used source MAC address is derived.

No. =C2=A0 =C2=A0 Ti= me =C2=A0 =C2=A0 =C2=A0 =C2=A0Len =C2=A0 Source =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Protocol Info

=C2=A0=C2=A0 4723 2.375135 =C2=A0 =C2=A0122 =C2=A0 = 111.111.234.130 =C2=A0 =C2=A0 =C2=A0 =C2=A0224.0.0.18 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0VRRP =C2=A0 =C2=A0 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

=C2=A0=C2=A0 =C2=A0Versio= n 2, Packet type 1 (Advertisement)

=C2=A0=C2=A0 =C2=A0Virtual Rtr= ID: 255

=C2=A0=C2=A0 =C2=A0Priority: 118 (Non-default backup pri= ority)

=C2=A0=C2=A0 =C2=A0Count IP Addrs: 18

=C2=A0=C2=A0 =C2=A0Auth Type: Simple Text Authentication [RFC 2338] / = Reserved [RFC 3768] (1)

=C2=A0=C2=A0 =C2=A0Adver Int: 1

=C2=A0=C2=A0 =C2=A0Checksum: 0xd785 [correct]

=C2=A0=C2=A0 =C2= =A0IP Address: 172.26.18.30 (172.26.18.30)

=C2=A0=C2=A0 =C2=A0IP = Address: 172.26.30.10 (172.26.30.10)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.129 (111.111.234.129) =C2= =A0*** VRID 122 ***

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.22.1 (1= 72.26.22.1)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.65 (111.11= 1.234.65)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.20.1 (172.26.20.1= )

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.225 (111.111.234.225)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.32.1 (172.26.32.1)

=C2= =A0=C2=A0 =C2=A0IP Address: 111.111.234.25 (111.111.234.25)

=C2= =A0=C2=A0 =C2=A0IP Address: 172.26.21.1 (172.26.21.1)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.209 (111.111.234.209)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.33.1 (172.26.33.1)

=C2= =A0=C2=A0 =C2=A0IP Address: 111.111.234.193 (111.111.234.193)

=C2= =A0=C2=A0 =C2=A0IP Address: 172.26.39.1 (172.26.39.1)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.15.1 (172.26.15.1)

=C2= =A0=C2=A0 =C2=A0IP Address: 172.26.99.1 (172.26.99.1)

=C2=A0=C2= =A0 =C2=A0IP Address: 172.26.41.1 (172.26.41.1)

=C2=A0=C2=A0 =C2= =A0IP Address: 111.111.234.241 (111.111.234.241)

=C2=A0=C2=A0 =C2=A0Authentication string: `xxxxx'

<= div>No. =C2=A0 =C2=A0 Time =C2=A0 =C2=A0 =C2=A0 =C2=A0Len =C2=A0 Source =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Protocol Info

=C2=A0=C2=A0 6020 2.455066= =C2=A0 =C2=A0210 =C2=A0 172.26.22.12 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0224= .0.0.18 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VRRP =C2=A0 =C2=A0 Announc= ement (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

=C2=A0= =C2=A0 =C2=A0Version 2, Packet type 1 (Advertisement)

=C2=A0=C2= =A0 =C2=A0Virtual Rtr ID: 79

=C2=A0=C2=A0 =C2=A0Priority: 101 (Non-default backup priority)

=C2=A0=C2=A0 =C2=A0Count IP Addrs: 39

=C2=A0=C2=A0 =C2=A0Auth = Type: No Authentication (0)

=C2=A0=C2=A0 =C2=A0Adver Int: 1

=C2=A0=C2=A0 =C2=A0Checksum: 0x1e7a [correct]

=C2=A0=C2=A0 = =C2=A0IP Address: 111.111.234.190 (111.111.234.190)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.22.11 (172.26.22.11)

= =C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.196 (111.111.234.196)

= =C2=A0=C2=A0 =C2=A0IP Address: 172.26.39.11 (172.26.39.11)

=C2=A0= =C2=A0 =C2=A0IP Address: 111.111.234.212 (111.111.234.212)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.33.11 (172.26.33.11)

= =C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.132 (111.111.234.132)

= =C2=A0=C2=A0 =C2=A0IP Address: 172.26.22.123 (172.26.22.123)

=C2= =A0=C2=A0 =C2=A0IP Address: 111.111.234.133 (111.111.234.133)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.134 (111.111.234.134)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.136 (111.111.234.136)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.137 (111.111.234.137)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.22.124 (172.26.22.124)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.138 (111.111.234.138)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.139 (111.111.234.139)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.140 (111.111.234.140)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.141 (111.111.234.141)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.142 (111.111.234.142)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.22.122 (172.26.22.122) *** VRID = 122 ***

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.22.125 (172.26.22.1= 25)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.22.126 (172.26.22.126)<= /div>

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.143 (111.111.234.143)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.146 (111.111.234.146)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.150 (111.111.234.150)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.152 (111.111.234.152)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.153 (111.111.234.153)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.22.154 (172.26.22.154)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.22.155 (172.26.22.155)

=C2= =A0=C2=A0 =C2=A0IP Address: 111.111.234.144 (111.111.234.144)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.161 (111.111.234.161)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.162 (111.111.234.162)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.163 (111.111.234.163)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.164 (111.111.234.164)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.165 (111.111.234.165)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.166 (111.111.234.166)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.167 (111.111.234.167)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.168 (111.111.234.168)

=C2=A0=C2=A0 =C2=A0IP Address: 172.26.22.181 (172.26.22.181)

=C2=A0=C2=A0 =C2=A0IP Address: 111.111.234.155 (111.111.234.155)

Regards, Martin

MartinVisser99@gmail.com
--0016e6480ebe838ac0047e7f59fe--