Configuring IBM PowerHA SystemMirror with IPv6
This appendix describes how to configure IBM PowerHA SystemMirror with IPv6.
The following topics are presented:
Configuring IBM PowerHA SystemMirror with IPv6
This section includes tips and considerations discovered while configuring IBM PowerHA SystemMirror with IPv6.
Enabling IPv6 on AIX
This section covers the basic steps to enable IPv6 on AIX. This must be done prior to performing any PowerHA configuration steps.
Autoconf6
On AIX, IPv6 can be enabled by the autoconf6 command. If no flags are specified, this command enables IPv6 on every Ethernet adapter that is configured. The -i flag is used to specify that certain adapters will be configured as IPv6. After executing the command, the IPv6 link local address is configured on the adapter that has been specified. Also SIT interface sit0 (used for IPv4-compatible IPv6 addresses) is configured as shown in Example A-1.
Example A-1 Executing autoconf6
# autoconf6 -i en1
# ifconfig -a
en0: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
inet 192.168.100.55 netmask 0xffffff00 broadcast 192.168.100.255
tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
en1: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
inet6 fe80::7840:c3ff:fe0b:1f03/64
tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
sit0: flags=8100041<UP,RUNNING,LINK0>
inet6 ::192.168.100.55/96
lo0: flags=e08084b,c0<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,LARGESEND,CHAIN>
inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
inet6 ::1%1/128
tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1
For these configuration changes to persist after a reboot, execute smitty chauto6. Choose the adapter to enable IPv6. Confirm your setting in the SMIT panel as shown in Figure A-1 on page 467, and press Enter.
|
Change / Show Restart Characteristics of Autoconf6 Process
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
* Start the Autoconf6 Process with VERBOSE on? no +
* Start the Autoconf6 Process with SIT on? yes +
Network INTERFACE en1
|
Figure A-1 Changing the autoconf6 process
After executing, the /etc/rc.tcpip file is modified as shown in Example A-2.
Example A-2 Activating the autoconf6 through /etc/rc.tcpip
# cat /etc/rc.tcpip | grep autoconf6
# Start up autoconf6 process
start /usr/sbin/autoconf6 "" " -i en1"
Configuring a static IPv6 address
To configure a static IPv6 address, the ifconfig command can be used with the inet6 flag as shown in Example A-3.
Example A-3 Configuring a static IP with the ifconfig command
# ifconfig en1 inet6 2000::c0a8:6437 prefixlen 64
For this change to persist after a reboot, smitty chinet6 can be used as shown in Figure A-2.
|
Change / Show an IPV6 Standard Ethernet Interface
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Network Interface Name en1
IPV6 ADDRESS (colon separated) [2000::c0a8:6437]
Prefixlength [64]
Current STATE up +
|
Figure A-2 SMIT panel for configuring the IPv6 address
This modifies the attributes of the specified device. The lsattr command is used to display the configuration, as shown in Example A-4.
Example A-4 Modified IP attribute
# lsattr -El en1 -a netaddr6 -a prefixlen -a state
netaddr6 2000::c0a8:6437 IPv6 Internet Address True
prefixlen 64 prefix Length for IPv6 Internet Address True
state up Current Interface Status True
Configuring local name resolutions
To configure local name resolutions, modify the /etc/hosts file as shown in Example A-5.
Example A-5 Adding IPv6 entries in /etc/hosts
# cat /etc/hosts
# IPv6 boot
2000::c0a8:6437 glvma1ip6
2000::c0a8:6438 glvma2ip6
2000:aaaa::a0a:6439 glvmb1ip6
2000:aaaa::a0a:643a glvmb2ip6
If the DNS is configured, and /etc/resolv.conf exists, remember to edit the /etc/netsvc.conf file to prefer local name resolutions by adding local or local6 to the hosts variable.
Configuring IPv6 static routes
To configure IPv6 static routes, the route command can be used with an inet6 flag as shown in Example A-6.
Example A-6 Adding routes through the route command
# route add -inet6 default 2000::c0a8:643b
For this to persist across a reboot, smitty mkroute6 can be used as shown in Figure A-3.
|
Add an IPV6 Static Route
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Destination TYPE net +
* IPV6 DESTINATION Address [default]
(colon separated or symbolic name)
* IPV6 GATEWAY Address [2000::c0a8:643b]
(colon separated or symbolic name)
COST [0] #
Prefixlength [64] #
Network Interface [] +
(interface to associate route with)
Enable Active Dead Gateway Detection? no +
|
Figure A-3 SMIT panel for adding routes
This modifies the attributes of the specified device. The lsattr command is used to display the configuration, as shown in Example A-7.
Example A-7 Route labels that have been modified
# lsattr -El inet0 -a rout6
rout6 net,-hopcount,0,,,,-static,::,2000::c0a8:643b IPv6 Route True
Configuration tips for PowerHA with IPv6
This section covers tips and limitations for configuring PowerHA with IPv6.
Persisting a static IPv6 address
In our test environment, we were required to perform the following for the static IPv6 address to persist during system reboots and cluster activation:
•Add the -g flag to the ndpd-host daemon.
•Disable the Router Advertisement (RA) functions on the network routers.
The reason these were required is that IPv6 introduces IPv6 stateless address auto configuration. This is a function that the client communicates with the network routers and automatically configures a global IPv6 address, which is based on the following:
•The network prefix provided from the network routers
•The client network card MAC address
|
Note: Refer to RFC 4862 - IPv6 Stateless Address Auto configuration for more details at:
http://tools.ietf.org/html/rfc4862
|
In AIX the ndpd-host daemon is responsible for the stateless IPv6 addresses.
When PowerHA is installed and the IPv6 addresses are configured, the ndpd-host daemon starts up on system startup. The hacmp entry in the inittab file is responsible for this as shown in Example A-8.
Example A-8 ndp-host startup from the hacmp entry in the inittab file
# lsitab hacmp
hacmp:2:once:/usr/es/sbin/cluster/etc/rc.init >/dev/console 2>&1
# cat /usr/es/sbin/cluster/etc/rc.init
IPV6_BOOT_INTERFACES=$(cllsif -S -J "$OP_SEP" | grep "${OP_SEP}$NODENAME${OP_SEP}" |
grep "${OP_SEP}boot${OP_SEP}" | grep AF_INET6 | cut -d"$OP_SEP" -f9)
[[ -n "$IPV6_BOOT_INTERFACES" ]] && {
for INTERFACE in $IPV6_BOOT_INTERFACES
do
/usr/sbin/autoconf6 -i $INTERFACE
done
/usr/bin/startsrc -s ndpd-host
sleep 60
}
...
Upon activating ndpd-host, we discovered that ndpd-host deletes the static IPv6 address, and instead the stateless IPv6 address becomes the global IPv6 address as shown in Example A-9.
Example A-9 Static IP address getting deleted
# lssrc -s ndpd-host
Subsystem Group PID Status
ndpd-host tcpip inoperative
# ifconfig en1
en1: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
inet6 2000::c0a8:6437/64
inet6 fe80::7840:c3ff:fe0b:1f03/64
tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
# startsrc -s ndpd-host
0513-059 The ndpd-host Subsystem has been started. Subsystem PID is 8782050.
# ifconfig en1
en1: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
inet6 2000::7840:c3ff:fe0b:1f03/64 <---- static IP address gets deleted and stateless IP address is being used
inet6 fe80::7840:c3ff:fe0b:1f03/64
tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
This is a known issue; APAR IV16141 has introduced the -g flag to avoid deletion of the static IPv6 address. Since the hacmp entry in the inittab starts the ndpd-host daemon with no flags specified, we needed to add this flag with the chssys command as shown in Example A-10. This must be executed on all nodes in the cluster.
Example A-10 Changing the attributes in ndpd-host
# chssys -s ndpd-host -a "-g"
# odmget -q "subsysname = ndpd-host" SRCsubsys
SRCsubsys:
subsysname = "ndpd-host"
synonym = ""
cmdargs = "-g" <----- confirm the setting
path = "/usr/sbin/ndpd-host"
uid = 0
auditid = 0
standin = "/dev/console"
standout = "/dev/console"
standerr = "/dev/console"
action = 2
multi = 0
contact = 3
svrkey = 0
svrmtype = 0
priority = 20
signorm = 0
sigforce = 0
display = 1
waittime = 20
grpname = "tcpip"
The execution of the command shown in Example A-10 on page 470 prevents the static IPv6 address from being deleted. However, now the stateless IPv6 address and the static IPv6 will coexist on the same adapter, as shown in Example A-11.
Example A-11 Coexistence of stateless and static IP addresses
# ifconfig en1
en1: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
inet6 fe80::7840:c3ff:fe0b:1f03/64
inet6 2000::c0a8:6437/64
tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
# startsrc -s ndpd-host
0513-059 The ndpd-host Subsystem has been started. Subsystem PID is 8782052.
# ifconfig en1
en1: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
inet6 2000::7840:c3ff:fe0b:1f03/64 <---- stateless IP address
inet6 fe80::7840:c3ff:fe0b:1f03/64
inet6 2000::c0a8:6437/64 <---- static IP address
tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
This also led to another issue: it changes the source IP addresses of packets. In the event of performing a migration, this made clmigcheck fail to create the CAA cluster due to incoming IPs not listed in /etc/cluster/rhosts. Example A-12 shows the error observed during the clmigcheck command.
Example A-12 clmigcheck error
# cat /etc/hosts
# IPv6 boot
2000::c0a8:6437 glvma1ip6
2000::c0a8:6438 glvma2ip6
2000:aaaa::a0a:6439 glvmb1ip6
2000:aaaa::a0a:643a glvmb2ip6
# cat /etc/cluster/rhosts
glvma1ip6
glvma2ip6
glvmb1ip6
glvmb2ip6
# clmigcheck
Saving existing /tmp/clmigcheck/clmigcheck.log to /tmp/clmigcheck/clmigcheck.log.bak
Verifying clcomd communication, please be patient.
ERROR: COMM-ERROR: Unable to verify inbound clcomd communication to node: glvma1ip6
Example A-13 on page 472 shows the tcpdump command on glvma1ip6 during the clmigcheck error. You can see, in bold, that the communication is done using the stateless IP addresses.
Example A-13 tcpdump from glvma1ip6 during the clmigcheck error
# ifconfig -a
en1: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
inet6 2000::7840:c3ff:fe0b:1f03/64 <---- stateless IP address.
inet6 fe80::7840:c3ff:fe0b:1f03/64
inet6 2000::c0a8:6437/64 <---- static IP address.
tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
# tcpdump -i en1 ip6
11:26:27.894223 IP6 2000::7840:c3ff:fe0b:1f03.1023 > glvmb2ip6.clcomd: . ack 147 win 32844 <nop,nop,timestamp 1353688754 1353688744>
11:26:27.894258 IP6 2000::7840:c3ff:fe0b:1f03.1023 > glvmb2ip6.clcomd: F 72:72(0) ack 147 win 32844 <nop,nop,timestamp 1353688754 1353688744>
11:26:27.894399 IP6 glvmb2ip6.clcomd > 2000::7840:c3ff:fe0b:1f03.1023: . ack 73 win 32844 <nop,nop,timestamp 1353688744 1353688754>
11:26:27.894897 IP6 glvmb2ip6.clcomd > 2000::7840:c3ff:fe0b:1f03.1023: S 814143724:814143724(0) ack 814079652 win 65535 <mss 1440,nop,wscale 3,nop,nop,timestamp 1353688744 1353688754>
In our test scenarios, to avoid further issues, we decided to disable the network routers’ Router Advertisement (RA) function, which is responsible for creating the stateless IPv6 addresses. Consult with your network administrator to inquire whether the same is possible in your environment.
|
Tips: Disabling the router advertisement differs depending on which network router you use. For CISCO IOS version 15.1 or later, issue the following command:
> ipv6 nd ra suppress all
|
The IBM PowerHA SystemMirror development team is currently addressing these issues, and intends to solve them in future software releases.
You may use the stateless IPv6 address instead of a static IPv6 address. However, we do not suggest doing so. Since a stateless IPv6 address is based on network router settings and the nodes MAC address, there is no guarantee that this IP address will persist.
Manual configuration of IPv6 labels
In our test environment we encountered issues were IPv6 interfaces and networks were not configured during cluster configuration through smitty sysmirror → Cluster Nodes and Networks → Multi Site Cluster Deployment → Setup a Cluster, Sites, Nodes and Networks. If these situations occur, configure IPv6 labels manually through smitty sysmirror → Cluster Nodes and Networks → Manage Networks and Network Interfaces. When configuring network interfaces, although optional, we advise to specify the interfaces in the SMIT panel as shown in Figure A-4 on page 473.
|
Add a Network Interface
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
* IP Label/Address [glvmb1ip6] +
* Network Type ether
* Network Name net_ether_03
* Node Name [glvmb1ip6] +
Network Interface [en1] <----
|
Figure A-4 Specifying network interfaces
When these interfaces are not specified, we see verification errors stating that a link local address has not been detected, as shown in Figure A-5. This still occurs even if we follow the steps in “Autoconf6” on page 466.
|
WARNING: No Link local addresses detected on interface of node glvmb1ip6.
Do you want to auto-configure link-local address on interface of glvmb1ip6? [Yes / No]:
|
Figure A-5 Verification error for a null interface device
The warning disappeared after specifying the network interface, as shown in Figure A-4.
IPv6 service IP label limitations
IPv6 service labels can only be configured on XD_data and ether networks. Figure A-6 shows the verification errors if configured for different types of networks. Currently XD_ip networks cannot be configured with IPv6 service IPs.
|
ERROR: Resource group "glvm_ip6" has IPv6 service label "glvmasrv" configured on
unsupported network type. IPv6 service IP can only be configured on network
of type "ether and XD_data".
|
Figure A-6 Verification error when configuring IPv6 service labels on an XD_ip network
The IBM PowerHA SystemMirror development team is currently addressing this limitation, and intends to solve it in future software releases.
IPv6 service IP label takeover issues
We encountered an issue when configuring the boot and service IPv6 label to the same prefix. When a service IP takeover occurs, the routing table gets deleted making the node inaccessible. Example A-14 shows the routing table before the service IP takeover.
Example A-14 IPv6 route before IP takeover
Route tree for Protocol Family 24 (Internet v6):
::/96 0.0.0.0 UC 0 0 sit0 - - =>
default 2000::c0a8:643b UGS 4 4055 en1 - -
::1%1 ::1%1 UH 1 56 lo0 - -
::192.168.100.55 192.168.100.55 UHLW 0 8 lo0 - -
2000::c0a8:6400/120 link#3 UC 1 0 en1 - -
2000::c0a8:6437 UHLWl 1 1750 lo0 - -
2000::c0a8:6438 7a:40:cf:a:ea:3 UHL 1 1798 en1 - -
2000::c0a8:6439 UHLWl 0 12 lo0 - -
2000::c0a8:643a 7a:40:cf:a:ea:3 UHLW 0 3 en1 - -
2000::c0a8:643b ee:af:b:bb:b8:2 UHLW 1 0 en1 - -
fe80::/64 link#3 UCX 2 0 en1 - -
fe80::7840:cfff:fe0a:ea03 7a:40:cf:a:ea:3 UHL 0 7 en1 - -
fe80::ecaf:bff:febb:b802 ee:af:b:bb:b8:2 UHL 0 17 en1 - -
ff01::%2/16 ::1 U 0 3 lo0 - -
ff02::/16 fe80::7840:c3ff:fe0b:1f03 U 0 36 en1 - -
ff11::%2/16 ::1 U 0 0 lo0 - -
ff12::/16 fe80::7840:c3ff:fe0b:1f03 U 0 0 en1 - -
Example A-15 shows the routing table after the service IP takeover, which shows the highlighted routes getting deleted.
Example A-15 IPv6 routes after IP takeover
Route tree for Protocol Family 24 (Internet v6):
::/96 0.0.0.0 UC 0 0 sit0 - - =>
default 2000::c0a8:643b UGS 10 40752 en1 - -
::1%1 ::1%1 UH 1 136 lo0 - -
::192.168.100.55 192.168.100.55 UHLW 0 8 lo0 - -
fe80::/64 link#3 UCX 6 0 en1 - -
fe80::7840:cfff:fe0a:ea03 7a:40:cf:a:ea:3 UHL 0 5 en1 - -
fe80::ecaf:bff:febb:b802 ee:af:b:bb:b8:2 UHL 0 5 en1 - -
ff01::%2/16 ::1 U 0 3 lo0 - -
ff02::/16 fe80::7840:c3ff:fe0b:1f03 U 0 41 en1 - -
ff11::%2/16 ::1 U 0 0 lo0 - -
ff12::/16 fe80::7840:c3ff:fe0b:1f03 U 0 0 en1 - -
Currently this can be avoided in one of two ways:
•Configure the IPv6 service labels other than the prefix of the IPv6 boot label.
•Use pre-post scripts to manually rebuild the routing table.
|
Important: There will be no IBM support for using this method. Testing will be your responsibility.
|
Development is currently aware of this issue. Contact your IBM support for any available fixes.
Multicast packets in an IPv6/IPv4 dual stack environment
When CAA is configured in a dual stack environment with isolated IPv4 and IPv6 networks, you observe the following behavior:
•IPv4 multicast is only sent through IPv4 adapters.
•IPv6 multicast is only sent through IPv6 adapters.
You can use the tcpdump command to confirm this behavior. Example A-16 shows the output in our environment.
Example A-16 Tcpdump in IPv6/IPv4 dual stack configuration
Multicast addresses:
IPv4 224.10.100.57
IPv6 ff05::e00a:6439
en0 is IPv4 isolated network
en1 is IPv6 isolated network
-------------------------------------------------------------------------------------
# tcpdump -i en0 ip multicast
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type 1, capture size 96 bytes
08:14:25.626648 IP glvmb1.drmsfsd > 224.10.100.57.drmsfsd: UDP, length 384
08:14:25.626678 IP glvmb1.drmsfsd > 224.10.100.57.drmsfsd: UDP, length 384
08:14:25.926655 IP glvmb1.drmsfsd > 224.10.100.57.drmsfsd: UDP, length 384
08:14:25.926685 IP glvmb1.drmsfsd > 224.10.100.57.drmsfsd: UDP, length 384
08:14:26.226669 IP glvmb1.drmsfsd > 224.10.100.57.drmsfsd: UDP, length 384
08:14:26.226698 IP glvmb1.drmsfsd > 224.10.100.57.drmsfsd: UDP, length 384
08:14:26.466735 IP glvmb1.drmsfsd > 224.10.100.57.drmsfsd: UDP, length 208
08:14:26.526679 IP glvmb1.drmsfsd > 224.10.100.57.drmsfsd: UDP, length 384
08:14:26.526705 IP glvmb1.drmsfsd > 224.10.100.57.drmsfsd: UDP, length 384
^C
165 packets received by filter
0 packets dropped by kernel
-------------------------------------------------------------------------------------
# tcpdump -i en1 ip multicast <------ no IPv4 multicast through en1
tcpdump: WARNING: en1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type 1, capture size 96 bytes
^C
150 packets received by filter
0 packets dropped by kernel
-------------------------------------------------------------------------------------
# tcpdump -i en0 ip6 multicast <------ no IPv6 multicast through en0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type 1, capture size 96 bytes
^C
377 packets received by filter
0 packets dropped by kernel
-------------------------------------------------------------------------------------
# tcpdump -i en1 ip6 multicast
tcpdump: WARNING: en1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type 1, capture size 96 bytes
08:15:20.828613 IP6 glvmb1ip6.drmsfsd > ff05::e00a:6439.drmsfsd: UDP, length 384
08:15:20.828636 IP6 glvmb1ip6.drmsfsd > ff05::e00a:6439.drmsfsd: UDP, length 384
08:15:21.128621 IP6 glvmb1ip6.drmsfsd > ff05::e00a:6439.drmsfsd: UDP, length 384
08:15:21.128645 IP6 glvmb1ip6.drmsfsd > ff05::e00a:6439.drmsfsd: UDP, length 384
^C
20 packets received by filter
0 packets dropped by kernel
The mping command can be used to verify that your network is correctly configured for multicast packets. For an overview of how to use the mping command, refer to multicast in a network verification at:
http://pic.dhe.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.powerha.trgd/ha_trgd_test_multicast.htm
Example A-17 on page 476 shows the results of the IPv4 multicast address verification in our test environment.
|
Important: When the hostname is configured to an IPv6 label, we observed that the mping command fails with the following error:
---------------------------------------------------------
# host `hostname`
glvma1ip6 is 2000::c0a8:6437 # mping -v -s -c 5 -a 224.10.100.57 mping version 1.1 gethostbyname() failed in mping_init_socket(): Error 0 -----------------------------------------------------------------------------
APAR IV34031 is opened for this issue.
The output shown in Example A-17 was taken when the hostname command was configured with an IPv4 label.
|
Example A-17 IPv4 multicast verification with the mping command
glvmb1ip6:
# mping -v -r -c 5 -a 224.10.100.57
mping version 1.1
Connecting using IPv4.
Listening on 224.10.100.57/4098:
Replying to mping from 10.10.100.58 bytes=32 seqno=0 ttl=1
Replying to mping from 10.10.100.58 bytes=32 seqno=1 ttl=1
Replying to mping from 10.10.100.58 bytes=32 seqno=2 ttl=1
Replying to mping from 10.10.100.58 bytes=32 seqno=3 ttl=1
Replying to mping from 10.10.100.58 bytes=32 seqno=4 ttl=1
#
----------------------------------------------------------
glvmb2ip6:
glvmb2ip6:
# mping -v -s -c 5 -a 224.10.100.57
mping version 1.1
Connecting using IPv4.
mpinging 224.10.100.57/4098 with ttl=1:
32 bytes from 10.10.100.57 seqno=0 ttl=1 time=0.196 ms
32 bytes from 10.10.100.57 seqno=1 ttl=1 time=0.160 ms
32 bytes from 10.10.100.57 seqno=2 ttl=1 time=0.161 ms
32 bytes from 10.10.100.57 seqno=3 ttl=1 time=0.153 ms
32 bytes from 10.10.100.57 seqno=4 ttl=1 time=0.156 ms
Sleeping for 1 second to wait for any additional packets to arrive.
--- 224.10.100.57 mping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.153/0.165/0.196 ms
If the mping command is issued with the -a flag, the IPv6 multicast addresses can also be specified. Example A-18 shows the results of an IPv6 multicast address in our test environment.
Example A-18 IPv6 multicast verification with the mping command
glvmb1ip6:
# mping -v -r -c 5 -a ff05::e00a:6439
mping version 1.1
Connecting using IPv6.
Listening on ff05::e00a:6439/4098:
Replying to mping from 2000:aaaa::a0a:643a bytes=48 seqno=0 ttl=1
Replying to mping from 2000:aaaa::a0a:643a bytes=48 seqno=1 ttl=1
Replying to mping from 2000:aaaa::a0a:643a bytes=48 seqno=2 ttl=1
Replying to mping from 2000:aaaa::a0a:643a bytes=48 seqno=3 ttl=1
Replying to mping from 2000:aaaa::a0a:643a bytes=48 seqno=4 ttl=1
------------------------------------------------------------------
glvmb2ip6:
# mping -v -s -c 5 -a ff05::e00a:6439
mping version 1.1
Connecting using IPv6.
mpinging ff05::e00a:6439/4098 with ttl=1:
48 bytes from 2000:aaaa::a0a:6439 seqno=0 ttl=1 time=0.247 ms
48 bytes from 2000:aaaa::a0a:6439 seqno=1 ttl=1 time=0.210 ms
48 bytes from 2000:aaaa::a0a:6439 seqno=2 ttl=1 time=0.199 ms
48 bytes from 2000:aaaa::a0a:6439 seqno=3 ttl=1 time=0.239 ms
48 bytes from 2000:aaaa::a0a:6439 seqno=4 ttl=1 time=0.202 ms
Sleeping for 1 second to wait for any additional packets to arrive.
--- ff05::e00a:6439 mping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.199/0.219/0.247 ms
CAA command enhancements
The lscluster command has been enhanced to provide the following new support for IPv6:
lscluster { -i | -d | -c [ -n clustername ] } | { -m [ nodename ] | -s | -i interfacename | -d diskname }
-m option will display PROTOCOL as ipv4 or ipv6.
-i option has no change.
-s option will display network statistics with ipv6 additions.
Example A-19 shows lscluster -m output displaying the PROTOCOL information.
Example A-19 lscluster -m example showing new PROTOCOL information
Node name: glvma2ip6
Cluster shorthand id for node: 3
UUID for node: 4109e892-42be-11e2-a5a7-7a40c30b1f03
State of node: UP
Smoothed rtt to node: 7
Mean Deviation in network rtt to node: 3
Number of clusters node is a member in: 1
CLUSTER NAME SHID UUID
glvma1_cluster 0 40f4497e-42be-11e2-a5a7-7a40c30b1f03
SITE NAME SHID UUID
siteA 1 40ec25f0-42be-11e2-a5a7-7a40c30b1f03
Points of contact for node: 3
------------------------------------------
Interface State Protocol Status
------------------------------------------
dpcom DOWN none RESTRICTED
en0 UP IPv4 none
en1 UP IPv6 none
The lscluster -s command now shows IPv6 statistics in Example A-20.
Example A-20 Extract from lscluster -s showing IPv6 statistic information
IPv6 pkts sent: 1040346 IPv6 pkts recv: 4857164
IPv6 frags sent: 63 IPv6 frags recv: 0
Migrating steps from IPv4 to IPv6
If you are planning to migrate your cluster network configuration from IPv4 to IPv6, then the following steps should be taken:
1. Add your new IPv6 addresses to your configuration.
Without removing any IPv4 configuration, use the mktcpip command to add an IPv6 address to each of the nodes in your cluster.
|
Tip: IPv4 addresses at this point should still exist. Your node hostnames should still resolve to IPv4 addresses.
|
2. Stop cluster services on each node and make the changes.
On one node at a time, stop cluster services and make the changes:
clstartstop -stop -n <clustername> -m <node hostname>
Ensure that the changes are made in:
– Node network configuration
– NDPD router
– DNS Server
|
Note: Enable IPv6 address resolution of the node to the same hostname which earlier resolved to a IPv4 address. Ensure that forward and reverse lookup are configured the same.
|
Restart cluster services after the changes using:
clstartstop -start -n <clustername> -m <node-hostname>
3. Removing an IPv4 configuration.
Once you have completed the changes on all nodes, use the rmtcpip command to remove the existing IPv4 addresses from each node that previously resolved to the hostname. Migration is now complete.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.