On 04/04/16(Mon) 10:38, Florian Riehm wrote: > [...] > If using carp balancing we have to use the physical source mac of the carp > parent interface to avoid duplicate mac addresses. > If using carp failover we have to use the virtual mac address of the carp > interface to share the virtual mac address. > That means the source mac is depending on the carp mode. > In my opinion carp_start() is a good place for the distinction of cases, even > if > it's not optimal from the performance point of view. It puts the carp specific > logic to a central place and makes clear why this is necessary. > In the past we had this logic less obviously implemented in ether_output() and > it was broken certain times. Fixing one problem led to other problems... > So I would prefer a clear, robust solution over a minimal performance gain.
I agree, I'm just unsure what motived people to not set the carp mac to the same mac as the parent when configured in balancing in the first place. > We have two types of multicast packets if using carp balancing: > 1.) Carp Advertisements > They are regular multicast frames. That means it's layer 2 and layer 3 > multicast. > The kernel should be able to handle them like normal multicast. > 2.) Incoming balanced traffic > This is layer 2 multicast with layer 3 unicast inside. This is special and > requires some attention. > First let's think about the question "Why do we need the multicast bit for > incoming traffic"? > We don't need this Flag! Switches need the flag to distribute the traffic to > all > ports. From this point of view it's maybe not that bad to remove the bit in > incoming packets as early as possible, like it's done in carp_input() already. > For the outgoing path the multicast bit is only relevant if we send arp > replies. > They have to look like this: > 08:00:27:df:cb:d2 08:00:27:65:ad:48 0806 42: arp reply 10.188.1.17 is-at > 01:00:5e:00:01:01 > Note that the multicast address is used only inside the arp packet, > NOT inside the ethernet header. This means it can not be added in carp_start() > and we will definitely need CARP specific part while creating arp replies. Why does you think it cannot be added to carp_start()? Sending ARP reply is just like the rest of the stack, it uses if_output() which ends up in carp_start()... unless the parent is answering the echo request which means we have a problem in our input path because carp_input() runs before in_arpinput(). > I'm working on a proof-of-concept to see if my idea works. Nice!
