SNASw XID protocol error during activation

[a.mountouris]

Hello forum,

we have a cisco 7204 snasw enabled connected to 2 OSA. The configuration is as:

source-bridge ring-group 2100

dlsw local-peer peer-id 10.201.254.210 promiscuous

dlsw prom-peer-defaults tcp-queue-max 150

!

interface Loopback0

ip address 10.201.254.210 255.255.255.255

!

interface FastEthernet0/0

ip address 10.211.7.2 255.255.255.0

duplex full

speed 100

!

interface FastEthernet0/1

ip address 10.211.60.2 255.255.255.0

duplex auto

speed auto

!

snasw dlctrace format analyzer

snasw cpname EFGEURO.SNASW1

snasw port PSNASW1 FastEthernet0/1

snasw port DLSW vdlc 2100 mac 4200.0000.0001 conntype len

snasw link LSNASW1 port PSNASW1 rmac 4600.0000.00a1

snasw link L1SNASW1 port PSNASW1 rmac 4600.0000.00a3

So we have defined two snasw links, LSNASW1 and L1SNASW1 and we use also vdlc port 2100. The dlsw peer interface is the loopback. On the other side of the dlsw cloud, there is a cisco router and an SNA server (microsoft 2003).

Although the dlsw is ok, we have problems with the actual session setup:

7200_SNASW_DLSW#sh dl pe

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.215.41.1 CONNECT 681 56 prom 0 1 0 00:11:08

Total number of connected peers: 1

Total number of connections: 1

7200_SNASW_DLSW#sh dl ci

Index local addr(lsap) remote addr(dsap) state uptime

3925868595 4200.0000.0001(04) 0088.500c.eb1d(04) CKT_ESTABLISHED -

(notice the 42000000001 which is the vdlc mac).

But in the attached file you can see the dlctrace output error:

we get the SNASW_CS_LOG_6 message, XID protocol during activation. Is it possible to analyse the trace output?

Regards, Apostolos.

[a.mountouris]

After some tests we performed in a test environment, we believe the error is the wrong REMOTE CPNAME defined on the SNA SERVER. This entry was LPAREB1 which is the SSCP name of the VTAM. Now that the router is in the middle, he has brought his cpname (SNASW1) between the server and the mainframe.

So server should now point to the cp name of the router.

Is there however a way to by pass this? Is there a way to still have the sscp coded as remote cpname on the server?

[rclousto]

Hi, sorry we did not reply yesterday, for some reason we did not get email notification on your post.

The only way to bypass this would be to change the SNASw device to have the CPname LPAREB1, and you would also have to change the VTAM name to something else. Since the SNA Server is rejecting our SNASw XID, there is nothing else we can do to make it accept it.

To avoid a future problem you should just leave the remote CPname blank on the SNA Server. SNA Server can learn the remote CP name on the XID exchange and it won't enforce a match.

Regards,

Bob

[a.mountouris]

Hi Bob,

thanks for the answer. However, what I cannot unerstand is why cisco is playing the role of the VTAM. Is cisco possible of activating the pu and lus on the sna server?

What happens then if I do not code switched major nodes on VTAM? Any server that connects to cisco will be able to connect to applications running on mainframe?

Could you please clarify how the bind process is being don between the cisco and the server? I couldn't find any document descibing this.

P.S. In the dlctrace, is there any sense code?

Regards, Apostolos.

[rclousto]

Hi Apostolos,

Cisco SNASw is only assisting with activating PUs and LUs by providing DLUR services. It does not replace VTAM, however it will pass all of the control flows to SNA Server as if it is coming directly from VTAM. Here is the PU/LU activation sequence:

SNA Server indicates it wants PU services on the XID it sends to SNASw.

If SNASw does not already have a DLUR-DLUS session (CPSVRMGR mode) with VTAM, it will BIND one. Then it will send a REQACTPU to VTAM, encapsulated in this LU 6.2 session. VTAM should +rsp to REQACTPU.

