Gert Doering <gert%greenie.muc.de@localhost> writes: > On Fri, Sep 16, 2011 at 04:05:44PM -0400, Greg Troxel wrote: >> /sbin/route add -inet6 2001:608:4:a053::/64 2001:608:4:a053::1:0 >> >> There is no reason to do this. Configuring an address automatically >> adds a route covering that prefix. It should not have worked (gotten a >> route exists error), but either it overwrote or the cloning route was >> missing for some reason (which is the thing to fix). > > Ah. > > I add the route, because it did not automatically show up (which is one > of the weirdest bits of cross-platform code - half of the platforms auto- > add the "connected" route at ifconfig, and the other half doesn't). It seems there is a bug in tap. In systems derived from 4.4BSD, the connected route should appear automatically when adding an address. I would say it's a bug for systems that have the concept of cloning route not to add it automatically when configuring an address. summary: I tried to replicate on sparc64. Both it and i386 seem to work correctly. > Step by step (without an application having the tap open, just ifconfig): > > # netstat -rn |grep tap > # ifconfig tap0 > ifconfig: SIOCGIFFLAGS tap0: Device not configured > # ifconfig tap0 create > # netstat -rn |grep tap > # ifconfig tap0 inet6 2001:608:4:a053::1:0/64 up up is implied by an address. Probably if you did up bare first, you'd see the fe80:: routes. > # netstat -rn |grep tap > fe80::%tap0/64 link#9 UC 0 0 - tap0 This seems right. > fe80::f00b:a4ff:fe00:4dd2%tap0 f2:0b:a4:00:4d:d2 UHL 0 0 - lo0 This one seems wrong. I have no such entry but instead have an ND cache entry. I suspect this and the missing cloning route are related. > ff01:9::/32 link#9 UC 0 0 - tap0 > ff02::%tap0/32 link#9 UC 0 0 - tap0 I have those (well, 7 not 9, but that's the ifindex I'm pretty sure). > # ifconfig tap0 > tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > address: f2:0b:a4:00:4d:d2 > media: Ethernet autoselect > inet6 fe80::f00b:a4ff:fe00:4dd2%tap0 prefixlen 64 scopeid 0x9 > inet6 2001:608:4:a053::1:0 prefixlen 64 > > ... so where does the route for the /64 prefix disappear to? It is perhaps not disappearing, but not getting added. Run 'route -n monitor' during this whole exercise to see what happens. > # uname -a > NetBSD zeta.medat.de 5.1_STABLE NetBSD 5.1_STABLE (GENERIC) #0: Tue > Feb 15 15:46:59 CET 2011 > gert%zeta.medat.de@localhost:/hilb31/sparc64.compile/obj/hilb31/netbsd/src/sys/arch/sparc64/compile/GENERIC > sparc64 Note that you are doing this on sparc64, which is LP64, and big endian. I predict that this will turn out to matter (but mine works). > As a cross-check, I just tried this on NetBSD 3.1, and indeed, the route > auto-appears on tap0, and ND starts > > 22:20:00.348908 2001:608:4:a253::1:0 > ff02::1:ff00:2: icmp6: neighbor > sol: who has 2001:608:4:a253::2 > > (different prefix deliberately chosen) What hardware? >> 2001:608:4:a000::/56 2001:608:4:a053::1 UGS 0 0 - tap0 >> 2001:608:4:a053::/64 2001:608:4:a053::1:0 UGS 1 0 - tap0 >> >> This looks wrong, but is probably due to the previous issues. Where >> did that /56 come from? > > Sorry for being misleading. That's an extra network that is just to > be routed across the tap0 /64, but I didn't want to modify the output > of "netstat -rn" in any way. The /56 route doesn't seem wrong, but I asked because it seems unnecessary to illustrate the problem and I thought perhaps there was something else that might turn out to matter. >> When doing netstat, do netstat -rn -f inet6 and then filter out what you >> are sure is not relevant, rather than assuming grepping for tap0 will >> show you everything you should look at. > > Yes, sorry for that (usually I grep for ":608:4:", knowing that this > network must only ever appear on tap0, but I wanted to include the fe80 > stuff). I didn't mean to complain about what you sent so much as suggest that looking more broadly would be helpful. Often I figure things out when something I didn't think to look at jumps out at me. That leads me to the general strategy of looking at everything and then filtering. > Here's "netstat -rn -f inet6" after the ifconfig sequence from above, > excluding everything that has no "tap0" or "2001:608:4:" in it: > > 2001:608:4:a053::1:0 f2:0b:a4:00:4d:d2 UHL 0 0 - lo0 > fe80::%tap0/64 link#9 UC 0 0 - tap0 > ff01:9::/32 link#9 UC 0 0 - tap0 > ff02::%tap0/32 link#9 UC 0 0 - tap0 That UHL route on lo0 also seems wrong, but I suspect that it's a consequence of the cloning route not getting added. >> When you configure the address on tap0, it should get a cloning route, >> which will have flags UC. This should be in generic ethernet code. >> Note that this apparently happened correctly for v4. > > Yes, in v4 this all works. I just did this on a sparc64 running 5.1_RC3. (I know that's old, and I will update to recent netbsd-5 and can try again if you're still having trouble.). After "ifconfig tap0 inet6 2001:db8::1", diff -u of "netstat -nr -f inet6" taken before and after shows: +2001:db8::/64 link#7 UC 0 0 - tap0 => and route -n monitor showed (annotated): got message of size 24 on Fri Sep 16 20:29:41 2011 RTM_IFANNOUNCE: iface arrival/departure: len 24, if# 7, what: arrival From 'ifconfig tap0 create' got message of size 108 on Fri Sep 16 20:29:55 2011 RTM_NEWADDR: address being added to iface: len 108, metric 0, flags: sockaddrs: <NETMASK,IFP,IFA> ffff:ffff:ffff:ffff:: tap0:f2.b.a4.0.d.3e 2001:db8::1 adding the address (a /64) got message of size 168 on Fri Sep 16 20:29:55 2011 RTM_ADD: Add Route: len 168, pid 0, seq 0, errno 0, flags: <UP,HOST,LLINFO> locks: inits: sockaddrs: <DST,GATEWAY> 2001:db8::1 f2.b.a4.0.d.3e adding the ND entry for ourselves, which ndp -an shows as: 2001:db8::1 f2:0b:a4:00:0d:3e tap0 permanent R got message of size 248 on Fri Sep 16 20:29:55 2011 RTM_ADD: Add Route: len 248, pid 0, seq 0, errno 0, flags: <UP,DONE,CLONING> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA> 2001:db8:: ffff:ffff:ffff:ffff:: tap0:f2.b.a4.0.d.3e 2001:db8::1 This is the cloning route above. got message of size 108 on Fri Sep 16 20:29:55 2011 RTM_NEWADDR: address being added to iface: len 108, metric 0, flags: sockaddrs: <NETMASK,IFP,IFA> ffff:ffff:ffff:ffff:: tap0:f2.b.a4.0.d.3e fe80::f00b:a4ff:fe00:d3e%tap0 got message of size 168 on Fri Sep 16 20:29:55 2011 link-local. apparently this is happening because the interface comes up when I gave it an inet6 address RTM_ADD: Add Route: len 168, pid 0, seq 0, errno 0, flags: <UP,HOST,LLINFO> locks: inits: sockaddrs: <DST,GATEWAY> fe80::f00b:a4ff:fe00:d3e%tap0 f2.b.a4.0.d.3e got message of size 248 on Fri Sep 16 20:29:55 2011 ND entry for our link-local address. RTM_ADD: Add Route: len 248, pid 0, seq 0, errno 0, flags: <UP,DONE,CLONING> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA> fe80::%tap0 ffff:ffff:ffff:ffff:: tap0:f2.b.a4.0.d.3e 2001:db8::1 link-local cloning route. I deleted the 2001:db8::1 address, and on re-adding it, I see only NEWADDR, ADD of ND entry and ADD of cloning route. Which all seems fine. So the big mystery is why your machine is not adding the cloning route. Are you using that prefix on any other interface (you can't)???
Attachment:
pgpJqSSkOMvba.pgp
Description: PGP signature