Hello all,
I would like to use LVS Direct Routing configuration on IPv6
but I encountered a problem as described below.
I'm now going to fix it but I've found that there may be a several
arguments to decide how it should be fix, so
I would like to ask everybody's opinion before I proceed.
Please give me your thoughts, comments about how we should fix it.
Symptom:
On IPv4, I have been using IPaddr2 RA for LVS DR and it works like a charm.
On IPv6, I tried to use IPv6addr RA for the virtual IPv6
address with a similar configuration as IPv4 but
the address would not become reachable from another node.
The ip command shows that the duplicate address has assigned to both lo
and ethX and one has 'dadfailed' flag (Duplicate Address Detection
defined in RFC4862).
# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
inet6 2004::210/128 scope global
valid_lft forever preferred_lft forever
(...)
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state
UP qlen 1000
inet6 2004::210/64 scope global tentative dadfailed
valid_lft forever preferred_lft forever
Arguments:
1) Which RA should be improved? IPaddr2 or IPv6addr?
Obviously we have two approaches to fix this and each has pros/cons.
a) improve IPadd2 to support IPv4/IPv6 dual stack
b) improve IPv6addr to remove a duplicate IPv6 address on the loopback.
As for a),
pros: easy to maintain as a single code base.
uniform behavior between IPv4/IPv6 since ip command already
supports dual stack.
cons: it changes the policy of the recommended RA for IPv6 on Linux.
need a new binary for the replacement of send_arp for IPv6.
As for b),
pros: no changes for the existing IPaddr2.
cons: need to implement "lvs_support=true" equivalent feature in C,
which may make the code to maintain harder.
2) Is "lvs_support=true" functionality really necessary?
When I use IPaddr2 for LVS on IPv4, it's been working perfectly
*without* "lvs_support=true".
In this case the same IP addresses are assigned to both lo and ethX, and
still works everything fine.
Addition to this, the latest IPaddr2 has a bug and it does not
remove the IP address on lo even if "lvs_support=true".
This was reported once before:
http://www.gossamer-threads.com/lists/linuxha/pacemaker/71106#71106
On IPv6, I also tried assigning an IPv6 address to both lo and ethX by ip
command manually, and it seems to work fine as same as IPv4.
The weird 'dadfailed' flag was not seen when I use ip command.
Proposed solution:
As considering all arguments above, I would like to suggest the
following modification:
- improve IPaddr2 as IPv4/IPv6 dual stack support.
- recommend to use IPaddr2 both for IPv4/IPv6 on Linux in the future.
IPaddr/IPv6addr would be only left for legacy and cross platform support.
- "lvs_support=true" option would be deprecated and no longer necessary.
Any opinions, suggestions are appreciated.
I will work on it after we all agree on how we should fix it.
Regards,
Keisuke MORI
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
I would like to use LVS Direct Routing configuration on IPv6
but I encountered a problem as described below.
I'm now going to fix it but I've found that there may be a several
arguments to decide how it should be fix, so
I would like to ask everybody's opinion before I proceed.
Please give me your thoughts, comments about how we should fix it.
Symptom:
On IPv4, I have been using IPaddr2 RA for LVS DR and it works like a charm.
On IPv6, I tried to use IPv6addr RA for the virtual IPv6
address with a similar configuration as IPv4 but
the address would not become reachable from another node.
The ip command shows that the duplicate address has assigned to both lo
and ethX and one has 'dadfailed' flag (Duplicate Address Detection
defined in RFC4862).
# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
inet6 2004::210/128 scope global
valid_lft forever preferred_lft forever
(...)
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state
UP qlen 1000
inet6 2004::210/64 scope global tentative dadfailed
valid_lft forever preferred_lft forever
Arguments:
1) Which RA should be improved? IPaddr2 or IPv6addr?
Obviously we have two approaches to fix this and each has pros/cons.
a) improve IPadd2 to support IPv4/IPv6 dual stack
b) improve IPv6addr to remove a duplicate IPv6 address on the loopback.
As for a),
pros: easy to maintain as a single code base.
uniform behavior between IPv4/IPv6 since ip command already
supports dual stack.
cons: it changes the policy of the recommended RA for IPv6 on Linux.
need a new binary for the replacement of send_arp for IPv6.
As for b),
pros: no changes for the existing IPaddr2.
cons: need to implement "lvs_support=true" equivalent feature in C,
which may make the code to maintain harder.
2) Is "lvs_support=true" functionality really necessary?
When I use IPaddr2 for LVS on IPv4, it's been working perfectly
*without* "lvs_support=true".
In this case the same IP addresses are assigned to both lo and ethX, and
still works everything fine.
Addition to this, the latest IPaddr2 has a bug and it does not
remove the IP address on lo even if "lvs_support=true".
This was reported once before:
http://www.gossamer-threads.com/lists/linuxha/pacemaker/71106#71106
On IPv6, I also tried assigning an IPv6 address to both lo and ethX by ip
command manually, and it seems to work fine as same as IPv4.
The weird 'dadfailed' flag was not seen when I use ip command.
Proposed solution:
As considering all arguments above, I would like to suggest the
following modification:
- improve IPaddr2 as IPv4/IPv6 dual stack support.
- recommend to use IPaddr2 both for IPv4/IPv6 on Linux in the future.
IPaddr/IPv6addr would be only left for legacy and cross platform support.
- "lvs_support=true" option would be deprecated and no longer necessary.
Any opinions, suggestions are appreciated.
I will work on it after we all agree on how we should fix it.
Regards,
Keisuke MORI
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/