This chapter describes the Data Link Switching (DLSw) , and the implementation of the Data Link Switching (DLSw) protocol. Changes made at the Config> prompt do not take effect immediately, but become part of the SRAM configuration used for subsequent restarts of the router. For a description of temporary, but immediate, configuration changes, see page ***.
The 2216 offers a wide range of function that enables you to integrate Systems Network Architecture (SNA) and Network Basic Input/Output System (NetBIOS) traffic into heterogeneous, wide area networks.
The following sections explain how to configure your router for DLSw:
DLSw is a forwarding mechanism for the LLC2, SDLC, and QLLC (SNA over X.25) protocols. It relies on the bridging function of the router, the Switch-to-Switch protocol (SSP), and TCP/IP to provide a reliable transport of SNA traffic over an internet. DLSw does not provide full routing capabilities, but it provides switching at the data link layer. Rather than bridging LLC2 frames, DLSw encapsulates their data in TCP frames and forwards the resulting messages over the WAN link to a peer DLSw router for delivery to their intended end-station addresses.
A number of ATM to Frame Relay interworking products allow traffic to be shipped on networks that consist of both Frame Relay and ATM devices. Typically, the Frame Relay devices operate at T1 speeds (1.544 Mbps) while ATM speeds are typically one or two orders of magnitude faster. DLS can play an important role in accommodating this speed differential.
DLS is an alternative to bridging SNA traffic. If you have two high speed campus networks that are attached by a slow T1 WAN link, you may decide between bridging and DLS. The unfortunate side effect of bridging is that all broadcast traffic will be forwarded across the T1 link, using up valuable bandwidth. DLSw, on the other hand, terminates the sessions locally, and does not use the WAN for broadcast traffic, resulting in more efficient use of the slower WAN link and ultimately better performance.
LLC2, SDLC, and QLLC are connection-oriented protocols. DLSw provides the dynamic characteristics of routable protocols and preserves both end-to-end reliability and control features for effective communication.
Figure 43 illustrates the traditional approach to bridging LLC2 frames across WAN links. With the traditional approach, network delays occur much more frequently in the WAN than on a LAN. These delays can result from simple network congestion, slower line speeds, or other factors. Whatever the cause, these delays increase the possibilities of session timeouts and of data not reaching intended destinations.
Also, LAN protocols, like LLC2, use significantly shorter retransmit/response times than the WAN's. Thus, end-to-end connections across a WAN link are extremely difficult to maintain, and session timeouts are much more probable.
In addition to session timeouts, there is a significant problem when data is delayed while crossing the WAN. A sending station can resend data that is delayed (but not lost); this can result in LLC2 end stations receiving duplicate data. Duplicate data can cause confusion for LLC2 procedures on the receiving side which can, in turn, result in inefficient use of the WAN link.
Figure 43. Traditional Approach to Bridging Across WAN Links
|
To reduce the chance of session timeouts, and to maintain the appearance of end-to-end connectivity for sending stations, DLSw works by terminating or "spoofing" LLC2 connections at the local router. Upon receiving an LLC2 frame, the router sends an acknowledgement to the sending station. This acknowledgment tells the sender that data that was previously transmitted has been received.
The acknowledgment prevents the station from retransmitting. From this point forward, assuring that data gets through is the responsibility of the DLSw software. The software accomplishes this by encapsulating the data in routable IP frames, then transports them (via TCP) to a DLSw peer. The peer DLSw router strips away the TCP headers, determines the address of the data's intended recipient, and establishes a new LLC2 connection with that end station.
Figure 44 illustrates this relationship between two DLSw peer routers, each attached to a Token-Ring Network.
Figure 44. Data Link Switching over the WAN
 |
