Mouse <mouse%Rodents-Montreal.ORG@localhost> writes: >> What is the interface type on the upstream link? > > As seen by the host, Ethernet. The physical layer is DSL (MVL, to be > specific), but as far as I've been able to tell it's operationally just > a really slow Ethernet. (In case it matters, the DSL CPE is behind a > switch which vlan-trunks that, among other things, to the router host.) > > The other end is not a mass-market big-ISP head; the DSL is being run > over dry copper to a DSLAM at my upstream/employer. Wow, how unusual. So: What driver (wm? fxp? vr?) is in use? Is the underlying physical interface the same one for the DSl-facing vlan as the house-lan-facing vlan? > Native, or at least as native as IPv6-over-Ethernet ever is. (Not > counting comments, there's nothing in the network config that says > vlan4 is a DSL line instead of a normal Ethernet.) OK, that's what I meant by native. >> Static route, or some IGP, or BGP, or ? > > Entirely manually-configured statics. So this should be easy to reproduce. I do wonder if it has to do with vlans. >> When you said "isn't answering", do you mean that you have an ndp >> cache entry, but when the unicast packet is sent, there is no >> link-level receiver? Or do you mean that there is no ndp entry, >> because it doesn't answer the ndp request packets? > > The latter. (It might have been the former initially, but certainly > after the reboot to clear the first wedge it will have been the latter > until I fixed things. The upstream host and my router disagreed over > what /127 to use on the DSL; I must have changed one end but not the > other and not rebooted since, or some such.) I dimly remember that ARP used to store a packet when sending an arp request, so that it could send it when the reply came. But that requires freeing the old one (with a queue of 1). I am unclear on how NDP does this, but it's something else to check.
Attachment:
pgpNEDZSXHFMl.pgp
Description: PGP signature