More fun with BSTUN: A few questions

[mark.w.miller]

I have got a test setup nearly ready to try on a live IBM BSC EP FEP port, but I wonder about a few status observations I have seen so far. I have forced all the leads ON on the serial ports where the FEP and its point-to-point counterpart station (a BSC2780 workstation that is used for manual key-entry to a mainframe app), and the router (7206 (IOS 12.0.16) shows the tunnel info (route, transport, address, etc.), but shows state "closed" when command "show bstun" is issued. Question: Under what conditions will the state be "open"? Only when live data or control bytes are transmitted? Or should it always be in "open" state? Tunnel is configured as bsc contention (point-to-point; passthru), (there is no polling; "sy sx eq" is used by which ever end wants to talk). Or, does the router need to see a certain combination of EIA lead states at the serial interface to open the tunnel?

The key-entry jobs (RJE) are laborius and time-consuming, and therefore control and data transmitted over this tunnel will be sporadic and infrequent. So it will be nice to know the expected behavior of the tunnel. Also, a few tips on use of priority queueing for this protocol would be appreciated; this data will be shipped across WAN with mostly TCP/IP data from Token Ring and Ethernet LANs.

[dixho · Accepted solution]

In general, BSTUN or STUN peers remain closed until the router receive a packet in STUN or data stream in BSTUN from the attached SNA device.

Cisco router only supports the following bisync protocol:

IBM BSC3270

IBM BSC3275

IBM BSC3780

BSC2780 is not supported. If you need BSC2780 support, you need to talk to the local sales rep.

I am not familiar with BSC2780. I do not know exactly data flow. I assume that it is very similar to BSC3780. There is a logic built inside IOS. IOS can handle delay request or response caused by IP network between the BSTUN peer. No fancy queuing is required.

[mark.w.miller]

Thanks.