A number of configuration issues must be addressed for the OpenROUTE DLSw software to interoperate with that of the IBM 6611t router.

The following sections provide an overview of these issues, and indicate which features of the OpenROUTE DLSw implementation are not interoperable with that of the IBM 6611.

Note: The issues discussed here derive from testing performed with the IBM 6611's MPNP V1.2 software. The issues may not apply to other MPNP software versions.

Bridge Configuration Issues

• The LAN identification (Segment number) of the DLSw must match on both the Nx Networks and IBM 6611 routers. If a mismatch persistently exists, enter the DLSw configuration environment (configuration). Use the set srb command to set a Segment Number value that matches the IBM 6611 equivalent.

• The maximum MTU value that can be used for the Bridge Frame is 2100 bytes. This is the largest value currently supported by the IBM 6611. If MTU values less than 2100 are specified, it is important that the configured values match on both the Nx Networks and IBM 6611 routers.

• The client/server and peer/peer DLSw group feature that enables DLSw neighbors to dynamically find each other is not interoperable with the IBM 6611 DLSw implementation. As a result, you must use the DLSw's add tcp neighbor configuration command to define the static IP addresses of adjacent IBM 6611 DLSw peers. However, you can still use DLSw group functionality to locate other Nx Networks routers even though IBM 6611 routers exist in the network.

• The preceding interoperability restriction on the OpenROUTE DLSw group feature has implications for the selection of RIP/OSPF:

  • To utilize DLSw groups on a Nx Networks router, the configuration of OSPF/MOSPF is also required. But since these DLSw groups are not interoperable with the 6611, it is possible to configure the Nx Networks DLSw router with only RIP enabled and no OSPF configuration.

  • Although OSPF and RIP can both be enabled on the Nx Networks side, MOSPF (if selected through the OSPF configuration) is not currently supported by the IBM 6611.

  • For the IBM 6611 MPNP V1R2.0 software, the APPN network node implementation on the 6611 only appears to work with RIP. It does not work with OSPF when interoperating with a Nx Networks CNX 600 running DLSw that is attached via Token Ring to an OS/2 PC APPN End Node.

• Within the OpenROUTE IP configuration make sure that the fill patterns configured for broadcast addresses on an interface match their equivalent definition on the IBM 6611.

• OpenROUTE Bandwidth Reservation System (BRS) that can be utilized to guarantee bandwidth for the transport of SNA traffic over DLSw, is not interoperable with the IBM 6611 DLSw implementation.

  Although the prioritization assigned by the Nx Networks hardware for BRS can be implemented in an outbound direction, the prioritization order will not be guaranteed if intermediate IP routers do not support BRS. Also, since the 6611 does not support BRS in its end of the line, BRS could only be applicable in a single direction.

• TCP Connection Break Detection Differences. If Keepalive is disabled, the OpenROUTE DLSw implementation will not detect a broken TCP connection until it attempts to send data on the connection.

• TCP Connection Reestablishment Differences. Once a TCP connection is broken, the OpenROUTE DLSw implementation re-establishes the TCP connection when a new DLSw SSP_CANUREACH is generated upon receipt of a DLC TEST message from an end station. The IBM 6611 may not exhibit the same behavior.

• Keepalive Disable/Enable Related Differences. The OpenROUTE DLSw implementation permits the enabling/disabling of a Keepalive option when a TCP neighbor IP address is added (configured). Although TCP in the IBM 6611 DLSw implementation will respond to Keepalive messages received on a TCP session, there is no mechanism to configure the resident 6611 TCP so as to enable the generation of TCP Keepalive messages.

• OpenROUTE DLSw implementation, there is no hard-coded restriction on the maximum number of TCP connections supported. As a result, the maximum number of TCP connections supported is directly related to a OpenROUTE DLSw Router's available memory. In the IBM 6611 case, there is a hard coded internal restriction of 100 TCP connections that can be supported in the DLSw implementation.

• The OpenROUTE DLSw implementation does not support generation of SSP_IAMOKAY message (SSP Message Type 'x1D') while IBM 6611 DLSw implementation is supported. This SSP message is undocumented in RFC 1434, and is silently discarded by the OpenROUTE DLSw implementation upon receipt.

• The IBM 6611 DLSw implementation processes SSP_ENTER_BUSY/EXIT_BUSY messages received from the OpenROUTE DLSw implementation but will not generate similar flow control related SSP messages.

• The OpenROUTE DLSw implementation does support the user defined SSP_TEST_CIRCUIT_REQ message (SSP message type 'x7A') that is generated by an IBM 6611 DLSw router functioning as an APPN network node. Upon receipt of this message, the OpenROUTE DLSw implementation will return the user defined SSP_TEST_CIRCUIT_RSP message (SSP message type 'x7B'). This response is expected by the IBM 6611 DLSw router's APPN network node implementation.

• The IBM 6611 chooses to fill bytes in reserved fields with 'xFF' values, whereas the OpenROUTE DLSw implementation zeros these fields whenever SSP Control or Information messages are transmitted. These differences should be noted whenever a Wide Area Sniffer is being used to monitor DLSw SSP messages flowing across a DLSw WAN connection.

• If a problem is encountered when trying to establish a DLSw connection initiated by the IBM 6611, check the IBM 6611 configuration to ensure that MAC address filtering has not been inadvertently enabled for an associated source or destination MAC address.

• Although RFC 1434 does not specifically address the issue of orphan DLSw sessions (e.g., DLSw sessions that remain in a DLSw circuit established state with no subsequent activity), both the OpenROUTE and IBM 6611 DLSw implementations resolve this issue by providing orphan DLSw session timeouts. DLSw sessions that remain inactive while in DLSw circuit established state for longer than 30 seconds are eliminated by both implementations.