Hello Stefan,
As a response to your latest email, the second solution seems the best to have.
As a general response, not related to this topic in particular, there is no single/correct solution for a requirement. What suits you best is acceptable and if it accomplishes the requirements then it should be accepted.
Alex V
On Thursday, October 8, 2015 2:21 PM, Stefan Sicleru <Stefan.Sicleru@xxxxxxxx> wrote:
Hello Alex,
> Subject: Re: [CGL 5.0] [CAF.2.1] [Enea Linux] Ethernet MAC address takeover
>
> Hello Stefan,
>
> I believe you are missing the point here. I actually mentioned: "In large networks it is disadvantageous to modify IP address – Media Access Control (MAC) pairs,
> because there could be certain routers which do not refresh their arp cache". So I am talking here about a slim possibility of having a router which doesn`t know
> how to refresh its ARP table. In my opinion this is the safest assumption and this is why the scenario of same IP same MAC is used in the fail-over functionality
> but this is actually only an example I wanted to present with the hope that the notion will be better understood.
Why do you think that ARP cache is needed on routers? Please correct me if I am wrong, but ARP tables from routers are not needed at all in
the process of communication between two or several computers through at least one router.Neither clients nor the cluster use the ARP table from the
routers. Because neither clients nor the cluster talk directly to the router (they don't have packets targeting the IP stack running on the router). The only
place where ARP packets are exchanged is between the clients and their first gateway (to learn the MAC address of their gateway) and between clusters
and their local gateway (to learn the MAC address of their local gateway). But router's ARP table is not involved anywhere. I may be missing something
here.
>
> I would now kindly advise you read carefully the attached links since they might offer more information on this subject. Next you can try and figure out how
> to tackle this task.
> I will also present you with some other details, maybe this way the information will become more clear:
> Pacemaker - resource manager; starts and stops the services, also contains the logic for ensuring their execution
> Heartbeat and Corosync - are both messaging layers; ensuring that the nodes can talk to one another
>
> The idea is that with only Pacemaker your failover functionality might not be complete. Using pacemaker + corosync or pacemaker + heartbeat is your choice.
> From what I read the heartbeat solution is actually maintained by Linbit but it has become deprecated so the best option seems to be the first suggested option.
>
> Another useful link: http://serverfault.com/questions/456501/newbie-questions-on-mac-and-high-availability-failovers
This is a good one. It's basically the same question I've had in my first e-mail. And this is the reason behind this thread of discussion.
Looking at the "best" answer (as marked by the question owner), they have the following conclusion:
* first solution would be to provide a _virtual_MAC_address_ by clustering software
* second solution would be to rely on gratuitous ARP the whole way and leave the new MACs in place.
I would vote for the second solution, but there is a CGL requirement that also looks for the first solution.
I have mentioned in my previous e-mail that pacemaker (plus corosync, crm, the whole clustering ecosystem) offers such a
mechanism of having a _virtual_MAC_ thay you may associate with an IP. The problem I am concerned of is that the virtual MAC is
actually a _multicast_MAC_, shared among all the nodes within the cluster. Or at least this is what pacemaker documentation
talks about [1] - check first paragraph.
So, I'm reiterating my initial question. It this solution acceptable? Or should we focus on cloning the unicast MAC address of the
failed nodes?
>
> Hope I was able to offer clarifications to my previous email.
What do you think, Alex? Is this acceptable? Having a virtual (actually multicast) MAC address in place?
Warm regards,
Stefan
--
[1] http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/_clone_the_ip_address.html
> Subject: Re: [CGL 5.0] [CAF.2.1] [Enea Linux] Ethernet MAC address takeover
>
> Hello Stefan,
>
> I believe you are missing the point here. I actually mentioned: "In large networks it is disadvantageous to modify IP address – Media Access Control (MAC) pairs,
> because there could be certain routers which do not refresh their arp cache". So I am talking here about a slim possibility of having a router which doesn`t know
> how to refresh its ARP table. In my opinion this is the safest assumption and this is why the scenario of same IP same MAC is used in the fail-over functionality
> but this is actually only an example I wanted to present with the hope that the notion will be better understood.
Why do you think that ARP cache is needed on routers? Please correct me if I am wrong, but ARP tables from routers are not needed at all in
the process of communication between two or several computers through at least one router.Neither clients nor the cluster use the ARP table from the
routers. Because neither clients nor the cluster talk directly to the router (they don't have packets targeting the IP stack running on the router). The only
place where ARP packets are exchanged is between the clients and their first gateway (to learn the MAC address of their gateway) and between clusters
and their local gateway (to learn the MAC address of their local gateway). But router's ARP table is not involved anywhere. I may be missing something
here.
>
> I would now kindly advise you read carefully the attached links since they might offer more information on this subject. Next you can try and figure out how
> to tackle this task.
> I will also present you with some other details, maybe this way the information will become more clear:
> Pacemaker - resource manager; starts and stops the services, also contains the logic for ensuring their execution
> Heartbeat and Corosync - are both messaging layers; ensuring that the nodes can talk to one another
>
> The idea is that with only Pacemaker your failover functionality might not be complete. Using pacemaker + corosync or pacemaker + heartbeat is your choice.
> From what I read the heartbeat solution is actually maintained by Linbit but it has become deprecated so the best option seems to be the first suggested option.
>
> Another useful link: http://serverfault.com/questions/456501/newbie-questions-on-mac-and-high-availability-failovers
This is a good one. It's basically the same question I've had in my first e-mail. And this is the reason behind this thread of discussion.
Looking at the "best" answer (as marked by the question owner), they have the following conclusion:
* first solution would be to provide a _virtual_MAC_address_ by clustering software
* second solution would be to rely on gratuitous ARP the whole way and leave the new MACs in place.
I would vote for the second solution, but there is a CGL requirement that also looks for the first solution.
I have mentioned in my previous e-mail that pacemaker (plus corosync, crm, the whole clustering ecosystem) offers such a
mechanism of having a _virtual_MAC_ thay you may associate with an IP. The problem I am concerned of is that the virtual MAC is
actually a _multicast_MAC_, shared among all the nodes within the cluster. Or at least this is what pacemaker documentation
talks about [1] - check first paragraph.
So, I'm reiterating my initial question. It this solution acceptable? Or should we focus on cloning the unicast MAC address of the
failed nodes?
>
> Hope I was able to offer clarifications to my previous email.
What do you think, Alex? Is this acceptable? Having a virtual (actually multicast) MAC address in place?
Warm regards,
Stefan
--
[1] http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/_clone_the_ip_address.html
_______________________________________________ Lf_carrier mailing list Lf_carrier@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/lf_carrier
