Guest

IBM Networking

Configuring DLSw+ Redundancy Between Two Subareas Using RIF-Passthru, DLSw+ Timers, and DLSw+ Backup

Document ID: 18783



Contents

Introduction
Before You Begin
      Conventions
      Prerequisites
      Components Used
Problem
Solution(s)
      Solution 1 - Using DLSw rif-passthru
      Solution 2 - Adjusting DLSw Timers
      Solution 3 - Using DLSw Backup Peers
Related Information

Introduction

There are a number of issues that users need to be aware of when setting Data-Link Switching (DLSw) paths between two subareas. The issues discussed in this document apply equally to subarea connections where Token Ring (for example, Source Route Bridging (SRB) ) is used to carry subarea connections. This includes Front End Processor Network Control Program (NCP) Token Ring Interconnection (FEP NTRI), Virtual Telecommunications Access Method (VTAM) with Channel Interface Processor (CIP) or 3172, or Synchronous Data Link Control (SDLC) attached FEP converted to Logical Link Control 2 (LLC2) using DLSw.

Before You Begin

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Prerequisites

There are no specific prerequisites for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Problem

When a Physical Unit Type 2 (PU2) connects to a FEP, it sends an explorer, gets one or more responses, and chooses one of these explorers to send the Exchange Identification (XID). The FEP then responds to the XID using the received Routing Information Field (RIF). With FEP-to-FEP, however, each FEP sends its own explorer, gets one or more responses, and then sends its XID over one of the RIFs. Each FEP explores independently. This means that the traffic in one direction can use a different RIF path to the traffic in the other direction. The problems arise when you try to put local-ack or some other feature in the middle that relies on seeing and understanding all or part of the traffic.

In the following network example:

dlsw_redundancy-a.gif

FEP1 can send XIDs over Router1A and Router2A, and FEP2 can send XIDs over Router2B and Router1B. Consequently, the DLSw circuit does not come up as DLSw, and only sees XIDs in one direction. This is ideal, as FEPs can send and receive XIDs over different RIF paths. Each DLSw peer pair, however, only sees either Set Asynchronous Balanced Mode Extended (SABME) or Unnumbered Acknowledgements (UA), and the circuit never comes up. Each FEP exhausts its retry sequence before exploring again. Various things may influence how long it takes before each FEP decides to use the same DLSw peer pair and the circuit is connected. Once the circuit is up and running, there should be no more problems. The bring up time for the circuit may be quite long however.

Solution(s)

The following lab toplogy was used in the solutions below:

dlsw_redundancy-b.gif

Solution 1 - Using DLSw rif-passthru

The first solution is to to configure rif-passthru in DLSw. In this solution, there is no local-ack and more importantly, the SABME/UAs are not visible to the DLSw peers. For the same reason, DLSw Fast Sequenced Transport (FST) does not work in this solution as it uses SABME/UAs to build the fast-cache entry. Since rif-passthru in DLSw does not use local-ack, all supervisory traffic goes onto the WAN. By using rif-passthru in DLSw, the RIF is limited to seven hop counts by the IBM standards end-to-end.

For router configurations, refer to the tables below.

Router1A

hostname Router1A
!
source-bridge ring-group 1000 
dlsw local-peer peer-id 10.1.1.1
dlsw remote-peer 0 tcp 10.1.1.4 rif-passthru 1000 


! --- Where 1000 is the the virtual ring number assigned 
!--- in the source-bridge ring-group command.

!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
!
interface TokenRing0/0
ip address 10.1.4.1 255.255.255.0
ring-speed 16
source-bridge 10 1 1000
source-bridge spanning
!
interface Serial1/0
bandwidth 64
ip address 10.1.2.1 255.255.255.0
clockrate 64000
!
router eigrp 100
network 10.0.0.0 

Router1B

hostname Router1B
!
source-bridge ring-group 1000
dlsw local-peer peer-id 10.1.1.2
dlsw remote-peer 0 tcp 10.1.1.3 rif-passthru 1000
!
interface Loopback0
ip address 10.1.1.2 255.255.255.255
!
interface Serial0
bandwidth 64
ip address 10.1.3.2 255.255.255.0
clockrate 64000
!
interface TokenRing0
ip address 10.1.4.2 255.255.255.0
ring-speed 16
source-bridge 10 2 1000
source-bridge spanning
!
router eigrp 100
network 10.0.0.0

