We run HIS (host integration services) and bridge it across a WAN link (many) one of our WAN providers had a filter in place from when we used to run it using RSRB as opposed to DLSw. The filter is/was:
access-list 202 permit 0x0000 0x0D0D
During the migration we blended our old config into the new config for MPLS including that filter.
I'm not much of an HIS (or hex for that matter) guy but we figured this out via trial and error over the course of 2 hours of downtime: When you run more than one PU on a single IP (HIS server) the DLSw circuits are formed on the router with different SAP IDs in this order 08, 0d, 0C and 10 (with 4 PUs.) (by DLSw debug on edge router)
During a migration from Frame-Relay to MPLS, the filter above continually prevented DLSw ckt formation on any PU passing packets with the SAP ID of 10 (I swapped SAP IDs on PUs and the PU containing the SAP ID of 10 continually failed to form the DLSw ckt.) We lifted the ACL and the ckt established flawlessly.
Now the questions:
1. What are the logical orders of SAP IDs? If I have a site using more than 4 PUs on one server, what (or where do I find out) is the SAP ID for PU # 5, 6, 7 and so on?
2. How do I do the conversion from 2 character SAP ID to the 0xXXXX (hex) format to build a new filter (ACL) that will allow SAP ID 10 (and above, if necessary.)
3. Is this filter necessary or is it an old recommendation left over from RSRB. What are the implications of running filterless? Are people hacking SNA/HIS? DLSw? Is there some sort of bug somewhere that causes ckts to be erroneously formed until memory is exhausted?(resulting in DOS)
Thanks Guys, my WAN vendor has lost this skill via attrition and brain-drain. I have no-one left in my organization that understands SNA or DLSw for that matter including myself! I have learned a ton over the last few years but even IBM is sunsetting the architecture eary next year so my resources are dwindling.