How To

Summary

Every system admin must be aware of the basic networking troubleshooting. This can often save time by performing some initial troubleshooting before engaging the networking team. In this technote, we'll cover the basics of network troubleshooting on the IBM AIX command line.

Steps

TCP/IP model quick review

Starting off with a quick review of the TCP/IP model. While it's often used along with the OSI model to discuss theoretical networking, it also demonstrates and represents the various networking protocols that are in use in modern networking environments.

There is no difference in practice between the two models. For the sake of simplicity, the TCP/IP model is more frequently used to abstract and lay the blueprint of network protocols operation. Assuming that a system admin is aware of the TCP/IP and the OSI model, this technote will proceed to troubleshoot issues present in the stack layers from Layer 1 to Layer 4.

This technote approaches networking connectivity issues in a Bottom-Up approach. The approach checks and confirms the connectivity of each protocol layer from the bottom (Layer 1, Physical Layer) to top (Layer 4, Transport Layer). This is since each layer's connectivity depends on the layer beneath.

The TCP/IP model is composed of 5 main layers:

Layer 5: Application Layer
Layer 4: Transport Layer
Layer 3: Network/Internet Layer
Layer 2: Data Link Layer
Layer 1: Physical Layer

Generally, there is no established, well-organized debugging method to troubleshoot networking issues. If you have trouble connecting the system to a network, many steps may be required to fix this. This technote will provide some edicts as to make debugging easier. You may want to build your own list however.

Note: This technote assumes all PowerVM VIOS commands are run in root shell environment. After logging into padmin, $oem_setup_env needs to be run.

Physical Layer

Did you make sure the cable is connected? That's the first question a system admin should ask themselves. It's easy to troubleshoot physical layer issues from the command line if you have console connectivity to the system.

Is the physical link up? Assuming that a physical adapter is configured on a PowerVM VIOS/AIX. The command that will be used to query for the link status is entstat:

# entstat -d entX | grep -i link

Using the command in context. If the physical port is ent1, the command will be:

# entstat -d ent1 | grep -i link
Physical Port Link Status: Down
Logical Port Link Status: Down
        PCIe Link Speed: Unknown

Tip

If you have multiple physical adapters. # netstat -v and then an additional awk can be used to iterate over each adapter to get the physical link status:

# netstat -v | awk '/ETHERNET STATISTICS/ {device = $3; getline; if ($0 ~ /Physical Port Link Status/) {print device ": " $0; getline; if ($0 ~ /Link Status:/) {print device ": " $0}} else if ($0 ~ /Shared/) {print device ": " $0} else {while ($0 !~ /ETHERNET STATISTICS/ && getline) {if ($0 ~ /Physical Port Link Status/) {print device ": " $0; getline; if ($0 ~ /Link Status:/) {print device ": " $0}; break}}}}'

(ent2): Physical Port Link Status: Up
(ent2): Logical Port Link Status: Up
(ent1): Physical Port Link Status: Down
(ent1): Logical Port Link Status: Down

(ent4): Device Type: Shared Ethernet Adapter

(ent0): Physical Port Link Status: Up
(ent0): Logical Port Link Status: Up

Notice the indication of 'Down' in the above output for ent1 adapter port. This means that the port isn't coming up. The next step would be to check the cabling for this adapter port, or the switch side for issues.

Note

For some adapter types (e.g. EN0W), the adapter port will not show Link Status: Up unless there is an interface (e.g. IP/SEA/EtherChannel) is configured on top. Before checking the cabling though, it's a good idea to make sure that an interface is configured.

Starting off, the error report (errpt) facility can be used in checking when an adapter port has actually gone down:

# errpt
IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
F596EFAC 0524110222 T H ent1 Physical link down

In the output above, a Physical link down event can be observed. To properly interpret the timestamp 0524110222, it can be read as MM/DD - HH:MnMn:SS or simply 05/24 - 11:02:22. The timestamp is based on the date and timezone configured on the AIX/PowerVM VIOS system. This can be forwarded to the networking team to check on the network side as well.

