|
|
This chapter describes how to configure DLSw+, our implementation of the data-link switching (DLSw) standard for Systems Network Architecture (SNA) devices. For a complete description of the commands in this chapter, refer to the "DLSw+ Configuration Commands" chapter of the Bridging and IBM Networking Command Reference.
DLSw+ supports media conversion between local or remote LANs and SDLC or Ethernet. For clarity, the configuration task list below describes configuration in a Token Ring environment. The only differences for SDLC and Ethernet are the specific commands needed to configure those media, plus a media-specific command to associate the interface with DLSw+.
To configure DLSw+, perform tasks in the following sections:
See the end of this chapter for "DLSw+ Configuration Examples." Media-specific configuration examples for Ethernet and SDLC are also provided. For details of SDLC commands in the sample SDLC configuration, refer to the "LLC2 and SDLC Commands" chapter of the Bridging and IBM Networking Command Reference.
The source-bridge ring can be shared between DLSw+ and SRB/RSRB. In DLSw+, the source-bridge ring group specifies the virtual ring that will appear to be the last ring in the RIF. Because RIFs are terminated at the router, there is no correlation between the ring-group number specified in DLSw+ peers. The numbers can be the same for management simplicity, but they do not have to be. To define a source-bridge ring group for DLSw+, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Define a ring group. | source-bridge ring-group ring-group [virtual-mac-address]1 |
Refer to "DLSw+ Using TCP Encapsulation and LLC2 Local AcknowledgmentBasic Configuration Example" for a sample configuration file.
Defining a DLSw+ local peer for a router enables DLSw+. You specify all local DLSw+ parameters as part of the local peer definition. To define a local peer, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Define the DLSw+ local peer. | dlsw local-peer [peer-id ip-address] [group group] [border] [cost cost] [lf size] [keepalive seconds] [passive] [promiscuous] [biu-segment] |
Refer to "DLSw+ Using TCP Encapsulation and LLC2 Local AcknowledgmentBasic Configuration Example" for a sample configuration.
DLSw+ ring lists map traffic on a local interface to remote peers. You can create a ring list of local ring numbers and apply the list to remote peer definitions. Traffic received from a remote peer is only forwarded to the rings specified in the ring list. Traffic received from a local interface is only forwarded to peers if the input ring number appears in the ring list applied to the remote peer definition. The definition of a ring list is optional. If you want all peers and all rings to receive all traffic, you do not have to define a ring list. Specify 0 for the list number in the remote peer statement.
To define a ring list, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Define a ring list. | dlsw ring-list list-number rings ring-number |
DLSw+ port lists map traffic on a local interface (either Token Ring or serial) to remote peers. You can create a port list of local ports and apply the list to remote peer definitions. Traffic received from a remote peer is only forwarded to peers if the input port number appears in the port list applied to the remote peer definition. The port list command provides a single command to specify both serial and Token Ring interfaces. Figure 67 shows how port lists are used to map traffic.
The definition of a port list is optional. If you want all peers and all interfaces to receive all traffic, you do not have to define a port list. Simply specify 0 for the list number in the remote peer statement.
To define a port list, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Define a port list. | dlsw port-list list-number type number |
DLSw+ bridge group lists map traffic on the local Ethernet bridge group interface to remote peers. You can create a bridge group list and apply the list to remote peer definitions. Traffic received from a remote peer is only forwarded to the bridge group specified in the bridge group list. Traffic received from a local interface is only forwarded to peers if the input bridge group number appears in the bridge group list applied to the remote peer definition. The definition of a bridge group list is optional. Because each remote peer has a single list number associated with it, if you want traffic to go to a bridge group and to either a ring list or port list, you should specify the same list number in each definition.
| Task | Command |
|---|---|
| Define a ring list. | dlsw bgroup-list list-number bgroups number |
You can define direct encapsulation, Fast Sequenced Transport (FST), or TCP encapsulation on a remote peer.
Our DLSw+ backup peer implementation allows the backup peer to remain active after the primary router becomes active. This implementation prevents disruption of SNA and NetBIOS sessions. When the primary peer becomes active, all new sessions are established using the primary peer. The backup peer connection remains active until there are no active LLC2 connections or until a user-configured period of time elapses.
To configure direct encapsulation of either Frame Relay or HDLC, perform one of the following tasks in global configuration mode:
To configure FST encapsulation on a remote peer, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Define an FST encapsulation remote peer. | dlsw remote-peer list-number fst ip-address [cost cost] [lf size] [pass-thru] [keepalive seconds] [lsap-output-list list] [host-netbios-out host-list-name] [bytes-netbios-out bytes-list-name] [backup-peer ip-address] |
You can configure TCP encapsulation on a remote peer. (TCP encapsulation supports ISDN DDR cost-savings through the configurable timeout, linger, and dynamic options.)
To configure TCP encapsulation on a remote peer, perform the following task in global configuration mode.
| Task | Command |
|---|---|
| Define a TCP encapsulation remote peer. | dlsw remote-peer list-number tcp ip-address [priority] [cost cost] [lf size] [pass-thru] [keepalive seconds] [tcp-queue-max size] [lsap-output-list list] [host-netbios-out host-list-name] [bytes-netbios-out bytes-list-name] [backup-peer ip-address] [timeout seconds] [dynamic] [inactivity minutes] [no-llc minutes] [linger minutes] |
The following is a list of valid port numbers used for TCP connections when the priority keyword is used with the dlsw remote-peer command:
| high | 2065 |
| medium | 1981 |
| normal | 1982 |
| low | 1983 |
Refer to "DLSw+ Using TCP Encapsulation and LLC2 Local AcknowledgmentBasic Configuration Example" for an example DLSw+ configuration for TCP encapsulation.
You can configure the Cisco IOS software for direct encapsulation of DLSw+ in Frame Relay according to RFC 1490. DLSw+ Direct over RFC 1490 supports either passthrough or local acknowledgment (DLC termination). DLSw+ supports transport for both SNA and NetBIOS data. SNA PU 2.0 and PU 2.1 are supported.
The configuration requires a minimum number of PVCs (since multiple protocols can share a single PVC). Aminimum number of PVCs simplifies configuration because multiple PUs can share a PVC without requiring configuration of multiple SAPs.
The passthrough option adds the smallest amount of link overhead and requires minimal processing cycles in the attaching routers when compared to TCP/IP encapsulation.
The local acknowledgment option prevents DLC timeouts during periods of WAN congestion. It also minimizes WAN traffic by keeping data link control (DLC) acknowledgments and keepalives off the WAN.
No controller or FEP upgrades are required to take advantage of this feature (if already Token Ring attached), reducing costs and simplifying migration to Frame Relay.
To enable DLSw+ over Frame Relay with passthrough, perform the following tasks, beginning in global configuration mode:
| Task | Command |
|---|---|
| Specify the serial port. | interface serial number1 |
| Enable Frame Relay encapsulation. | encapsulation frame-relay2 |
| Define the mapping between DLSw+ and the DLCI. | frame-relay map dlsw dlci-number2 |
To enable DLSw+ over Frame Relay with local acknowledgment, perform the following tasks, beginning in global configuration mode:
| Task | Command |
|---|---|
| Specify the serial port. | interface serial number1 |
| Enable Frame Relay encapsulation. | encapsulation frame-relay2 |
| Define the mapping between DLSw+ and the DLCI. | frame-relay map llc2 dlci-number2 |
To enable DLSw+ on a Token Ring interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable DLSw+ on a Token Ring interface. | source-bridge local-ring bridge-number ring-group1 |
To enable DLSw+ on certain Ethernet interfaces, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable DLSw+ on an Ethernet interface. | dlsw bridge-group group-number |
To enable DLSw+ on an SDLC interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable DLSw+ on an SDLC interface. | sdlc dlsw sdlc-address |
To configure an SDLC multidrop line downstream, you configure the SDLC role as either primary or prim-xid-poll. SDLC role primary specifies that any PU without the xid-poll parameter in the sdlc address command is a PU 2.0 device. SDLC role prim-xid-poll specifies that every PU is type 2.1. We recommend that you specify sdlc role primary if all SDLC devices are type PU 2.0 or a mix of PU 2.0 and PU 2.1. Specify sdlc role prim-xid-poll if all devices are type PU 2.1
Refer to the section "DLSw+ with SDLC Multidrop Support Configuration Example" for sample configurations.
You can configure DLSw+ for QLLC connectivity, which enables both of the following two scenarios:
To enable QLLC connectivity for DLSw+, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Specify an interface as an X.25 device. | encapsulation x.251 |
| Activate X.25 subaddresses. | x25 address subaddress1 |
| Associate a virtual MAC address with the X.121 address of the remote X.25 device. | x25 map qllc x121-addr [x25-map-options]2 |
| Enable DLSw+ over QLLC. | qllc dlsw {subaddress subaddress | pvc pvc-low [pvc-high]} [vmac vmacaddr [poolsize]] [partner partner-macaddr] [sap ssap dsap] [xid xidstring] [npsi-poll] |
To modify an existing configuration parameter, perform one or more of the tasks in the following sections:
To configure a DLSw+ explorer queue, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Configure the depth of DLSw+ explorer queue router. | dlsw explorerq-depth queue-max |
To configure DLSw+ timers, perform the following task in global configuration mode:
To configure peer-on-demand defaults, perform one of the following task in global configuration mode:
To reduce explorer traffic destined for this peer, the peer can send other peers a list of resources for which it has information (icanreach) or does not have information (icannotreach). This information is exchanged as part of a capabilities exchange.To configure static resources that will be exchanged as part of a capabilities exchange, perform one of the following tasks in global configuration mode:
To configure static paths to minimize explorer traffic originating in this peer, perform one of the following tasks in global configuration mode:
To configure duplicate path handling, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Configure duplicate path handling. | dlsw duplicate-path-bias [load-balance] |
To monitor and maintain activity on the DLSw+ network, perform one or more of the following tasks in privileged EXEC mode:
The following sections provide DLSw+ configuration examples:
This sample configuration requires the following tasks, which are described in earlier sections of this document:
Encapsulate the source-route bridged traffic inside IP datagrams passed over a TCP connection between two routers with local acknowledgment enabled when you have LANs separated by wide geographic distances, and you want to avoid multiple retransmissions or loss of user sessions that can occur with time delays.
Logical Link Control-Type 2 (LLC2) is an ISO standard data link level protocol used in Token Ring networks. LLC2 was designed to provide reliable transmission of data across LAN media and to cause minimal or at least predictable time delays. However, RSRB and wide-area network (WAN) backbones created LANs that are separated by wide, geographic distances spanning countries and continents. As a result, LANs have time delays that are longer than LLC2 allows for bidirectional communication between hosts. Local acknowledgment addresses the problem of unpredictable time delays, multiple retransmissions, and loss of user sessions.
In a typical LLC2 session, when one host sends a frame to another host, the sending host expects the receiving host to respond positively or negatively in a predefined period of time commonly called the T1 time. If the sending host does not receive an acknowledgment of the frame it sent within the T1 time, it retries a few times (normally 8 to 10). If there is still no response, the sending host drops the session.
Figure 68 illustrates an LLC2 session. A 37x5 on a LAN segment can communicate with a 3x74 on a different LAN segment separated via a wide-area backbone network. Frames are transported between Router A and Router B by means of DLSw+. However, the LLC2 session between the 37x5 and the 3x74 is still end-to-end; that is, every frame generated by the 37x5 traverses the backbone network to the 3x74, and the 3x74, on receipt of the frame, acknowledges it.
On backbone networks consisting of slow serial links, the T1 timer on end hosts could expire before the frames reach the remote hosts, causing the end host to retransmit. Retransmission results in duplicate frames reaching the remote host at the same time as the first frame reaches the remote host. Such frame duplication breaks the LLC2 protocol, resulting in the loss of sessions between the two IBM machines.
One way to solve this time delay is to increase the timeout value on the end nodes to account for the maximum transit time between the two end machines. However, in networks consisting of hundreds or even thousands of nodes, every machine would need to be reconfigured with new values. With local acknowledgment for LLC2 enabled, the LLC2 session between the two end nodes would not be not end-to-end, but instead, would terminate at two local routers. Figure 69 shows the LLC2 session with the 37x5 ending at Router A and the LLC2 session with the 3x74 ending at Router B. Both Router A and Router B execute the full LLC2 protocol as part of local acknowledgment for LLC2.
With local acknowledgment for LLC2 enabled in both routers, Router A acknowledges frames received from the 37x5. The 37x5 still operates as if the acknowledgments it receives are from the 3x74. Router A looks like the 3x74 to the 37x5. Similarly, Router B acknowledges frames received from the 3x74. The 3x74 operates as if the acknowledgments it receives are from the 37x5. Router B looks like the 3x74 to 37x5. Because the frames no longer have to travel the WAN backbone networks to be acknowledged, but instead are locally acknowledged by routers, the end machines do not time out, resulting in no loss of sessions.
Enabling local acknowledgment for LLC2 has the following advantages:
LLC2 local acknowledgment is enabled only with TCP remote peers (as opposed to LAN or direct serial interface remote peers).
If the LLC2 session between the local host and the router terminates in either router, the other will be informed to terminate its connection to its local host.
If the TCP queue length of the connection between the two routers reaches the highwater mark, the routers sends Receiver-Not-Ready (RNR) messages to the local hosts until the queue limit is reduced to below this limit.
The configuration of the LLC2 parameters for the local Token Ring interfaces can affect overall performance. Refer to the chapter "Configuring LLC2 and SDLC Parameters" in this manual for more details about fine-tuning your network through the LLC2 parameters.
The routers at each end of the LLC2 session execute the full LLC2 protocol, which could result in some overhead. The decision to use local acknowledgment for LLC2 should be based on the speed of the backbone network in relation to the Token Ring speed. For LAN segments separated by slow-speed serial links (for example, 56 kbps), the T1 timer problem could occur more frequently. In such cases, it might be wise to turn on local acknowledgment for LLC2. For LAN segments separated by a T1, backbone delays will be minimal; in such cases, FST or direct should be used. Speed mismatch between the LAN segments and the backbone network is one criterion to help you decide to use local acknowledgment for LLC2.
There are some situations (such as the receiving host failing between the time the sending host sends data and the time the receiving host receives it), in which the sending host would determine, at the LLC2 layer, that data was received when it actually was not. This error occurs because the router acknowledges that it received data from the sending host before it determines that the receiving host can actually receive the data. But because both NetBIOS and SNA have error recovery in situations where an end device goes down, these higher-level protocols will resend any missing or lost data. Because these transaction request/confirmation protocols exist above LLC2, they are not affected by tight timers, as is LLC2. They also are transparent to local acknowledgment.
If you are using NetBIOS applications, note that there are two NetBIOS timers--one at the link level and one at the next higher level. Local acknowledgment for LLC2 is designed to solve link timeouts only. If you are experiencing NetBIOS session timeouts, you have two options:
Figure 70 illustrates a DLSw+ configuration with local acknowledgment.
source-bridge ring-group 10 ! dlsw local-peer peer-id 10.2.25.1 dlsw remote-peer 0 tcp 10.2.5.2 interface loopback 0 ip address 10.2.25.1 255.255.255.0 . . . interface tokenring 0 no ip address ring-speed 16 source-bridge active 25 1 10
source-bridge ring-group 12 dlsw local-peer peer-id 10.2.5.2 dlsw remote-peer 0 tcp 10.2.25.1 interface loopback 0 ip address 10.2.5.2 255.255.255.0 . . . interface tokenring 0 no ip address ring-speed 16 source-bridge active 5 1 12
Figure 71 illustrates DLSw+ configured using border peers, showing circuits to each other. Router A is configured to operate in promiscuous mode, and border peers Routers B and C forward broadcasts. This configuration reduces processing requirements in Router A (the access router) and still support any-to-any networks.
The following are configuration files for the routers in Figure 71.
hostname RouterA ! source-bridge ring group 31 dlsw local-peer peer-id 128.207.152.5 group 70 promiscuous dlsw remote peer 0 tcp 128.207.150.8 ! interface serial 0 ip unnumbered tokenring clockrate 56000 ! interface tokenring 0 ip address 128.207.152.5 255.255.255.0 ring-speed 16 source-bridge 200 13 31 source-bridge spanning ! . . . router igrp 777 network 128.207.0.0
hostname RouterB ! . . . source-bridge ring-group 31 dlsw local-peer peer-id 128.207.150.8 group 70 border promiscuous dlsw remote-peer 0 tcp 128.207.169.3 dlsw remote-peer 0 tcp 128.207.152.5 ! . . . interface serial 0 ip unnumbered tokenring 0 bandwidth 56 ! . . . interface tokenring 0 ip address 128.207.150.8 255.255.255.0 ring-speed 16 source-bridge 3 14 31 source-bridge spanning ! router igrp 777 network 128.207.0.0
hostname RouterC ! . . . source-bridge ring-group 69 dlsw local-peer peer-id 128.207.169.3 group 69 border promiscuous dlsw remote-peer 0 tcp 128.207.150.8 ! . . . interface tokenring 3/0 description fixed to flashnet ip address 128.207.2.152 255.255.255.0 ring-speed 16 multiring all ! interface tokenring 3/1 ip address 128.207.169.3 255.255.255.0 ring-speed 16 source-bridge 33 2 69 source-bridge spanning ! . . . router igrp 777 network 128.207.0.0
Figure 72 illustrates a peer group configuration that allows any-to-any connection except for Router B.
The following are configuration files for the routers in Figure 72.
hostname Router A ! . . . source-bridge ring-group 2000 dlsw local-peer peer-id 150.150.99.1 group 2 promiscuous dlsw remote-peer 0 tcp 150.150.100.1 ! interface loopback 0 ip address 150.150.99.1 255.255.255.192 ! interface serial 0 ip address 150.150.9.1 255.255.255.192 ! . . . interface tokenring 0 no ip address ring-speed 16 source-bridge 99 1 2000 source-bridge spanning ! . . . router eigrp 202 network 150.150.0.0
hostname RouterB ! . . . source-bridge ring-group 2000 dlsw local-peer peer-id 150.150.98.1 group 2 dlsw remote-peer 0 tcp 150.150.100.1 ! interface loopback 0 ip address 150.150.98.1 255.255.255.192 ! . . . interface serial 1 no ip address encapsulation sdlc no keepalive priority-group 1 clockrate 9600 sdlc role primary sdlc vmac 4000.8888.0100 sdlc address 01 sdlc xid 01 05d20006 sdlc partner 4000.1020.1000 01 sdlc dlsw 1 ! interface tokenring 0 no ip address ring-speed 16 multiring all source-bridge 98 1 2000 source-bridge spanning ! . . . router eigrp 202 network 150.150.0.0
hostname RouterC ! . . . source-bridge ring-group 2000 dlsw local-peer peer-id 150.150.100.1 group 2 border promiscuous dlsw remote-peer 0 tcp 150.150.96.1 dlsw remote-peer 0 tcp 150.150.98.1 dlsw remote-peer 0 tcp 150.150.99.1 ! interface loopback 0 ip address 150.150.100.1 255.255.255.192 ! . . . interface serial 7 ip address 150.150.9.2 255.255.255.192 clockrate 56000 ! interface serial 8 ip address 150.150.10.2 255.255.255.192 ! interface serial 9 ip address 150.150.8.2 255.255.255.192 ! interface tokenring 0 no ip address ring-speed 16 multiring all source-bridge 500 1 2000 ! router eigrp 202 network 150.150.0.0
hostname RouterD ! . . . source-bridge ring-group 2000 dlsw local-peer peer-id 150.150.96.1 group 1 border promiscuous dlsw remote-peer 0 tcp 150.150.97.1 dlsw remote-peer 0 tcp 150.150.100.1 ! interface loopback 0 ip address 150.150.96.1 255.255.255.192 ! . . . interface serial 1/0 ip address 150.150.8.1 255.255.255.192 clockrate 56000 ! interface serial 1/1 ip address 150.150.16.1 255.255.255.192 ! . . . interface tokenring g0/0 ip address 150.150.2.1 255.255.255.192 ring-speed 16 source-bridge 96 1 2000 source-bridge spanning ! interface tokenring 0/1 ip address 150.150.13.1 255.255.255.192 no ip address ring-speed 16 source-bridge 92 1 2000 source-bridge spanning ! . . . router eigrp 202 network 150.150.0.0
hostname RouterE ! . . . source-bridge ring-group 2000 dlsw local-peer peer-id 150.150.97.1 group 1 promiscuous dlsw remote-peer 0 tcp 150.150.96.1 ! interface loopback 0 ip address 150.150.97.1 255.255.255.192 ! interface serial 0 mtu 1400 ip address 150.150.16.2 255.255.255.192 ! . . . interface tokenring 0 no ip address no ip route-cache ring-speed 16 source-bridge 97 1 2000 source-bridge spanning ! . . . router eigrp 202 network 150.150.0.0
In the following example all devices are type PU 2.0:
interface serial 2 mtu 4400 no ip address encapsulation sdlc no keepalive clockrate 19200 sdlc role primary sdlc vmac 4000.1234.5600 sdlc N1 27200 sdlc address C1 sdlc xid C1 05DCCCC1 sdlc partner 4001.3745.1088 C1 sdlc address C2 sdlc xid C2 05DCCCC2 sdlc partner 4001.3745.1088 C2 sdlc dlsw C1 C2
The following example shows mixed PU 2.0 and PU 2.1 devices:
interface serial 2 mtu 4400 no ip address encapsulation sdlc no keepalive clockrate 19200 sdlc role primary sdlc vmac 4000.1234.5600 sdlc N1 27200 sdlc address C1 sdlc xid C1 05DCCCC1 sdlc partner 4001.3745.1088 C1 sdlc address C2 xid-poll sdlc xid C2 05DCCCC2 sdlc partner 4001.3745.1088 C2 sdlc dlsw C1 C2
In the following example all devices are type PU 2.1 (Method 1):
interface serial 2 mtu 4400 no ip address encapsulation sdlc no keepalive clockrate 19200 sdlc role primary sdlc vmac 4000.1234.5600 sdlc N1 27200 sdlc address C1 xid-poll sdlc xid C1 05DCCCC1 sdlc partner 4001.3745.1088 C1 sdlc address C2 xid-poll sdlc xid C2 05DCCCC2 sdlc partner 4001.3745.1088 C2 sdlc dlsw C1 C2
In the following example all devices are type PU 2.1 (Method 2):
interface serial 2 mtu 4400 no ip address encapsulation sdlc no keepalive clockrate 19200 sdlc role prim-xid-poll sdlc vmac 4000.1234.5600 sdlc N1 27200 sdlc address C1 xid-poll sdlc xid C1 05DCCCC1 sdlc partner 4001.3745.1088 C1 sdlc address C2 sdlc xid C2 05DCCCC2 sdlc partner 4001.3745.1088 C2 sdlc dlsw C1 C2
DLSw+ also supports Ethernet media. Except for configuring for a specific media, in this case Ethernet, the configuration is similar to other DLSw+ configuration (see Figure 73).
The following are the configuration files for the routers in Figure 73.
hostname RouterA ! . . . source-bridge ring-group 31 dlsw local-peer peer-id 128.207.111.1 dlsw remote-peer 0 tcp 128.207.1.145 lf 1500 dlsw bridge-group 5 ! interface Ethernet 0 ip address 128.207.111.1 255.255.255.0 bridge-group 5 ! . . bridge 5 protocol ieee ! . .
hostname RouterB ! . . . source-bridge ring-group 500 dlsw local-peer peer-id 128.207.1.145 dlsw remote-peer 0 tcp 128.207.111.1 lf 1500 dlsw bridge-group 5 . . . interface ethernet 1/2 ip address 128.207.1.145 255.255.255.0 bridge-group 5 . . . interface tokenring 2/0 no ip address ring-speed 16 multiring all source-bridge 7 1 500 source-bridge spanning ! . . . router igrp 777 network 128.207.0.0
DLSw+ provides media conversion between local or remote LANs and SDLC. For additional information about configuring SDLC parameters, refer to the chapter "Configuring LLC2 and SDLC Parameters."
Figure 74 illustrates DLSw+ with SDLC encapsulation. For this example, 4000.1020.1000 is the MAC address of the FEP host (PU4). 1000.5aed.1f53 is the MAC address of the AS/400 host, which is defined as Node Type 2.1. Router B serves as the primary station for the remote secondary stations 01. Router B can serve as either primary station or secondary station to remote station D2.
The following is the configuration file for Router A.
hostname RouterA ! . . . source-bridge ring-group 2000 dlsw local-peer peer-id 150.150.10.2 dlsw remote-peer 0 tcp 150.150.10.1 ! . . . interface serial 8 ip address 150.150.10.2 255.255.255.192 clockrate 56000 ! . . . interface tokenring 0 no ip address ring-speed 16 source-bridge 500 1 2000 source-bridge spanning ! . . . router eigrp 202 network 150.150.0.0
hostname RouterB ! . . . source-bridge ring-group 2000 dlsw local-peer peer-id 150.150.10.1 dlsw remote-peer 0 tcp 150.150.10.2 ! . . . interface serial 0 ip address 150.150.10.1 255.255.255.192 ! interface serial 1 description PU2 with SDLC station role set to secondary no ip address encapsulation sdlc no keepalive clockrate 9600 sdlc role primary sdlc vmac 4000.9999.0100 sdlc address 01 sdlc xid 01 05d20006 sdlc partner 4000.1020.1000 01 sdlc dlsw 1 ! interface serial 2 description Node Type 2.1 with SDLC station role set to negotiable or primary encapsulation sdlc sdlc role none sdlc vmac 1234.3174.0000 sdlc address d2 sdlc partner 1000.5aed.1f53 d2 sdlc dlsw d2 ! interface tokenring 0 no ip address early-token-release ring-speed 16 multiring all source-bridge 100 1 2000 source-bridge spanning ! interface tokenring 1 no ip address ring-speed 16 multiring all source-bridge 400 1 2000 source-bridge spanning ! router eigrp 202 network 150.150.0.0
Frame Relay support extends the DLSw+ capabilities to include Frame Relay in direct mode. Frame Relay support includes permanent virtual circuit capability and provides a newly supported DLC. DLSw+ runs over Frame Relay without LACK. It supports the Token Ring-to-Token Ring connections similar to FST and other direct DLCs. Figure 75 illustrates a DLSw+ configuration over Frame Relay.
The following configuration examples are based on Figure 75. The Token Rings in the illustration are Ring 2.
source-bridge ring-group 100 dlsw local-peer peer-id 1.1.1.1 dlsw remote-peer 0 frame-relay interface serial 0 30 ! interface tokenring 0 ring-speed 16 source-bridge active 1 1 100 ! interface serial 0 mtu 3000 no ip address encapsulation frame-relay frame-relay lmi-type ansi frame-relay map llc2 30
source-bridge ring-group 100 dlsw local-peer peer-id 1.1.1.2 dlsw remote-peer 0 frame-relay interface serial 0 30 ! interface tokenring 0 ring-speed 16 source-bridge active 2 1 100 ! interface serial 0 mtu 3000 no ip address encapsulation frame-relay frame-relay lmi-type ansi frame-relay map llc2 30
The following three examples describe QLLC support for DLSw+.
In this configuration, DLSw+ is used to allow remote devices to connect to a DLSw+ network over an X.25 public packet-switched network.
In this example, all QLLC traffic is addressed to destination address 4000.1161.1234, which is the MAC address of the FEP.
The remote X.25-attached 3174 is given a virtual MAC address of 1000.0000.0001. This virtual MAC address is mapped to the X.121 address of the 3174 (31104150101) in the X.25 attached router.
interface serial 0 encapsulation x25 x25 address 3110212011 x25 map qllc 1000.0000.0001 31104150101 qllc dlsw partner 4000.1611.1234
In this configuration, a single 3174 needs to communicate with both an AS/400 and a FEP. The FEP is associated with subaddress 150101 and the AS/400 is associated with subaddress 151102.
If an X.25 call comes in for 33204150101, the call is mapped to the FEP and forwarded to mac address 4000.1161.1234. The 3174 appears to the FEP as a Token Ring-attached resource with MAC address 1000.0000.0001. The 3174 uses a source SAP of 04 when communicating with the FEP, and a source SAP of 08 when communicating with the AS/400.
interface serial 0 encapsulation x25 x25 address 31102 x25 map qllc 1000.0000.0001 33204 qllc dlsw subaddress 150101 partner 4000.1161.1234 qllc dlsw subaddress 150102 partner 4000.2034.5678 sap 04 08
In this example, two different X.25 resources want to communicate over X.25 to the same FEP.
In the router attached to the X.25 network, every X.25 connection request for X.121 address 31102150101 is directed to DLSw+. The first SVC to be established will be mapped to virtual MAC address 1000.0000.0001. The second SVC to be established will be mapped to virtual MAC address 1000.0000.0002.
interface serial 0 encapsulation x25 x25 address 31102 x25 map qllc 33204 x25 map qllc 35765 qllc dlsw subaddress 150101 vmacaddr 1000.0000.0001 2 partner 4000.1611,1234
|
|