Using mping command to verify multicast communication

no comments
In PowerHA 7.1 clusters mping is very useful tool to check that multicast communications work for CAA.

By default, PowerHA® SystemMirror® uses unicast communications for heartbeat. For cluster communication, you can optionally select to configure a multicast address or have CAA automatically select the multicast address if your network is configured to support multicast communication. If you choose to use multicast communication, do not attempt to create a cluster until you verify that multicast packets can be sent successfully across all nodes that are part of the cluster. end of change

To test end-to-end multicast communication for all nodes used to create the cluster on your network, run the mping command to send and receive packets between nodes.

If you are running PowerHA SystemMirror 7.1.1, or later, you cannot create a cluster if the mping command fails. If the mping command fails, your network is not set up correctly for multicast communication. If so, review the documentation for your switches and routers to enable multicast communication.

You can run the mping command with a specific multicast address; otherwise, the command uses a default multicast address. You must use the multicast addresses that are used for creating the cluster as input for the mping command.

Note: The mping command uses the interface that has the default route. To use the mping command to test multicast communication on a different interface that does not have the default route, you must temporarily add a static route with the required interface to the multicast IP address.

start of change The following example shows a success case and a failure case for the mping command, where node A is the receiver and node B is the sender. end of change

start of change Success case:

Receiver

root@nodeA:/# mping -r -R -c 5
mping version 1.1
Listening on 227.1.1.1/4098:

Replying to mping from 9.3.207.195 (nodeB.aus.stglabs.ibm.com) bytes=32 seqno=0 ttl=1
Replying to mping from 9.3.207.195 (nodeB.aus.stglabs.ibm.com) bytes=32 seqno=1 ttl=1
Replying to mping from 9.3.207.195 (nodeB.aus.stglabs.ibm.com) bytes=32 seqno=2 ttl=1
Replying to mping from 9.3.207.195 (nodeB.aus.stglabs.ibm.com) bytes=32 seqno=3 ttl=1
Replying to mping from 9.3.207.195 (nodeB.aus.stglabs.ibm.com) bytes=32 seqno=4 ttl=1

Sender

root@nodeB:/# mping -R -s -c 5
mping version 1.1
mpinging 227.1.1.1/4098 with ttl=1:

32 bytes from 9.3.207.190 (nodeA.aus.stglabs.ibm.com) seqno=0 ttl=1 time=0.985 ms
32 bytes from 9.3.207.190 (nodeA.aus.stglabs.ibm.com) seqno=1 ttl=1 time=0.958 ms
32 bytes from 9.3.207.190 (nodeA.aus.stglabs.ibm.com) seqno=2 ttl=1 time=0.998 ms
32 bytes from 9.3.207.190 (nodeA.aus.stglabs.ibm.com) seqno=3 ttl=1 time=0.863 ms
32 bytes from 9.3.207.190 (nodeA.aus.stglabs.ibm.com) seqno=4 ttl=1 time=0.903 ms

--- 227.1.1.1 mping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.863/0.941/0.998 ms

end of change

start of change Failure case:

Receiver

root@nodeA:/# mping -r -R -c 5 -6
mping version 1.1
Listening on ff05::7F01:0101/4098:

Replying to mping from fe80::18ae:19ff:fe72:1a15 bytes=48 seqno=0 ttl=1
Replying to mping from fe80::18ae:19ff:fe72:1a15 bytes=48 seqno=1 ttl=1
Replying to mping from fe80::18ae:19ff:fe72:1a15 bytes=48 seqno=2 ttl=1
Replying to mping from fe80::18ae:19ff:fe72:1a15 bytes=48 seqno=3 ttl=1
Replying to mping from fe80::18ae:19ff:fe72:1a15 bytes=48 seqno=4 ttl=1

Sender

root@nodeB:/# mping -R -s -c 5 -6
mping version 1.1
mpinging ff05::7F01:0101/4098 with ttl=1:


--- ff05::7F01:0101 mping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.000/0.000/0.000 ms

end of change

Note: start of change To verify a result, you must check the sender side of the mping command only. Also, note the percentage of packet loss. To verify whether multicast is working on a network, you must perform the mping tests with both nodes tested as both the sender and receiver. Typically, the non-verbose output provides you the necessary information. However, if you choose to use the -v flag with the mping command, a good knowledge about the internals of the program is necessary, without which the verbose output can be misunderstood. You can also check the return code from the sender side of the mping command. If an error occurs, the sender side returns 255. Upon success, it returns 0. end of change