Because DLSw terminates the DLC connection at the local device (see Figure 44 ), it is especially effective at eliminating SNA session timeouts and reducing WAN overhead on shared circuits. The protocol has these main benefits:
The following sections address the use of various DLSw features:
DLSw uses TCP to provide reliable, sequenced delivery of end-user information across an IP network. DLSw message formats allow multiple end-station sessions, or circuits, to be carried across a single TCP transport connection. There are two ways to configure which DLSw-capable routers should have TCP transport connections between them to allow the desired end-station connectivity:
To configure a neighbor IP address at a router, use the add tcp command once for each of that router's neighbors. It is not required for each of the two routers in a neighbor relationship to configure the other's IP address. Only one router needs to have the other's address, and the other router can be configured to accept dynamic TCP connections from non-configured neighbors. Use the enable dynamic-neighbors command to configure this behavior, and use the set dynamic-tcp command to configure the parameters used for these dynamic connections. Enabling dynamic TCP connections can be particularly useful for "hub" routers that you do not want to reconfigure when you set up new remote branch office routers that connect to the hub.
In addition to the IP address, the add tcp command enables you to configure a number of parameters for the neighbor and the TCP connection itself. The Keepalive parameter controls whether the TCP layer occasionally polls its peer TCP layer in the absence of any user data traffic. Enabling Keepalive messages results in more timely notification of TCP connection failure, but can increase WAN overhead and cause the reporting of failures that could have been successfully re-routed.
The NetBIOS SessionAlive Spoofing parameter controls whether or not the NetBIOS SessionAlive frames are forwarded to the DLSw peer. This parameter is important when NetBIOS sessions have been established across DLSw peers over an ISDN link. If this parameter is enabled and the Keepalive parameter is disabled, then no DLSw traffic will pass between the DLSw partners if idle NetBIOS sessions are established between the DLSw peers. This would allow an underlying ISDN connection to terminate while maintaining an idle NetBIOS session over DLSw.
The connectivity setup type parameter controls when DLSw brings up and takes down the TCP connection. When one or both neighbors have the CST set to active, DLSw attempts to bring up the connection at system startup and at regular intervals until it is up. Once the TCP connection is established, DLSw attempts to keep it up at all times by trying to bring it back when it fails. If both neighbors have set the CST to passive, DLSw brings up the TCP connection only when it is actually needed to establish a DLSw end-station session. When the last DLSw session ends and no new session is started in a configurable period of time (the neighbor inactivity timer), DLSw disconnects the TCP connection and frees the associated internal resources.
To avoid configuring neighbor IP addresses in one or both of every pair of neighbor routers, set up DLSw to use multicast IP to discover the IP address of the neighbors to which it should connect. Use the join-group command at each router to make it a member of one or more DLSw groups and to assign a role within the group. The role may be "client", "server", or "peer". DLSw uses multicast IP to discover the IP addresses of all DLSw routers that are members of the same groups and that have the complementary role (that is, clients discover servers within a group and vice versa, and peers discover other peers).
When DLSw learns the IP addresses of its neighbors in each group, it uses the "connectivity setup type" of its membership in the group and that of each group neighbor to determine when a TCP connection to that neighbor should be brought up. As with configured individual neighbors, when either CST is active, DLSw brings up the TCP connection to the discovered neighbor as soon as possible and attempts to keep the connection up at all times. When both CSTs are passive, DLSw brings up the TCP connection only when it is required to carry DLSw sessions, and uses the neighbor inactivity timer to disconnect the TCP connection when it is not being used.
DLSw uses multicast IP services for more than discovering the IP addresses of neighbor routers. It uses these same services to forward DLSw messages searching for end-station resources (for example, MAC addresses or NetBIOS names), and to forward NetBIOS datagram traffic. This feature can dramatically increase the scalability of DLSw networks because there is no need for static TCP connections to all neighbors to carry search and datagram messages. Also, DLSw does not need to send a different copy of each broadcast message on every TCP connection, but can send a single copy that is replicated within the multicast IP infrastructure.
To use multicast IP for exploration and frame forwarding, issue the join-group command and set the connectivity setup type to passive. DLSw automatically determines which other group members are multicast-capable, and which are using their group membership simply to discover neighbor IP addresses and bring up static TCP connections. DLSw simultaneously works with both types of neighbors when searching for end-station resources, forwarding NetBIOS datagrams, and establishing DLSw sessions.
When you issue the join-group command, you select one of two addressing methods to describe the group you are joining. When you provide a group ID and the client/server/peer role as previously described, the router constructs the corresponding multicast IP addresses and can communicate with other IBM routers that use this method. You may also choose to directly specify the multicast IP addresses to be used and whether each address should be read from, written to, or both. This method was introduced to support RFC 2166 and allow multicast interoperability with other DLSw Version 2 compliant products.
A given router may be a member of traditional groups and concurrently read from and write to DLSw Version 2 multicast addresses. The new multicast addresses may also be used for neighbor discovery, but you must ensure that for every pair of routers intended to form a TCP connection, one router has a connectivity setup type of active on a write-capable address on which the other router is reading. Whether you are doing neighbor discovery or not, specifying multicast addresses requires more careful configuration planning to ensure reachability than using group IDs and the client/server/peer model.
If the amount of explorer traffic being forward between DLSw neighbors is too high, there are some capabilities to reduce this explorer traffic.
The MAC address lists operate in a similar manner as the NetBIOS name lists. For information about NetBIOS Name Lists, see "NetBIOS Name Lists".
DLSw supports SNA and NetBIOS end stations attached to the router via LAN and remote-bridging WAN interfaces. These end stations and the router are both running ISO 8802-2 (IEEE 802.2) standard Logical Link Control (LLC) to provide data sequencing and reliable delivery. The router currently supports bridged LLC traffic over the following interface types, and all can be used for traffic flowing between DLSw and LLC end stations:
Because DLSw uses the MAC and SAP addresses available in bridged frames, there is no need to configure in DLSw any information about individual LLC end stations. DLSw receives broadcast traffic sent by these end stations, and uses normal LAN/bridge broadcast methods to make initial contact with them. You must, however, configure the bridging support for any interface that DLSw is to use, and configure within DLSw the SAPs that it is to use on each interface.
DLSw supports SDLC end stations that may be SNA PU types 1, 2.0, 2.1, 4 (for NCP-NCP traffic), or 4/5 (a host or NCP performing the SNA boundary function). The router can serve in either a primary or secondary SDLC link station role, based on the role configured for the SDLC interface, or based on SNA XID negotiation. In the primary role, the router can support multiple SDLC devices of differing PU types on the same physical multipoint SDLC line. In the secondary role, the router can represent multiple SDLC secondary stations on a single physical SDLC interface. It also supports the IBM 3174 Group Poll function in the secondary role.
| Note: | DLSw supports SDLC PU1 devices communicating with SDLC-attached or LAN-attached devices supporting PU1 devices (for example, 3745). But it does not support SDLC PU1 devices communicating with devices not supporting PU1 devices (for example, AS/400). |
Figure 45. Example DLSw SDLC Configurations
 |
Figure 45 illustrates some of the SDLC configurations supported by DLSw, and shows a subset of the DLSw configuration required to map between SDLC and DLSw (MAC and SAP) addresses. The diagram shows both local (within a single router) and remote (across two routers and an IP network) DLSw sessions.
The following DLSw sessions are configured:
For NCP A to be able to communicate with these 4 PUs, Router A must have a secondary link station configured on Interface 1 for each PU. This interface should be configured in SDLC as secondary, full-duplex, and point-to-point. Group poll is recommended whenever there are several secondary stations on the same interface, to reduce non-productive polling.
In this example, NCP A communicates to PC C via SDLC station address 01, to the 3174 via address 02, to PC A via address 03, and to PC B via address 04. Note that the PC A and C sessions both involve SDLC-to-LLC conversion, in a local and remote configuration, respectively. The session to PC B is a local SDLC-to-SDLC session, which may be unusual.
For the secondary link stations defined in Router A, a PU type of 5 indicates that the SDLC device is a host (here front-ended by a controller) performing the SNA BNN function to a downstream PU2.0 device. A PU type of 2 here indicates that the SDLC host/FEP is acting as a T2.1 node communicating with another T2.1 node in the DLSw network.
Here, these devices are to function as T2.1 nodes and the SDLC links on their respective routers are configured as negotiable (T2.1 nodes are also supported on fixed-role links, and DLSw restricts role negotiation accordingly). The stations will perform full XID negotiation, including role determination and SDLC address resolution (if the router and the end station on the same link is each configured with different SDLC station addresses). Note that there is no relationship in remote SDLC-SDLC configurations between the SDLC station addresses used on the two different SDLC links. Remote SDLC-to-LLC sessions are also supported between T2.1 devices.
NCP B is configured as PU Type 4, indicating that this DLSw session is to carry INN subarea traffic between NCPs, and not BNN traffic from an NCP to a PU 2 device. The example shows a remote SDLC-to-LLC session, but like-to-like sessions are also supported. DLSw INN function does not support multilink TGs or the NCP remote load/dump functions.
DLSw configuration provides a mapping between single-byte SDLC station addresses and the MAC addresses and SAPs by which DLSw identifies end stations. The Source MAC address for an SDLC station represent the SDLC device to the rest of the DLSw network. It is the source address for frames coming from the device, and the destination address for frames going to the device. A Source MAC address is required for the SDLC device to be able to communicate through DLSw.
The Destination MAC address specifies the end station in the DLSw network to which this SDLC device should be connected when it starts to communicate. SDLC devices that are always to be the target of new sessions and never the initiator should have a zero destination MAC address. When the router is configured as a secondary link station, it is important to define a destination MAC address so that a host connect-out will be successful. This is because a secondary link station cannot initiate a contact to the host on behalf of a remote DLSw end station connecting in, but must wait to be polled. Note that when the remote DLSw end station is itself SDLC (for example, the 3174 on Router B in Figure 45) and is paired with a local secondary station, the remote station may have a zero destination MAC address to reflect this dependency on a host connect-out.
To use DLSw over an SDLC interface, you configure the address mapping as part of DLSw configuration, and you also configure some information as part of SDLC configuration. As a minimum in SDLC, you must set the interface to be SDLC and configure other interface-level parameters such as the link role. SDLC interface parameters provide default values for all SDLC link stations on that interface, but if you wish to have unique values for a station, you can configure individual SDLC station information.
The address pair interface number, SDLC station address is the common key that links DLSw address-mapping information to the station-level configuration in SDLC. Router software make this association at initialization time. If DLSw attempts to initialize a link station whose SDLC station address is not configured in SDLC on the interface that DLSw specifies, SDLC creates a link station definition dynamically and uses the parameter defaults defined in SDLC for that interface.
SDLC Relay is a router function that encapsulates whole SDLC frames in IP packets, which are then routed to another router that also supports SDLC Relay. The destination router strips off the IP header and delivers the SDLC frames unmodified onto a destination SDLC link.
This function differs from DLSw SDLC support in the following ways:
You must use DLSw when:
You must use SDLC Relay when:
In other SDLC-SDLC configurations, choose the function that best meets your requirements for ease of configuration, WAN utilization, and support for your current end station environment. For more information on SDLC Relay, refer to Software User's Guide
QLLC is a protocol that operates above the packet layer protocol of X.25 to provide an SDLC-like station appearance to SNA devices on X.25 networks. QLLC supports a single SNA PU per virtual circuit (either PVC or SVC). X.25 channel multiplexing provides for the attachment of many virtual circuits or PUs through a single physical interface to the X.25 network. QLLC architecture defines primary, secondary, and peer station roles, but these are less important than in SDLC because they do not affect the transmission of end-user data. The data for all virtual circuits on an interface flows on a single LAPB layer-2 link connection, which operates in a balanced mode. Either side has permission to send at all times while the link is connected.
DLSw supports QLLC end stations that may be SNA PU types 2.0, 2.1, 4 (for NCP-NCP traffic), or 4/5 (a host or NCP performing the SNA boundary function). End stations may be attached via configured PVCs, configured SVCs, or dynamic SVCs resulting from an incoming call. The router can resolve to either a primary or secondary QLLC link station role, based on the role configured for the X.25 interface and based on SNA XID negotiation. Different PU types may co-exist on different virtual circuits within the same physical interface, but only a single link station role is supported per interface.
Figure 46. Example DLSw QLLC Configurations
 |
