I am having issues in brining up the connectivity between AS400 connecting to FEP using SDLC. I am trying to perform STUN SDLC on the 2800 routers with low speed WAN interfaces facing AS400 and FEP, here is the toplogy;
The links are on Low speed serial interfaces 19.2 Kbps. The interface states are all up/up, but STUN is closed.
AS400 is configured in *SEC role.
Router configs are as follows;
R1 (Router facing AS400)
stun peer-name 192.168.213.32
stun protocol-group 1 sdlc
(config-if serial 0/0/0)#
description connection to AS/400 SDLC PU 2.1 address C1
There is a parameter that I frequently had to use when doing STUN which I do not see in your config. That parameter is:
and it is configured on the serial interface. Try adding that to both of your serial interfaces and see if it makes any difference.
If it still does not work then I would suggest that you verify connectivity between the specified addresses. On R1 do an extended ping and in the extended ping specify the destination as 192.168.213.33 and specify the source address as 192.168.213.32. If that works then do an extended ping on R2. In the extended ping on R2 specify the destination as 192.168.213.32 and specify the source as 192.168.213.33.
I have to correct the last post which pasted a sample BSTUN config. The original query was regarding STUN, not BSTUN. STUN is for SDLC traffic, whereas BSTUN is for bisync traffic,they are very different.There is no such thing as "AS400 stun with contention".
Need to check a few things, as the SYUN tunnel will not attempt to come up unless one side sees input packets that match address C1.
(1)Remove "stun quick-response" from both routers, it is not needed here and may even cause this not to work, as there is a bug you may hit if you configure this on the side that is role primary under the interface.
(2)Verify that C1 is the correct SDLC address. IF you are not sure, then configure STUN BASIC and capture "debug stun packet" and debug sdlc packet"
(3)Check for input packets on the interface. Configure "NRZi-ENCODING" if you don't see input packets and then check again.
(4)As already mentioned, verify IP connectivity between the IP addresses used for STUN.
If it still doesn't come up. I suggest that you capture a show tech from both routers, a show STUN from both routers and open a TAC case for assistance.
Thanks for your input, here is the situation now; Encoding, addressing and ip connectivity are all verified and okay. The configuration that I have initially posted has worked after recycling the line on the FEP side. Then we performed a shakedown test on the line end-to-end and we have observed one issue which I am trying to eliminate as follows;
We did a shakedown test and everything have recovered as expected, except when we recycled the router interface facing FEP, the line did not came up until recycled at the FEP. So it means that, in current scenario if line facing the FEP goes down, it looks like that a recycle on the FEP side will be required. Is this a normal behaviour?
Also please provide me the bug-id that you have mentioned related to "quick response command".
CISCO TAC is already looking into it, but sometime it?s always helpful to have it discussed in this forum as well since SNA/FEP/SDLC/STUN are aging technologies and a lot of expertise in these areas have become non-handson.
STUN quick-response is for a multidrop configuration, AS/400 to several 5x94 type of devices, all on the same input interface. When one 5x94 would go down, the AS/400 would reset the whole line, causing all of the 5X94s on the line to go down. This command will cause the router to respond with a "disconnect mode" (DM) frame for any inactive secondary device polled by the AS/400. The AS/400 will then proceed to poll the next device without resetting the line.
As far as having to reset the line on the FEP, hard to say, it is possible that this is correct.
This document will provide screenshots to outline the steps to setup
TACACS+ configuration to ACI and also the configuration required on
Cisco ACS server. Please find the official Cisco guide for configuring
TACACS+ Authentication to ACI:
Is it supported or NOT supported? It's a frequently asked question.
Before APIC, release 2.3(1f), transit routing was not supported within a
single L3Out profile. In APIC, release 2.3(1f) and later, you can
configure transit routing with a single L3Out pr...
Cisco Documents are usually accurate, but when it came to the document
on Cisco APIC Signature-Based Transactions it was slightly off the mark.
This document is for those novices to API like me who cant seem to
figure out how to go about performing signat...