Checking the interfaces if they are properly configured an set to UP is also a good idea in identifying whether the adapter port is down for good, or if the adapter port just need an additional step of configuration. The additional configuration in the case of VIOS can be a Shared Ethernet Adapter, an EtherChannel, or even a direct IP configured on the adapter port.

Using ifconfig command to check whether an interface is up

The ifconfig command can be used to check whether the IP configuration is proper and running. For an adapter port that shows Link Down. ifconfig -a can be used to show all of the interfaces on an AIX system:

# ifconfig -a
en1: flags=1e084863,814c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
        inet 192.168.0.10 netmask 0xffff0000 broadcast 192.168.255.255
        inet6 fe80::b0ad:34ff:fea3:3402/64
         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
sit0: flags=8100041<UP,RUNNING,LINK0>
        inet6 ::192.168.0.10/96
en0: flags=1e080822,18c0<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
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

Based on the output above, the interface en0 is not UP and RUNNING unlike en1. Configuring an interface on the interface en0 can be done through running smit chinet.

After validating the IP Address, the Subnet Mask, and the State of the Interface is required. ifconfig en0 can be run to validate the interface is now running:

# ifconfig en0
en0: flags=1e080863,18c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
        inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255
         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1

Now, running entstat -d ent0 once more can be used to check the Link Status of the adapter port:

# entstat -d ent0 | grep -i link
Physical Port Link Status: Up
Logical Port Link Status: Up
        PCIe Link Speed: 8.0 GT/s

In other situations involving PowerVM VIOS, the interface can be a Shared Ethernet Adapter. Refer back to the technical documents in the Related Information section for ways to configure Shared Ethernet Adapter. It's worth noting that a Shared Ethernet Adapter can go in LIMBO state due to the sole/all adapter(s) underlying is improperly connected. LIMBO state will cause LPARs using the same Shared Ethernet Adapter in losing connectivity if the BACKUP Shared Ethernet Adapter is also in LIMBO state or if no High Availability configuration is in place.

Read more about how SEA behaves in a situation when ha_mode is set to standby on SEA while other SEA is standby or LIMBO in the Related Information section.

Data Link Layer

All local network communication occurs through protocols that operate in L2; This process involves the transfer of data frames between devices within the same Layer 2 network, often referred to as a local area network (LAN). For most system administrators, the Address Resolution Protocol (ARP) is the key Layer 2 protocol. ARP is used to associate Layer 3 IP addresses with Layer 2 Ethernet MAC addresses.

When a device attempts to communicate with another device on the same local network (such as the default gateway), it typically knows the IP address of the other device but not its MAC address. The Address Resolution Protocol (ARP) addresses this by determining the corresponding MAC address.

ARP also plays a crucial role with communicating packets to external network subnets since AIX needs to be able to communicate with the gateway to be able to route packets to hosts that do not reside on the same subnet.

A common issue that might arise is an ARP entry not populating, particularly for a host's default gateway. If the local machine cannot resolve its gateway's MAC address, it will be unable to send traffic to remote networks. This could be due to an incorrect IP address configured for the gateway or another issue, such as a misconfigured switch port.

Checking the ARP entries on AIX is fairly simple using the arp command:

# arp -an

The -n flag suppresses Domain Name System resolution which can prove beneficial in case of a network connectivity disruption where AIX is unable to reach the DNS server. If the -n is not used while AIX is unable to reach the DNS server, the query for the hostnames can take relatively long time.

The output to the arp command will look something similar to:

# arp -an
  ? (192.168.1.200) at 7a:21:16:25:8f:2 [ethernet] stored in bucket 7

  ? (192.168.1.31) at 98:be:94:58:cd:a4 [ethernet] stored in bucket 87

bucket:    0     contains:    0 entries
bucket:    1     contains:    0 entries
..
There are 2 entries in the arp table.

The output observed implies that AIX was able to resolve two MAC addresses with two IP addresses on the same subnet 192.168.1.0/24. To confirm if the MAC addresses observed are related to the default gateway IP, another command is used:

# netstat -nr

Observe how the -n flag was used again to suppress the name resolution. The output will look like:

# netstat -nr
Routing tables
Destination        Gateway           Flags   Refs     Use  If   Exp  Groups

