![[previous]](../../../graphics/l_arrow.gif){kind=icon}
![[next]](../../../graphics/r_arrow.gif){kind=icon}
SMDS is a connectionless packet switched service provided by telephone companies. Hosts or internetworking equipment connected to SMDS nodes can exchange packets across the wide area network.
To connect a router to an SMDS network, three levels of the SMDS Interface Protocol (SIP) must be supported. Your 3Com router provides the SIP-3 Protocol, which encapsulates the user data into an L3PDU. SIP-1 and SIP-2 are provided by a third-party CSU/DSU.
The sections that follow provide some basic information about SMDS Service:
SMDS addresses are of two types: individual addresses, for unicast traffic, and group addresses, for multicast traffic. The addresses are distinguished by the value of the first or control digit, which has the value hexadecimal C for an individual address and hexadecimal E for a group address. Each address has 15 decimal digits following the control digit, and resembles a telephone number. If an address has fewer than 15 digits, the software automatically right-pads it with hexadecimal Fs to the full length.
|
C14085551212FFFF |
Individual Address |
|
E14085551234FFFF |
Group Address |
An individual address routes data to a unique node, a device attached to an SMDS network through a Subscriber Network Interface (SNI). The SMDS service provider assigns a block of up to 16 individual addresses to each SNI. Enterprise OS software can use the extra addresses to create virtual SMDS ports through the SNI. For information about configuring virtual ports on SMDS, see "Configuring Virtual Ports" in the Configuring Advanced Ports and Paths chapter.
SMDS permits multiple nodes to be assigned the same group address (in addition to their individual addresses). Packets sent to a group address are delivered to all nodes in the group. This feature gives SMDS the appearance of a LAN.
The LMI Protocol runs between the bridge/router data terminal equipment (DTE) and the CSU/DSU data communications equipment (DCE). The LMI Protocol improves reliability between the DTE and DCE by exchanging heartbeat packets every 5 to 30 seconds, depending on the configuration.
If the LMI Protocol is not enabled, the line between the router and the CSU/DSU is assumed to be up. The LMI Protocol is disabled by default on your bridge/router.
Some DSUs do not run the LMI Protocol. In this case, set the CONTrol parameter in the SMDS Service to NoLMI (the default setting).
The SMDS Service sets upper limits on the number of members in a group, the number of groups an individual address can belong to, and the total number of addresses (individual and group) that any one SNI can exchange packets with.
The set of addresses that an SNI can exchange data with is configured by the service provider, following the subscriber's specifications, into a feature of the SMDS switch called the address screen. The NETBuilder bridge/router does not implement the address screen and is not aware of it.
Although an SMDS virtual port can have more than one group address, a group address cannot be shared by multiple ports on the same NETBuilder bridge/router, since Enterprise OS software uses the group address to identify the virtual port for which a packet is intended.
SMDS group addresses can be used in a variety of applications where it is desirable to divide nodes on the network into several groups that are treated in different ways. The following sections give some examples of these applications.
The simplest SMDS configuration allows each router to exchange data with each of the subscriber's other routers, creating a full mesh across the SMDS network. Within this configuration, group addresses can be used to separate routing protocols. For example, all routers support IP, so all routers would belong to the IP group. Only routers that support AppleTalk would belong to the AppleTalk group. By addressing them to the AppleTalk group, AppleTalk routing updates and name service queries can be sent only to AppleTalk routers.
Figure 358 illustrates this configuration. Routers A and B route both IP and AppleTalk. Router C routes only IP. Routers A and B are assigned one SMDS group address (creating an AppleTalk group), while all three routers are assigned another SMDS group address (creating an IP group). When the routing protocols have been properly set up, AppleTalk routing and name service broadcast packets are delivered only to routers A and B, not to router C.
Figure 358 
SMDS Full Mesh Configuration with Two Groups
A more complex configuration might use virtual ports to provide additional control over the traffic. Consider a situation in which transparent bridging over SMDS is configured. Several organizations whose LANs are located close together (for example, several small companies in the same office building) all need a wide area connection to their branch offices. These organizations would like to share the cost of a bridge, but they do not want to compromise the privacy of their data or allow others to use bandwidth that they pay for. Virtual ports over SMDS, together with bridge filtering, can allow these organizations to share equipment without mixing bandwidth or broadcast traffic. The traffic of each organization is filtered to a separate virtual port, and the SMDS group address is used to identify these virtual ports.
Figure 359 
Transparent Bridging over SMDS
In Figure 359, LANs X and Y share bridge/routers A, B, and C, one at each location, which are all configured as bridges. Each bridge has two local ports. On each bridge, LAN X is attached to local port 1, and LAN Y is attached to local port 2.
In practice, LANs X and Y may be close to each other at only one location, not three. The techniques described in this section can be used to separate traffic at that location.
Each bridge also has a wide area port, which has been configured for the SMDS Service, as described in this chapter. Enterprise OS software has also been used to create two virtual ports, V1 and V2, for this SMDS port, again on all three bridges. (One of these two ports could actually be the parent port rather than a virtual port.) At each bridge, the parent SMDS port is used to configure the SMDS CONTrol parameter, selecting the data exchange interface (DXI) that matches the DSU, and enabling or disabling LMI operation.
Two SMDS group addresses, E14085550010 and E14085550020, have been obtained from the SMDS service provider. Group address E14085550010 is assigned to virtual port V1 on all three bridges, and group address E14085550020 is assigned to virtual port V2 on all three bridges, as described in this chapter. Each virtual port on each bridge also has a unique SMDS individual address, as required by the SMDS Service.
The bridge filters on each bridge are configured so that packets are bridged only between virtual SMDS port V1 and local port 1, and between virtual SMDS port V2 and local port 2.
The bridge filters can be configured using the following commands. First, set the default action of the FIlter Service to Discard by entering:
SETDefault -FIlter DefaultAction = Discard
Define a filter mask called ANY that matches any packet by entering:
ADD -FIlter MASK ANY %0 | %ff = %ff
Add filter policies using the mask ANY by entering:
ADD -FIlter POLicy LANX-V1 forward ANY between !1 and !V1
ADD -FIlter POLicy LANY-V2 forward ANY between !2 and !V2
At each bridge, traffic from LAN X travels over local port 1 and is bridged to virtual SMDS port V1, where it is multicast to group address E14085550010. Traffic from LAN Y travels over local port 2 and is bridged to virtual SMDS port V2, where it is multicast to group address E14085550020.
The SNI address screen is configured as a full mesh, so all SMDS traffic from each bridge is sent to the other two bridges. At each bridge, traffic received for group address E14085550010 is assigned to virtual port V1 and bridged to local port 1, which is attached to LAN X. Traffic received for group address E14085550020 is assigned to virtual port V2 and bridged to local port 2, which is attached to LAN Y.
Even local bridging between ports attached to the same bridge is filtered, so data from the two organizations is always kept separate.
You may require source route bridging over the SMDS cloud between some LAN ports (for instance, token ring and FDDI) but not others. To keep source-route-bridged traffic separate from transparently bridged traffic, you can create a virtual SMDS port to carry one kind of bridged traffic, and use the parent port or another virtual port for the other.
Route filtering in AppleTalk is configured for each port with of the NetFilter parameter. You can selectively filter routing information learned on one port and propagated to other ports by creating virtual SMDS ports and distinct SMDS groups. Entity filtering in AppleTalk is controlled in a similar way by the EntityFilter and EntityFilterNum parameters and can be propagated selectively by the same technique.
Over IPX routing, SMDS virtual ports can be used for phased introduction of NLSP to the network, where some remote bridge/routers have not yet been upgraded to support NLSP but still support RIP/SAP. Instead of defaulting to RIP/SAP, those remote bridge/routers that understand NLSP can be collected into a new subgroup, while RIP/SAP routers remain in the original subgroup until they can be upgraded.
With IP routing, you can use SMDS virtual ports to control routing information with varying policies or protocols among the different SMDS virtual ports. For instance, one subgroup of equipment may already be using OSI IS-IS to support CLNP. The solution is to enable Integrated IS-IS selectively for these nodes under IP.
You can connect a large IP network over an SMDS cloud by combining the multiple area techniques of OSPF with SMDS virtual ports. This hierarchical approach expands the total number of bridge/routers that can be interconnected over SMDS by limiting the number that must communicate directly. Dividing the SMDS-connected bridge/routers into regions has two advantages:
The network bandwidth and router CPU time saved by OSPF summarization techniques will, in many cases, compensate for the extra hop needed by traffic traveling from a stub area to the backbone or another stub area. This configuration also saves the cost of additional SNIs that would otherwise be needed for the regional and backbone routers.
Figure 360 
Large Hierarchical SMDS Network