| Message ID | 54CF3348.40207@huawei.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
From: shengyong <shengyong1@huawei.com> Date: Mon, 2 Feb 2015 16:20:24 +0800 > Hi, David Miller There are other people on this list more skilled than I am at answering this question, just FYI... -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 02, 2015 at 04:20:24PM +0800, shengyong wrote: > Hi, David Miller > Since commit 81aded246 (ipv6: Handle PMTU in ICMP error handlers), the entries > in neigh table may get expired. But in the situation: > > Host only > PC <------------> Virtual Machine > > a packet is sent from PC to VM, and the packet looks like: > ----------------------------------- > | IPv6 (src=PC-addr, dst=VM-addr) | > |---------------------------------| > | ICMPv6 (Packet Too Big) | > |---------------------------------| > | IPv6 (src=VM-addr, dst=VM-addr) | > |---------------------------------| > | ICMPv6 (Neighbor Advertisement) | > ----------------------------------- > > Then the local addr on VM will be updated with an expire value. After the > lifetime of the local addr is expired, the VM is unreachable from PC. > > # ip -6 route list table local > local fe80::1 dev lo metric 0 *expire 596* We first need to find out why you receive this Packet Too Big message, can you capture this packet somehow? Then we have to see why this loopback route gets a pmtu update from that packet. Is the destination address of the Packet Too Big message really fe80::1? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
在 2015/2/3 17:28, Steffen Klassert 写道: > On Mon, Feb 02, 2015 at 04:20:24PM +0800, shengyong wrote: >> Hi, David Miller >> Since commit 81aded246 (ipv6: Handle PMTU in ICMP error handlers), the entries >> in neigh table may get expired. But in the situation: >> >> Host only >> PC <------------> Virtual Machine >> >> a packet is sent from PC to VM, and the packet looks like: >> ----------------------------------- >> | IPv6 (src=PC-addr, dst=VM-addr) | >> |---------------------------------| >> | ICMPv6 (Packet Too Big) | >> |---------------------------------| >> | IPv6 (src=VM-addr, dst=VM-addr) | >> |---------------------------------| >> | ICMPv6 (Neighbor Advertisement) | >> ----------------------------------- >> >> Then the local addr on VM will be updated with an expire value. After the >> lifetime of the local addr is expired, the VM is unreachable from PC. >> >> # ip -6 route list table local >> local fe80::1 dev lo metric 0 *expire 596* > > We first need to find out why you receive this Packet Too Big message, The packet is sent by a commercial-off-the-shelf testcase, and I can reproduce the situation by using scapy and creating a packet as the following: $ cat packet-too-big.py #!/usr/bin/python from scapy.all import * # fe80::800:27ff:fe00:0 is linklocal addr of PC # fe80::a00:27ff:fe1a:e2a0 is linklocal addr of VM base=IPv6(src='fe80::800:27ff:fe00:0',dst='fe80::a00:27ff:fe1a:e2a0') pkt_too_big=ICMPv6PacketTooBig(mtu=1024) ext_base=IPv6(src='fe80::a00:27ff:fe1a:e2a0',dst='fe80::a00:27ff:fe1a:e2a0',plen=24) ext_nd_na=ICMPv6ND_NA() packet=base/pkt_too_big/ext_base/ext_nd_na send(packet) > can you capture this packet somehow? I captured the packet in wireshark, it is exact the packet created by the script. > Then we have to see why this loopback > route gets a pmtu update from that packet. I tried to print info when the VM receives pkt-too-big packet. The calling stack is icmpv6_rcv->icmpv6_notify->icmpv6_err->ip6_update_pmtu->ip6_rt_update_pmtu->rt6_update_expires. In ip6_update_pmtu, ip6_route_output looks up the route table, and returns the dst_entry of the linklocal addr. Then it is set to expire. > Is the destination address > of the Packet Too Big message really fe80::1? In fact, if the dst of the above `ext_base' is the local addr of the VM, the local addr on VM will be expired. thx, Sheng > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/ipv6/route.c b/net/ipv6/route.c index b2614b2..b80317a 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -1136,6 +1136,9 @@ static void ip6_rt_update_pmtu(struct dst_entry *dst, struct sock *sk, { struct rt6_info *rt6 = (struct rt6_info*)dst; + if (rt6->rt6i_flags & RTF_LOCAL) + return; + dst_confirm(dst); if (mtu < dst_mtu(dst) && rt6->rt6i_dst.plen == 128) { struct net *net = dev_net(dst->dev);
Hi, David Miller Since commit 81aded246 (ipv6: Handle PMTU in ICMP error handlers), the entries in neigh table may get expired. But in the situation: Host only PC <------------> Virtual Machine a packet is sent from PC to VM, and the packet looks like: ----------------------------------- | IPv6 (src=PC-addr, dst=VM-addr) | |---------------------------------| | ICMPv6 (Packet Too Big) | |---------------------------------| | IPv6 (src=VM-addr, dst=VM-addr) | |---------------------------------| | ICMPv6 (Neighbor Advertisement) | ----------------------------------- Then the local addr on VM will be updated with an expire value. After the lifetime of the local addr is expired, the VM is unreachable from PC. # ip -6 route list table local local fe80::1 dev lo metric 0 *expire 596* I find that the current code seems not check whether the entry is a local one when doing PMTU update. And if the following code is added, the situation could be avoided. So is this modification correct? Or how can we avoid such expiring? thx & BR, Sheng -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html