Route Tree for Protocol Family 2 (Internet):
default            192.168.1.200       UG        1    291482 en1      -      -

The very first route entry corresponds to the default gateway address AIX will use when it tries to communicate with external networks which is 192.168.1.200 and the arp entry implies that the AIX system was able to resolve and associate the MAC address 7a:21:16:25:8f:02 with the gateway IP address 192.168.1.200.

In a situation when the MAC address isn't properly resolved, the ARP entry will show as (incomplete):

# arp -an
  ? (192.168.1.200) at (incomplete)

The next step to troubleshooting this issue is to engage the networking team to trace the ARP requests sent and validate if the requests are received by the destination. In some scenarios, improper VLAN tagging can play a role in affecting the ARP requests/replies paths.

VLAN tagging on AIX

A VLAN functions as a logical subnet within a switch or across an entire physical network. In a physically separated network, devices are assigned to specific switch ports.

In contrast, when VLANs are used to separate a network, devices are logically divided using a VLAN TAG in the Ethernet frame. This tag is added to Layer 2 (L2) frames, marking the frame with a specific VLAN ID.

Switches that support VLANs can assign these tagged frames to specific VLANs, allowing the creation of logically distinct networks on a shared infrastructure. These VLANs do not need to be physically contiguous and can span wide-ranging networks and multiple switches.

The principles of VLANs are defined by the IEEE 802.1Q standard.

It's noticed that network disruptions often occur when VLANs are configured virtually on a POWER system for the first time due to the confusion and lack of arrangement between what is already on the network and what needs to be done on the POWER system. This document will go over several scenarios:

AIX's network is managed by a VIOS (e.g. VEA is used for network connectivity)
AIX is using dedicated ethernet adapters
AIX is using vNICs

AIX's network is managed by a VIOS

Network virtualization on POWER systems depend mainly on the configuration of Shared Ethernet Adapters. Often, intertwined concepts regarding configuring a Shared Ethernet Adapter will cause confusion.

Before going ahead an exploring the case when AIX/VIOS has its IP configured on a Virtual Ethernet Adapter (VEA), it will be good to have an understanding of the difference between a VLAN ID (VID) and a Port VLAN ID (PVID).

The VLAN tag information is referred to as VLAN ID (VID). Ports on a switch are configured as being members of a VLAN designated by the VID for that port. The default VID for a port is referred to as the Port VID (PVID). The VID can be added to an Ethernet packet either by a VLAN-aware host, or by the switch in the case of VLAN-unaware hosts. Ports on an Ethernet switch must therefore be configured with information that indicates whether the host connected is VLAN-aware.

Simply put, when a VEA on an AIX/VIOS that is set up on a Virtual Network bridged by a Shared Ethernet Adapter (SEA) has a VID that is identical to the PVID of the SEA, the outgoing traffic of this system will be untagged.

In a scenario where the switch is configured in trunk mode, untagged traffic is usually dropped at the switch level. Further configuration of the system from a VLAN perspective is required.

Checking which VLAN the Virtual Ethernet Adapter is using is done through executing the command:

# entstat -d entX | grep -i vlan

The output will show the PVID of the VEA in addition to VID. Consider the following snippet:

# entstat -d ent1 | grep -i vlan
Invalid VLAN ID Packets: 0
Port VLAN ID:     1
VLAN Tag IDs:  None

The traffic that goes out of the client LPAR will be tagged with a VLAN tag of 1. If the SEA bridging the network for this LPAR has a PVID of 1. This will indicate that the traffic is sent untagged. If the PVID of the SEA is different from 1 AND has VLAN 1 included as a VID of the SEA, the traffic will go out of the POWER frame with a tag of 1.

Checking which VIDs and PVIDs are used by each SEA is made through:

# entstat -d entX | egrep "ETHERNET STATISTICS|Port VLAN ID|VLAN Tag IDs" | awk '/ETHERNET STATISTICS/ { adapter=$0 } /Port VLAN ID/ { vlan_id=$0 } /VLAN Tag IDs/ { vlan_tags=$0; if (vlan_id && vlan_tags) { print adapter "\n" vlan_id "\n" vlan_tags; adapter=""; vlan_id=""; vlan_tags="" } }' | awk '!seen[$0]++'