Next VTAM will send ACTPU down to SNASw, again encapsulated in the DLUR-DLUS session. SNASw de-encapsulates it and forwards it to SNA Server. SNA Server should return +rsp(ACTPU), and SNASw will forward this back to VTAM.

ACTLU processing is handled in a similar way.

If VTAM did not have the switch major node with the PU defined and active, VTAM would have rejected the REQACTPU and ACTPU would not have flowed. SNASw would retry REQACTPU in case the swmajnode comes active.

This is completely described in the DLUR architecture reference. You can find APPN/DLUR architecture documents at http://www.networking.ibm.com/app/aiwdoc.htm . DLUR is the 3rd document down. SSCP-PU and SSCP-LU activation is in chapter 6, and LU-LU activation is chapter 8.

Let me know if you need more detail on this, or if I've misunderstood your question.

There was no sense code in the DLC trace. It would have been in frame 397 sent by SNA Server, in the CV22 at the end of the XID. The sense code field is optional and SNA Server chose not to included it. The CV22 does include an error byte offset of x'001D'. This points to the CP name in the CV 0E in the XID previously sent by SNASw, indicating as you found that the CP name sent by SNASw was not the CP name that SNA Server configured in the link.

Regards,

Bob

[a.mountouris]

Thanks Bob for the explanation.

Let me summarise to see if I understand. The SNA server has defined as REMOTE CPNAME the SSCPNAME of the VTAM. This does not work because SNASw send its own CPNAME to the server.

On the other hand, if the cisco snasw CPNAME is coded as REMOTE CPNAME on the server, then the connection works.

(I would expect that the opposite would happen).

The sense code we get is listed on pdlog (my mistake, I though it is listed in dlctrace) and it is "08090049". So the cpname that is sent by SNASw is not what the server expects.

Is there any way of making cisco 8SNASw) not to send any CPNAME (at least not to send its own) and have VTAM for this function?

[rclousto]

SNASw will always send its own CP name, that you have configured with 'snasw cpname' on the router. There is no way to get it to not send a CP name or a different CP name. I don't think the APPN architecture allows either. So to get the connection working you will either have to change the SNA Server link definition to remove the CPNAME, or change the 'snasw cpname' configuration line to the name SNA Server is expecting. And since VTAM and SNASw cannot have the same CP name--the link between VTAM and SNASw would not come up--you would have to change the VTAM CPNAME as well.

Sense code 08090049 in the log just means that SNASw has detected that the other side (SNA Server) has rejected the last XID it sent. It doesn't point to the real problem, which is indicated in the XID CV22 that SNA Server sent.

Regards,

Bob

[romney]

Apostolos,

you are confusing two different things.

The SNA server is configured as a PU 2.1, so it initiates an XID3 exchange with snaswitch to bring up an APPN link/tg. Part of that exchange involves learning/verifying each others CP names. Because the SNA server has configured a specific CP name (VTAM's) as the adjacent CP it expects to contact when the link is activated, it is rejecting the XID snasw is sending it. The appropriate way to resolve this is to remove the CP name configuration from SNA server and allow it to learn the CP name.

The SNA server is also configured with dependent LUs to support, so in the XID3 it sends to snaswitch it indicates it wants to receive an ACTPU. snaswitch then knows that it needs to act as a DLUR on behalf of SNA server. When the above CP name issue is resolved and the XID3 exchange succeeds, snaswitch will then initiate the REQACTPU sequence that Bob summarized for you.

I hope making the above distinction helps.

- Ray

[richard.nixon]

I think the issue you're not seeing here is that the router is participating in this as an SNA peer (an APPN node in fact) not just a passthrough device.... that makes things more complex.

Basically what you need to understand is that everything you configure about the adjacent device (in this case the router) on the SNA server has to match the adjacent device's own config (think of it as a security check if you like). If you can keep it to just the MAC address and maybe an XID, that makes life easy for you because a blank matches everything.

If you really don't want to have the router interfere at an SNA level and you don't need APPN for something else, just configure basic DLSW on the router(s). DLSW acts more like a clever bridge and means you can just do a simple parameter matching between the SNA server and the Mainframe VTAM.

Hope this helps.