| Home » General » Discussions » IPv6 and OVZ part deux (Get ready for some fun?) Goto Forum:
	| 
		
			| IPv6 and OVZ part deux [message #41338] | Mon, 03 January 2011 10:53  |  
			| 
				
				
					|  lars.bailey Messages: 38
 Registered: April 2010
 | Member |  |  |  
	| Getting IPv6 working with OpenVZ,is either going to be heaven,or hell,depending on several factors.
 For IPv6 in general,it mostly involves;
 
 * unfamiliar with IPv6 numeration(s)
 
 * improper subnetting schemas
 
 * improper routing configuration(s)
 
 * OS specific configurations for IPv6
 
 These,are easily remidied.
 For OpenVZ,it is going to depend on the Node server operating system,and/or OS template cache.
 If you think I'm on crack in my remark above,think again.
 My testing has been done on F13 and Oracle Enterprise(EL5)
 On F13,IPv6 and OpenVZ is a snap,and was tested with RedHat,Debian,and OpenSUSE containers.
 On Oracle,or any EL5 flavor,it gets really interesting.
 especially using EL5 template caches(CentOS)
 This also goes for CentOS templates on F13.
 You have to enable IPv6 in a EL5 container,just like you would on the Node server.
 To prove IPv6 can easily be setup,this is a live IPv6 F13 container,running on F13 Node server.
 
 => Taken from my testing notes
 The prefix below,is a private global range,used in testing IPv6
 
 The IPv6 router's source route interface(Node),is configured with a IPv6 address from the "/64" prefix.
 
 fd60:1014:9458:4b60::9
 
 A test VE container was created,with virtual Ethernet,and its VETH interface,was also configured with an IPv6 address,from the available "/64" prefix.
 
 fd60:1014:9458:4b60::a
 
 Test for reachability.
 
 # ping6 -c 3 fd60:1014:9458:4b60::9
 PING fd60:1014:9458:4b60::9(fd60:1014:9458:4b60::9) 56 data bytes
 64 bytes from fd60:1014:9458:4b60::9: icmp_seq=1 ttl=64 time=0.369 ms
 64 bytes from fd60:1014:9458:4b60::9: icmp_seq=2 ttl=64 time=0.315 ms
 64 bytes from fd60:1014:9458:4b60::9: icmp_seq=3 ttl=64 time=0.242 ms
 
 --- fd60:1014:9458:4b60::9 ping statistics ---
 3 packets transmitted, 3 received, 0% packet loss, time 2001ms
 rtt min/avg/max/mdev = 0.242/0.308/0.369/0.055 ms
 
 
 # ping6 -c 3 fd60:1014:9458:4b60::a
 
 PING fd60:1014:9458:4b60::a(fd60:1014:9458:4b60::a) 56 data bytes
 64 bytes from fd60:1014:9458:4b60::a: icmp_seq=1 ttl=64 time=0.329 ms
 64 bytes from fd60:1014:9458:4b60::a: icmp_seq=2 ttl=64 time=0.342 ms
 64 bytes from fd60:1014:9458:4b60::a: icmp_seq=3 ttl=64 time=0.346 ms
 
 --- fd60:1014:9458:4b60::a ping statistics ---
 3 packets transmitted, 3 received, 0% packet loss, time 2001ms
 rtt min/avg/max/mdev = 0.329/0.339/0.346/0.007 ms
 #
 
 "ping6" results show IPv6 networking is working on both interfaces.
 /68 from /64 prefix,cut to a /96,and then down to "/120" prefix length.
 May not be standard,but works in a pinch.
 Secondary IPv6 address,from the the "/120" subnet.
 
 FD60:1014:9458:4B60:E003:5000:0010:0101/128 VETH interface
 FD60:1014:9458:4B60:E003:5000:0010:01FF/128 VE
 
 # ifconfig veth6101.0
 veth6101.0 Link encap:Ethernet  HWaddr 00:18:51:40:DF:09
 inet6 addr: fe80::218:51ff:fe40:df09/64 Scope:Link
 inet6 addr: fd60:1014:9458:4b60:e003:5000:10:101/64 Scope:Global
 inet6 addr: fd60:1014:9458:4b60::a/64 Scope:Global
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:48 errors:0 dropped:0 overruns:0 frame:0
 TX packets:99 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:2274 (2.2 KiB)  TX bytes:7664 (7.4 KiB)
 
 The container.
 
 [root@moe /]# ifconfig eth0
 eth0      Link encap:Ethernet  HWaddr 00:18:51:0C:72:E2
 inet6 addr: fd60:1014:9458:4b60:e003:5000:10:1ff/64 Scope:Global
 inet6 addr: fe80::218:51ff:fe0c:72e2/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:99 errors:0 dropped:0 overruns:0 frame:0
 TX packets:61 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:7664 (7.4 KiB)  TX bytes:3166 (3.0 KiB)
 
 A default route to the VETH interface was added
 
 [root@moe /]# ip -6 ro show dev eth0
 fd60:1014:9458:4b60::/64  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
 fe80::/64  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
 default via fd60:1014:9458:4b60:e003:5000:10:101  metric 1  mtu 1500 advmss 1440 hoplimit 0
 
 Ping the default gateway.
 
 # ping6 -c 3 fd60:1014:9458:4b60:e003:5000:10:101
 PING  fd60:1014:9458:4b60:e003:5000:10:101(fd60:1014:9458:4b60:e00 3:5000:10:101) 56 data bytes
 64 bytes from fd60:1014:9458:4b60:e003:5000:10:101: icmp_seq=1 ttl=64 time=0.989 ms
 64 bytes from fd60:1014:9458:4b60:e003:5000:10:101: icmp_seq=2 ttl=64 time=0.375 ms
 64 bytes from fd60:1014:9458:4b60:e003:5000:10:101: icmp_seq=3 ttl=64 time=0.381 ms
 
 --- fd60:1014:9458:4b60:e003:5000:10:101 ping statistics ---
 3 packets transmitted, 3 received, 0% packet loss, time 2004ms
 rtt min/avg/max/mdev = 0.375/0.581/0.989/0.289 ms
 
 From the IPv6 router,to the container.
 
 # ping6 -c 3 fd60:1014:9458:4b60:e003:5000:10:1ff
 PING  fd60:1014:9458:4b60:e003:5000:10:1ff(fd60:1014:9458:4b60:e00 3:5000:10:1ff) 56 data bytes
 64 bytes from fd60:1014:9458:4b60:e003:5000:10:1ff: icmp_seq=1 ttl=64 time=1.04 ms
 64 bytes from fd60:1014:9458:4b60:e003:5000:10:1ff: icmp_seq=2 ttl=64 time=0.364 ms
 64 bytes from fd60:1014:9458:4b60:e003:5000:10:1ff: icmp_seq=3 ttl=64 time=0.382 ms
 
 --- fd60:1014:9458:4b60:e003:5000:10:1ff ping statistics ---
 3 packets transmitted, 3 received, 0% packet loss, time 2002ms
 rtt min/avg/max/mdev = 0.364/0.597/1.046/0.317 ms
 #
 
 From the IPv6 router,VE6101 is reachable.
 Router not reachable from VE,*may need route on Node - add /120 => VETH
 Added direct route to the IPv6 router.
 "route6-eth0" file,in container's /etc/sysconfig/network-scripts directory.
 
 fd60:1014:9458:4b60::9 via fd60:1014:9458:4b60:e003:5000:10:101
 
 # ip -6 ro show dev eth0
 fd60:1014:9458:4b60::9 via fd60:1014:9458:4b60:e003:5000:10:101  metric 1024  mtu 1500 advmss 1440 hoplimit 0
 fd60:1014:9458:4b60::/64  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
 fe80::/64  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
 #
 
 Ping IPv6 router.
 
 # ping6 -c 3 fd60:1014:9458:4b60::9
 PING fd60:1014:9458:4b60::9(fd60:1014:9458:4b60::9) 56 data bytes
 64 bytes from fd60:1014:9458:4b60::9: icmp_seq=1 ttl=64 time=1.48 ms
 64 bytes from fd60:1014:9458:4b60::9: icmp_seq=2 ttl=64 time=0.377 ms
 64 bytes from fd60:1014:9458:4b60::9: icmp_seq=3 ttl=64 time=0.375 ms
 
 --- fd60:1014:9458:4b60::9 ping statistics ---
 3 packets transmitted, 3 received, 0% packet loss, time 2003ms
 rtt min/avg/max/mdev = 0.375/0.746/1.488/0.525 ms
 #
 
 Test container shows as reachable neighbor,without Proxy_NDP.
 IPv6 transit over GRE tunnel6 successful.
 
 ""
 
 Like I said,it couldn't have gotten any easier.
 On Oracle,this same setup,breaks the IPv6 stack.
 Loss of link-local,is common on source-route interface,and is causing me grief,although we do not use Oracle as a rule for OVZ.
 If you are going to transition,better think ahead.
 I'm glad I put a little effort first,before any assumptions.
 |  
	|  |  |  
	| 
		
			| Re: IPv6 and OVZ part deux [message #41388 is a reply to message #41338] | Thu, 13 January 2011 07:30   |  
			| 
				
				
					|  lars.bailey Messages: 38
 Registered: April 2010
 | Member |  |  |  
	| Before this thread is read any further,I need to clear up some things,in my haste to prove that IPv6 can be set up easily with OpenVZ.
 But,I also wanted to illustrate what not to do.
 First off,do not use IFCONFIG,with IPv6 configurations.
 IFCONFIG,assumes /64 prefix lengths.for host addresses.
 This may pose a dilemma,for some end-users.
 IPv6 configurations via scripting,or router software on Node?
 We chose to add router software on Nodes,and add *init script to VE's.
 The second,was using a /64 prefix length.
 There have been inquiries elsewhere on the OVZ forum,on whether a /64 prefix can be subnetted?
 Yes,a /64 can be subnetted.(use ipv6gen.pl)
 Using the IP command manually;
 
 1. Take a /64 private IPv6 address range from SimplyDNS,to test with.
 I'm going to use this /64.
 
 fd22:a075:afd0:e096::/64
 
 Subnet it down to a /96.
 
 FD22:A075:AFD0:E096:0000:0000::/96
 FD22:A075:AFD0:E096:0000:0001::/96
 FD22:A075:AFD0:E096:0000:0002::/96
 FD22:A075:AFD0:E096:0000:0003::/96
 FD22:A075:AFD0:E096:0000:0004::/96
 FD22:A075:AFD0:E096:0000:0005::/96
 FD22:A075:AFD0:E096:0000:0006::/96
 FD22:A075:AFD0:E096:0000:0007::/96
 FD22:A075:AFD0:E096:0000:0008::/96
 FD22:A075:AFD0:E096:0000:0009::/96
 FD22:A075:AFD0:E096:0000:000A::/96
 => etc.
 
 I'm going to use this /96.
 
 FD22:A075:AFD0:E096:0000:0001::/96
 
 2. Add IPv6 address,to source-route interface.
 
 [root@stooge network-scripts]# ip address add \
 > fd22:a075:afd0:e096:0:1::1a dev eth1
 
 3. Check with IFCONFIG.
 
 [root@stooge network-scripts]# ifconfig eth1
 eth1      Link encap:Ethernet  HWaddr 00:14:BF:5E:51:3F
 inet addr:192.168.1.64  Bcast:192.168.1.255  Mask:255.255.255.0
 inet6 addr: fe80::214:bfff:fe5e:513f/64 Scope:Link
 inet6 addr: fd22:a075:afd0:e096:0:1:0:1a/128 Scope:Global
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:477340 errors:0 dropped:0 overruns:0 frame:0
 TX packets:353145 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:245276422 (233.9 MiB)  TX bytes:174651991 (166.5 MiB)
 Interrupt:9 Base address:0x4800
 
 Notice,it shows up as a hermit host.
 Always add prefix length.
 So again,add IPv6 address.
 
 [root@stooge network-scripts]# ip address add \
 > fd22:a075:afd0:e096:0:1::1a/96 dev eth1
 
 4. Check with IFCONFIG.
 
 [root@stooge network-scripts]# ifconfig eth1
 eth1      Link encap:Ethernet  HWaddr 00:14:BF:5E:51:3F
 inet addr:192.168.1.64  Bcast:192.168.1.255  Mask:255.255.255.0
 inet6 addr: fe80::214:bfff:fe5e:513f/64 Scope:Link
 inet6 addr: fd22:a075:afd0:e096:0:1:0:1a/96 Scope:Global
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:477443 errors:0 dropped:0 overruns:0 frame:0
 TX packets:353163 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:245282889 (233.9 MiB)  TX bytes:174653483 (166.5 MiB)
 Interrupt:9 Base address:0x4800
 
 5. Take the /96,and subnet to a /116.
 
 FD22:A075:AFD0:E096:0000:0001:0000:0000/116
 FD22:A075:AFD0:E096:0000:0001:0000:1000/116
 FD22:A075:AFD0:E096:0000:0001:0000:2000/116
 FD22:A075:AFD0:E096:0000:0001:0000:3000/116
 FD22:A075:AFD0:E096:0000:0001:0000:4000/116
 FD22:A075:AFD0:E096:0000:0001:0000:5000/116
 FD22:A075:AFD0:E096:0000:0001:0000:6000/116
 FD22:A075:AFD0:E096:0000:0001:0000:7000/116
 FD22:A075:AFD0:E096:0000:0001:0000:8000/116
 FD22:A075:AFD0:E096:0000:0001:0000:9000/116
 FD22:A075:AFD0:E096:0000:0001:0000:A000/116
 => etc
 
 As a rule,we do not subnet any given prefix,any further than /116.
 Some may feel,this is "address waste",but with IPv6,we have no
 reason to get anal about it.
 You choose your method.
 I'm going to use this /116 prefix.
 
 FD22:A075:AFD0:E096:0000:0001:0000:1000/116
 
 For the VETH and VE interfaces,I will use these host addresses.
 
 VETH - fd22:a075:afd0:e096:0:1:0:1fff/116
 VE eth0 - fd22:a075:afd0:e096:0:1:0:1001/116
 
 6. Configure IPv6 address for VETH interface.
 
 [root@stooge network-scripts]# ip address add \
 > fd22:a075:afd0:e096:0:1:0:1fff/116 dev veth6101.0
 
 7. Check with IFCONFIG.
 
 [root@stooge network-scripts]# ifconfig veth6101.0
 veth6101.0 Link encap:Ethernet  HWaddr 00:18:51:2C:C8:6D
 inet addr:192.168.100.101  Bcast:192.168.100.255  Mask:255.255.255.0
 inet6 addr: fd22:a075:afd0:e096:0:1:0:1fff/116 Scope:Global
 inet6 addr: fe80::218:51ff:fe2c:c86d/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:432 errors:0 dropped:0 overruns:0 frame:0
 TX packets:83 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:16956 (16.5 KiB)  TX bytes:5716 (5.5 KiB)
 
 [root@stooge network-scripts]#
 
 8. For the VE.
 
 Configure IPv6 address from this same subnet.
 
 FD22:A075:AFD0:E096:0000:0001:0000:1001/116
 
 [root@moe /]# ip address add \
 > fd22:a075:afd0:e096:0:1:0:1001/116 dev eth0
 
 9. Check with IFCONFIG.
 
 [root@moe /]# ifconfig eth0
 eth0      Link encap:Ethernet  HWaddr 00:18:51:8F:16:2E
 inet addr:192.168.101.1  Bcast:192.168.101.255  Mask:255.255.255.0
 inet6 addr: fd22:a075:afd0:e096:0:1:0:1001/116 Scope:Global
 inet6 addr: fe80::218:51ff:fe8f:162e/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:83 errors:0 dropped:0 overruns:0 frame:0
 TX packets:446 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:5716 (5.5 KiB)  TX bytes:17784 (17.3 KiB)
 
 [root@moe /]#
 
 10. Add default route.
 
 [root@moe /]# ip ro add default via \
 > fd22:a075:afd0:e096:0:1:0:1fff dev eth0
 
 11. Check routing table.
 
 [root@moe /]# ip -6 ro show dev eth0
 fd22:a075:afd0:e096:0:1:0:1000/116  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
 fe80::/64  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
 default via fd22:a075:afd0:e096:0:1:0:1fff  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
 
 12. Ping gateway.(VETH)
 
 [root@moe /]# ping6 -c 3 fd22:a075:afd0:e096:0:1:0:1fff
 PING  fd22:a075:afd0:e096:0:1:0:1fff(fd22:a075:afd0:e096:0:1:0:1ff f) 56 data bytes
 64 bytes from fd22:a075:afd0:e096:0:1:0:1fff: icmp_seq=1 ttl=64 time=1.43 ms
 64 bytes from fd22:a075:afd0:e096:0:1:0:1fff: icmp_seq=2 ttl=64 time=0.270 ms
 64 bytes from fd22:a075:afd0:e096:0:1:0:1fff: icmp_seq=3 ttl=64 time=0.287 ms
 
 --- fd22:a075:afd0:e096:0:1:0:1fff ping statistics ---
 3 packets transmitted, 3 received, 0% packet loss, time 2011ms
 rtt min/avg/max/mdev = 0.270/0.663/1.433/0.544 ms
 
 13. Check your neighbor entry.
 
 [root@moe /]# ip -6 neigh show
 fd22:a075:afd0:e096:0:1:0:1fff dev eth0 lladdr 00:18:51:2c:c8:6d REACHABLE
 fe80::218:51ff:fe2c:c86d dev eth0 lladdr 00:18:51:2c:c8:6d REACHABLE
 
 The VETH interface,will always be the container's "neighbor".
 14. Now,the GW router.(Node)
 
 [root@moe /]# ping6 -c 3 fd22:a075:afd0:e096:0:1:0:1a
 PING fd22:a075:afd0:e096:0:1:0:1a(fd22:a075:afd0:e096:0:1:0:1a) 56 data bytes
 64 bytes from fd22:a075:afd0:e096:0:1:0:1a: icmp_seq=1 ttl=64 time=0.944 ms
 64 bytes from fd22:a075:afd0:e096:0:1:0:1a: icmp_seq=2 ttl=64 time=0.282 ms
 64 bytes from fd22:a075:afd0:e096:0:1:0:1a: icmp_seq=3 ttl=64 time=0.254 ms
 
 --- fd22:a075:afd0:e096:0:1:0:1a ping statistics ---
 3 packets transmitted, 3 received, 0% packet loss, time 2003ms
 rtt min/avg/max/mdev = 0.254/0.493/0.944/0.319 ms
 
 |  
	|  |  |  
	|  |  
	| 
		
			| Re: IPv6 and OVZ part deux [message #41436 is a reply to message #41423] | Thu, 20 January 2011 18:12   |  
			| 
				
				
					|  lars.bailey Messages: 38
 Registered: April 2010
 | Member |  |  |  
	| I was getting ready to post my final conclusion to an issue in another thread,on using Ethernet bridging with IPv6. Your example confirmed my thinking,into a proper way of using IPv6 with bridged Ethernet.
 My thread here,mainly dealt with IPv6/OVZ,using non-bridged virtual Ethernet,and this type of setup is clean and simple.
 I have experimented with IPv6/OVZ/Ethernet bridging,and also ran into issues,using IPv6 with parallel bridges vs. source-route.
 Using an interface other than source-route,for a IPv6 Ethernet bridge,caused link-local breakdowns.
 It's not uncommon to use a parallel interface,for a IPv4 Ethernet bridge.
 Proxy_ARP,is only needed for the bridge.
 In using this type setup with IPv6,sans Proxy_ARP,the VE was reachable,but not the other way around.
 Once I try to "ping6" the Node source-route interface from a VE,link-local is lost on all bridged interfaces,including Ethernet bridge.
 This may be due to my part,in the way the network configurations was setup.
 The network daemon,did not initialize the VETH interfaces.
 They were set to;
 
 ONBOOT=no
 
 This kept the bogus "boot error" messages off the Node,where the VETH interface was not found,and was initialized by the vz daemon.
 This presented no problems with IPv4.
 Once I set this back to;
 
 ONBOOT=yes
 
 and let the network daemon initialize the interface,link-local would come back on the VETH interfaces.
 Removing the physical interface from the bridge,and restarting
 the interface(s),I would have link-local back on the bridge and
 physical interface.
 These,was always set to ONBOOT=yes.
 Why link-local is lost,is a mystery to me.
 Since IPv4 uses ARP and IPv6 uses NDP,enabling Proxy_NDP,did not
 help in this type of bridge setup.
 I simply removed the parallel bridge configuration,and created a Ethernet bridge using the source-route interface,and IPv6 over bridged Ethernet works perfect
 And as you stated,we do use DHCP for IPv4,to provide routing
 info and DNS,and this will be added later via DHCPv6.
 I'm going to try a couple of things from your post,on our test network.
 I'll let you know how it went.
 Thanks for your post.
 
 Regards
 
 Lars Bailey
 
 
 |  
	|  |  |  
	| 
		
			| Re: IPv6 and OVZ part deux [message #41437 is a reply to message #41436] | Fri, 21 January 2011 04:24   |  
			| 
				
				
					|  lars.bailey Messages: 38
 Registered: April 2010
 | Member |  |  |  
	| @ Jean-Marc 
 This is what I now use on a test Node,for IPv6/OVZ/Ethernet bridging.
 
 The Node server;
 
 * /etc/sysconfig/network
 
 NETWORKING=yes
 HOSTNAME=stooge
 GATEWAYDEV=virtbr0
 NETWORKING_IPV6=yes
 IPV6INIT=yes
 IPV6FORWARDING=yes
 IPV6_AUTOCONF=no
 IPV6_AUTOTUNNEL=no
 
 This is the source-route bridge network configuration.
 
 * ifcfg-virtbr0
 
 DEVICE=virtbr0
 TYPE=Bridge
 ONBOOT=yes
 STP=off
 DELAY=0
 BOOTPROTO=static
 IPADDR=192.168.1.72
 NETMASK=255.255.255.0
 IPV6ADDR=fd22:a075:afd0:e096::101/64
 IPV6_DEFAULTGW=fd22:a075:afd0:e096::1FF
 
 I used a private IPv6 address range,for internal testing.
 Node IPv6 routing table.
 
 # ip -6 ro show dev virtbr0
 fd22:a075:afd0:e096::/64  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
 fe80::/64  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
 default via fd22:a075:afd0:e096::1ff  metric 1  mtu 1500 advmss 1440 hoplimit 4294967295
 #
 
 A test VE container was created,and bound to the Ethernet bridge.
 
 # brctl show
 bridge name	bridge id		STP enabled	interfaces
 virtbr0		8000.001851a86b76	no		eth0
 veth6101.0
 #
 
 This is the test VE network configuration.
 
 DEVICE=eth0
 TYPE=Ethernet
 ONBOOT=yes
 IPV6INIT=yes
 IPV6ADDR=fd22:a075:afd0:e096:65::65/64
 
 From Node,the VE is reachable.
 
 # ping6 -c 3 fd22:a075:afd0:e096:65::65
 PING fd22:a075:afd0:e096:65::65(fd22:a075:afd0:e096:65::65) 56 data bytes
 64 bytes from fd22:a075:afd0:e096:65::65: icmp_seq=1 ttl=64 time=1.34 ms
 64 bytes from fd22:a075:afd0:e096:65::65: icmp_seq=2 ttl=64 time=0.375 ms
 64 bytes from fd22:a075:afd0:e096:65::65: icmp_seq=3 ttl=64 time=0.372 ms
 
 --- fd22:a075:afd0:e096:65::65 ping statistics ---
 3 packets transmitted, 3 received, 0% packet loss, time 2002ms
 rtt min/avg/max/mdev = 0.372/0.696/1.342/0.457 ms
 #
 
 From VE,Node is reachable.
 
 # vzctl enter 6101
 entered into VE 6101
 [root@moe /]# ping6 -c 3 fd22:a075:afd0:e096::101
 PING fd22:a075:afd0:e096::101(fd22:a075:afd0:e096::101) 56 data bytes
 64 bytes from fd22:a075:afd0:e096::101: icmp_seq=1 ttl=64 time=1.50 ms
 64 bytes from fd22:a075:afd0:e096::101: icmp_seq=2 ttl=64 time=0.403 ms
 64 bytes from fd22:a075:afd0:e096::101: icmp_seq=3 ttl=64 time=0.401 ms
 
 --- fd22:a075:afd0:e096::101 ping statistics ---
 3 packets transmitted, 3 received, 0% packet loss, time 2002ms
 rtt min/avg/max/mdev = 0.401/0.769/1.503/0.519 ms
 [root@moe /]#
 
 It's pretty straight-forward,and no more worries on link-local breakage.
 For IPv4,it was pretty straight-forward too.
 This is the IPv4 container's routing.
 
 [root@curly /]# ip ro show
 192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.64
 169.254.0.0/16 dev eth0  scope link
 default via 192.168.1.254 dev eth0
 
 This should be self-explainatory.
 Ping OpenVZ website.
 
 [root@curly /]# ping -c 3 www.openvz.org
 PING www.openvz.org (64.131.90.7) 56(84) bytes of data.
 64 bytes from openvz.org (64.131.90.7): icmp_seq=1 ttl=48 time=38.3 ms
 64 bytes from openvz.org (64.131.90.7): icmp_seq=2 ttl=48 time=40.1 ms
 64 bytes from openvz.org (64.131.90.7): icmp_seq=3 ttl=48 time=38.3 ms
 
 --- www.openvz.org ping statistics ---
 3 packets transmitted, 3 received, 0% packet loss, time 2042ms
 rtt min/avg/max/mdev = 38.381/38.982/40.184/0.879 ms
 [root@curly /]#
 
 What differs here now is,the IPv4 containers are directly routed,and I'm a little concerned about DHCP time-outs,due to X bridged interfaces on source-route.
 In using DHCP on the Node for network assignment,required the use of NAT rules,as the IPv4 containers resided on their own subnet.
 This simplified route management for a VE.
 Since,I have never used a source-route Ethernet bridge setup with DHCP,I think NAT rules still applies,but I will give your aliased interface a shot,and see what happens.
 In truth,I'm not a big fan of source-route bridging.
 But with IPv6/Ethernet bridging,this is going to be a common practice.
 One arena I want to play around with,is using VDE.
 I downloaded "openVswitch",compiled,and installed on the test Node.
 Time is not a premium for me right now,and my technology mistress is going to accompany me,in finding a good divorce lawyer.(LOL)
 
 
 
 
 
 
 |  
	|  |  |  
	| 
		
			| Re: IPv6 and OVZ part deux [message #41457 is a reply to message #41338] | Tue, 25 January 2011 13:03   |  
			| 
				
				
					|  lars.bailey Messages: 38
 Registered: April 2010
 | Member |  |  |  
	| I tried the aliased interface solution,and found it wasn't needed for my specific application,but thanks for the info.
 For what its worth,I dumped the source-route bridge,as I prefer to
 have the ability to provide other transit mechanisms.
 Between Ethernet bridging vs. virtual Ethernet with IPv6,it has now
 become moot.
 Unless you need bridging for a specific application(auto-config),I simply go with IPv6 virtual Ethernet,as these types of containers,are now reachable from within other containers.(just like bridged containers)
 I do like the idea of using multiple bridges(physically or virtually bound),to form bridge groups,and these have worked with no issues.
 Since removing ProxyARP and ProxyNDP,for dual-homed bridges,I do not have the link-local breakdowns,I had before.
 In hind-sight,this was always demonstrated in documentation on the
 Net.
 |  
	|  |  |  
	| 
		
			| Re: IPv6 and OVZ part deux [message #41503 is a reply to message #41338] | Wed, 02 February 2011 10:56  |  
			| 
				
				
					|  lars.bailey Messages: 38
 Registered: April 2010
 | Member |  |  |  
	| Although I mentioned link-local breakdowns on Oracle server in this post,this issue was contributed to an error on my part. We moved off of physically bound Ethernet bridges,to virtually bound bridges.
 For this particular test server,I forgot to create and bind a TAP interface,to the bridge.
 Once I created the TAP,bound it to the bridge,then everything worked as it should.
 No ProxyARP and ProxyNDP.
 No link-local breakdowns.
 Since we do not use other network interfaces on the Node,for anything other than taking up MB slots,physically bound bridges  did not make sense,as the Node's do not use source-route bridging.
 Forgetting TAP interfaces for virtual bridges won't be a problem now,as the Node's will be retro-fitted with virtually switched VLANS,using VDE.
 Live and learn.
 
 
 |  
	|  |  | 
 
 
 Current Time: Fri Oct 31 11:07:53 GMT 2025 
 Total time taken to generate the page: 0.11172 seconds |