|
|
Cisco's implementation of block serial tunnel (BSTUN) encapsulates Binary Synchronous Communications protocol (Bisync), Adplex, ADT Security Systems, Inc., Diebold, and asynchronous generic traffic for transfer over router links.
Cisco's tunneling of asynchronous security protocols feature (ASP) enables your Cisco 2500, 4000, or 4500 series router to support devices that use the following asynchronous security protocols:
These protocols enable enterprises to transport polled asynchronous traffic over the same network that supports their Systems Network Architecture (SNA) and multiprotocol traffic, eliminating the need for separate facilities. Figure 3 shows how you can reconfigure an existing asynchronous link between two security devices and provide the same logical link without any changes to the existing devices.
Router A is configured as the secondary end of the BSTUN asynchronous link and is attached to the security control station; Router B is configured as the primary end of the BSTUN asynchronous link and has one or more alarm panels attached to it.
At the downstream router, traffic from the attached alarm panels is encapsulated in IP. The asynchronous (alarm) traffic can be routed across arbitrary media to the host site where the upstream router supporting these protocols removes the IP encapsulation headers and presents the original traffic to the security control station over a serial connection. High-Level Data Link Control (HDLC) can be used as an alternative encapsulation method for point-to-point links.
The routers transport all asynchronous (alarm) blocks between the two devices in passthrough mode using BSTUN for encapsulation. BSTUN uses the same encapsulation architecture as serial tunnel (STUN), but is implemented on an independent tunnel. As each asynchronous frame is received from the line, a BSTUN header is added to create a BSTUN frame, and then BSTUN is used to deliver the frame to the correct destination router.
The Cisco routers do not perform any local acknowledgment or cyclic redundancy check (CRC) calculations on the asynchronous alarm blocks. The two end devices are responsible for error recovery in the asynchronous alarm protocol.
Multipoint configurations are common in security networks, where a number of alarm panels are frequently connected to a security control station over a single low-speed link. Our virtual multidrop support allows alarm panels from different physical locations in the network to appear as a single multidrop line to the security control station. Both Adplex and ADT are virtual multidropped protocols.
Multidrop operation is provided as a logical multipoint configuration. Figure 4 shows how a multipoint security network is reconfigured using Cisco routers. Router A is configured as an alarm secondary node, routers B and C are configured as alarm primary nodes. Router A monitors the address field of the polling or selection block and puts this address information in the BSTUN frame so BSTUN can deliver the frame to the correct downstream node.
Asynchronous alarm protocols are half-duplex protocols; transmission can occur in either direction, but only in one direction at a time. Each block of transmission is acknowledged explicitly by the remote end.
Network delays make it possible for a frame to arrive "late," meaning that the poll-cycling mechanism at the security control station has already moved on to poll the next alarm panel in sequence when it receives the poll response from the previous alarm panel.
To protect against this situation, routers configured for adplex or for adt-poll-select protocols use a sequence number built into the encapsulating frame to detect and discard late frames. The "upstream" router (connected to the security control station) inserts a frame sequence number into the protocol header, which is shipped through the BSTUN tunnel and bounced back by the "downstream" router (connected to the alarm panel). The upstream router maintains a frame-sequence count for the line, and checks the incoming frame-sequence number from the downstream router. If the two frame-sequence numbers do not agree, the frame is considered late (out of sequence) and is discarded.
Because the adt-vari-poll option allows the transmission of unsolicited messages from the alarm panel, frame sequencing is not supported for this protocol.
This feature is supported on these platforms:
To configure and monitor Bisync or polled asynchronous (alarm) features with BSTUN, complete the tasks in the following sections:
To enable BSTUN, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable BSTUN. | bstun peer-name ip-address |
The IP address defines the address by which this BSTUN peer is known to other BSTUN peers that are using the TCP transport. This command must be configured even when TCP is not being used.
The no bstun peer-name command disables the BSTUN function.
Define a BSTUN group and specify the protocol it uses. To define the protocol group, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Define the protocol group. | bstun protocol-group group-number protocol |
The block serial protocols include bsc, bsc-local-ack, adplex, adt-poll-select, adt-vari-poll, diebold, and async-generic.
Traditionally, the adt-poll-select protocol is used over land-based links, while the adt-vari-poll protocol is used over satellite (VSAT) links. The adt-vari-poll protocol typically uses a much slower polling rate when alarm consoles poll alarm panels because adt-vari-poll allows alarm panels to send unsolicited messages to the alarm console. In an adt-vari-poll configuration, alarm panels do not have wait for the console to poll them before responding with an alarm, they automatically send the alarm.
Interfaces configured to run the adplex protocol have their baud rate set to 4800 bps, use even parity, 8 data bits, 1 start bit, and 1 stop bit.
Interfaces configured to run the adt-vari-poll protocol have their baud rate set to 600 bps, use even parity, 8 data bits, 1 start bit, and 1.5 stop bits. If different line configurations are required, use the rxspeed, txspeed, databits, stopbits, and parity line configuration commands to change the line attributes.
Interfaces configured to run the async-generic protocol have their baud rate set to 9600 bps, use no parity, 8 data bits, 1 start bit, and 1 stop bit. If different line configurations are required, use the rxspeed, txspeed, databits, stopbits, and parity line configuration commands to change the line attributes.
Configure BSTUN on the serial interface before issuing any further BSTUN or protocol configuration commands for the interface. To configure the BSTUN function on a specified interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Configure BSTUN on an interface. | encapsulation bstun |
This command must be configured on an interface before any other BSTUN or asynchronous security protocol commands are configured for this interface.
The no encapsulation bstun command disables BSTUN on this interface.
Each BSTUN-enabled interface on a router must be placed in a previously defined BSTUN group. Packets will travel only between BSTUN-enabled interfaces that are in the same group. To assign a serial interface to a BSTUN group, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Assign a serial interface to a BSTUN group. | bstun group group-number |
The no bstun group command removes the interface from the BSTUN group.
To specify how frames are forwarded when received on a BSTUN interface, perform one of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Propagate all BSTUN traffic received on the input interface, regardless of the address contained in the serial frame. TCP encapsulation is used to propagate frames that match the entry. | bstun route all tcp ip-address1 |
| Propagate all BSTUN traffic received on the input interface, regardless of the address contained in the serial frame. HDLC encapsulation is used to propagate the serial frames. | bstun route all interface serial number |
| Use HDLC encapsulation to propagate the serial frames. The specified interface is a direct BSTUN link, rather than a serial connection to another peer. | bstun route interface serial number direct |
| Propagate the serial frame that contains a specific address. TCP encapsulation is used to propagate frames that match the entry. | bstun route address address-number tcp ip-address |
| Propagate the serial frame that contains a specific address. HDLC encapsulation is used to propagate the serial frames. | bstun route address address-number interface serial number |
| Propagate the serial frame that contains a specific address. HDLC encapsulation is used to propagate the serial frames. The specified interface is a direct BSTUN link, rather than a serial connection to another peer. | bstun route address address-number interface serial number direct |
When the adplex protocol is specified in the bstun protocol-group command, Adplex device addresses are limited to the range 1 to 127 because Adplex alarm panels invert the device address in the Adplex frame when responding to alarm console commands.
When the adt-poll-select protocol is specified in the bstun protocol-group command, routes for specific addresses cannot be specified on the downstream router (connected to the alarm panel), because no address field is provided within frames that are sent back to the alarm console. The only way to route back traffic to the alarm console is to use the bstun route all form of the bstun route command. This is also true for the diebold protocol and any other protocols supported by the async-generic protocol group that do not include a device address in the frame.
When the adt-vari-poll protocol is specified in the bstun protocol-group command, ADT device addresses are limited to the range 0 to 255, and address 0 is reserved for use as a broadcast address for adt-vari-poll only. If address 0 is specified in the bstun route address form of the bstun route command, the address is propagated to all configured BSTUN peers. Cisco supports broadcast addressing in a virtual multidrop configuration.
It is possible to use both the all and the address keywords on different bstun route commands on the same serial interface. When this is done, the address specifications take precedence; if none of these match, then the all specification is used to propagate the frame.
You can assign BSTUN traffic priorities based on either the BSTUN header or the TCP port. To prioritize traffic, perform one of the following tasks in global configuration mode:
You can customize BSTUN queuing priorities based on either the BSTUN header or TCP port. To customize priorities, perform one of the following tasks in global configuration mode:
Depending on the selected block serial protocol group, you must configure one or more options for that protocol group. The options for each of these protocol groups are explained in the following sections.
To configure Bisync options on a serial interface, perform one of the following tasks in interface configuration mode:
To configure asynchronous security protocol options on a serial interface, perform one or more of the following tasks in interface configuration mode:
In this example Router A and Router B are configured for both Adplex and Bisync across the same block serial tunnel, as shown in Figure 5.
version 11.0 ! hostname router-a ! bstun peer-name 172.28.1.190 bstun protocol-group 1 bsc bstun protocol-group 2 adplex bstun protocol-group 3 adplex ! interface serial 0 no ip address ! interface serial 1 no ip address ! interface serial 2 physical-layer async description Connection to 1st Security Alarm Console. no ip address encapsulation bstun no keepalive bstun group 2 bstun route address 2 tcp 172.28.1.189 bstun route address 3 tcp 172.28.1.189 adplex secondary ! interface serial 3 description Connection to BSC 3780 host. no ip address encapsulation bstun no keepalive clockrate 9600 bstun group 1 bstun route all tcp 172.28.1.189 bsc char-set ebcdic bsc contention ! interface serial 4 physical-layer async description Connection to 2nd Security Alarm Console. no ip address encapsulation bstun no keepalive bstun group 3 bstun route address 2 tcp 172.28.1.189 bstun route address 3 tcp 172.28.1.189 adplex secondary ! interface serial 5 no ip address ! interface serial 6 no ip address ! interface serial 7 no ip address ! interface serial 8 no ip address ! interface serial 9 no ip address ! interface tokenring 0 ip address 172.28.1.190 255.255.255.192 ring-speed 16 ! interface BRI0 ip address shutdown ! ip host ss10 172.28.0.40 ip host s2000 172.31.0.2 ip route 0.0.0.0 0.0.0.0 172.28.1.129 ! snmp-server community public RO ! line con 0 exec-timeout 0 0 line 2 no activation-character transport input-all parity even stopbits 1 rxspeed 4800 txspeed 4800 line 4 transport input all parity even stopbits 1 rxspeed 4800 txspeed 4800 line aux 0 transport input all line vty 0 4 password mango login ! end
version 11.0 ! hostname router-b ! bstun peer-name 172.28.1.189 bstun protocol-group 1 bsc bstun protocol-group 2 adplex bstun protocol-group 3 adplex source-bridge ring-group 100 ! interface serial 0 no ip address ! interface serial 1 no ip address ! interface serial 2 physical-layer async description Connection to Security Alarm Panel. no ip address encapsulation bstun no keepalive bstun group 2 bstun route all tcp 172.28.1.190 adplex primary ! interface serial 3 description Connection to BSC 3780 device. no ip address encapsulation bstun no keepalive clockrate 9600 bstun group 1 bstun route all tcp 172.28.1.190 bsc char-set ebcdic bsc contention ! interface serial 4 physical-layer async description Connection to async port on NCD (VT100 terminal emulation). no ip address ! interface serial 5 no ip address encapsulation sdlc-primary no keepalive nrzi-encoding clockrate 9600 sdllc traddr 4000.0000.4100 222 2 100 sdlc address C1 sdllc xid C1 05D40003 sdllc partner 4000.0000.0307 C1 ! interface serial 6 description Connection to alarm panel. physical-layer async no ip address encapsulation bstun no keepalive bstun group 3 bstun route all tcp 172.28.1.190 adplex primary !interface serial 7 no ip address ! interface serial 8 no ip address ! interface serial 9 no ip address ! interface tokenring 0 ip address 172.28.1.189 255.255.255.192 ring-speed 16 source-bridge 4 1 100 ! interface BRI0 ip address shutdown ! ip host ss10 172.28.0.40 ip host s2000 172.31.0.2 ip route 0.0.0.0 0.0.0.0 172.28.1.129 ! snmp-server community public RO ! line con 0 exec-timeout 0 0 line 2 no activation-character transport input-all parity even stopbits 1 rxspeed 4800 txspeed 4800 line 4 transport input all stopbits 1 line 6 transport input all parity even stopbits 1 rxspeed 4800 txspeed 4800 line 7 transport input all line aux 0 transport input all line vty 0 4 password mango login ! end
This section documents new and modified commands. All other commands used with this feature are documented in the Cisco IOS Release 11.2 command references.
Use the asp addr-offset interface configuration command to configure an asynchronous port to transmit and receive polled asynchronous traffic through a BSTUN tunnel. Use the no form of this command to cancel the specification.
asp addr-offset address-offset| address-offset | Location of the address byte within the polled asynchronous frame being received. |
No default is specified.
Interface configuration
This command first appeared in Cisco IOS Release 11.2 F.
This command only applies when the async-generic protocol has been specified on an interface using a combination of the bstun protocol-group global configuration command and the bstun group interface configuration command.
Interfaces configured to run the async-generic protocol have their baud rate set to 9600 bps, use 8 data bits, no parity, 1 start bit, and 1 stop bit. If different line configurations are required, use the rxspeed, txspeed, databits, stopbits, and parity line configuration commands to change the line attributes.
The addresses of the alarm panels should be used in the address field of the bstun route address interface configuration command.
The following example specifies that the first byte in the polled asynchronous frame contains the device address:
asp addr-offset 0
asp role
asp rx-ift
bstun protocol-group
bstun route
Use the asp role interface configuration command to specify whether the router is acting as the primary end of the polled asynchronous link or as the secondary end of the polled asynchronous link connected to the serial interface and the attached remote device is a security alarm control station. Use the no form of this command to cancel the specification.
asp role {primary | secondary}| primary | Router is the primary end of the polled asynchronous link connected to the serial interface, and the attached remote devices are alarm panels. |
| secondary | Router is the secondary end of the polled asynchronous link connected to the serial interface, and the attached remote device is a security alarm control station. |
No default is specified.
Interface configuration
This command first appeared in Cisco IOS Release 11.2 F.
When the router is configured as the primary end of the link, the polled asynchronous support feature in the serial interface uses the address of the incoming encapsulation for reply.
When the router is configured as the secondary end of the link, the polled asynchronous support feature in the serial interface uses the address in the block in the framing encapsulation.
The addresses of the alarm panels should be used in the address field of the bstun route address interface configuration command.
The following example specifies the router as the primary end of the link:
asp role primary
Use the asp rx-ift interface configuration command to specify a time period that, by expiring, signals the end of one frame being received and the start of the next. Use the no form of this command to cancel the specification.
asp rx-ift interframe-timeout| interframe-timeout | Number of milliseconds between the end of one frame being received and the start of the next frame. |
The default timeout value is 40 ms.
Interface configuration
This command first appeared in Cisco IOS Release 11.2 F.
The interframe timeout is useful when different baud rates are used between the router and the alarm console or alarm panel. For example, you might set an interframe timeout of 6 ms if the polled asynchronous protocol is running at 9600 bps, but set the value to 40 ms if the protocol is running at 300 bps.
This command applies only when the async-generic protocol has been specified on an interface using a combination of the bstun protocol-group global configuration command and the bstun group interface configuration command.
Interfaces configured to run the async-generic protocol have their baud rate set to 9600 bps, use 8 data bits, no parity, 1 start bit, and 1 stop bit. If different line configurations are required, use the rxspeed, txspeed, databits, stopbits, and parity line configuration commands to change the line attributes.
The addresses of the alarm panels should be used in the address field of the bstun route address interface configuration command.
The following example sets the interframe timeout value to 6 ms because the polled asynchronous protocol is running at 9600 bps:
asp rx-ift 6
asp addr-offset
asp role
bstun protocol-group
bstun route
Use the bstun protocol-group global configuration command to define a BSTUN group and the protocol it uses. Use the no form of this command to delete the BSTUN group.
bstun protocol-group group-number protocol| group-number | BSTUN group number. Valid numbers are decimal integers in the range 1 to 255. |
| protocol | Block serial protocol, selected from the following:
adplex |
No defaults are specified.
Global configuration
This command first appeared in Cisco IOS Release 11.0.
Interfaces configured to run the adplex protocol have their baud rate set to 4800 bps, use even parity, 8 data bits, 1 start bit, and 1 stop bit.
Interfaces configured to run the adt-vari-poll protocol have their baud rate set to 600 bps, use even parity, 8 data bits, 1 start bit, and 1.5 stop bits. If different line configurations are required, use the rxspeed, txspeed, databits, stopbits, and parity line configuration commands to change the line attributes.
Interfaces configured to run the async-generic protocol have their baud rate set to 9600 bps, use no parity, 8 data bits, 1 start bit, and 1 stop bit. If different line configurations are required, use the rxspeed, txspeed, databits, stopbits, and parity line configuration commands to change the line attributes.
The following example defines BSTUN group 1, specifies that it uses the Bisync protocol, and indicates that frames will be locally acknowledged:
bstun protocol-group 1 bsc-local-ack
bstun group
Use the bstun route interface configuration command to define how frames will be forwarded from a BSTUN interface to a remote BSTUN peer. Use the no form of this command to cancel the definition.
bstun route {all | address address-number} {tcp ip-address | interface serial number} [direct]| all | All BSTUN traffic received on the input interface is propagated, regardless of the address contained in the serial frame. |
| address | Serial frame that contains a specific address is propagated. |
| address-number | Poll address, a hexadecimal number from 01 to FF (but not all values are valid). The reply address to be used on the return leg is calculated from the configured poll address. |
| tcp | TCP encapsulation is used to propagate frames that match the entry. |
| ip-address | IP address of the remote BSTUN peer. |
| interface serial | HDLC encapsulation is used to propagate the serial frames. |
| number | Serial line to an appropriately configured router on the other end. |
| direct | (Optional) Specified interface is also a direct BSTUN link, rather than a serial connection to another peer. |
No defaults are specified.
Interface configuration
This command first appeared in Cisco IOS Release 11.0.
When the adplex protocol is specified in the bstun protocol-group command, Adplex device addresses are limited to the range 1 to 127 because Adplex alarm panels invert the device address in the Adplex frame when responding to alarm console commands.
When the adt-poll-select protocol is specified in the bstun protocol-group command, routes for specific addresses cannot be specified on the downstream router (connected to the alarm panel), because no address field is provided within frames that are sent back to the alarm console. The only way to route traffic back to the alarm console is to use the bstun route all form of the bstun route command. This is also true for the diebold protocol and any other protocol supported by the async-generic protocol group that does not include a device address in the frame.
When the adt-vari-poll protocol is specified in the bstun protocol-group command, ADT device addresses are limited to the range 0 to 255, and address 0 is reserved for use as a broadcast address for adt-vari-poll only. If address 0 is specified in the bstun route address form of the bstun route command, the address is propagated to all configured BSTUN peers.
It is possible to use both the all and the address keywords on different bstun route commands on the same serial interface. When this is done, the address specifications take precedence; if none of these match, then the all specification is used to propagate the frame.
In the following example, all BSTUN traffic received on serial interface 0 is propagated, regardless of the address contained in the serial frame:
bstun route all interface serial 0
This section documents the debug asp packet command related to asynchronous security protocol tunneling.
debug asp packetUse the debug asp packet EXEC command to display information on all asynchronous security protocols operating on the router. The no form of this command disables the debug information output.
[no] debug asp packetThe router uses asynchronous security protocols such as ADT Security Systems, Inc., Adplex, and Diebold to transport alarm blocks between two devices (such as a security alarm system console and an alarm panel). The alarm blocks are transported in passthrough mode using BSTUN encapsulation.
Figure 6 shows a partial sample debug asp packet output for asynchronous security protocols when packet debugging is enabled on an asynchronous line carrying Diebold alarm traffic. In this example, two polls are sent from the Diebold alarm console to two alarm panels that are multi-dropped from a single RS-232 interface. The alarm panels have device addresses F0 and F1. The example trace indicates that F1 is responding and F0 is not responding. At this point, you need to examine the physical link and possibly use a datascope to determine why the device is not responding.
router# debug asp packet
ASP packet debugging is on
12:19:48: ASP: Serial5: ADI-Rx: Data (4 bytes): F1FF4C42
12:19:49: ASP: Serial5: ADI-Tx: Data (1 bytes): 88
12:19:49: ASP: Serial5: ADI-Rx: Data (4 bytes): F0FF9B94
12:20:47: ASP: Serial5: ADI-Rx: Data (4 bytes): F1FF757B
12:20:48: ASP: Serial5: ADI-Tx: Data (1 bytes): F3
12:20:48: ASP: Serial5: ADI-Rx: Data (4 bytes): F0FFB1BE
12:21:46: ASP: Serial5: ADI-Rx: Data (4 bytes): F1FFE6E8
12:21:46: ASP: Serial5: ADI-Tx: Data (1 bytes): 6F
12:21:46: ASP: Serial5: ADI-Rx: Data (4 bytes): F0FFC1CE
Table 5 describes the fields and messages shown in Figure 6.
| Field | Description |
|---|---|
| ASP | Async security protocol packet. |
| Serial 5 | Interface receiving and transmitting the packet. |
| ADI-Rx | Packet is being received. |
| ADI-TX | Packet is being transmitted. |
| Data (n bytes) | Type and size of the packet. |
| F1FF4c42 | Alarm panel device address. |
The following list identifies the MIB variables introduced with Cisco IOS Release 11.2(3)F:
|
|