Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Fix Version/s: Vz7.0-Update19
-
Component/s: Containers::Kernel
-
Security Level: Public
-
Environment:vzkernel 3.10.0-1160.80.1.vz7.191.4
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.bond0.forwarding = 1
net.ipv6.conf.bond0/10.forwarding = 1
net.ipv6.conf.bond0/6.forwarding = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.eth0.forwarding = 1
net.ipv6.conf.eth1.forwarding = 1
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.venet0.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1
net.ipv6.conf.bond0.proxy_ndp = 0
net.ipv6.conf.bond0/10.proxy_ndp = 0
net.ipv6.conf.bond0/6.proxy_ndp = 0
net.ipv6.conf.default.proxy_ndp = 0
net.ipv6.conf.eth0.proxy_ndp = 0
net.ipv6.conf.eth1.proxy_ndp = 0
net.ipv6.conf.lo.proxy_ndp = 0
net.ipv6.conf.venet0.proxy_ndp = 0
vzkernel 3.10.0-1160.80.1.vz7.191.4 net.ipv6.conf.all.forwarding = 1 net.ipv6.conf.bond0.forwarding = 1 net.ipv6.conf.bond0/10.forwarding = 1 net.ipv6.conf.bond0/6.forwarding = 1 net.ipv6.conf.default.forwarding = 1 net.ipv6.conf.eth0.forwarding = 1 net.ipv6.conf.eth1.forwarding = 1 net.ipv6.conf.lo.forwarding = 1 net.ipv6.conf.venet0.forwarding = 1 net.ipv6.conf.all.proxy_ndp = 1 net.ipv6.conf.bond0.proxy_ndp = 0 net.ipv6.conf.bond0/10.proxy_ndp = 0 net.ipv6.conf.bond0/6.proxy_ndp = 0 net.ipv6.conf.default.proxy_ndp = 0 net.ipv6.conf.eth0.proxy_ndp = 0 net.ipv6.conf.eth1.proxy_ndp = 0 net.ipv6.conf.lo.proxy_ndp = 0 net.ipv6.conf.venet0.proxy_ndp = 0
-
Fixed in Build:vzkernel-3.10.0-1160.105.1.vz7.220.2
Description
>Description of problem:
NDP proxy does not work, therefore, Ipv6 addresses of the container are not available
>Steps to Reproduce:
In the normal case, when adding Ipv6, the following operations are performed:
1. The route to the IPv6 address is added to the main routing table with the command:
route ip -6 add $IPv6 dev venet0
2. An IPv6 address is added to the proxy table using the commands:
ip -6 neigh add proxy $IPv6 dev bond0
ip -6 neigh add proxy $IPv6 dev bond0.6
ip -6 neigh add proxy $IPv6 dev bond0.10
Now when neighbor solicitation requests arrive on the external interfaces bond0, bond0.6 and bond0.10, indicating "who has $IPv6", the node will have to respond with a neighbor advertisement packet indicating the MAC the address of the external interface.
>Actual results:
The NDP proxy functionality does not work and the node simply does not respond to the neighbor solicitation request. The IPv6 router cannot get the MAC address of the node on which the container with the desired IPv6 address is located and therefore cannot send a request
As a result, the IPv6 address is unavailable
>Expected results:
IPv6 address is available and responding to requests
When loading a node with an older kernel, for example on 3.10.0-1160.53.1.vz7.185.3, the problem does not reproduce and Ipv6 works correctly
NDP proxy does not work, therefore, Ipv6 addresses of the container are not available
>Steps to Reproduce:
In the normal case, when adding Ipv6, the following operations are performed:
1. The route to the IPv6 address is added to the main routing table with the command:
route ip -6 add $IPv6 dev venet0
2. An IPv6 address is added to the proxy table using the commands:
ip -6 neigh add proxy $IPv6 dev bond0
ip -6 neigh add proxy $IPv6 dev bond0.6
ip -6 neigh add proxy $IPv6 dev bond0.10
Now when neighbor solicitation requests arrive on the external interfaces bond0, bond0.6 and bond0.10, indicating "who has $IPv6", the node will have to respond with a neighbor advertisement packet indicating the MAC the address of the external interface.
>Actual results:
The NDP proxy functionality does not work and the node simply does not respond to the neighbor solicitation request. The IPv6 router cannot get the MAC address of the node on which the container with the desired IPv6 address is located and therefore cannot send a request
As a result, the IPv6 address is unavailable
>Expected results:
IPv6 address is available and responding to requests
When loading a node with an older kernel, for example on 3.10.0-1160.53.1.vz7.185.3, the problem does not reproduce and Ipv6 works correctly
