setrdesigners.blogg.se - Wow troubleshooting iptrace

#Wow troubleshooting iptrace full#
#Wow troubleshooting iptrace free#
#Wow troubleshooting iptrace windows#

Then, we shall go into the user interfaces for both, storage management, security standards compliance and operations, and full systems management.

#Wow troubleshooting iptrace windows#

Whether you are a Windows expert looking to learn more about the latest version of AIX, AIX 5L, or are an AIX expert and are looking to inform yourself of the latest Windows platform, Windows 2000, you will find each chapter in this redbook covers the fundamental technologies that make each operating system what it is.In ensuing chapters, we will discuss fundamental operating system concepts, architectures, open standards compliances, and product packaging for both AIX 5L and Windows 2000. If true, you can stop the mksysb process and kill “backbyname” on the Client LPAR if it remains running after stopping mksysb.The object of this redbook is to demonstrate the AIX 5L and Windows 2000 platforms to show the reader similarities and differences between each operating system. You can confirm the mksysb is hanging when there is no progress seen in the mksysb file size and the “backbyname” is still running on the Client LPAR: To verify the value is set, use # no -a | grep keep To change the value on your AIX system use: IBM does not offer recommendations on what the value should be, but its good if it's not less than 15 minutes or 1800 half seconds.

The default is 14400 half seconds which are 2 hours. To fix this, your firewall's TCP timeout window must be increased to match the longest time it may take for an mksysb operation to complete.Īs a workaround, the TCP keepalive settings on AIX may be tuned, the most common one is tcp_keepidle, this attribute is responsible for the time it takes for AIX to start sending keepalive packages on idle sessions. This is generally caused by the TCP timeout setting on your firewall, because the AUX session may remain idle for a long time, depending on how long it takes for the mksysb to complete, some firewalls may consider the session inactive and drop it. WireShark analysis will show retransmissions for the "FIN" package on the NIM AUX port 3902: If the packages are missing from the NIM side, it means they were dropped in between the two LPARs, most likely by a firewall. You can verify the NIM is not receiving those packages by looking for the same package ID on the NIM side of the trace. You can use a tool like Wireshark to open the trace files and analyze the data, you need to look for “Retrasmission” packages on the client side of the trace and on port 3902, those indicate the client LPAR is trying to send out something to NIM, but is not getting a reply.

Stop the iptrace on both LPARs and analyze the data:.

*Note this process may start a minute or two after intiating the mksysb command on NIM.

If this process is gone, it means the backup operation has either failed or completed.

Wait for the process to hang, you can verify its hanging by checking if the mksysb process is done on the Client LPAR, for example using “ps -ef’.

# nim -o define -t mksysb -a server=master -a source= -a mk_image=yes -a location= You can do that by following the bellow steps:

#Wow troubleshooting iptrace free#

*Before starting ensure you have at least 500MB free in the /tmp file system. To diagnose this problem, we will need to take a iptrace/tcpdump from both the NIM LPAR and the Client LPAR during the hanging operation.