Router2A

hostname Router2A
!
source-bridge ring-group 1000
dlsw local-peer peer-id 10.1.1.4
dlsw remote-peer 0 tcp 10.1.1.1 rif-passthru 1000
!
interface Loopback0
ip address 10.1.1.4 255.255.255.255
!
interface TokenRing2/0
ip address 10.1.5.4 255.255.255.0
ring-speed 16
source-bridge 273 4 1000
source-bridge spanning
!
interface Serial3/1
bandwidth 64
ip address 10.1.2.4 255.255.255.0
!
router eigrp 100
network 10.0.0.0

Router2B

hostname Router2B
!
source-bridge ring-group 1000
dlsw local-peer peer-id 10.1.1.3
dlsw remote-peer 0 tcp 10.1.1.2 rif-passthru 1000
!
interface Loopback0
ip address 10.1.1.3 255.255.255.255
!
interface TokenRing2/0
ip address 10.1.5.3 255.255.255.0
ring-speed 16
source-bridge 273 3 1000
source-bridge spanning
!
interface Serial3/1
bandwidth 64
ip address 10.1.3.3 255.255.255.0
!
router eigrp 100
network 10.0.0.0

Note: rif-passthru is also required to remotely load an NCP. rif-passthru sets the initialization mode/request initialization mode support. In the above configuration, source-bridge ring-group 1000 was configured on all DLSw routers to prevent an explorer from arriving back at the originating ring. Also note that in this situation, you need to maintain a unique RIF field in both directions that configured unique bridge numbers in the source-bridge command on all four routers. For example, to go from FEP1 to FEP2, you could use Ring 10, Bridge 1, Ring 1000, Bridge 4, and Ring 273, or Ring 10, Bridge 2, Ring 1000, Bridge 3, and Ring 273.

For more information on RIF Passthru in DLSw, refer to RIF Passthru in DLSw .

Solution 2 - Adjusting DLSw Timers

Adjusting timers is another solution to delay explorers passing through the less preferable DLSw peers. By adjusting the timers, you aretrying to bias the explorers to find the preferred path first. Assuming that Router1B and Router2B is the less preferable path, configure both Router1B and Router2B with the following commands:

In this solution, DLSw does not keep reachability cache entries for more than four seconds. This means that effectively all explorers result in a CANUREACH (CUR) to the remote rather than replying locally. The explorer-wait-time forces DLSw to delay sending a test reponse to the local FEP when getting an ICANREACH (ICR). This delays the bring up of the circuit by the configured amount, which is in this example, two seconds.

Note: The sna-cache-timeout must exceed the explorer-wait-time.Otherwise, the cache entry is destroyed while DLSw is waiting to send the test response. This means that the test response is never sent.

Router1A

hostname Router1A
!
source-bridge ring-group 1000
dlsw local-peer peer-id 10.1.1.1
dlsw remote-peer 0 tcp 10.1.1.4
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
!
interface TokenRing0/0
ip address 10.1.4.1 255.255.255.0
ring-speed 16
source-bridge 10 1 1000
source-bridge spanning
!
interface Serial1/0
bandwidth 64
ip address 10.1.2.1 255.255.255.0
clockrate 64000
!
router eigrp 100
network 10.0.0.0 

Router1B

hostname Router1B
!
source-bridge ring-group 1000
dlsw local-peer peer-id 10.1.1.2
dlsw timer sna-cache-timeout 4
dlsw timer explorer-wait-time 2
dlsw remote-peer 0 tcp 10.1.1.3
!
interface Loopback0
ip address 10.1.1.2 255.255.255.255
!
interface Serial0
bandwidth 64
ip address 10.1.3.2 255.255.255.0
clockrate 64000
!
interface TokenRing0
ip address 10.1.4.2 255.255.255.0
ring-speed 16
source-bridge 10 2 1000
source-bridge spanning
!
router eigrp 100
network 10.0.0.0

Router2A