Figure 46 illustrates some of the QLLC configurations supported by DLSw, and shows a subset of the DLSw configuration required to map between QLLC and DLSw (MAC and SAP) addresses. The diagram shows both local (within a single router) and remote (across two routers and an IP network) DLSw sessions. No QLLC-to-SDLC pairings are shown, but these are supported in both local and remote configurations.
The following DLSw sessions are configured:
NCP A is attached to Interface 1 on Router A via 2 PVCs and 2 SVCs, each virtual circuit representing one PU. PVCs are addressed within an interface by a Logical Channel Number, and SVCs by the DTE address (phone number) of the attached X.25 device. As with SDLC, DLSw configuration maps these "native" DLC addresses (LCN or DTE address) to DLSw addresses (MACs and SAPs).
In this example, NCP A communicates with the 3174 (remote QLLC-QLLC) via PVC 03, and with PC B (local QLLC-QLLC) via PVC 04. These LCNs are actually local to Router A; NCP may use different LCNs for its corresponding PVCs into the X.25 network. Router A connects NCP A with PC C (remote QLLC-LLC) and with PC A (local QLLC-LLC) using two SVCs between the DTE address 3720000 for NCP A and the DTE address for interface 1 on Router A. Since Router A needs to be able to accept calls from NCP A, it has Interface 1 enabled for incoming calls to DLSw. NCP A uses Connection IDs, discussed below, to connect out to PCs A and C.
In Router B, PC C is not configured because it is LLC/LAN-attached. The 3174 is connected via Interface 1 LCN 07, which has no relation to the Interface or LCN number used at Router A.
In addition to NCP A, the AS/400 is also attached to Router A via Interface 1. Unlike SDLC, there is no performance advantage to limiting the number of stations on a given interface. There can be multiple stations on a link regardless of the link role. If the role is negotiable and the stations are T2.1 or PU4 nodes, each station can negotiate independently to become primary or secondary.
The AS/400 has no destination MAC address configured in Router A, and therefore cannot connect out to the 5494. The 5494 is not configured in Router B, and will therefore be a dynamic SVC. The 5494 uses a Connection ID to indicate that it wants to be connected to the AS/400. Router B has Interface 1 enabled for incoming calls to DLSw so that it can receive calls from the 5494.
NCP B is configured as PU Type 4, indicating that this DLSw session is to carry INN subarea traffic between NCPs, and not BNN traffic from an NCP to a PU 2 device. The example shows a remote QLLC-to-LLC session, but like-to-like sessions and sessions involving SDLC are also supported. DLSw INN function does not support multilink TGs or the NCP remote load/dump functions.
DLSw provides a mapping between the MAC/SAP pairs used to address end-station entities in the DLSw domain, and the interface, LCN (PVC) or interface, DTE address (SVC) pairs used in the X.25 domain. This mapping takes place at connection-establishment time, but uses addressing information configured in the router and in end station products.
DLSw receives a CUR_ex or CUR_cs message addressed to a particular target MAC and SAP. It searches among its QLLC end stations for one whose SMAC and SSAP (SAP is only checked for CUR_cs) match this target MAC/SAP. There should be either one or no matches, because SMACs are unique within the router.
If a match is found, DLSw initiates connection establishment with the QLLC station using the corresponding interface and LCN for a PVC, or the interface and phone number for an SVC. DLSw can place multiple outgoing calls to the same DTE address using a single QLLC station (SVC) definition. This allows many DLSw devices to connect to the same destination with a minimum of configuration effort.
For PVCs, QLLC receives a frame that starts circuit establishment from the attached end station. QLLC and DLSw match the interface and LCN on which the frame was received to a QLLC station list entry. Either one or no matches are found, because LCNs must be unique within an interface. If there is no match or the entry has no DMAC/DSAP defined, the connect-in fails. Otherwise a connection is initiated to the defined DMAC/DSAP. The origin MAC/SAP for the connection is the SMAC/SSAP from the same list entry.
For SVCs, DLSw derives MAC/SAP addresses using either the X.25 calling party address, or a connection id (bytes 4-11) in the call user data field of the received Call_Request packet. If the calling party address is available, DLSw first checks it against all its configured SVC DTE addresses for the called interface. Either one or no matches are found, because DTE addresses must be unique within an interface. If a match is found and the QLLC station list entry has a non-zero DMAC/DSAP, DLSw uses this DMAC/DSAP as the target address for connection establishment. The origin MAC/SAP for the connection is the SMAC/SSAP from the same list entry.
If no calling party address is available, or there is one but it matches an entry with no defined DMAC/DSAP, or it does not match any defined DTE address for the called interface, DLSw checks whether any connection id (CID) received in the Call_Request packet matches any defined in DLSw QLLC Destination records. The CID is interpreted as an EBCDIC alphanumeric string of up to 8 characters.
If there is a CID match, DLSw uses the associated DMAC/DSAP in the Destination Record as the destination address for circuit establishment. If there was also a calling party address match (with no defined DMAC/DSAP), DLSw uses the SMAC/SSAP from the matched station list entry. Otherwise, DLSw dynamically assigns the SMAC and SSAP. For the SMAC, DLSw chooses the next available (round robin) MAC address in the range defined by the global DLSw configuration parameters QLLC base MAC address and Max dynamic addresses. The dynamically-selected SSAP is always 0x04.
If there is no calling party address or connection id match, DLSw does not take the call. Note that CIDs are the only way a single calling party address can place calls to multiple destinations.
APPN and DLSw may both accept QLLC calls from the same calling party address. DLSw gets first access to the call because it is more restrictive in what calls it will accept. If DLSw finds no calling party or connection id match, DLSw does not clear the call, but allows it to be presented to APPN.
For an incoming call to be accepted, then, either the calling party address or a connection id must be defined to DLSw. While this is required primarily to provide address mapping, it also provides an element of security against incoming calls from unauthorized parties. Other possible security measures include not enabling an interface for incoming calls to DLSw, and setting the number of possible dynamic source MAC addresses to zero. The former will prevent all incoming calls on that interface, even from DTE addresses configured in DLSw. The latter will prevent only dynamic calls in from non-configured DTE addresses.
To allow any X.25 calling party (regardless of DTE address or CID ) to be accepted by DLSw and matched to a specific DMAC and DSAP (one per box), you can configure a QLLC Destination record with a CID value of "ANYCALL" and the desired DMAC and DSAP. DLSw dynamically assigns the SMAC and SSAP. If this feature is used, DLSw accepts all calls. No calls are presented to APPN and all security features associated with address mapping are bypassed.
To use DLSw's QLLC support over a given X.25 interface, you must configure the address mapping as part of DLSw configuration, and you must also configure the following information as part of X.25 interface configuration. See "Configuring X.25 Interfaces" for an example of these steps, and refer to the chapter "Using the X.25 Network Interface" in Nways Multiprotocol Access Services Software User's Guide for additional information.
Unlike SDLC, X.25 has no capability to dynamically create a link station (virtual circuit) definition based on information configured in DLSw.
The X.25 Transport Protocol (XTP) is a router function that takes packets from X.25 virtual circuits, and transports them via TCP/IP to another router that also supports XTP. The destination router then removes XTP header information and delivers the packets onto a destination X.25 virtual circuit.
This function compares with DLSw QLLC support in the following ways:
You must use DLSw when:
You must use XTP when:
In other QLLC-to-QLLC configurations, choose the protocol that best matches the requirements of your network. For more information on XTP, refer to the chapter entitled "Using, Configuring, and Monitoring XTP" in the Software User's Guide.
DLSw has an internal interface with APPN that connects APPN to end stations attached to remote DLSw routers. The remote routers need not support APPN, which may reduce the amount of memory they require. As shown in Figure 47, this internal interface is the equivalent of collapsing a DLC connection (for example, LLC over a LAN) into a single software interface.
Figure 47. APPN-to-DLSw Software Interface
 |
