We are building an ipSecPolicy file for REFRESH/UPDATE into PAGENT for load to TCPIP for packet management. In defining our rules, we've found we have a very large Policy Agent definition file to cover such disparate issues as VIPA, DVIPA, Enterprise Extender and other areas. We generate a set of CISCO ACL rules that are used to build the Policy Agent file (ipSecPolicy) for load to Pagent.
We experienced an abend in PAGENT at a customer site due to the size of the policy file input. We had an issue opened prior and a few people from IBM got onto a call with us to discuss. A post in the older (now closed) ticket:
TS016819475 - ZOS PAGENT crashes upon F PAGENT,REFRESH trying to digest ipsec rules
Fabian.Rosas.jr
Thanks for the dump.
We were able to determine that PAGENT exhausted all of its 31 bit storage and had toresort to 24 bit storage until that was also exhausted. In other words we are in a storageconstrained condition.
8/22/24, 10:29 AM ZOS PAGENT crashes upon F PAGENT,REFRESH trying to digest ipsec rules - Cases - IBM Support
When you issue the MODIFY PAGENT,REFRESH the current policy still exists in storage while the new one is read in. When the MODIFY PAGENT,REFRESH occurs PAGENT needs to compare the new and the old policy prior to installation of the new one. You do not have enough storage to hold two instances. In conclusion your IPsec policy is simply too big.
Regards,
Fabian Rosas Jr.
z/OS Comm Server Support
On the customer call which Fabian attended it was explained that PAGENT must read the entire policy into storage for comparison purposes. We asked about the storage exhaustion logic and what limitation we might have to operate under and was provided no advice other than decrease the size of the input ipSecPolicy file for update to PAGENT.
The obvious comment would be to put this required storage above the bar as a correction for this problem. As networks expand along with the accompanying ipSecPolicy input file, the need to manage more data into PAGENT becomes critical. We also inquired about alternate methods to getting this data into PAGENT, i.e. using multiple files or staging data, and were told it reads just the one supplied ipSecPolicy file and processes the entire input all at one. It was also pointed out that the CommonipSecPolicy file could also be used for shared content across IP Stacks but that PAGENT likely would again read ALL data from both Common and LPAR specific ipSecPolicy info all at once
We need a solution that will work for us as this customer has an extremely large network of mainframe systems and a significant set of dynamic VIPA connections to manage via the CISCO ACLs created and processed into an ipSecPolicy input file
In our expanded test we had just over 32,000 ACL rules resulting in a policy file of 650,000 lines which at 132 bytes would be roughly 86MB of storage. It would seem to me this should fit within the 2G 31 bit storage scheme, even with two copies.
As networks grow, this limitation, and lack of any warning while running REFRESH is going to be more of an issue. Can we get this addressed sooner than later as a major problem with PAGENT in large networks?
As a developer, my recommendation would be this processing be moved above the bar or an alternate method to input multi-part ipSecPolicy files enabled.
