Re: STUN: AS400 to FEP SDLC

iftikhar.qurashi · ‎06-30-2006

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;

as400----R1-------R2-------FEP

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

stun quick-response

(config-if serial 0/0/0)#

description connection to AS/400 SDLC PU 2.1 address C1

mtu 2104

no ip address

encapsulation stun

serial restart-delay 0

clock rate 19200

stun group 1

stun sdlc-role primary

sdlc address C1

stun route address C1 tcp 192.168.213.33 local-ack

R2 (Router facing FEP)

--------------

stun peer-name 192.168.213.33

stun protocol-group 1 sdlc

stun quick-response

(config-if serial 0/0/0)#

mtu 2104

no ip address

encapsulation stun

half-duplex

serial restart-delay 0

clock rate 19200

stun group 1

stun sdlc-role secondary

sdlc address C1

stun route address C1 tcp 192.168.213.32 local-ack

Could you please let me know if I am missing anything major in the topology or configurations.

I can also provide AS400 line and FEP configurations if required

thanks

devang_etcom · ‎07-01-2006

its looks like ok...

i also had configure BSTUN for one of my project but its of multiple BSTUN group because its used for the Frame Relay topology... and i think you need only one group...

just look at this it may help you..

Building configuration...

bstun peer-name 10.1.1.1.

bstun protocol-group 1 async-generic

bstun protocol-group 2 async-generic

interface loopback 0

ip address 10.1.1.1

interface serial1/0

encapsulation frame-relay

interface serial 1/0.1 point-to-point

ip address 20.1.1.1 255.255.255.0

frame-relay interface-dlci 100

interface serial 1/0.2 point-to-point

ip address 20.2.1.1 255.255.255.0

frame-relay interface-dlci 200

interface serial 2/0

physical-layer async

encapsulation bstun

asp role secondary

bstun group 1

bstun route all tcp 30.1.1.1

interface serial 2/1

physical-layer async

encapsulation bstun

asp role secondary

bstun group 2

bstun route all tcp 30.2.1.1

ip route 30.2.1.0 255.255.0.0 20.2.1.2

ip route 0.0.0.0 0.0.0.0 20.1.1.2

line 65

speed 4800

parity even

databits 7

stopbits 1

.

line 66

speed 4800

parity even

databits 7

stopbits 1

.

!

end

and its same as for the other end...

hope this will help you

rate this post if it helps

regads

Devang

Richard Burts · ‎07-02-2006

Iftikhar

There is a parameter that I frequently had to use when doing STUN which I do not see in your config. That parameter is:

nrzi-encoding

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.

HTH

Rick

HTH

Rick

CSCO10408957 · ‎07-21-2006

simple stun config:

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_configuration_example09186a00800fad6c.shtml

AS400 stun with contention:

------A-END-----------

bstun peer-name XX.XX.XX.XX

bstun protocol-group 60 bsc

!

interface Serial0/1

encapsulation bstun

no keepalive

full-duplex

clockrate 19200

bstun group 60

bsc contention 1

bstun route all tcp YY.YY.YY.YY

!

------B-END-----------

bstun peer-name YY.YY.YY.YY

bstun protocol-group 60 bsc

interface Serial0/1

encapsulation bstun

no keepalive

full-duplex

clockrate 19200

bstun group 60

bsc contention 1

bstun route all tcp XX.XX.XX.XX

!

Please also check the clockrate match with both sides, mostly using 9600.

dmcloon · ‎07-21-2006

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".

jihicks · ‎07-22-2006

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.

Best regards,

Jim

iftikhar.qurashi · ‎07-22-2006

Hi Jim,

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.

Thanks for everyone's input

Iftikhar

jihicks · ‎07-23-2006

The bug ID is CSCee95909.

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.