APPN cannot use the DLSw software interface to reach end stations that are locally attached to the APPN/DLSw router. It must use its native DLC support to communicate with these devices.
No additional DLSw configuration is required to support the APPN interface. You should enable TCP Keepalive messages to the DLSw remote router, to enable detection of the loss of the link stations on the DLSw port. You must configure APPN to use a DLSw virtual interface to reach a given end station. For information on implementing APPN using DLSw, refer to the chapter on configuring APPN in Protocol Configuration and Monitoring Reference Volume 2.
Many DLSw network configurations provide multiple paths from an origin DLSw router to destination end-stations by making the end-stations local to more than one destination DLSw router. To provide additional control over which remote DLSw router are used for new circuits, you can assign a priority (high, medium, or low) to each defined neighbor. Although the allowable values are similar, neighbor priority is not the same as priorities for balancing SNA and NetBIOS traffic that is discussed in "Balancing SNA and NetBIOS Traffic".
For neighbor priority, you assign a priority when you define a neighbor using the add tcp or join group commands. A group's priority is inherited by all transport connections brought up within that group.
When DLSw is originating a circuit and finds that the destination MAC address or NetBIOS name is reachable through multiple remote DLSw routers, it establishes the circuit through the one of those neighbors that has the highest priority. If there are multiple remote routers that share this highest priority, DLSw uses a "round-robin" method of allocating new circuits among those routers.
Using neighbor priority, you can establish a primary/backup relationship among remote routers. A lower priority router is not used unless the higher priority router becomes unavailable. In addition, the round-robin method provides for load balancing among routers of equal priority.
Notes:
Thus, the first response to the NetBIOS explorer message is saved. This neighbor is used to bring up this NetBIOS circuit, and a response is sent to the original NetBIOS frame that was received. In the meantime, subsequent responses to the NetBIOS explorer message are used to update the NetBIOS name cache.
It is possible to disable the neighbor priority feature for all MAC addresses or for certain sets of MAC addresses. To disable it for all MAC addresses, set the wait neighbor priority timer to 0. To disable it for a set of MAC addresses, create a MAC cache explorer override and set its wait neighbor priority timer to 0.
If the neighbor priority feature is disabled, the DSLw partner information is not cached for the MAC address. SNA and NetBIOS explorers are always sent to all applicable DLSw partners and the first DSLw partner to respond is used to establish the DLSw session (regardless of its priority).
With the introduction of DLSw support for NetBIOS traffic, you need to control the mix of SNA and NetBIOS traffic within DLSw transport connections. Without this control, NetBIOS file transfers have a tendency to shut out interactive SNA traffic for undesirably long periods of time, especially if the TCP connections are running over relatively slow WAN links. You can control this traffic mix using configuration parameters of the set priority command. Using these parameters, you can:
To set up a ratio of SNA and NetBIOS frames, you globally select one of four priority values (critical, high, medium, or low) for each protocol. At circuit setup time, the router uses the DLSw Version 1 (RFC 1795) circuit priority mechanism to try to negotiate each new circuit's priority to the value for the protocol the circuit will be using. The DLSw router that initiates the circuit will choose the circuit priority to use. If the local DLSw router initiates the circuit, the circuit priority it chooses is based on the configured circuit priority defaults and circuit priority overrides. If the remote DLSw router initiates the circuit, the local DLSw router will notify the remote DLSw router of its need to use a circuit priority based on the configured defaults and overrides, but the remote DLSw router may choose a different value. In any event, each established circuit is assigned one of the four priorities by the router that initiated that circuit's establishment.
During periods of TCP congestion, the router queues frames (from circuits that have data to transmit) into one of four queues - one queue for each possible circuit priority. The frames are queued FIFO within each priority. To feed the TCP transmit process, the router selects frames from each priority queue as dictated by the "message allocation by priority" parameter. This defaults to 4/3/2/1, meaning that at most, four messages are taken from the critical priority queue, followed by at most three from the medium priority queue, and so on. If a queue is empty, it misses its turn in the cycle.
To prevent a single large NetBIOS frame from dominating a slow link for a long time, you can use the "NetBIOS maximum frame size" parameter to provide an upper limit to the size of a single NetBIOS frame. This value is passed to both NetBIOS end-stations during circuit establishment using the Largest Frame (LF) bits in the source-routing MAC header. Source-routing NetBIOS end-stations should observe the LF values and not generate frames larger than the specified value.
There are four default circuit priorities that can be configured:
These different values allow different ratios of SNA and NetBIOS and explorer and session traffic to be assigned.
There may be cases where you want to assign a certain circuit priority to specific traffic. For example, you might want to make traffic destined for a certain SNA MAC address higher priority than all other traffic. This can be accomplished using circuit priority overrides (add priority) command. This enables an explorer and session circuit priority to be assigned to a specific range of source MAC addresses and SAPs and destination MAC addresses and SAPs. These circuit priority overrides are evaluated in the order in which they are configured. The circuit priority is set to the value in the first circuit priority override match found. If no circuit priority override match is found, the default circuit priority is used.
The following sections explain the setup procedures for DLSw:
In addition, a sample DLSw configuration with explanatory notes has been included (see Figure 48).
To use DLSw, configure the following protocols: ASRT, IP, and
DLSw. In addition, you may need to configure the protocols listed in Table 36.
Table 36. DLSw Optional Protocols
| Optional Protocol | When Used |
|---|---|
| LLC2 | When non-default LLC2 parameters need to be used |
| SDLC | To connect to devices using SDLC |
| OSPF | For dynamic routing or to use DLSw multicast groups |
| X.25 | To connect to devices using QLLC |
The sections that follow explain how to configure these required and optional protocols in a step-by-step fashion.
When running DLSw in a 4M DRAM 2216, it may be necessary to allow more memory for DLSw by reducing the number of global packet buffers. Enter the set global command at the Config> prompt, then enter the number of global packet buffers.
Since the DLSw router appears as a bridge to attached end-stations, you need to configure source route bridging. Do this by following these steps:
Running DLSw over token ring requires that only source route bridging be present on the designated bridge port. Thus, you must disable transparent bridging. Do this with the disable transparent command. Then, issue the enable source routing command to turn on source routing for the bridge port.
Ensure that the transparent bridging is enabled on the bridge port. Issue the enable transparent command.
Create a protocol filter against the SAPs (service access points) you intend DLSw to use. If the router is performing bridging operations, plus forwarding packets via DLSw, it is essential to do this. If you do not, DLSw packets that are received by the bridge will be forwarded by DLSw and bridged by the router. The idea is to prevent DLSw packets from being forwarded (bridged) in parallel with DLSw routing.
To create a SAP filter, issue the add protocol-filter dsap 4 command at the Config ASRT> prompt.
In addition to this command, you must specify the bridge port to which it applies. This command tells the router to filter all traffic that has a DSAP of 4 except on the port designated for DLSw. (Note that this assumes you have chosen a SAP of 4 for DLSw traffic. This is something you do during the DLSw configuration.)
Source Routing Transparent Bridge Configuration
===============================================
Bridge: Enabled Bridge Behavior: Unknown
+----------------------------+
-------------------| SOURCE ROUTING INFORMATION |-------------------------------
+----------------------------+
Bridge Number: 01 Segments: 1
Max ARE Hop Cnt: 14 Max STE Hop cnt: 14
1:N SRB: Not Active Internal Segment: 0x000
LF-bit interpret: Extended
+-------------------+
-------------------| SR-TB INFORMATION |----------------------------------------
+-------------------+
SR-TB Conversion: Disabled
TB-Virtual Segment: 0x000 MTU of TB-Domain: 0
+------------------------------------+
-------------------| SPANNING TREE PROTOCOL INFORMATION |-----------------------
+------------------------------------+
Bridge Address: Default Bridge Priority: 32768/0x8000
STP Participation: IEEE802.1d
+-------------------------+
-------------------| TRANSLATION INFORMATION |----------------------------------
+-------------------------+
FA<=>GA Conversion: Enabled UB-Encapsulation : Disabled
DLS for the bridge: Enabled
+------------------+
-------------------| PORT INFORMATION |-----------------------------------------
+------------------+
Number of ports added: 1
Port: 1 Interface: 0 Behavior: SRB Only STP: Enabled
You need to configure IP so that the local DLSw router can form TCP connections to other DLSw peers. To do this:
If you want to use OSPF as your routing protocol, you need to configure it as follows:
The SDLC configuration command enables you to create or modify the SDLC interface configuration as part of the DLSw configuration process.
| Note: | If SDLC is the encapsulator for V.25bis, the physical link parameters
cannot be set at the SDLC level as they must be configured at the
V.25bis level. In this case, you must not configure the
following SDLC parameters:
|
You must configure SDLC links if you intend to support SDLC over DLSw. This section explains how to access the SDLC configuration console, and describes SDLC-related commands.
If there is an SDLC device directly connected, configure the SDLC protocol as follows:
| Note: | If you are using SDLC to connect from a PC, you must also set the encoding (NRZ/NRZI), and duplex (full/half) to match the PC's configuration. |
Configure the X.25 interface if you intend to use DLSw's support for QLLC devices. Follow these steps:
Before configuring DLSw, enter the list device command at the Config> prompt to list the interface numbers of different devices.
To configure the DLSw protocol:
This SRB segment number must be the same for all DLSw routers attached to the same LAN, and should be unique in the source route bridge domain. The bridge uses this number in the Routing Information Field (RIF) when the frames are sent on the LAN. The segment number is the key for preventing loops.
| Note: | A router can participate in a group only if its peer router is an MAS-based platform running DLSw. If you configure one DLSw router for a group, you must enable OSPF and MOSPF on all DLSw routers in the group. |
Or, if you want to support dynamic SVCs, enable X.25 interfaces for call-in with the enable qllc callin command and define DLSw destinations with the add qllc destination command.
The following sample DLSw configuration assumes that the device has not been configured for any other protocols or data-links. For this reason, the script begins at the Config (only)> prompt, rather than at Config>.
The example is based on the information shown in Figure 48.
The DLSw router being configured (R1 in the diagram) supports one LLC and one SDLC connection to its DLSw peer (R2). The TCP connection between the two routers is over serial line.
Configuring R1 for DLSw requires all of the information shown. This information includes the :
The example indicates where this information is provided in the course of the configuration procedure.
Figure 48. Sample Diagram for DLSw Configuration
 |
