Re: missing clue regarding IPv6, vlans bridging
I did some additional tests : pings using link-local addresses work out-of-the-box, whether the target is hme0 or le0, but the problem remains with public addresses (2000::/3) On Mon, Jul 28, 2008 at 2:36 PM, dermiste [EMAIL PROTECTED] wrote: Hi misc, my ISP is kind enough to provide native IPv6 access, so I'd like to have a full-IPv6 intranet. IPv6 addresses are assigned with rtadv and IPv4 with DHCP The setup : curry: OpenBSD-current, Thinkpad x41. /etc/hostname.bge0: up /etc/hostname.vlan0: vlan 0 vlandev bge0 up rtsol /etc/hostname.vlan1: vlan 1 vlandev bge0 up dhcp NONE NONE NONE debruijn: OpenBSD-4.3, Sun Ultra 1. /etc/hostname.le0: dhcp NONE NONE NONE up rtsol /etc/hostname.hme0 lladdr 08:00:20:68:54:b1 up #by default hme0's ll@ equals le0's ll@ /etc/hostname.vlan0 vlan 0 vlandev hme0 up /etc/hostname.vlan1 inet 192.168.1.1 255.255.255.0 192.168.1.255 vlan 1 vlandev hme0 up /etc/bridgename.bridge0 add le0 add vlan0 up (plus nat on le0 inet from !(le0) - (le0)) [Teh Intartubz] ! ! ! +-+ | le0 | | +--+| | bridge0| | ! | | vlan0 vlan1 | | +--+--+ | | hme0 | +-+ ! ! ! [my network] If it's not clear enough, vlan 0 is for IPv6 and vlan 1 for IPv4, so I can bridge vlan0 and le0. debruijn boots cleanly, gets all its adresses and routes, both v6 and v4. curry boots cleanly, gets all its addresses and routes, both v6 and v4 then : 1) from curry, I try to ping6 debruijn, but it says host unreachable 2) from debruijn, I try to ping6 curry, and it works. 3) from curry, I try to ping6 debruijn, and it works. I tcpdump'ed hme0, vlan0 and bridge0 during curry boot, and the packets flow through all 3, showing DHCP on vlan1 and rtadv on vlan0 + bridge0. During the pings, not a single packet goes through bridge0 or vlan0, but I've a lot of ICMPv6 neighbor sol on hme0 from curry during 1), then a successful neighbor sol - neighbor adv from debruijn to curry followed by echo requests and replies on hme0 during 2), then the same pattern from curry to debruijn on hme0 during 3). I really can't see what's wrong with my setup, clues anyone ? -- Vincent Gross So, the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well. -- Jerome Simeon Phil Wadler -- -- Vincent Gross So, the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well. -- Jerome Simeon Phil Wadler
Re: missing clue regarding IPv6, vlans bridging
dermiste [EMAIL PROTECTED] wrote: 1) from curry, I try to ping6 debruijn, but it says host unreachable 2) from debruijn, I try to ping6 curry, and it works. 3) from curry, I try to ping6 debruijn, and it works. This is very typical of multicast reception failing on one box (debruijn in your case). At step 1, curry sends a neighor solicitation message by multicast, so it can map the IPv6 address to the link layer address, but debruijn doesn't see the packet and fails to respond. At step 2, everything works in the opposite direction, and debruijn caches curry's address and proceeds to use it in step 3. Link-local v6 addresses also work fine because they don't involve neighbor discovery. I tcpdump'ed hme0, vlan0 and bridge0 during curry boot, and the packets flow through all 3, showing DHCP on vlan1 and rtadv on vlan0 + bridge0. Hmm. The router solicitation message curry sends is also a multicast packet. You might want to track its way. I really can't see what's wrong with my setup, clues anyone ? Not sure. What happens if you put an IPv6 address on debruijn's vlan0 interface and try to ping6 that address? -- Christian naddy Weisgerber [EMAIL PROTECTED]
Re: missing clue regarding IPv6, vlans bridging
On Tue, Jul 29, 2008 at 09:16:21PM +, Christian Weisgerber wrote: | dermiste [EMAIL PROTECTED] wrote: | | 1) from curry, I try to ping6 debruijn, but it says host unreachable | 2) from debruijn, I try to ping6 curry, and it works. | 3) from curry, I try to ping6 debruijn, and it works. | | This is very typical of multicast reception failing on one box | (debruijn in your case). | | At step 1, curry sends a neighor solicitation message by multicast, | so it can map the IPv6 address to the link layer address, but | debruijn doesn't see the packet and fails to respond. At step 2, | everything works in the opposite direction, and debruijn caches | curry's address and proceeds to use it in step 3. | | Link-local v6 addresses also work fine because they don't involve | neighbor discovery. Uhm, why ? 23:37:41.664994 00:0c:29:e5:f9:24 33:33:ff:ff:4d:0d 86dd 86: fe80::20c:29ff:fee5:f924 ff02::1::4d0d: icmp6: neighbor sol: who has fe80::20c:29ff:feff:4d0d(src lladdr: 00:0c:29:e5:f9:24) (len 32, hlim 255) How would you determine the linklayer address of your neighbour without neighbor discovery ? Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: missing clue regarding IPv6, vlans bridging
Paul de Weerd [EMAIL PROTECTED] wrote: | Link-local v6 addresses also work fine because they don't involve | neighbor discovery. Uhm, why ? 23:37:41.664994 00:0c:29:e5:f9:24 33:33:ff:ff:4d:0d 86dd 86: fe80::20c:29ff:fee5:f924 ff02::1::4d0d: icmp6: neighbor sol: who has fe80::20c:29ff:feff:4d0d(src lladdr: 00:0c:29:e5:f9:24) (len 32, hlim 255) I stand corrected. How would you determine the linklayer address of your neighbour without neighbor discovery ? Well, you could, since the link-local address is reversibly constructed from the link-layer address. On further reflection, I realize that not all the world is ethernet and this relation might not be true for other types of interfaces. Vexingly, I seem to remember that at one time I actually verified this behavior. I must have made a mistake then. My interest was the influence of neighbor discovery on NTP. Some fresh tcpdumping here shows that the typical packet exchange goes like this: 0 sec NTP request --- - NTP reply +5 sec neighbor sol -- -- neighbor adv -- neighbor sol neighbor adv -- That seems counterintuitive, but it is nice for NTP. -- Christian naddy Weisgerber [EMAIL PROTECTED]
missing clue regarding IPv6, vlans bridging
Hi misc, my ISP is kind enough to provide native IPv6 access, so I'd like to have a full-IPv6 intranet. IPv6 addresses are assigned with rtadv and IPv4 with DHCP The setup : curry: OpenBSD-current, Thinkpad x41. /etc/hostname.bge0: up /etc/hostname.vlan0: vlan 0 vlandev bge0 up rtsol /etc/hostname.vlan1: vlan 1 vlandev bge0 up dhcp NONE NONE NONE debruijn: OpenBSD-4.3, Sun Ultra 1. /etc/hostname.le0: dhcp NONE NONE NONE up rtsol /etc/hostname.hme0 lladdr 08:00:20:68:54:b1 up #by default hme0's ll@ equals le0's ll@ /etc/hostname.vlan0 vlan 0 vlandev hme0 up /etc/hostname.vlan1 inet 192.168.1.1 255.255.255.0 192.168.1.255 vlan 1 vlandev hme0 up /etc/bridgename.bridge0 add le0 add vlan0 up (plus nat on le0 inet from !(le0) - (le0)) [Teh Intartubz] ! ! ! +-+ | le0 | | +--+| | bridge0| | ! | | vlan0 vlan1 | | +--+--+ | | hme0 | +-+ ! ! ! [my network] If it's not clear enough, vlan 0 is for IPv6 and vlan 1 for IPv4, so I can bridge vlan0 and le0. debruijn boots cleanly, gets all its adresses and routes, both v6 and v4. curry boots cleanly, gets all its addresses and routes, both v6 and v4 then : 1) from curry, I try to ping6 debruijn, but it says host unreachable 2) from debruijn, I try to ping6 curry, and it works. 3) from curry, I try to ping6 debruijn, and it works. I tcpdump'ed hme0, vlan0 and bridge0 during curry boot, and the packets flow through all 3, showing DHCP on vlan1 and rtadv on vlan0 + bridge0. During the pings, not a single packet goes through bridge0 or vlan0, but I've a lot of ICMPv6 neighbor sol on hme0 from curry during 1), then a successful neighbor sol - neighbor adv from debruijn to curry followed by echo requests and replies on hme0 during 2), then the same pattern from curry to debruijn on hme0 during 3). I really can't see what's wrong with my setup, clues anyone ? -- Vincent Gross So, the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well. -- Jerome Simeon Phil Wadler
