Chris's AIX Blog

I came across this strange LPM issue recently. Thought I’d share it with you.

All the customers VIOS were configured with the viosecure level set to high.

When the VIOS is configured with a security profile set to high, PCI or DoD, a new feature is enabled during LPM. This new feature is called “Secure LPM”. As a result when you initiate an LPM operation, the “Secure LPM” feature automatically enables the VIOS firewall and configures a secure (ipsec) tunnel for all LPM traffic over the network.

Before we started LPM, the VIOS firewall is off:

$ viosecure -firewall view

IPv4 Firewall OFF

ALLOWED PORTS

Local Remote

Interface Port Port Service IPAddress Expiration

Time(seconds)

--------- ---- ---- ------- --------- ---------------

And it's activated after we start LPM:

$ viosecure -firewall view

IPv4 Firewall ON

ALLOWED PORTS

Local Remote

Interface Port Port Service IPAddress Expiration

Time(seconds)

--------- ---- ---- ------- --------- ---------------

In the customer’s case, we moved a partition from a 795 running a pair of VIOS at 2.2.1.3 to another 795 running another pair of VIOS at 2.2.2.1. This worked OK. When we attempted to move the partition back, we received an error stating that the source MSP had rejected the request.

HSCLA230

The mover service partition on the source managed system has rejected the request to stop the migration. Verify that the migration state of the partition is Migration Starting, and try the operation again.

After a while we discovered that when the LPM operation started, the source VIOS would enable its firewall and we would immediately loose connectivity (i.e. our SSH session to the VIOS would hang). We also found that RMC connectivity between the source VIOS and HMC also dropped. Somehow the VIOS firewall was blocking network connectivity to pretty much everything.

Eventually, after much digging we found that the source VIOS was the victim of an errant firewall rule (configured on the source VIOS itself).

0 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 yes all any 0 any 0 both both no all packets 0 all 0 none Default Rule

We were then able to move the partition back to the original frame. We are still searching for an answer to how this happened. The IBM support team believe the rule must have been created by an administrator at some point. Of course, the administrator claims that is untrue.