We have an SNAsw problem. Sense error is 1016000F.Both sent and received XID's indicate the same, non-negotiable, link station role.
However this is not the case, the server connected has an LS_NEG setting which should work for any other far end setting. The router show snasw port detail indicates a 'negotiable' state for the virtual token ring port we are transporting through.
We are running with IOS c2900-universalk9-mz.SPA.152-2.T1.bin. A bug search does not throw up anything that matches though similar SNAsw problems al seem fixed in 15. We are using HP SNA Plus2 with the node configured as a node with PU2.1.
Anyone come across such a problem ?
Did this work ok on a earlier version of code ? Can you gather a dlctrace of the XID exchange ? ie:
snas dlctrace buffer-size 10000
snas dlcfilter rmac 1111.1111.1111 (use the mac-address of the device)
snas start dlctrace
snas stop dlctrace
term len 0
sh snas dlctrace all detail
Also, gather "show runn " incl snasw". You can determine the remote mac-address from show dlsw circuit, show snasw link detail etc
Thanks for your reply. It hasn't worked on an ealier version of code. We updated to the latest version in case we needed a TAC case.
Attached is the SNASW config and .show snasw dlc-trace' in which you can see the XID protocol error information including the ' both sent and received XIDs indicate the same, non negotiable, link station role.
We are currently tryig to get a PComm session test up and running to replcate but have a PComm support call out as PComm stops forwarding the SNA Over Ethernet (80d5) packets when a bridge group is configured on the router interface.
This is the xid that is sent by the HP which indicates a failure
0E77B240: 00 40400016 . ..
0E77B250: 10200080 0C7630A1 4708103E 8100A400 .......~....a.u.
0E77B260: 100404BF 326405D0 11020000 008BD100 .......}......J.
0E77B270: 00000080 00010B51 00040900 00000007 ................
0E77B280: 000E10F4 C4E5D6D5 C5E34BD7 C4E5E4C3 ...4DVONET.PDVUC
0E77B290: E2D7F210 2A002911 0C0804F0 F6F0F0F0 SP2........06000
0E77B2A0: F00A06E2 D5C1D793 A4A2F203 0840110F 0..SNAPlus2.. ..
0E77B2B0: C885A693 85A3A340 97818392 81998422 Hewlett packard.
0E77B2C0: 07001D00 0806002C
The last portion is cv 0x22 identifying what it doesn't like, ie: "22 07001D00 0806002C". The last 4 bytes are the sense code "0806002C". From the IBM Z/OS website
Sense code 0806 - Resource unknown: For example, the request contained a name or address not identifying a PU, LU, SSCP, link, or link station known to the receiver or the sender.
Extended sense 002C - The identification supplied by the adjacent node in its XID3 differed from the identification that the receiving node was configured to expect.
So, the router identifies itself with its netid and cpname. ie: from the preceding XID you can see DVONET.EER1101
0D9F1F20: 00000007 000E0FF4 C4E5D6D5 C5E34BC5 .......4DVONET.E
0D9F1F30: C5D9F1F1 F0F1102E 002D110C 0804F0F3 ER1101........03
which obviously comes from the router config
snasw cpname DVONET.EER1101
So, I suspect that the HP is configured with the cpname of the node which it expects to connect to. If this is a migration, then almost certainly the HP still has the cpname from the previous adjacent node. Check through the HP config and either change the cpname or delete it (assuming that you are allowed to leave it blank).
Thanks, after this trace we changed the adjacent node name to 0000 in the SNA config file and were left with the cisco router error sense code alerting us to the XID's sent bu LU's both set to non-negotiable. Having got this far I think this constitutes a TAC case. I have also connected PComm and managed to get an LU6.2 connection (having to apply the 80d5 conversion to 802.3 for the LLC2 translation) so whilst the router config seems to be doing its job the error sense code we get when the server is attempting to connect is a misnomer. I have run a bug search for the ios and also a wider snasw search and not got a match.
John, if you want, put in the case notes to route the case to me (firstname.lastname@example.org). I'm in Europe. Matthew