Running the command over a Shared Ethernet Adapter ent4 will give an example output:

# entstat -d ent4 | egrep "ETHERNET STATISTICS|Port VLAN ID|VLAN Tag IDs" | awk '/ETHERNET STATISTICS/ { adapter=$0 } /Port VLAN ID/ { vlan_id=$0 } /VLAN Tag IDs/ { vlan_tags=$0; if (vlan_id && vlan_tags) { print adapter "\n" vlan_id "\n" vlan_tags; adapter=""; vlan_id=""; vlan_tags="" } }' | awk '!seen[$0]++'

ETHERNET STATISTICS (ent2) :
Port VLAN ID:     10
VLAN Tag IDs:    1

This output implies that the SEA ent4 has a virtual trunk adapter ent2. The VEA ent2 has a PVID of 10 and a VID of 1.

AIX is using dedicated ethernet adapters

In cases where AIX has a dedicated ethernet adapter and the switch port isn't configured in access mode, an additional pseudo-VLAN adapter is required.

The pseudo-VLAN adapter is configured by running:

# smitty vlan

The pseudo-VLAN adapter will be configured with a base adapter of entX. entX will be the port that is directly connected to the switch. Based on the VLAN requirement, the tag is further added. This will create adapter entY.

The LPAR IP is then configured over the VLAN adapter entY using smit mktcpip.

AIX is using vNICs

A virtual Network Interface Controller (vNIC) is a type of virtual Ethernet adapter that is configured on client partitions of Power Systems servers. Each vNIC is backed by an SR-IOV logical port that is available in a Virtual I/O Server (VIOS) partition. This type of vNIC is also called dedicated vNIC, as the backing SR-IOV logical port serves the vNIC exclusively. The VLAN settings and MAC settings are applied to both the vNIC and the SR-IOV logical ports.

The vNIC VLAN setting on AIX can be checked through the command:

# entstat -d entX | grep -i vlan

Consider a vNIC adapter ent5 on an AIX LPAR, the command output will be:

# entstat -d ent5 | grep -i vlan
Port VLAN ID Status: Enabled
        Port VLAN ID: 0010
        Port VLAN Priority: 0
VLAN ACL Status: Disabled

In this example, the VLAN ID used for the tagging is VLAN 10.

For more info on vNIC functionality, refer to the link on vNIC Functionality Guide in Related Information section.

Network Layer

Internet Protocol (IP) and IP addresses operate in Layer 3. This addressing scheme provides a way for hosts on different subnets to reach each other. Kicking off the troubleshooting in this layer involves making sure AIX's IP is properly set which is done using the ifconfig command.

ifconfig can be used with the -a flag to output all of the interfaces that are not in detached state (e.g. Up and Down). Consider the following output:

# ifconfig -a
en1: flags=1e084863,80480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
        inet 192.168.1.70 netmask 0xffff0000 broadcast 192.168.255.255
         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
en5: flags=1e080862,18c0<BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
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/64
         tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1

Three interfaces can be observed; en1, en5, and the loopback interface lo0. One notable thing is how en5 doesn't have an IP configured and still shows on the ifconfig output. This is due to the state of the interface is currently Down but not detached.

It can also be observed that the interface en5 doesn't have the UP flag set unlike en1:

en1: flags=1e084863,80480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
                          ^^     
        inet 192.168.1.70 netmask 0xffff0000 broadcast 192.168.255.255
         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1

                         |--- Notice the absence of the UP flag.
                         v
en5: flags=1e080862,18c0<BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1

For the interface en1 that is UP; several things can be taken away from that output:

The IP address is 192.168.1.70
The Subnet Mask (netmask) is 0xffff0000 or 255.255.0.0

If the interface didn't have an IP, then it would be essential to troubleshoot this. The lack of an IP address in a new setup often occurs when 3rd party scripts are used to initially configure the AIX system, or due to issues with DHCP. For other scenarios involving systems that have been running, it is often noticed that the disappearance of the IP is usually incurred by the configuration of the IP by ifconfig command since the ifconfig command doesn't write the change to the ODM.