Cluster Aware AIX (CAA) selects a default multicast address if you do not specify a multicast address when you create the cluster. The default multicast address is created by combining the logical OR of the value (228.0.0.0) with the lower 24 bits of the IP address of the node. For example, if the IP address is 9.3.199.45, then the default multicast address would be 228.3.199.45.

The Internet Protocol version 6 (IPv6) addresses are supported by PowerHA SystemMirror 7.1.2, or later. When IPv6 addresses are configured in the cluster, Cluster Aware AIX (CAA) activates heartbeating for the IPv6 addresses with an IPv6 multicast address. You must verify that the IPv6 connections in your environment can communicate with multicast addresses.

To verify that IPv6 multicast communications are configured correctly in your environment, you can run the mping command with the -6 option. When you run the mping command, it verifies the IPv6 multicast communications with the default IPv6 multicast address. To specify a specific IPv6 multicast address, run the mping command with the -a option and specify an IPv6 multicast address. You do not need to specify the -6 option when using the -a option. The mping command automatically determines the family of the address passed with the -a option.

Installing Symantec™ Cluster Server 6.1 on AIX servers

Comments Off

Daniel writes a nice blog on how to install Symantec Cluster Service 6.1 on AIX servers.

 

Step by step procedure:

 

Building a Symantec Cluster Server on IBM POWER 

 

Comments Off

Using tools iptrace, snoop, tcpdump, wireshark, and nettl to trace packet

Comments Off

Problem(Abstract)

Creating, formatting, and reading packet traces is sometimes required to resolve problems with IBM® WebSphere® Edge Server. However, the most appropriate tool varies, depending on operating system.

Resolving the problem

Available for multiple operating systems
Wireshark is useful and a freely available tool that can read files and capture packets on almost any operating system.

Using iptrace on AIX®
You can use any combination of these options, you do not need to use them all:

-a Do NOT print out arps. Useful with clean up traces.
-s <source id> Limit trace to source/client IP address, if known.
-d <destination id> Limit trace to destination IP, if known.
-b Capture bidirectional traffic (send and responsepackets).
-p <port> Specify the port to be traced.

Example:

  1. Run iptrace on AIX interface en1 to capture port 80 traffic from a single client IP to a server IP:

    iptrace -a -i en1 -s clientip -b -d serverip -p 80 trace.out

    This trace will capture both directions of the port 80 traffic on interface en1 between the clientip and serverip and send this to the raw file of trace.out.

  2. Reproduce the problem, then run the following:

    ps -ef|grep iptrace
    kill -15 <pid>

Trace tools like Wireshark can read trace.out files created by iptrace

exception: it is not possible to collect a packet capture on AIX when using IBM Load Balancer for ipv4 and ipv6
.

Using snoop on Solaris™

-v Include verbose output. Commonly used when dumping to pre-formatted output.
-o Dump in binary format. Output written to a binary file that is readable by Ethereal.

Example scenario:
snoop hme0 -v >snoop.out
snoop -o snoop.out

These commands capture all traffic on the hme0 interface. Use combinations of snoop options to meet your needs.

Warning: Using some options, packets may be corrupted by snoop.

Using tcpdump on Linux®
tcpdump has many options and a comprehensive man page.

A simple way to capture all packets to a binary file which is readable with ethereal.

Example:
tcpdump -s 2000 -w filename.out

For a simple packet trace that is formatted and readable by any text editor.
This will listen on the default interface for all port 80 traffic.

Example:
tcpdump port 80 >filename.out

This will watch only the eth1 interface.

Example:
tcpdump -i eth1 >filename.out

Using Network Monitor with Microsoft® Windows®

  1. Start Network Monitor.
  2. Select the interface to listen on and click start.
  3. Once the traffic needed has been captured, click stop.
  4. Save the resulting file which can be read by Network Monitor or ethereal.

For additional information, visit the technote, How to capture network traffic with Network Monitor

Using nettl on HP-UX
The nettl tool provides control network tracing and logging.

Scenario:
/usr/sbin/nettl -start
/usr/sbin/nettl -stop
/usr/sbin/nettl -firmlog 0|1|2 -card dev_name ...
/usr/sbin/nettl -log class ... -entity subsystem ...
/usr/sbin/nettl -status [log |trace |all]
/usr/sbin/nettl -traceon kind ... -entity subsystem ...
     [-card dev_name ...] [-file tracename] [-m bytes] [-size portsize]
     [-tracemax maxsize] [-n num_files]
/usr/sbin/nettl -traceoff -entity subsystem ...

Comments Off