90
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).
# smitty ips4_conf_filter
List IP Security Filter Rules
1 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no udp eq 4001 eq 4001 both both no all packets 0 all 0 none Default Rule
2 *** Dynamic filter placement rule for IKE tunnels *** no
3 deny 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 y all any 0 any 0 all both inbound no yes 0 no 0 patt_none
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 removed this rule (after some discussion with IBM support).
# smitty ips4_conf_filter
Delete IP Security Filter Rules
3 deny 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 y all any 0 any 0 all both inbound no yes 0 no 0 patt_none
# smitty ips4_conf_filter
List IP Security Filter Rules
1 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no udp eq 4001 eq 4001 both both no all packets 0 all 0 none Default Rule
2 *** Dynamic filter placement rule for IKE tunnels *** no
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.