The lack of the IP configuration in the ODM puts the system in a situation where if any changes are to be made to the interface or in a case of system reboot, the configuration doesn't sustain the change and disappears.

Validating that the proper IP along with the correct Subnet Mask are configured on a system is always the first step to working out a connectivity issue on L3.

While ping is usually a go-to utility to troubleshoot L3 issues, it really isn't definitive. Usually when there is connectivity disruption issue on a system, pinging the system won't work. Tracing the route to see where the packet gets dropped along the way is often optimal. For this, traceroute is usually used.

Traceroute uses the Time to Live (TTL) field in IP packets to trace the path data takes to its destination. It starts by sending a packet with a TTL of one. When the packet's TTL runs out, the router sends back an ICMP Time-to-Live Exceeded message. Traceroute then sends another packet with an incremented TTL to find the next hop. This process continues, resulting in a list of intermediate routers that the packet went through to reach its destination.

A common problem often encountered is the absence of an upstream gateway for a specific route or a missing default route. When an IP packet needs to be sent to a different network, it has to be directed to a gateway for further routing. The gateway determines how to route the packet to its final destination. The list of gateways for various routes is maintained in a routing table. Retrieving the routing table in an AIX system is achieved through running # netstat -nr:

# netstat -nr
Routing tables
Destination        Gateway           Flags   Refs     Use  If   Exp  Groups

Route Tree for Protocol Family 2 (Internet):
default            192.168.0.1       UG        1    313905 en1      -      -   
192.168.0.0        192.168.1.70       UHSb      0         0 en1      -      -   =>
192.168/16         192.168.1.70       U         4     24300 en1      -      -   
192.168.1.70       127.0.0.1         UGHS      0     11037 lo0      -      -   
192.168.255.255    192.168.1.70       UHSb      0         4 en1      -      -   
127/8              127.0.0.1         U         3    294858 lo0      -      -   

Route Tree for Protocol Family 24 (Internet v6):
::1%1              ::1%1             UH        0     69173 lo0      -      -

The first line in the routing table represents the default route to any network other than 192.168/16. Simple topologies will usually include one 'default' entry. More info on AIX Network Routing can be found in the Related Information section.

A missing or incorrect default gateway is a common issue.

Transport Layer

If the physical connectivity has been checked and proved healthy. VLAN configuration is in place, and IP has been confirmed to be valid but the system is unreachable over certain service ports, this points more to an issue on the fourth layer; Transport Layer.

Two protocols mainly operate in this layer; TCP and UDP, with TCP being a connection-oriented protocol and UDP being connectionless. Services and applications open and listen on sockets; a socket is simply a combination of an IP address and a port.

This addressing mechanism provides a way for the traffic to be received by the service it is destined for. This technote doesn't aim to provide and discuss how the protocols of this layer work, nor how sockets usually operate. The focus will be mainly on troubleshooting common issues that arise in this layer of the TCP/IP stack.

Consider a scenario where AIX is unreachable over port 22 (e.g. the port that is used for SSH communication). The first thing a system admin should be interested in looking at is making sure that the system is listening over this port 22. This can also be helpful if there is another service or daemon that is listening on that port preventing the original service intended to run.

The command used to list all of the ports open on an AIX system is again netstat, however different flags are used. This technote will use # netstat -an to provide a list of the ports where an AIX is listening. Consider the output below:

