From: Sun Shouxin <hidden> Date: 2021-12-24 14:26:27
Since ipv6 neighbor solicitation and advertisement messages
isn't handled gracefully in bonding6 driver, we can see packet
drop due to inconsistency bewteen mac address in the option
message and source MAC .
Another examples is ipv6 neighbor solicitation and advertisement
messages from VM via tap attached to host brighe, the src mac
mighe be changed through balance-alb mode, but it is not synced
with Link-layer address in the option message.
The patch implements bond6's tx handle for ipv6 neighbor
solicitation and advertisement messages.
Suggested-by: Hu Yadi <redacted>
Reported-by: kernel test robot <redacted>
Signed-off-by: Sun Shouxin <redacted>
---
drivers/net/bonding/bond_alb.c | 149 +++++++++++++++++++++++++++++++++
1 file changed, 149 insertions(+)
@@ -1269,6 +1271,137 @@ static int alb_set_mac_address(struct bonding *bond, void *addr)returnres;}+/*determine if the packet is NA or NS*/+staticbool__alb_determine_nd(structicmp6hdr*hdr)+{+if(hdr->icmp6_type==NDISC_NEIGHBOUR_ADVERTISEMENT||+hdr->icmp6_type==NDISC_NEIGHBOUR_SOLICITATION){+returntrue;+}++returnfalse;+}++staticvoidalb_change_nd_option(structsk_buff*skb,void*data)+{+structnd_msg*msg=(structnd_msg*)skb_transport_header(skb);+structnd_opt_hdr*nd_opt=(structnd_opt_hdr*)msg->opt;+structnet_device*dev=skb->dev;+structicmp6hdr*icmp6h=icmp6_hdr(skb);+structipv6hdr*ip6hdr=ipv6_hdr(skb);+u8*lladdr=NULL;+u32ndoptlen=skb_tail_pointer(skb)-(skb_transport_header(skb)++offsetof(structnd_msg,opt));++while(ndoptlen){+intl;++switch(nd_opt->nd_opt_type){+caseND_OPT_SOURCE_LL_ADDR:+caseND_OPT_TARGET_LL_ADDR:+lladdr=ndisc_opt_addr_data(nd_opt,dev);+break;++default:+lladdr=NULL;+break;+}++l=nd_opt->nd_opt_len<<3;++if(ndoptlen<l||l==0)+return;++if(lladdr){+memcpy(lladdr,data,dev->addr_len);+icmp6h->icmp6_cksum=0;++icmp6h->icmp6_cksum=csum_ipv6_magic(&ip6hdr->saddr,+&ip6hdr->daddr,+ntohs(ip6hdr->payload_len),+IPPROTO_ICMPV6,+csum_partial(icmp6h,+ntohs(ip6hdr->payload_len),0));+return;+}+ndoptlen-=l;+nd_opt=((void*)nd_opt)+l;+}+}++staticu8*alb_get_lladdr(structsk_buff*skb)+{+structnd_msg*msg=(structnd_msg*)skb_transport_header(skb);+structnd_opt_hdr*nd_opt=(structnd_opt_hdr*)msg->opt;+structnet_device*dev=skb->dev;+u8*lladdr=NULL;+u32ndoptlen=skb_tail_pointer(skb)-(skb_transport_header(skb)++offsetof(structnd_msg,opt));++while(ndoptlen){+intl;++switch(nd_opt->nd_opt_type){+caseND_OPT_SOURCE_LL_ADDR:+caseND_OPT_TARGET_LL_ADDR:+lladdr=ndisc_opt_addr_data(nd_opt,dev);+break;++default:+break;+}++l=nd_opt->nd_opt_len<<3;++if(ndoptlen<l||l==0)+returnNULL;++if(lladdr)+returnlladdr;++ndoptlen-=l;+nd_opt=((void*)nd_opt)+l;+}++returnlladdr;+}++staticvoidalb_set_nd_option(structsk_buff*skb,structbonding*bond,+structslave*tx_slave)+{+structipv6hdr*ip6hdr;+structicmp6hdr*hdr;++if(skb->protocol==htons(ETH_P_IPV6)){+if(tx_slave&&tx_slave!=+rcu_access_pointer(bond->curr_active_slave)){+ip6hdr=ipv6_hdr(skb);+if(ip6hdr->nexthdr==IPPROTO_ICMPV6){+hdr=icmp6_hdr(skb);+if(__alb_determine_nd(hdr))+alb_change_nd_option(skb,tx_slave->dev->dev_addr);+}+}+}+}++staticboolalb_determine_nd(structsk_buff*skb,structbonding*bond)+{+structipv6hdr*ip6hdr;+structicmp6hdr*hdr;++if(skb->protocol==htons(ETH_P_IPV6)){+ip6hdr=ipv6_hdr(skb);+if(ip6hdr->nexthdr==IPPROTO_ICMPV6){+hdr=icmp6_hdr(skb);+if(__alb_determine_nd(hdr))+returntrue;+}+}++returnfalse;+}+/************************ exported alb functions ************************/intbond_alb_initialize(structbonding*bond,intrlb_enabled)
From: Jakub Kicinski <kuba@kernel.org> Date: 2021-12-24 22:57:21
On Fri, 24 Dec 2021 09:25:12 -0500 Sun Shouxin wrote:
Since ipv6 neighbor solicitation and advertisement messages
isn't handled gracefully in bonding6 driver, we can see packet
drop due to inconsistency bewteen mac address in the option
message and source MAC .
Another examples is ipv6 neighbor solicitation and advertisement
messages from VM via tap attached to host brighe, the src mac
mighe be changed through balance-alb mode, but it is not synced
with Link-layer address in the option message.
The patch implements bond6's tx handle for ipv6 neighbor
solicitation and advertisement messages.
Suggested-by: Hu Yadi <redacted>
Reported-by: kernel test robot <redacted>
Hi,
I noticed one warning info on spinics, it said the patch "Still breaks
allmodconfig build".
I wonder why I didn't get it ,but I still rebuild it with allmodconfig, no
any warning jump out.
Anyone can light shouxin a bit?
Thanks.
------
胡亚弟
中国电信股份有限公司云计算分公司 研发一部
Mobile: 15810133835
北京市海淀中街15号远中悦莱
Email: huyd12@chinatelecom.cn
------------------------------------------------------------------------
-----邮件原件-----
发件人: sunshouxin@chinatelecom.cn [off-list ref]
发送时间: 2021年12月24日 22:25
收件人: j.vosburgh@gmail.com; vfalico@gmail.com; andy@greyhouse.net;
davem@davemloft.net; kuba@kernel.org
抄送: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
huyd12@chinatelecom.cn
主题: [PATCH v5] net: bonding: Add support for IPV6 ns/na to
balance-alb/balance-tlb mode
Since ipv6 neighbor solicitation and advertisement messages isn't handled
gracefully in bonding6 driver, we can see packet drop due to inconsistency
bewteen mac address in the option message and source MAC .
Another examples is ipv6 neighbor solicitation and advertisement messages
from VM via tap attached to host brighe, the src mac mighe be changed
through balance-alb mode, but it is not synced with Link-layer address in
the option message.
The patch implements bond6's tx handle for ipv6 neighbor solicitation and
advertisement messages.
Suggested-by: Hu Yadi <redacted>
Reported-by: kernel test robot <redacted>
Signed-off-by: Sun Shouxin <redacted>
---
drivers/net/bonding/bond_alb.c | 149 +++++++++++++++++++++++++++++++++
1 file changed, 149 insertions(+)
From: Jay Vosburgh <hidden> Date: 2021-12-27 20:36:20
Sun Shouxin [off-list ref] wrote:
Since ipv6 neighbor solicitation and advertisement messages
isn't handled gracefully in bonding6 driver, we can see packet
drop due to inconsistency bewteen mac address in the option
message and source MAC .
Another examples is ipv6 neighbor solicitation and advertisement
messages from VM via tap attached to host brighe, the src mac
mighe be changed through balance-alb mode, but it is not synced
with Link-layer address in the option message.
The patch implements bond6's tx handle for ipv6 neighbor
solicitation and advertisement messages.
I'm not sure what you've changed here for v5 as there's no
changelog, but I believe the observed problems to be a transmit side
effect (i.e., it is induced by the balance-tlb mode balancing of
outgoing traffic). As such, the tlb side will rebalance all of the
traffic every ten seconds, so any MAC ND_OPT_*_LL_ADDR option
assignments in the outgoing NS/NA datagrams will only be valid for that
length of time, correct?
The topology diagram and example that you've removed from the
commit log with v5 said, in part, that the issue arose because the
LL_ADDR option MAC didn't match the actual source MAC. Since tlb mode
can reshuffle the flows every ten seconds, how did the proposed solution
work reliably?
In any event, my real question is whether simply disabling tlb
balancing for NS/NA datagrams will resolve the observed issues (i.e.,
have bond_xmit_tlb_slave_get return NULL for IPv6 NS/NA datagrams).
Doing so will cause all NS/NA traffic to egress through the active
interface. There's already a test in your logic to check for the
tx_slave != bond->curr_active_slave, so presumably everything works
correctly if the NS/NA goes out on the curr_active_slave. If the "edit
NS/NA datagrams" solution works even in the face of rebalance of
traffic, then would simply assigning all NS/NA traffic to the
curr_active_slave eliminate the problem?
-J
quoted hunk
Suggested-by: Hu Yadi <redacted>
Reported-by: kernel test robot <redacted>
Signed-off-by: Sun Shouxin <redacted>
---
drivers/net/bonding/bond_alb.c | 149 +++++++++++++++++++++++++++++++++
1 file changed, 149 insertions(+)
Since ipv6 neighbor solicitation and advertisement messages
isn't handled gracefully in bonding6 driver, we can see packet
drop due to inconsistency bewteen mac address in the option
message and source MAC .
Another examples is ipv6 neighbor solicitation and advertisement
messages from VM via tap attached to host brighe, the src mac
mighe be changed through balance-alb mode, but it is not synced
with Link-layer address in the option message.
The patch implements bond6's tx handle for ipv6 neighbor
solicitation and advertisement messages.
I'm not sure what you've changed here for v5 as there's no
changelog, but I believe the observed problems to be a transmit side
effect (i.e., it is induced by the balance-tlb mode balancing of
outgoing traffic). As such, the tlb side will rebalance all of the
traffic every ten seconds, so any MAC ND_OPT_*_LL_ADDR option
assignments in the outgoing NS/NA datagrams will only be valid for that
length of time, correct?
Yes, MAC ND_OPT_*_LL_ADDR option assignments in the outgoing NS/NA
datagrams will only be valid for that length of time ,and then,
it will be inconsistensy in the next ten seconds.
The topology diagram and example that you've removed from the
commit log with v5 said, in part, that the issue arose because the
LL_ADDR option MAC didn't match the actual source MAC. Since tlb mode
can reshuffle the flows every ten seconds, how did the proposed solution
work reliably?
In function alb_set_nd_option, we will change the LL_ADDR option Mac
to the source Mac. This could work in this conditon.
In any event, my real question is whether simply disabling tlb
balancing for NS/NA datagrams will resolve the observed issues (i.e.,
have bond_xmit_tlb_slave_get return NULL for IPv6 NS/NA datagrams).
Doing so will cause all NS/NA traffic to egress through the active
interface. There's already a test in your logic to check for the
tx_slave != bond->curr_active_slave, so presumably everything works
correctly if the NS/NA goes out on the curr_active_slave. If the "edit
NS/NA datagrams" solution works even in the face of rebalance of
traffic, then would simply assigning all NS/NA traffic to the
curr_active_slave eliminate the problem?
Yes, assigning all Ns/Na traffic to the curr_active_slave can resolve the
difference between mac in the Ns/Na options with the source mac.
But this makes the rlb doesn't work in the alb mode,
one interface with bond6 will not receive any ingress packets.
It is mismatch Bond6 specification.
-J
quoted
Suggested-by: Hu Yadi <redacted>
Reported-by: kernel test robot <redacted>
Signed-off-by: Sun Shouxin <redacted>
---
drivers/net/bonding/bond_alb.c | 149 +++++++++++++++++++++++++++++++++
1 file changed, 149 insertions(+)
Any comments will be appreciated.
在 2021/12/28 11:01, 孙守鑫 写道:
在 2021/12/28 4:36, Jay Vosburgh 写道:
quoted
Sun Shouxin [off-list ref] wrote:
quoted
Since ipv6 neighbor solicitation and advertisement messages
isn't handled gracefully in bonding6 driver, we can see packet
drop due to inconsistency bewteen mac address in the option
message and source MAC .
Another examples is ipv6 neighbor solicitation and advertisement
messages from VM via tap attached to host brighe, the src mac
mighe be changed through balance-alb mode, but it is not synced
with Link-layer address in the option message.
The patch implements bond6's tx handle for ipv6 neighbor
solicitation and advertisement messages.
I'm not sure what you've changed here for v5 as there's no
changelog, but I believe the observed problems to be a transmit side
effect (i.e., it is induced by the balance-tlb mode balancing of
outgoing traffic). As such, the tlb side will rebalance all of the
traffic every ten seconds, so any MAC ND_OPT_*_LL_ADDR option
assignments in the outgoing NS/NA datagrams will only be valid for that
length of time, correct?
Yes, MAC ND_OPT_*_LL_ADDR option assignments in the outgoing NS/NA
datagrams will only be valid for that length of time ,and then,
it will be inconsistensy in the next ten seconds.
quoted
The topology diagram and example that you've removed from the
commit log with v5 said, in part, that the issue arose because the
LL_ADDR option MAC didn't match the actual source MAC. Since tlb mode
can reshuffle the flows every ten seconds, how did the proposed solution
work reliably?
In function alb_set_nd_option, we will change the LL_ADDR option Mac
to the source Mac. This could work in this conditon.
quoted
In any event, my real question is whether simply disabling tlb
balancing for NS/NA datagrams will resolve the observed issues (i.e.,
have bond_xmit_tlb_slave_get return NULL for IPv6 NS/NA datagrams).
Doing so will cause all NS/NA traffic to egress through the active
interface. There's already a test in your logic to check for the
tx_slave != bond->curr_active_slave, so presumably everything works
correctly if the NS/NA goes out on the curr_active_slave. If the "edit
NS/NA datagrams" solution works even in the face of rebalance of
traffic, then would simply assigning all NS/NA traffic to the
curr_active_slave eliminate the problem?
Yes, assigning all Ns/Na traffic to the curr_active_slave can resolve the
difference between mac in the Ns/Na options with the source mac.
But this makes the rlb doesn't work in the alb mode,
one interface with bond6 will not receive any ingress packets.
It is mismatch Bond6 specification.
quoted
-J
quoted
Suggested-by: Hu Yadi <redacted>
Reported-by: kernel test robot <redacted>
Signed-off-by: Sun Shouxin <redacted>
---
drivers/net/bonding/bond_alb.c | 149 +++++++++++++++++++++++++++++++++
1 file changed, 149 insertions(+)
Hi guys
Any comment?
thanks a lot.
在 2022/1/4 16:35, 孙守鑫 写道:
Any comments will be appreciated.
在 2021/12/28 11:01, 孙守鑫 写道:
quoted
在 2021/12/28 4:36, Jay Vosburgh 写道:
quoted
Sun Shouxin [off-list ref] wrote:
quoted
Since ipv6 neighbor solicitation and advertisement messages
isn't handled gracefully in bonding6 driver, we can see packet
drop due to inconsistency bewteen mac address in the option
message and source MAC .
Another examples is ipv6 neighbor solicitation and advertisement
messages from VM via tap attached to host brighe, the src mac
mighe be changed through balance-alb mode, but it is not synced
with Link-layer address in the option message.
The patch implements bond6's tx handle for ipv6 neighbor
solicitation and advertisement messages.
I'm not sure what you've changed here for v5 as there's no
changelog, but I believe the observed problems to be a transmit side
effect (i.e., it is induced by the balance-tlb mode balancing of
outgoing traffic). As such, the tlb side will rebalance all of the
traffic every ten seconds, so any MAC ND_OPT_*_LL_ADDR option
assignments in the outgoing NS/NA datagrams will only be valid for that
length of time, correct?
Yes, MAC ND_OPT_*_LL_ADDR option assignments in the outgoing NS/NA
datagrams will only be valid for that length of time ,and then,
it will be inconsistensy in the next ten seconds.
quoted
The topology diagram and example that you've removed from the
commit log with v5 said, in part, that the issue arose because the
LL_ADDR option MAC didn't match the actual source MAC. Since tlb mode
can reshuffle the flows every ten seconds, how did the proposed solution
work reliably?
In function alb_set_nd_option, we will change the LL_ADDR option Mac
to the source Mac. This could work in this conditon.
quoted
In any event, my real question is whether simply disabling tlb
balancing for NS/NA datagrams will resolve the observed issues (i.e.,
have bond_xmit_tlb_slave_get return NULL for IPv6 NS/NA datagrams).
Doing so will cause all NS/NA traffic to egress through the active
interface. There's already a test in your logic to check for the
tx_slave != bond->curr_active_slave, so presumably everything works
correctly if the NS/NA goes out on the curr_active_slave. If the "edit
NS/NA datagrams" solution works even in the face of rebalance of
traffic, then would simply assigning all NS/NA traffic to the
curr_active_slave eliminate the problem?
Yes, assigning all Ns/Na traffic to the curr_active_slave can resolve the
difference between mac in the Ns/Na options with the source mac.
But this makes the rlb doesn't work in the alb mode,
one interface with bond6 will not receive any ingress packets.
It is mismatch Bond6 specification.
quoted
-J
quoted
Suggested-by: Hu Yadi <redacted>
Reported-by: kernel test robot <redacted>
Signed-off-by: Sun Shouxin <redacted>
---
drivers/net/bonding/bond_alb.c | 149 +++++++++++++++++++++++++++++++++
1 file changed, 149 insertions(+)