![[previous]](../../../graphics/l_arrow.gif){kind=icon}
![[next]](../../../graphics/r_arrow.gif){kind=icon}
This section describes how to customize data link switching configurations.
By default, the bridge/router can accept DLSw tunnel connections from any other configured DLSw bridge/routers. By setting a bridge/router to a Secure state, unauthorized sites can be prevented from accessing a particular site. For less vital traffic, you can leave the bridge/router configured to accept tunnel connections from any remote bridge/router. If you plan to have terminal users at many different remote sites making tunnel connections to a site, you can use the NonSecure setting.
Figure 236 shows a bridge/router at a central host site accepting incoming tunnel connections from three branch offices to access the local site.
Figure 236 
Data Link Switching Tunnel Configuration for Central bridge/router
Table 70 lists the commands used for this configuration.
Before beginning this procedure, complete the following tasks:
To configure a central site bridge/router to accept any incoming tunnel connection requests, follow these steps:
1 . Enable transmission of TCP keepalive packets by entering:
SETDefault -TCP CONTrol = KeepAlive
This command will keep switched virtual circuits active even though there is no traffic across the link other than KeepAlive packets.
2 . Specify the number of contiguously missed keepalive packets that will bring down the TCP session.
SETDefault -TCP KeepAliveLimit = 3
3 . Enable LLC traffic from a port to be tunneled through data link switching by entering:
SETDefault !1 -LLC2 CONTrol = Enable
4 . Assign a unique virtual ring number for the data link switching cloud.
SETDefault -LLC2 TUNnelVRing = 100
This virtual ring number must match on all peer bridge/routers used for data link switching and must be unique within the token ring network. It also will minimize the risk of topology loops.
5 . Configure an IP address to connect traffic to and from the router.
SETDefault -DLSw Interface = 129.213.1.1
All Internet addresses for connected bridge/routers must be known in the local bridge/router's routing table, either dynamically through RIP or OSPF, or statically configured in the IP routing tables.
6 . Set the central site bridge/router to accept all DLSw connection requests (including requests from bridge/routers that are not configured as data link tunnel peers) by entering:
SETDefault -DLSw MOde = NonSecure
You can configure data link switching with additional security beyond what is defined with DLSw peers and known IP addresses. With the -DLSw AccessAct parameter, you can configure the media address you are permitting access to for SNA traffic, or for NetBIOS traffic you can configure specific NetBIOS names of devices you are permitting access to.
The following examples of setting up security access for SNA traffic see Figure 234. Examples 1 and 2 configure bridge/router B for security access.
If you want to prevent PC1 from accessing the host, at the bridge/router on network B, enter:
SETDefault -DLSw AccessAct = RemoteSnaDiscard
ADD !1 -DLSw SnaRemAccess 00608C26C1B5 ffffffffffff 10005A265BED ffffffffffff
If you want to prevent PC1 from accessing any remote system at the bridge/router on network B, enter:
SETDefault -DLSw AccessAct = RemoteSnaDiscard
ADD !1 -DLSw SnaRemAccess 00608C26C1B5 ffffffffffff 000000000000 000000000000
If you want to allow only PC1 access to the host, but want to restrict access to all other systems at the bridge/router on network B, enter:
SETDefault -DLSw AccessAct = RemoteSnaForward
ADD !1 -DLSw SnaRemAccess 00608C26C1B5 ffffffffffff 10005A265BED ffffffffffff
Examples 3 and 4 configure bridge/router A for security access.
If you want to prevent PC1 from accessing the host, at bridge/router A, enter:
SETDefault -DLSw AccessAct = LocalSnaDiscard
ADD !1 -DLSw SnaLocalAccess 00608C26C1B5 ffffffffffff 10005A265BED ffffffffffff
If you want to prevent PC1 from accessing any system attached to bridge/router B, at bridge/router A, enter:
SETDefault -DLSw AccessAct = LocalSnaDiscard
ADD !1 -DLSw SnaLocalAccess 00608C26C1B5 ffffffffffff 000000000000 000000000000
If you want to allow only PC1 to access the host, but restrict access for all other local systems, at bridge/router A, enter:
SETDefault -DLSw AccessAct = LocalSnaForward
ADD !1 -DLSw SnaLocalAccess 00608C26C1B5 ffffffffffff 10005A265BED ffffffffffff
The following examples of setting up security access for NetBIOS traffic see Figure 235. Examples 1 and 2 configure bridge/router B for security access.
If you want to prevent PC001 from accessing the LAN server LS0001, at the bridge/router on network B, enter:
SETDefault -DLSw AccessAct = RemoteNBDiscard
ADD !1 -DLSw NBRemAccess PC0001 LS001
If you want to allow only PC0001 access to LAN server LS0001, but want to restrict access to all other systems, at the bridge/router on network B, enter:
SETDefault -DLSw AccessAct = RemoteNBForward
ADD !1 -DLSw NBRemAccess PC0001 LS0001
Examples 3 and 4 configure bridge/router A for security access.
If you want to prevent PC0001 from accessing LS0001, at bridge/router A, enter:
SETDefault -DLSw AccessAct = LocalNBDiscard
ADD !1 -DLSw NBLocalAccess PC0001 LS0001
If you want to allow only PC0001 to access LS0001, but restrict access for all other local systems, at bridge/router A, enter:
SETDefault -DLSw AccessAct = LocalNBForward
ADD !1 -DLSw NBLocalAccess PC0001 LS0001
You can disable tunneled data link switch peer connections for a specific peer by tunneling to and from an internetwork, or disabling all tunneling on the local bridge/router.
To disable tunneling from a switch to a peer network, enter:
SETDefault !1 -DLSw PEer = 129.213.1.2 Disable
This command disables a connection to a peer data link switch.
To disable all tunneling on the bridge/router, enter:
SETDefault -DLSw Interface = 0.0.0.0
If your installation requires multiple DLSw tunnels, you can configure your data link switch connections to use statically defined media addresses. For example, to configure bridge/router A in the SNA example shown in Figure 234 with the host media address, enter the following command using noncanonical format for the address:
ADD !1 -DLSw PeerMacAdd 10005A265BED
Explorer type frames are then sent to the one predefined DLSw peer address.
If your installation has routers with multiple DLSw tunnels, you can configure your data link switch connections to use statically defined NetBIOS names. For example, to configure bridge/router A in the NetBIOS example shown in Figure 235 with the host name, enter:
ADD !1 -DLSw PeerNBName LANSERVER1
This setting ensures that Name Query frames are not broadcast to all DLSw peer addresses, but are sent only to the predefined DLSw peer.
The section describes how to increase performance and reduce NetBIOS broadcasts.
The 3Com DLSw router at the receiving end of a NetBIOS broadcast sends only one NetBIOS broadcast across the data link switch. The remote DLSw Peer router receives the NetBIOS broadcast and resends this same frame as many times as are defined by the NBBdcastResend parameter at the configured time interval.
If you want to change the values for NetBIOS broadcasts, enter:
SETDefault -DLSw NBBcastResend = 5
SETDefault -DLSw NBBcastTimeout = 2
NBBcastResend and NBBcastTimeout are independent of each other. Setting one parameter does not effect the other parameter.
This section describes how to assign priorities and allocate bandwidth percentage to traffic from individual workstations, allowing you to give higher priority to mission-critical applications. The address of workstations and host computers in this section are used for example purposes only. Be sure to use the correct addresses for your network.
If the physical port that DLSw is using is being used by another protocol, you also may want to configure data prioritization. For information about how to configure data prioritization, see the Prioritizing Multiprotocol Data chapter.
DLSw allows you to allocate bandwidth to traffic coming from individual workstations on network segments directly attached to a NETBuilder II bridge/router. In addition, DLSw allows you to assign priority to traffic coming from workstations. By assigning priority, you specify the order in which packets from workstations are placed on the link between NETBuilder and WAN services. This effects traffic delays but not traffic throughput. By allocating bandwidth, you specify how much link bandwidth the packets receive.
This example illustrates how prioritization and bandwidth allocation work together.
Figure 237 shows two NETBuilder II bridge/routers, router 1 and router 2, as DLSw peers connected by a Frame Relay circuit.
Figure 237 
DLSw Prioritization and Bandwidth Allocation Example
There are six workstations, A through F, connected to router 1 through LAN 1 and LAN 2. There also are two SNA hosts, host 1 and host 2, and one NetBIOS server, server 1, connected to router 2. The following is the prioritization criteria defined for DLSw traffic going from router 1 to router 2:
DLSw does not waste tunnel bandwidth. Bandwidth not allocated can be used by any workstations routed through the same tunnel.
DLSw allows you to allocate connection bandwidth and assign priorities to traffic from individual workstations. This section describes how to configure the example in Figure 237. The addresses of workstations and host computers in this section are not the addresses you are going to use for your network. Be sure to use the correct addresses for your network.
Before beginning this procedure, complete the following tasks:
To configure the example in Figure 237, follow these steps:
1 . Add a prioritization criterion for workstation A and its session partner, host 1, to the DLSw prioritization database, by entering:
ADD !3 -DLSw PRiorityCRiteria 1 20 Medium A SNA H1 SNA
2 . Add a prioritization criterion for workstation B and its session partner, host 2, to the DLSw prioritization database, by entering:
ADD !4 -DLSw PRiorityCRiteria 1 30 High B SNA H2 SNA
3 . Add a prioritization criterion for workstation F and its session partner, server 1, to the DLSw prioritization database, by entering:
ADD !5 -DLSw PRiorityCRiteria 1 10 Low F NB S1 NB
4 . Add a prioritization criteria for all remaining session partners to the DLSw prioritization database, by entering:
ADD !6 -DLSw PRiorityCRiteria 1 40 Medium * SNA * SNA
5 . Enable the connection between the devices attached to router 1 and the data link switch by entering:
SETDefault -DLSw PEer = 129.0.0.2 Enable
To delete an instance ID from the DLSw prioritization database, enter:
DELete !3 -DLSw PRiorityCRiteria 1
CAUTION: This command deletes every attribute defined for each device associated with the instance ID and tunnel ID.
To display information in the DLSw prioritization database, enter:
SHow -DLSw PRiorityCRiteria 1
To change prioritization criterion number 3 to 60% bandwidth, enter:
SETDefault !3 -DLSw PRiorityCRiteria 1 60
To display prioritized statistics for tunnels on the local router, enter:
SHow -DLSw PRioritySTATistics
-------------DLSw PRioritizationSTATistics 192.0.60.10-------------
Tid CurBw BytesPassed
1 8000 16073
-------------------------CriteriaStatistics-----------------------
Cid Config% History% BytesPassed HoldQSize
1 30 0 0
0
2 20 34 5484
0
3 30 56 9035
0
4 20 10 1730
0
33 0 0 0
0
To reset statistics for tunnels on the remote router, enter:
FLush -DLSw PRioritySTATistics
For more information about prioritizing tunnel traffic., see the DLSw Service Parameters chapter in Reference for Enterprise OS Software.
To set the traffic priority of DLSw packets, use:
SETDefault -LLC2 TUNnelPRiority = <H | M | L | DEFault>
Using this parameter, you set the priority of the packets to high, medium, or low. If this parameter is set to default, the system uses the -IP QueuePriority setting. For more information about the TUNnelPRiority parameter, see the LLC2 Service Parameters chapter in Reference for Enterprise OS Software.
The priority you set using the -LLC2 TUNnelPRiority parameter is different from the priority criteria set using the -DLSw PriorityCriteria parameter. The latter parameter only sets the criteria for prioritizing SNA traffic versus NetBIOS traffic.
When setting prioritization for DLSw packets, UDP explorer frames are automatically set to high priority regardless of the -LLC2 TUNnelPRiority parameter setting. The priority of all other types of UDP packets is set using -LLC2 TUNnelPRiority.
This section describes how to configure DLSw to distribute sessions evenly over multiple DLSw connections and use alternate routes (tunnel paths) for sessions.
If DLSw multicast is being used, circuit balancing is not necessary.
The circuit balancing feature of DLSw allows you to use more than one route between end-stations. When you enable circuit balancing, DLSw considers all available routes between end-stations before assigning a session to a tunnel. DLSw also distributes sessions evenly across all available routes. For example, if there are two routes, and one route has two sessions and the other has three, DLSw assigns the next incoming session to the first route. If a connection fails, DLSw disruptively reroutes end-station and host sessions to an available route (users have to reestablish their sessions with host applications).
Figure 238 shows a SuperStack II NETBuilder bridge/router (router 1) with one token ring LAN attached. The LAN also has six workstations attached. router 1 has WAN connections to two NETBuilder II bridge/routers (router 2 and router 3) attached to a front-end processor (FEP) at a host site. Traffic between end-stations (the workstations) and the host travels through DLSw tunnels, and the circuit balancing feature of DLSw is enabled.
When router 1 is configured for circuit balancing, DLSw distributes sessions evenly between Connection 1 and Connection 2. If one of the connections fails, DLSw disruptively reroutes sessions between workstations on the LAN and the host by moving them to the other tunnel.
Figure 238 
Circuit Balancing Example
For circuit balancing to function properly, WAN links must be the same speed. If the WAN links shown in the figure are different speeds (for example, one link is T1 and the other is 64K), then the router with circuit balancing learns the route from the T1 link before the learning the route from the 64K link. All circuits are directed to the DLSw connection on the T1 link instead of being distributed on both the 64K and T1 DLSw connections. Only after alternate routes are in the cache of the circuit balanced router, is the subsequent session establishment balanced (for example, an SNA session to the same MAC address destination is deactivated and then reactivated again).
This section describes how to configure the example in Figure 238.
Before beginning this procedure, complete the following tasks:
To configure circuit balancing for SNA bridge/router 1, see Figure 238 and follow these steps from the router 1 console. Be sure to use the addresses and commands appropriate for your network.
1 . Enable circuit balancing for traffic between router 1 and router 2, and between router 1 and router 3 by entering:
SETDefault -DLSw CircuitBal = Enable
Unless you specify a <cache refresh timeout> value in the SETDefault command, DLSw defaults to 60 minutes. Cache refresh timeout is the interval between each route discovery broadcast.
2 . Confirm that circuit balancing is enabled by entering:
SHow -DLSw CircuitBal
To set the interval between each route discovery broadcasting between router 1 and router 2 to 100 minutes, enter:
SetDefault -DLSw CircuitBal = Enable 100
To prevent DLSw from assigning any new circuits (sessions) to Tunnel 1, enter:
SETDefault !1 -DLSw PEer = 129.0.0.2 Enable
SET -DLSw CONNections = 129.0.0.2 Quiesce
To prevent DLSw from sending broadcast or explorer packets on Tunnel 2, enter:
SETDefault !2 -DLSw PEer = 129.0.0.3 Enable NoBroadcast
You can use local switching and port groups to design DLSw topologies over remote connections for the following situations:
Local switch port grouping is supported over Frame Relay links only. Also, local switch port grouping cannot be used for BSC traffic.
You can configure local switching port groups to funnel connections from many LANs into a single bridge/router and in turn funnel these multiple connections through a single data link switch to reach the central site host. With this capability, you can switch incoming traffic of one type to outgoing traffic of the same type or another type on the same bridge/router.
Local switching port groups can be used in specific network topologies where Frame Relay Access Device (FRAD) functionality is desired but is not efficient. For example, port groups can be used in configurations in which IBM traffic is forwarded from an LLC2 or RFC 1490 domain to a Frame Relay circuit that connects to a central site in RFC 1490 format but without the MAC address translation. The central site in this configuration usually hosts so many stations that configuring each remote MAC address into the mapping table is impractical. If you use the FRAD capability, you are required to configure these remote MAC addresses. Local switching port groups enable you to set up such a large network without having to configure hundreds of remote MAC addresses. For more information about FRAD and BAN, see the Configuring Frame Relay Access Device Support for SNA chapter.
Port groups configured using this feature are known as explicit port groups. Ports defined as SDLC, FRAD, BAN, or LLC2 (for ports that are LAN encapsulated) are known as implicit port groups. The local switching feature enables you to switch traffic from a port group to other port groups.
Figure 239 is an example of configuring port grouping to enable local switching on the bridge/router. In the figure, ports 1 through 4 are incoming ports over a variety of media. These four ports are grouped into port group 1 on the bridge/router; all incoming traffic over the four ports are switched to Frame Relay and are then sent to the Frame Relay WAN over port 7.
Figure 239 
Port Group Local Switching
You can configure up to eight external port groups on a single bridge/router. Figure 240 is an example of multiple port groups on a bridge/router, with each port group forwarding the traffic from its port group to a different host.
Figure 240 
Multiple Port Groups on a Bridge/Router
Using port groups, you can reduce the number of Frame Relay connections needed, which enables greater scalability for larger networks. Figure 241 is an example of how port grouping can be used to funnel many connections on a large network down to one. In the example, many branch office LANs are connected across a Frame Relay network to a NETBuilder bridge/router at a regional site; the regional site in turn is connected to the host front-end-processor at the central site across another Frame Relay network. By setting up the port groups, you can group the multiple LAN connections from the branch offices and funnel them to the central site across the single data link switch tunnel.
Using this approach, you can avoid having hundreds of DLSw tunnels from each branch office terminating at the central site bridge/router. By combining all SNA traffic from the branch offices into a single Frame Relay DLSw tunnel, you can greatly reduce the number of tunnels at the central site, enabling greater scalability for large networks.
Figure 241 
DLSw Port Group Topology
You cannot have local switch port grouping enabled while bridging is enabled. Before configuring port groups, make sure bridging is disabled.
3 . Enable LLC2 on port 1 by entering:
SETDefault !1 -LLC2 CONTrol = Enable
4 . On the branch office NETBuilder bridge/router, enable source route bridging on port 1 by entering:
SETDefault !1 -SR SrcRouBridge = SrcRouBridge
5 . Define the regional office NETBuilder bridge/router as the DLCI neighbor using:
ADD !<port> -BRidge DlciNeighbor = <dlci> (16-991)
ADD !1 -BRidge DlciNeighbor = 20
6 . Set the DLCI throughput using:
SETDefault !<port> -FR DLCIR = <dlci> <cir>
SETDefault !1 -FR DLCIR = 20 64
7 . Define the port group using:
ADD !<port_group_id> -DLSw PortGroup <port> [,...] ["<string>"]
ADD !1 -DLSw PortGroup 1
ADD !1 -DLSw PortGroup 2, 3, 4, 5 "PG1"
8 . Repeat the previous steps for each branch office bridge/router that will be accessing the same host, assigning the specific ports as necessary.
The following restrictions relate to the use of port groups:
DELete !<port_group_id> -DLSw PortGroup [<port> [,...] | ALL]
For example, to delete ports 4 and 5 in port group 1, enter:
DELete !1 -DLSw PortGroup 4, 5
DELete !1 -DLSw PortGroup ALL
You can use port grouping to solve the following DLSw network design issues:
The following sections describe these issues.
Figure 242 is an example in which NETBuilder bridge/routers at six separate branch offices each have a DLSw connection across an IP network into a NETBuilder II bridge/router at a central site. Because there are six DLSw connections, the central site must deal with the overhead and processing for each connection.
Figure 242 
DLSw Connections to Remote Offices (Before Port Grouping)
In Figure 243, port groups have been configured on NETBuilder bridge/routers at regional offices. Each port group has three remote site branch offices assigned to it, with the three remote connections funneled through a single DLSw connection to the central site. By assigning port groups in this way, you can reduce the number of incoming DLSw connections to the central site from six to two.
Figure 243 
DLSw Connections to Remote Offices (After Port Grouping)
Figure 244 is an example of a DLSw meshed network in which there are bridge/routers at nine remote sites, each configured with DLSw connections so that every site can communicate directly with every other site. Such meshed topologies create additional overhead of large numbers of Frame Relay circuits and TCP connections and create problems with topology update broadcasts.
Figure 244 
DLSw Meshed Network (Before Port Grouping)
Figure 245 shows the same meshed network with port groups configured at intermediate regional offices. By configuring port groups on each of the remote sites funneling into three regional offices, each remote site can connect with every other remote site. By assigning port groups in this way, you can reduce the number of DLSw connections from 35 to three. On the regional office bridge/routers, you must either have bridging enabled, or you can configure a port group on each regional office bridge/router for the ports incoming from the remote sites.
Figure 245 
DLSw Meshed Network (After Port Grouping)
Host topologies are often designed so that the same MAC address is assigned to multiple token ring interface Cards (TICs) on front-end-processors. This configuration, referred to as a dual-TIC topology, provides greater backup, redundancy, and load balancing across the dual interface cards. The NETBuilder DLSw implementation supports dual-TIC topologies in source-routed environments.
Figure 246 is an example in which dual TICs are set up on two token rings. The TICs on the front-end-processors have redundant MAC addresses. For example, the MAC address 10005A265BED is mapped to TIC #A on both 3745A and to TIC #A on 3745B, while MAC address 00608C26C1B5 is mapped to TIC #B on both front end processors.
Figure 246 
DLSw in a Source Route Dual-TIC Topology
In this configuration, the NETBuilder II bridge/router supports the dual-TIC environment. No special configuration is required to support dual-TIC except for the following steps:
This section describes how the SnaAlertsToTraps feature of DLSw converts SNA alerts to SNMP traps so that SNMP managers, such as SunNet Manager, NetView AIX, or HP OpenView, can process them. When SNA devices detect a problem, they can send SNA alerts to a focal point (usually NetView) where they are processed and displayed to an operator. The alerts contain information describing the problem and possible actions to be taken.
DLSw allows you to interconnect devices such as OS/2 workstations and 3174 cluster controllers to SNA hosts using NETBuilder II bridge/routers. The SnaAlertsToTraps feature of DLSw enables SNMP management platforms to manage SNA devices (end-stations) by converting their SNA alerts to SNMP traps and sending the traps to the SNMP manager.
Figure 247 shows an end-station and an IBM host connected by a SuperStack II bridge/router (router 1) and a NETBuilder II bridge/router (router 2) over an IP network. The end-station sends SNA alerts to router 1, which passes them to the IBM host, where NetView processes and displays them to an operator. router 1 converts the SNA alerts to SNMP traps and sends the traps to the SNMP manager.
Figure 247 
SnaAlertsToTraps Example
To configure the SnaAlertsToTraps feature, follow these steps from the SuperStack II console:
1 . Set the trap option for the SNMP Service by entering:
SETDefault -SNMP CONTrol = Trap
The SnaAlertsToTraps feature does not work unless trap is set using the SNMP Service. For more information about how to configure the NETBuilder II bridge/router so that it can be controlled by an SNMP manager, see the Network Management chapter and the SNMP Service Parameters chapter in Reference for Enterprise OS Software.
2 . Enable the SnaAlertsToTraps feature by entering:
SETDefault -DLSw SnaAlertsToTraps = Send
Show -DLSw SnaAlertsToTraps