Re: [Keepalived-devel] VMAC, vmac_xmit_base, and IGMP

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Quentin Armitage <quentin <at> armitage.org.uk> writes:
> 
> 
> RFC 3768 states at paragraph 7.2 that VRRP advertisements must use the
Virtual Router MAC address, and the proposed change would appear to break that.
> Would the solution here be to use the underlying interface for receiving
multicast advertisements, and hence the IGMP join message will be sent with
the MAC address of the underlying interface, and to use the vmac interface
for transmitting advertisements.
> An alternative would be to use a single socket for listening for all the
VRRP multicasts, and the code does an IP_ADD_MEMEBERSHIP specifying the
ifindex for each underlying interface on which it wants to listen, and then
only one socket is needed for each vmac interface, which is only used for
sending gratuitous ARPs and advertisements.
> Quentin Armitage
> On Tue, 2014-07-22 at 12:54 +0200, Alexandre Cassen wrote:
> 
> 
> Hi Patrick,
> 
> just back to you :) (well ok, long delay :D)
> 
> You right, if someone planes to use VMAC it MUST consider using
vmac_xmit_base. Simply because there is a huge semantic difference between
using interface to carry on signalling protocol frames and VRRP VIP related
traffic. VRRP protocol frames MUST run over physical rather than VRRP VIP
traffic on VMAC interface.
> 
> I think vmac_xmit_base MUST be on by default. I am considering switching
this in core code.
> 
> regs,
> Alexandre
> 
> 
> On 25 Jun 2014, at 17:40, Patrick Schaaf <netdev <at> bof.de> wrote:
> 
> > Hello Alexandre,
> > 
> > On Monday 23 June 2014 13:52:47 Alexandre Cassen wrote:
> >> 
> >> Well, some switch are updating their CAM according to IGMP join msg (cisco
> >> are doing it), so if you are using switch like that vmac_xmit_base must be
> >> used.
> > 
> > Isn't that just the normal switch source MAC learning in action there?
i.e. it 
> > will happen on just about any switch in existence?
> > 
> > Is there an exception in the ethernet standards that disables (should
disable) 
> > source MAC learning for IGMP multicast (or general multicast)?
> > 
> > best regards
> >  Patrick
> > 
> >> On 27 May 2014, at 17:44, Patrick Schaaf <netdev <at> bof.de> wrote:
> >>> Hi,
> >>> 
> >>> "playing" with the VMAC feature on a keepalived 1.2.13 driven cluster of
> >>> balancers, I noticed a peculiar "feature" that I saw no mention of in the
> >>> documentation. Thought I'd note it here...
> >>> 
> >>> I am running a ping to the VRRP address from an internal host. Then I
> >>> restart one of the BACKUP keepaliveds. And notice a single ping to
> >>> receive an "ICMP host unreachable" reply with source the IP address of
> >>> that BACKUP balancer.
> >>> 
> >>> Looking into it with tcpdump, I notice that when the daemon starts, it
> >>> sends IGMP messages with source MAC the VMAC - thus teaching the switch,
> >>> for a short while, that it would like to have packets for the VMAC.
> >>> 
> >>> Adding vmac_xmit_base to the configuration fixes the issue - the IGMP
> >>> messages are then sent with the base interface source MAC address.
> >>> 
> >>> In practise the "error interval" will probably be smaller, due to the
> >>> MASTER balancer more continuously sending packets with VMAC source - my
> >>> test setup has no operational traffic or I probably wouldn't have
> >>> noticed.
> >>> 
> >>> I don't know whether this could be considered a bug, or at what priority,
> >>> or what to do about it, except maybe adding another reason in the docs
> >>> why vmac_xmit_base might be a good idea.
> >>> 
> >>> I'll close with a curious question: are there reasons why vmac_xmit_base
> >>> is
> >>> NOT a good idea?
> >>> 
> >>> best regards
> >>> 
> >>> Patrick
> >>> 
> >>> --------------------------------------------------------------------------
> >>> ---- The best possible search technologies are now affordable for all
> >>> companies. Download your FREE open source Enterprise Search Engine today!
> >>> Our experts will assist you in its installation for $59/mo, no commitment.
> >>> Test it for FREE on our Cloud platform anytime!
> >>> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clkt
> >>> rk _______________________________________________
> >>> Keepalived-devel mailing list
> >>> Keepalived-devel <at> lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
> > 
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Keepalived-devel mailing list
> Keepalived-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> 
> _______________________________________________
> Keepalived-devel mailing list
> Keepalived-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
> 

Hi folks, following up on this thread.

With vmac_xmit_base set, I see VRRP advertisements in this form (2.2.2.3
being the physical IP):

14:39:52 66:0e:94:13:d1:ab > 01:00:5e:00:00:12, ethertype IPv4 (0x0800),
length 46: 2.2.2.3 > 224.0.0.18: VRRPv3, Advertisement

and without it:

14:40:21.737169 00:00:5e:00:01:05 > 01:00:5e:00:00:12, ethertype IPv4
(0x0800), length 46: 2.2.2.3 > 224.0.0.18: VRRPv3, Advertisement

As pointed out a in an earlier email, the latter complies to the RFC which
makes it possible to use keepalived with other VRRPv3 implementations such
as Solaris' VRRP.
The problem I then run into (also mentioned earlier in this thread) are IGMP
reports. I still see the VMAC being reported as the source mac for the
physical interface even when keepalived is in backup mode:

14:50:35 64:0e:94:18:01:a3 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800),
length 56: 0.0.0.0 > 224.0.0.1:  igmp query v3 [max resp time 1.0s]
14:50:36 66:0e:94:82:bf:49 > 01:00:5e:00:00:16, ethertype IPv4 (0x0800),
length 56: 2.2.2.2 > 224.0.0.22: igmp v3 report, 1 group record(s)
14:50:36 00:00:5e:00:01:05 > 01:00:5e:00:00:16, ethertype IPv4 (0x0800),
length 54: 2.2.2.3 > 224.0.0.22: igmp v3 report, 1 group record(s) <--

Any ideas on how to address this?

Thanks,
Rafael