This section provides examples of the following:
The devices you will add are token ring, SDLC, or QLLC. You may also add Ethernet as a transparent bridge port. For purposes of illustration, this sample DLSw configuration supports SDLC, LLC, and QLLC. However, it is only necessary for an actual configuration to support one of these data-links.
In the case of SDLC and QLLC, you must explicitly set the data link, because the interface also supports other data links such as FR, X.25, and SDLC Relay.
Config (only)>set data-link sdlc 2 Config (only)>set data-link x25 3
After adding devices, you can list the devices to verify that they have been assigned to the appropriate router interfaces.
Enter the list device command at the config> prompt to display a list of the configured devices and their interface numbers.
Config (only)>list device Ifc 0 Ethernet CSR 81600, CSR2 80C00, vector 94 Ifc 1 WAN PPP CSR 381620, CSR2 380D00, vector 125 Ifc 2 WAN SDLC CSR 81640, CSR2 80E00, vector 92 Ifc 3 WAN X.25 CSR 81620, CSR2 80D00, vector 93 Ifc 4 WAN Frame Relay CSR 381640, CSR2 380E00, vector 124 Ifc 5 Token Ring CSR 600000, vector 95
Notice that this list command shows that a token-ring device has been assigned to interface 5.
Configure the token-ring setup. 16 Mbps is usually used with UTP cables, so this is done here. The list command shown in these procedures is not required either at this point, or at any other time during configuration of the router.
Config (only)> network 5 Token-Ring interface configuration TKR config>speed 16 TKR config>media utp TKR config>list Token-Ring configuration: Packet size (INFO field): 2052 Speed: 16 Mb/sec Media: Unshielded RIF Aging Timer: 120 Source Routing: Enabled MAC Address: 000000000000 IPX interface configuration record missing TKR config>exit
Configuring the WAN Interface. The first port (interface 1) is used for the WAN (TCP/IP) link. The data link selected for the WAN is PPP. This is the default choice for the data link. The other possibilities are frame-relay and X.25.
Config (only)>network 1 Point-to-Point user configuration PPP Config>list hdlc Mode: Synchronous Encoding: NRZ Idle State: Flag Clocking: External Cable type: RS-232 DTE Speed (bps): 0 Transmit Delay Counter: 0 Lower DTR: Disabled
You must also set the cable type. For PPP the cable type is set using the set hdlc cable command.
Next, set the line speed and clocking type for the serial interface, if necessary.
PPP Config>set hdlc clock internal Must also the line speed to a valid value Line speed (2400 to 2048000) [0]? 56000
After setting the line speed and clocking type, you can check the configuration with the list hdlc command as shown
PPP Config>list hdlc Mode: synchronous Encoding: NRZ Idle State: Flag Clocking: Internal Cable type: RS-232 DTE Speed (bps): 56000 Transmit Delay Counter: 0 Lower DTR: Disabled PPP Config>exit
If you are configuring DLSw to support SDLC, the next step is to configure SDLC. Most of the configurable items do not need modification.
To access the SDLC configuration, use the network command and the number of the interface to which an SDLC device has been assigned (in this case, 2).
Config>network 2 SDLC user configuration
Most of the information that you add when you configure SDLC is hardware-related.
The example begins with a list link command. The list command does not alter the configuration, but shows you the values that are currently associated with the SDLC link.
If you are configuring a IBM 2216 Model 400 Switch:
SDLC 2 Config>list link
Link configuration for: LINK_2 (ENABLED)
Role: PRIMARY Type: POINT-TO-POINT
Modulo 8 Frame Size 2048
Timers: XID/TEST response: 2.0 sec
SNRM response: 2.0 sec
Poll response: 0.5 sec
Inter-poll delay: 0.2 sec
Counters: XID/TEST retry: 4
SNRM retry: 6
Poll retry: 10
In the same way that we configured a token-ring device, the clocking type and line speed must be modified for the SDLC device. If you are using an external modem eliminator, this is unnecessary.
SDLC 2 Config>set link clock internal Must also set the line speed to a valid value Line speed (2400 to 2048000) [0]? 9600 SDLC 2 Config>exit
In order to support the QLLC station shown in Figure 48, you must configure interface 3 to be X.25 and have QLLC support for DLSw on the indicated PVC. The following example starts from scratch with a non-X.25 serial interface. The following sample configuration shows QLLC support for DLSw on a PVC. You should:
In the example, X.25 is configured on interface 1.
Config>net Network number [0]? 1 X.25 User Configuration X.25 Config>li sum X.25 Configuration Summary Node Address: <none> Max Calls Out: 4 Inter-Frame Delay: 0 Encoding: NRZ Speed: 56000 Clocking: Internal MTU: 2048 Cable: RS-232 DTE Lower DTR: Disabled Default Window: 2 SVC idle: 30 seconds National Personality: GTE Telenet (DTE) PVC low: 0 high: 0 Inbound low: 0 high: 0 Two-Way low: 1 high: 64 Outbound low: 0 high: 0 Throughput Class in bps Inbound: 2400 Throughput Class in bps Outbound: 2400 X.25 Config>set addr address [ ]? 3721111 X.25 Config>set pvc low 1 X.25 Config>set pvc high 4 X.25 Config>set svc low-two 5 X.25 Config>set svc high-two 64
X.25 Config>li sum X.25 Configuration Summary Node Address: 3721111 Max Calls Out: 4 Inter-Frame Delay: 0 Encoding: NRZ Speed: 56000 Clocking: Internal MTU: 2048 Cable: RS-232 DTE Lower DTR: Disabled Default Window: 2 SVC idle: 30 seconds National Personality: GTE Telenet (DTE) PVC low: 1 high: 4 Inbound low: 0 high: 0 Two-Way low: 5 high: 64 Outbound low: 0 high: 0 Throughput Class in bps Inbound: 2400 Throughput Class in bps Outbound: 2400 X.25 Config>li prot X.25 protocol configuration No protocols defined X.25 Config>add prot Protocol [IP]? dls Idle timer [20]? QLLC response timer [20]? QLLC response count [10]? Accept Reverse Charges [N]? Request Reverse Charges [N]? Station Type (1) PRI (2) SEC (3) (PEER) [3]? Non standard packet size [32]? Packet window size [128]? Max message size [256]? Call User Data (in HEX) [0000000000000000]?
X.25 Config> li prot X.25 protocol configuration Prot Window Packet-size Idle Max Station Number Size Default Maximum Time VCs Type 26 -> DLS 128 32 256 20 4 PEER X.25 Config> li pvc X.25 PVC configuration No PVCs defined X.25 Config>add pvc Protocol [IP]? dls Packet Channel [1]? 4 Destination X.25 Address [ ]? 4444 Window Size [2]? Packet Size [128]? X.25 Config> li pvc X.25 PVC configuration Prtcl X.25_address Window Pkt_len Pkt_chan 26 -> DLS 4444 2 128 4 X.25 Config> li add X.25 address translation configuration No address translations defined X.25 Config> add addr Protocol [IP]? dls Enter an DLS address identifier (upto 12 chars) [ ]? Chicago X.25 Address [ ]? 4444 X.25 Config> li addr X.25 address translation configuration IF # Prot # Protocol address -> X.25 address 1 26 -> DLS Chicago -> 4444
| Note: | The DTE address "4444" used for the PVC with logical channel number "4" is not used by DLSw, but is used only by X.25 for correlating configuration information. Likewise, the DLSw protocol address ("Chicago" in this example), has no meaning to DLSw but is solely for ease of reference to the various DTE addresses that DLSw can use. Unlike other protocols running on X.25, DLSw address translation is defined as part of DLSw configuration and not in X.25 configuration. |
Once device configuration is complete, you must configure the necessary protocols. To run over DLSw you must configure IP, OSPF (or RIP), ASRT, and the DLSw protocol.
This example begins with the IP configuration:
Config>protocol ip Internet protocol user configuration
The list all command shows the default IP configuration.
IP config>list all
Interface addresses
IP addresses for each interface:
intf 0 192.1.1.3 255.255.255.0 Local wire broadcast, fill 1
intf 1 IP disabled on this interface
intf 2 IP disabled on this interface
Routing
Protocols
BOOTP forwarding: disabled
IP Time-to-live: 64
Source Routing: enabled
Echo Reply: enabled
Directed broadcasts: enabled
ARP subnet routing: disabled
ARP network routing: disabled
Per-packet-multipath: disabled
OSPF: enabled
BGP: disabled
RIP: enabled
RIP default origination: disabled
Per-interface address flags:
intf 0 192.1.1.3 Send net, subnet, static and default routes
Received RIP packets are ignored.
intf 1 IP & RIP are disabled on this interface
intf 2 IP & RIP are disabled on this interface
Accept RIP updates always for:
[NONE]
This example shows the creation of a minimal IP configuration. For more information on this important protocol, see "Using IP".
IP config>add address Which net is this address for [0]? 1 New address [0.0.0.0]? 128.185.236.33 Address mask [255.255.0.0]? 255.255.255.0
IP config>set internal-ip-address 128.185.236.49
IP config>list all
Interface addresses
IP addresses for each interface:
intf 0 192.1.1.3 255.255.255.0 Local wire broadcast, fill 1
intf 1 128.185.236.33 255.255.0.0 Local wire broadcast, fill 1
intf 2 IP disabled on this interface
Internal IP address: 128.185.236.49
Routing
Protocols
BOOTP forwarding: disabled
IP Time-to-live: 64
Source Routing: enabled
Echo Reply: enabled
Directed broadcasts: enabled
ARP subnet routing: disabled
ARP network routing: disabled
Per-packet-multipath: disabled
OSPF: enabled
BGP: disabled
RIP: enabled
RIP default origination: disabled
Per-interface address flags:
intf 0 192.1.1.3 Send net, subnet, static and default routes
Received RIP packets are ignored.
intf 1 128.185.236.33 Send net, subnet, static and default routes
Received RIP packets are ignored.
intf 2 IP & RIP are disabled on this interface
Accept RIP updates always for:
[NONE]
IP config>exit
In this configuration, OSPF is used rather than RIP. You can use either of these routing protocols. However, if you choose RIP, you will not be able to use DLSw Group function.
First, enter a list command. The command displays the default OSPF configuration. You must modify this configuration to run DLSw.
Config>protocol ospf
Open SPF-Based Routing Protocol configuration console
OSPF Config>list all
--Global configuration--
OSPF Protocol: Enabled
# AS ext. routes: 1000
Estimated # routers: 50
External comparison: Type 2
AS boundary capability: Disabled
Multicast forwarding: Disabled
--Area configuration--
Area ID AuType Stub? Default-cost Import-summaries?
0.0.0.0 0=None No N/A N/A
OSPF Config>enable ospf Estimated # external routes [0]? 100 Estimated # OSPF routers [0]? 25
OSPF Config>enable multicast Inter-area multicasting enabled? [No]:
OSPF Config>set interface 128.185.236.33 Attaches to area [0.0.0.0]? Retransmission Interval (in seconds) [5]? Transmission Delay (in seconds) [1]? Router Priority [1]? Hello Interval (in seconds) [10]? Dead Router Interval (in seconds) [40]? Type Of Service 0 cost [1]? Authentication Key [ ]? Retype Auth. Key [ ]? Forward multicast datagrams? [Yes]: Forward as data-link unicasts? [No]: IGMP polling interval (in seconds) [60]? IGMP timeout (in seconds) [180]? OSPF Config>
OSPF Config>list all
--Global configuration--
OSPF Protocol: Enabled
# AS ext. routes: 100
Estimated # routers: 25
External comparison: Type 2
AS boundary capability: Disabled
Multicast forwarding: Enabled
Inter-area multicast: Disabled
--Area configuration--
Area ID AuType Stub? Default-cost Import-summaries?
0.0.0.0 0=None No N/A N/A
--Interface configuration--
IP address Area Cost Rtrns TrnsDly Pri Hello Dead
192.1.1.3 0.0.0.0 1 5 1 1 10 40
128.185.236.33 0.0.0.0 1 5 1 1 10 40
Multicast parameters
IP address MCForward DLUnicast IGMPPoll IGMPtimeout
192.1.1.3 On Off 60 180
128.185.236.33 On Off 60 180
OSPF Config>exit
Configure the router for source route bridging and enable the port as shown:
Config (only)>protocol asrt
Adaptive Source Routing Transparent Bridge user configuration
ASRT config>enable bridge
ASRT config>list port Port Id (dec) : 128:01, (hex): 80-01 Port State : Enabled STP Participation: Enabled Port Supports : Transparent Bridging Only Assoc Interface : 0 Path Cost : 0 +++++++++++++++++++++++++++++++++++++++++++
ASRT config>disable transparent Port Number [1]? ASRT config>enable source-routing
Port Number [1]? Segment Number for the port in hex(1 - FFF) [1]? b0b Bridge number in hex (1 - 9, A - F) [1]?
Next enable DLSw on the bridge port.
ASRT config>enable dls
After completing these steps, enable DLSw as shown. Listing the bridge configuration will confirm that you have configured ASRT correctly.
ASRT config>list bridge
Source Routing Transparent Bridge Configuration
===============================================
Bridge: Enabled Bridge Behavior:
Unknown
+----------------------------+
-------------------| SOURCE ROUTING INFORMATION |------------------------------
+----------------------------+
Bridge Number: 01 Segments: 1
Max ARE Hop Cnt: 14 Max STE Hop cnt: 14
1;N SRB: Not Active Internal Segment: 0x000
LF-bit interpret: Extended
+-------------------+
-------------------| SR-TB INFORMATION |---------------------------------------
+-------------------+
SR-TB Conversion: Disabled
TB-Virtual Segment: 0x000 MTU of TB-Domain: 0
+------------------------------------+
-------------------| SPANNING TREE PROTOCOL INFORMATION |----------------------
+------------------------------------+
Bridge Address: Default Bridge Priority: 32768/0x8000
STP Participation: IEEE802.1d
+-------------------------+
-------------------| TRANSLATION INFORMATION |---------------------------------
+-------------------------+
FA<=>GA Conversion: Enabled UB-Encapsulation: Disabled
DLS for the bridge: Enabled
+------------------+
-------------------| PORT INFORMATION |----------------------------------------
+------------------+
Number of ports added: 1
Port: 1 Interface: 0 Behavior: SRB Only STP: Enabled
This is an important step that is often neglected when configuring DLSw.
Because DLSw, rather than bridging, will be used to forward traffic on SAPs (service access points) 04, 08, 0C, we must add a special protocol filter to the bridging setup.
| Note: | You need to implement the filter described here only if bridging, in addition to DLSw, has been configured across the WAN links. This is not the case in this example. In this example, the procedure for creating a SAP filter is provided for reference purposes only. |
The filter's purpose is to prevent the bridge from forwarding, on other ports, packets that should be handled only by DLSw. It is not optimal for DLSw and the bridging function to forward the same packets. When this occurs, race conditions develop that can cause degradation of network performance.
This command creates a filter that works on all packets with a destination SAP of 4. The list command issued subsequently displays the filter characteristics.
ASRT config>add prot-filter dsap 4 Filter packets arriving on all ports?? [No]: yes ASRT config>list prot-f dsap Protocol Class: DSAP Protocol Type : 04 Protocol State: FILTERED Port Map : 1 ========================== No ETHER type Filter Records Associated No SNAP Filter Records Associated
Once the filtering you need is in place, exit the ASRT configuration.
ASRT config>exit
The final step is configuring the DLSw protocol. The following list command shows the defaults.
Config>protocol dls DLSw protocol user configuration DLSw config>list dls DLSw is DISABLED LLC2 send Disconnect is ENABLED Dynamic Neighbors is ENABLED SRB Segment number 000 MAC <-> IP mapping cache size 128 Max DLSw sessions 1000 DLSw global memory allotment 141312 LLC per-session memory allotment 8192 SDLC per-session memory allotment 4096 QLLC per-session memory allotment 4096 NetBIOS UI-frame memory allotment 40960 Dynamic Neighbor Transmit Buffer Size 5120 Dynamic Neighbor Receive Buffer Size 5120 Dynamic Neighbor Maximum Segment Size 1024 Dynamic Neighbor Keep Alive DISABLED Dynamic Neighbor SessionAlive Spoofing DISABLED Dynamic Neighbor Priority MEDIUM QLLC base source MAC address 40514C430000 QLLC maximum dynamic addresses 64 Type of local MAC list NON-EXCLUSIVE Use of local MAC list is ENABLED Use of remote MAC list is ENABLED SNA explorer limit 100 NetBIOS explorer limit 100
You enable DLSw, and set the SRB segment number. The segment number refers to the token-ring device, as shown in Figure 48.
DLSw config>enable dls DLSw config>set srb 020
This example defines both a group and a configured TCP session. Configuring DLSw does not require this. However, you must define one or the other (either a DLSw group or a configured TCP session) to connect-out to a neighbor DLSw router. If you want non-configured routers to connect-in, issue the enable dynamic-neighbors command.
The join-group command is used to create a DLSw group. You designate each group member as Client/Server or Peer. Peer is the default.
Here, the join-group command is executed for R1 (see Figure 48), designating this DLSw router as a Client in group 1. To join this group, R2 would have to be added as a Server, and the join-group command issued on R2.
DLSw config>join Configure group member (G) or specific multicast address (M) - [G]? Group ID (1-64 Decimal) [1]? Client/Server or Peer Group Member(C/S/P)- [P]? c Connectivity Setup Type (a/p) [p]? Transmit Buffer Size (Decimal) [5120]? Receive Buffer Size (Decimal) [5120]? Maximum Segment Size (Decimal) [1024]? Enable/Disable Keepalive (E/D) [D]? Enable/Disable NetBIOS SessionAlive Spoofing (E/D) [D]? Neighbor Priority (H/M/L) [M]? DLSw config>list group Group# Xmit Rcv Max Keep- SessAlive Mcast IP Addr Role CST Bufsize Bufsize Segsize alive Spoofing Priority ------------- ------- --- ------- -------- -------- -------- --------- -------- Group 1 CLIENT p 5120 5120 1024 DISABLED DISABLED MEDIUM
The add TCP command is used to define explicitly configured DLSw neighbors. The neighbor DLSw IP Address added here is the internal IP Address of the peer DLSw router (called R2 in Figure 48). You also can configure R2 with the neighbor IP Address of R1, or you can configure R2 to accept dynamic neighbors.
DLSw config>add tcp
Enter the DLSw neighbor IP Address [0.0.0.0]? 128.185.122.234
Connectivity Setup Type (a/p) [p]?
Transmit Buffer Size (Decimal) [5120]?
Receive Buffer Size (Decimal) [5120]?
Maximum Segment Size (Decimal) [1024]?
Enable/Disable Keepalive (E/D) [D]?
Enable/Disable NetBIOS SessionAlive Spoofing (E/D)[D]?
Neighbor Priority (H/M/L) [M]?
DLSw config>list tcp
Xmit Rcv Max Keep- SesAlive
Neighbor CST Bufsize Bufsize Segsize Alive Spoofing Priority
--------------- --- ------- ------- ------- -------- -------- ---------
128.185.122.234 p 5120 5120 1024 DISABLED DISABLED MEDIUM
You must define each SDLC link station.
DLSw config>add sdlc Interface # [0]? 2 SDLC Address or 'sw' (switched dial-in) [C1]? Source MAC address [4000112402C1]? 4000003174d1 Source SAP in hex [4]? Destination MAC address [000000000000]? 400000000002 Destination SAP in hex [0]? 4 PU type (1/2/4/5) [2]? XID0 block num in hex (0-0xfff) [0]? 017 XID0 id num in hex (0-0xfffff) [0]? 00001 Poll with TEST (T) or SNRM (S) [T]? DLSw config>li sdlc all Net Addr Status Source SAP/MAC Dest SAP/MAC PU Blk/Idnum PollFrame 2 C1 Enabled 04 4000003174D1 04 400000000002 2 017/00001 TEST
Define the address mapping for each PVC and configured SVC. In the example configuration, there is one QLLC device attached to a PVC.
DLSw config> add qllc sta Interface # [0]? 3 PVC or SVC [PVC]? Logical channel number (1-4095) [0]? 4 Source MAC address [400000310101]? 400000317402 Source SAP in hex [4]? Destination MAC address [000000000000]? 400000000002 Destination SAP in hex [0]? 4 PU type (2/4/5) [2]? XID0 block num in hex (0-0xfff) [0]? 017 XID0 id num in hex (0-0xfffff) [0]? 00001 New QLLC station record added DLSw config> li q st If P/S LCN/DTE addr E/D Source SAP/MAC Dest SAP/MAC PU Blk/IdNum 3 PVC 4 E 04 400000317402 04 400000000002 2 017/00001
The next thing to do is open service access points (SAPs) on each of the bridging interfaces.
SAP numbers 0, 4, 8, and C are commonly used SNA SAPs. To open all of these SAPs, use the SNA option with the open-sap command as shown. To open SAPs for NetBIOS, choose the NB option. If you prefer, you can also enter SAPs individually by entering a hexadecimal number.
DLSw config> open-sap Interface #[1]? Enter SAP in hex (range 0-FE), or one of the following: 'SNA', 'NB', or LNM [4]? sna SAP(s) 0 4 8 C opened on interface 1 DLSw config>
The following is the DLSw display after configuring.
DLSw config>list dls
DLSw is ENABLED
LLC2 send Disconnect is ENABLED
Dynamic Neighbors is ENABLED
SRB Segment number 020
MAC <-> IP mapping cache size 128
Max DLSw sessions 1000
DLSw global memory allotment 141312
LLC per-session memory allotment 8192
SDLC per-session memory allotment 4096
QLLC per-session memory allotment 4096
NetBIOS UI-frame memory allotment 40960
Dynamic Neighbor Transmit Buffer Size 5120
Dynamic Neighbor Receive Buffer Size 5120
Dynamic Neighbor Maximum Segment Size 1024
Dynamic Neighbor Keep Alive DISABLED
Dynamic Neighbor SessionAlive Spoofing DISABLED
Dynamic Neighbor Priority MEDIUM
QLLC base source MAC address 40514C430000
QLLC maximum dynamic addresses 64
Type of local MAC list NON-EXCLUSIVE
Use of local MAC list is ENABLED
Use of remote MAC list is ENABLED
SNA explorer limit 100
NetBIOS explorer limit 100
When you have finished configuring DLSw, exit the DLSw configuration and restart the router.
DLSw config>exit Config (only)>restart Are you sure you want to restart the gateway? (Yes or [No]): yes