hostname Router2A
!
source-bridge ring-group 1000
dlsw local-peer peer-id 10.1.1.4
dlsw remote-peer 0 tcp 10.1.1.1
!
interface Loopback0
ip address 10.1.1.4 255.255.255.255
!
interface TokenRing2/0
ip address 10.1.5.4 255.255.255.0
ring-speed 16
source-bridge 273 4 1000
source-bridge spanning
!
interface Serial3/1
bandwidth 64
ip address 10.1.2.4 255.255.255.0
!
router eigrp 100
network 10.0.0.0

Router2B

hostname Router2B
!
source-bridge ring-group 1000
dlsw local-peer peer-id 10.1.1.3
dlsw timer sna-cache-timeout 4
dlsw timer explorer-wait-time 2
dlsw remote-peer 0 tcp 10.1.1.2
!
interface Loopback0
ip address 10.1.1.3 255.255.255.255
!
interface TokenRing2/0
ip address 10.1.5.3 255.255.255.0
ring-speed 16
source-bridge 273 3 1000
source-bridge spanning
!
interface Serial3/1
bandwidth 64
ip address 10.1.3.3 255.255.255.0
!
router eigrp 100
network 10.0.0.0

Solution 3 - Using DLSw Backup Peers

Another solution is to use backup peers. Router1B and Router2B are promiscuous peers. Router1A has a peer to Router2A and backup peer to Router2B with linger=0 (a value of 0 (zero) means the DLSw backup peer is disconnected as soon as the primary peer is re-established). Router2A is a peer to Router1A and a backup peer to Router1B with linger=0. To ensure proper backup and redundancy, you need to make sure that IP routing allows IP to reroute across the Token Ring and over the other link in case of link failure. Also, it is recommended here to use the Token Ring IP addresses for the DLSw local peer addresses. This means that the peer goes up/down with the Token Ring interface. This is necessary as, at any one time, there is only ever one peer active.

Router1A

hostname Router1A
!
source-bridge ring-group 1000
dlsw local-peer peer-id 10.1.4.1
dlsw remote-peer 0 tcp 10.1.5.4
dlsw remote-peer 0 tcp 10.1.5.3 backup-peer 10.1.5.4 linger 0
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
!
interface TokenRing0/0
ip address 10.1.4.1 255.255.255.0
ring-speed 16
source-bridge 10 1 1000
source-bridge spanning
!
interface Serial1/0
bandwidth 64
ip address 10.1.2.1 255.255.255.0
clockrate 64000
!
router eigrp 100
network 10.0.0.0

Router1B

hostname Router1B
!
source-bridge ring-group 1000
dlsw local-peer peer-id 10.1.4.2
dlsw remote-peer 0 tcp 10.1.5.4 passive
!
interface Loopback0
ip address 10.1.1.2 255.255.255.255
!
interface Serial0
bandwidth 64
ip address 10.1.3.2 255.255.255.0
clockrate 64000
!
interface TokenRing0
ip address 10.1.4.2 255.255.255.0
ring-speed 16
source-bridge 10 2 1000
source-bridge spanning
!
router eigrp 100
network 10.0.0.0

Router2A

hostname Router2A
!
source-bridge ring-group 1000
dlsw local-peer peer-id 10.1.5.4
dlsw remote-peer 0 tcp 10.1.4.1
dlsw remote-peer 0 tcp 10.1.4.2 backup-peer 10.1.4.1 linger 0
!
interface Loopback0
ip address 10.1.1.4 255.255.255.255
!
interface TokenRing2/0
ip address 10.1.5.4 255.255.255.0
ring-speed 16
source-bridge 273 4 1000
source-bridge spanning
!
interface Serial3/1
bandwidth 64
ip address 10.1.2.4 255.255.255.0
!
router eigrp 100
network 10.0.0.0

Router2B

hostname Router2B
!
source-bridge ring-group 1000
dlsw local-peer peer-id 10.1.5.3
dlsw remote-peer 0 tcp 10.1.4.1 passive
!
interface Loopback0
ip address 10.1.1.3 255.255.255.255
!
interface TokenRing2/0
ip address 10.1.5.3 255.255.255.0
ring-speed 16
source-bridge 273 3 1000
source-bridge spanning
!
interface Serial3/1
bandwidth 64
ip address 10.1.3.3 255.255.255.0
!
router eigrp 100
network 10.0.0.0


Related Information



Updated: Sep 09, 2005 Document ID: 18783