# netstat -an
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp        0      0  *.*                    *.*                    CLOSED
tcp4       0      0  *.*                    *.*                    CLOSED
tcp4       0      0  *.13                   *.*                    LISTEN
tcp        0      0  *.21                   *.*                    LISTEN
tcp6       0      0  *.22                   *.*                    LISTEN
tcp4       0      0  *.22                   *.*                    LISTEN
tcp        0      0  *.23                   *.*                    LISTEN
tcp4       0      0  *.25                   *.*                    LISTEN
tcp4       0      0  *.37                   *.*                    LISTEN
tcp        0      0  *.111                  *.*                    LISTEN
tcp        0      0  *.512                  *.*                    LISTEN
tcp        0      0  *.513                  *.*                    LISTEN
tcp        0      0  *.514                  *.*                    LISTEN
tcp4       0     52  192.168.1.70.22        192.168.1.35.48349     ESTABLISHED
tcp        0      0  *.657                  *.*                    LISTEN
tcp4       0      0  *.1334                 *.*                    LISTEN
tcp        0      0  *.3901                 *.*                    LISTEN
tcp        0      0  *.32768                *.*                    LISTEN
tcp        0      0  *.32769                *.*                    LISTEN
udp4       0      0  *.*                    *.*                   
udp4       0      0  *.13                   *.*                   
udp4       0      0  *.37                   *.*                   
udp        0      0  *.111                  *.*                   
udp        0      0  *.514                  *.*                   
udp4       0      0  *.518                  *.*                   
udp        0      0  *.657                  *.*                   
udp        0      0  192.168.1.70.2279      *.*                   
udp        0      0  *.2279                 *.*                   
udp        0      0  *.32768                *.*                   
udp        0      0  *.32772                *.*                   
udp        0      0  *.32777                *.*                   
udp        0      0  *.32850                *.*                   
udp        0      0  *.32864                *.*

Several services can be observed listening on different ports. For example, a service running on port 22 is noted to be running, and is listening on all local IPs for port 22. This is denoted by *.22 in the Local Address column. A list of the names of the services can be retrieved from /etc/services file.

Troubleshooting remote connectivity over a specific port can also be achieved by telnet utility. The telnet command creates a TCP connection to the specified host and port, making it ideal for testing remote TCP connectivity. Consider a scenario where a connection is being opened on port 24 (port 24 doesn't have any services listening on it from the output of netstat -an).

# telnet 192.168.1.70 24
Trying...
telnet: connect: Connection refused

This output indicates that it is not possible to reach 192.168.1.70 over port 24. As explained earlier, the service may not be running, and it would be required to review the services running on that AIX system to see if that's the case. Another possibility is that telnet traffic is not allowed on the network. Involvement of the networking team might be required to troubleshoot and verify Layer 4 connectivity on the network.

Summing it up...

This technote covers basic network concepts, starting from the bottom with cables and switches, up to IP addresses and ports. It's a beginner's guide to troubleshooting basic network connection problems, using built-in tools and utilities.

Additional Information

Additional Information:

SUPPORT
If you require more assistance, use the following step-by-step instructions to contact IBM to open a case for software with an active and valid support contract. 1. Document (or collect screen captures of) all symptoms, errors, and messages related to your issue. 2. Capture any logs or data relevant to the situation. 3. Contact IBM to open a case: -For electronic support, see the IBM Support Community: https://www.ibm.com/mysupport -If you require telephone support, see the web page: https://www.ibm.com/planetwide/ 4. Provide a clear, concise description of the issue. - For more information, see: Working with IBM AIX Support: Describing the problem. 5. If the system is accessible, collect a system snap, and upload all of the details and data for your case. - For more information, see: Working with IBM AIX Support: Collecting snap data

Click here to submit feedback for this document.

Author:

Mustafa Atallah

Related Information:

Related Information

Common Causes of SEA Limbo State

How SEA behaves in a situation when ha_mode is set to standby on SEA while oth…

IBM AIX - Network Routing Explained

vNIC Functionality Guide

Virtual Network Management with HMC Enhanced UI

[{"Type":"MASTER","Line of Business":{"code":"LOB08","label":"Cognitive Systems"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"ARM Category":[{"code":"a8m0z000000cw0AAAQ","label":"Networking-\u003ETCPIP"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"},{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSPHKW","label":"PowerVM Virtual I\/O Server"},"ARM Category":[{"code":"a8m3p000000F86VAAS","label":"PowerVM VIOS-\u003ENetwork"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Product Synonym

PowerVM; AIX

Was this topic helpful?

Document Information

Modified date:
10 June 2024

UID

ibm17154661

Tips

IBM AIX/PowerVM VIOS – Basic Network Connectivity Troubleshooting Guide