Download WAN_Unit_8-SMDS

Switched Multimegabit Data Service
(SMDS) Defined



SMDS offers the ability to eliminate the geographic
restrictions of distributed high-speed data
communications at native LAN speeds
SMDS, in its most common form as a public,
connectionless, cell-switched data service, allows data
to be switched between multiple public-addressed
subscribers at multimegabit per second speed
SMDS offers the capability to virtually extend the LAN,
at direct connect LAN speeds, across the MAN and
WAN
Origins of SMDS



SMDS was created as a Metropolitan Area Network
(MAN) service by Bellcore as a service and not a
protocol
The first realization of SMDS was defined using the
DQDB technology, as specified in the IEEE 802.6
standard.
The IEEE 802.6 DQDB standard defines
connectionless data-transport service using 53-byte
slots to provide integrated data, video, and voice
services over a MAN, which is typically a geographic
area of diameter less than 150 km
Origins of SMDS (Continue…)


SMDS is a form of cell switching. Cell switching is
defined in terms of standards, underlying
architectures, initial services implementation (such as
SMDS), and protocols.
Cell switching has taken two development paths:
• connectionless data transport in the form of IEEE 802.6
(DQDB)
• connection-oriented and connectionless in the form of
Asynchronous Transfer Mode (ATM)

SMDS services use the IEEE 802.6 DQDB CL
(Connectionless) service
Origins of SMDS (Continue…)



Central-office switch vendors such as Siemens
Stromberg-Carlon were the primary players for the first
versions of cell switching to hit the telecommunications
market: Switched Multimegabit Data Service (SMDS)
using the DQDB architecture as access
These switches first made use of DQDB’s ConnectionLess
(CL) service
Versions of SMDS service have been offered by IXCs,
LECs, and PTTs worldwide, including MCI
Communications, Brotish Telecom, Telecom Ireland, and
Deutsch Telecom
What is a MAN?




The interconnection of multiple SMDS or DQDB
subnetworks forms a Metropolitan Area Network
(MAN).
The MAN can provide shared media for voice, data,
and video transmissions over a local geographic area,
as well as high-speed extension of each LAN and
WAN attached
Cells are routed through the MAN wideband channels
similar to packets in a packet-switched network,
except that the bandwidth is 155 Mbps
Refer to Figure 12.1 (p. 470)
What is a MAN? (Continue…)



MANs interconnect LANs and WANs, while providing
switching, concentration, and high-speed data
transport.
The MAN operates on a shared DQDB bus. This bus
operates as a LAN, where each station on the bus has
equal access to all available bandwidth
MANs implementing DQDB architecture to support
SMDS will cut switched-network costs
SMDS Service-Public versus Private




SMDS is primarily a public data network offering, but could
also be used in a private network.
SMDS will connect multiple nodes, referred to as
Customer Access Nodes (CANs).
SMDS can provide transport for a variety of customer
network access methods, including packet-switched
networks, synchronous data transport, ISDN, and LANs
such as Ethernet and Token Ring
SMDS is publicly offered by several RBOCs (Ameritech,
Bell Atlantic, BellSouth, GTE, Pacific Bell, and SNET) and
only one IntereXchange Carrier (IXC), MCI
Communications
Subscriber Interface and Access Protocols

There are six major methods for users to access an
SMDS network
•
•
•
•
•

SMDS Subscriber Network Interface (SNI)
SMDS Interface Protocol (SIP)
Data eXchange Interface (DXI)
SIP Relay Access
ATM UNI Access
Refer to Figure 12.2 (p. 473)
SMDS L3_PDU



The L3_PDU carries the real protocol value of SMDS
Refer to Figure 12.3 (p. 474)
The three most common types of transport for the L3 PDU are
the DXI frame, 802.6 cell, and ATM cell
SMDS Subscriber Network Interface (SNI)



The SNI is the subscriber physical and administrative interface
and boundary to the SMDS network or service provider
Standard SNI access methods use the access DQDB protocol
and standard CSU/DSU
Refer to Figure 12.2 (p. 473)
SMDS Interface Protocol (SIP)







SIP Provides for many CPE devices to communicate over the SNI
using the DQDB protocol.
SIP operation is primarily the exchange of L3_PDUs between
CPE and SMDS network switching nodes
This operation is called an “Access DQDB”, which is
distinguished as CPE-to-MAN Switching System access
The SMDS access DQDB is based on the open bus topology
If there are multiple customers at a site, each customer must be
provided a separate access DQDB into the SMDS network
Refer to Figure 12.2 (p. 473)
Refer to Figure 12.4 (p. 475)
Data eXchange Interface (DXI)




The Data eXchange Interface (DXI) was developed
by the SMDS Interest Group as a cost-effective
access method
It required only the upgrade of the CSU/DSU
equipment and software on the CPE device rather
than a hardware upgrade to the CPE device
This allowed for easy integration and upgrade
capability to SMDS for the existing router base
Refer to Figure 12.2 (p. 473)
Data eXchange Interface (DXI)
(Continue…)




The DXI Local Management Interface (LMI) protocol
is used for signaling across the DXI
A High Speed Serial Interface (HiSSI) can also
provide transport for DS3 DXI access, and is used by
providers such as MCI Communications
The DXI is an enhanced version of the standard
HDLC protocol and frame
Refer to Figure 12.5 (p. 476)
Data eXchange Interface (DXI)
(Continue…)




MCI Communications improved the specification by
eliminating the need for a special CSU/DSU for
speeds of 56 kbp. 476s to 1.544 Mbps
DXI SMDS service is offered by some LECs, such as
Bell Atlantic and Pacific Bell
Both vendors provide an access server technology to
convert the customer DXI into an SMDS Interface
Protocol (SIP)
Refer to Figure 12.6 (p.476)
Frame Relay Access






SIP Relay is the method of using a frame relay
protocol as an access to an SMDS service
Refer to Figure 12.2e (p. 473)
This method passes L3_PDUs into the FR frame and
extracts them out of a FR frame at the destination
end
Refer to Figure 12.7 (p. 477)
Refer to Figure 12.8 (p. 477)
This allows the use of a single interface port for both
frame relay and SMDS access to a public network
The Customer Premises Environment
(CPE)



The user environment, CPE, typically contains
multiple applications using diverse protocols, and
riding multiple subnetworks
The customer’s requirements can either be satisfied
by interfaces directly into the SMDS network or by
concentration via a variety of devices (routers,
bridges, DSUs, CSUs, etc.)
Many vendors now support the SIP, DXI, and frame
relay SIP interfaces
Addressing and Traffic Control



The addressing scheme used by the SMDS network
is formatted using the same structure as the North
American Numbering Plan (NANP)
This scheme was chosen to speed the integration of
SMDS into the telephone network addressing
infrastructure for integration of voice and data
operations
CPE interface methods to an SMDS network device
via multiple access protocols across the SNI include
SIP, DXI, SIP relay, ISDN, and ATM
Addressing and Traffic Control
(Continue…)




The SMDS service provider will have full control over
the use or more unique addresses
The subscriber will have full control over the use of
each individual address, and may assign multiple
SMDS addresses per CPE
SMDS can assign a group address to multiple
devices so that they can multicast their data to other
members of their group address
There are many addressing functions available, such
as unicasting and multicasting
Unicasting and Multicasting (Group
Addressing)


SMDS offers either a point-to-point datagram delivery
service called unicasting or a point-to-multipoint
service defines as a group multicast address
Group-addressed data unit transport provides the CPE
capability to transmit to a maximum of 128 individual
recipient addresses
Source Address Validation and Address
Screening



The SMDS source address is screened by the
network to ensure that it is valid for the source SMDS
access line
SMDS customers can screen incoming data and only
accept data from specific source SMDS addresses or
block data
SMDS users can also limit the destination SMDS
addresses
SIR Access Classes as Traffic and
Congestion Control



SMDS controls congestion and traffic through the use
of an open loop flow control mechanism called
Sustained Information Rate (SIR) regulated through
the assignment of classes
SMDS SIR is based on the aggregate of all data
originating on the SMDS access line regardless of it’s
destination
SIRs are defined by access class
Access Classes




Access classes are a method of providing bandwidth
priorities for times when there is network congestion
at the SNI
Network congestion occurs when there is an attempt
by the network to transfer one or more SMDS data
units without an interval of time between the units
The access class places a limit per user on the rate
of sustained information transfer available
In actual practice on an SNI, the SMDS CSU/DSU
chooses the access class and then clocks and
meters the traffic from the router to average the traffic
to meet the SIR rate
SMDS Addressing




The public phone network uses an addressing, or
numbering, scheme called E.164 that basically has a
country code part and then a nationally assigned part
for each country
Today, SMDS 10-digit numbers do not coincide with
the national phone number 10-digit system.
Some moves by carriers such as MCI
Communications are trying to change the system to
be more in line with public phone numbers
Refer to Figure 12.10 (p. 484)
SMDS and DQDB Protocol Structures

The IEEE 802.6 standard is one of the 802.X series of
LAN and MAN standards, which has been further
modified for operation over the WAN
IEEE 802.6 Compared to the OSIRM



IEEE 802.6 is part of the IEEE defined 802.X suite of
LAN and MAN protocols.
The IEEE 802.6 MAN protocol spans both the physical
layer and media access control (MAC) sublayer.
Refer to to Figure 12.11 (p. 485)
Structure of SMDS and IEEE 802.6


SMDS and the IEEE 802.6 DQDB protocol have oneto-one mapping to each other
Refer to Figure 12.12 (p. 485)
SMDS and DQDB Architecture


SMDS is defined as a service, and therefore can be
offered with multiple access protocols and over
multiple backbone transport technologies
Today, SMDS service is offered over both DQDB and
ATM network transport architectures
SMDS Backbone Architecture




SMDS public network backbone design can be
composed of multiple MAN Switching Systems (SSs)
connected by InterCarrier Interface (ICI) transport.
Users interface to the network via SMDS CPE over the
SMDS access protocols.
Refer to Figure 12.16 (p. 489)
Access DQDB refers to the use of the DQDB protocol
as the basis for the SMDS interface protocol providing
access to the SMDS service
SMDS Backbone Architecture
(Continue…)



Bellcore standards define the SMDS Switching
System (SS) as a collection of equipment that
provides high-speed packet switching function in a
network supporting SMDS
Switching Systems (SSs) can be configured in a
distributed architecture where multiple SSs would
form the SMDS network
Refer to Figure 12.17 (p. 491)
SMDS Backbone Architecture
(Continue…)





SSs operate in either a store-and-forward mode where the SS
reads in the entire L3-PDU on the SNI before transmitting it on
to the next SS or end CPE device
This technique of reassembly adds store-and-forward delay.
One method of eliminating this delay is through pipe-lining,
where the switch immediately starts forwarding part of the
L3_PDU before the entire L3_PDU is received into the switch
Switching systems can also take the form of a single switch in a
centralized architecture
Refer to Figure 12.18 (p. 491)
DQDB and SMDS Functions





The DQDB architecture is based on a 45/155/622
Mbps dual bus which operates similarly to token ring
architecture
Fixed-length cells are placed within time slots that
move from a time slot generator on one end of the bus
to a terminator on the other end
There are three implementations of the DQDB: the
point-to-point bus, the open-dual bus, and th elooped
dual (folded) bus
Refer to Figure 12.19 (p. 492)
Refer to Figure 12.20 (p. 492)
DQDB Architecture – Bus Defined






There are two unidirectional buses, A and B, that interconnect a
number of nodes, often configured in a physical ring.
Even though the physical configuration may be a ring, logical
operation is bus-oriented.
Nodes read from both buses, usually passing along any data
onto the next node in the bus
Each node may become the Head Of Bus (HOB) or End Of Bus
(EOB)
The HOB generates 53-octet slots in a framing structure to
which the other nodes synchronize. The EOB node simply
terminates the bus
Refer to Figure 12.21 (493)
DQDB Architecture – Bus Defined
(Continue…)


Although the bus appears to pass through each node
on the bus, in fact it only passes by each node. This
provides for a highly reliable network, as a node
failure will not affect the operation of the rest of the
network
The looped architecture provides a common point for
timing into the network to ensure network
synchronization, as well as a self-healing, fault
isolation mechanism inherent to the architecture
SMDS Internetworking – Bridging and
Routing


Bridging can be accomplished either with MAC
bridging or simple encapsulation
Routing can be accomplished with simple
encapsulation of IP
SMDS Bridging with TCP/IP





SMDS bridging is one method of extending the LAN
environment through SMDS using a bridge
Some protocols require bridging such as DEC LAT
and NetBIOS.
The local end-user device will send the IP packets
within the IEEE 802.3 Ethernet frames to the local
bridge.
The bridge will use encapsulation bridging into SMDS
SIP frames
Refer to Figure 12.25 (p. 498)
SMDS Routing with TCP/IP




The router provides the conversion from the MAC
protocol to the SMDS SIP. Using the SIP, the router
now uses a DQDB providing SMDS to allow highspeed connectivity over large geographic areas
The router does pay attention to the LLC and IP
addresses when making its routing decision, rather
than forwarding the frames received
The router makes the SMDS transport look like just
another LAN segment
Refer to Figure 12.26 (p. 499)
Cisco
Managing Traffic with Access Lists
Objectives
 Configure IP standard access lists
 Configure IP extended access lists
 Configure IPX SAP filters
 Monitor & verify access lists
Access Lists
 Purpose:
• Used to permit or deny packets moving
through the router
• Permit or deny Telnet (VTY) access to or from a
router
• Create dial-on demand (DDR) interesting traffic
that triggers dialing to a remote location
Important Rules
Packets are compared to each line of the assess
list in sequential order
 Packets are compared with lines of the access
list only until a match is made
• Once a match is made & acted upon no further
comparisons take place
 An implicit “deny” is at the end of each access list
• If no matches have been made, the packet will
be discarded

Types of Access Lists
 Standard Access List
• Filter by source IP addresses only
 Extended Access List
• Filter by:
– Source IP
– Destination IP
– Protocol Field
– Port Number
Application of Access Lists
 Inbound Access Lists
• Packets are processed before being routed to
the outbound interface
 Outbound Access Lists
• Packets are routed to the outbound interface &
then processed through the access list
ACL Guidelines




One access list per
interface, per protocol, or
per direction
More specific tests at the
top of the ACL
New lists are placed at the
bottom of the ACL
Individual lines cannot be
removed





End ACLs with a permit any
command
Create ACLs & then apply
them to an interface
ACLs do not filter traffic
originated from the router
Put Standard ACLs close
to the destination
Put Extended ACLs close
the the source
Standard IP Access Lists
Router#config t
Enter configuration commands, one per line. End with
CNTL/Z.
Router(config)#access-list ?
<1-99>
IP standard access list
<100-199>
IP extended access list
<1000-1099> IPX SAP access list
<1100-1199> Extended 48-bit MAC address access list
<1200-1299> IPX summary address access list
<200-299>
Protocol type-code access list
<300-399>
DECnet access list
<600-699>
Appletalk access list
<700-799>
48-bit MAC address access list
<800-899>
IPX standard access list
<900-999>
IPX extended access list
Standard IP Access Lists
 Creating a standard IP access list:
Router(config)#access-list 10 ?
deny
Specify packets to reject
permit Specify packets to forward
 Permit or deny?
Router(config)#access-list 10 deny ?
Hostname or A.B.C.D Address to match
any
any source host
host
A single host address
 Using the host command
Router(config)#access-list 10 deny host 172.16.30.2
Wildcards
 What are they???
• Used with access lists to specify a….
– Host
– Network
– Part of a network
Block Sizes
64

32
16
8
4
Rules:
• When specifying a range of addresses, choose the
closest block size
• Each block size must start at 0
• A ‘0’ in a wildcard means that octet must match exactly
• A ‘255’ in a wildcard means that octet can be any value
• The command any is the same thing as writing out the
wildcard: 0.0.0.0 255.255.255.255
Example
 172.16.30.5
0.0.0.255
• The 0’s tell the router to match the 1st three
octets exactly
• The 255 tells the router the 4th octet can be
any value
• This shows how a full subnet (172.16.30.0) is
specified
Specifying a Range of Subnets
(Remember: specify a range of values in a block size)
Requirement: Block access in the range from 172.16.8.0
through 172.16.15.0 = block size 8
Network number = 172.16.8.0
Wildcard
= 0.0.7.255
**The wildcard is always one number less than the block size
Examples


RouterA(config)#access-list 10 deny 172.16.10.0 0.0.0.255
RouterA(config)#access-list 10 deny 172.16.0.0 0.0.255.255

RouterA(config)#access-list 10 deny 172.16.16.0 0.0.3.255

RouterA(config)#access-list 10 deny 172.16.16.0 0.0.7.255

RouterA(config)#access-list 10 deny 172.16.32.0 0.0.31.255

RouterA(config)#access-list 10 deny 172.16.64.0 0.0.63.255
Examples
Acme#config t
Acme(config)#access-list 10 deny 172.16.40.0 0.0.0.255
Acme(config)#access-list 10 permit any
(permit any ~ Acme(config)#access-list 10 permit 0.0.0.0
255.255.255.255)
Acme(config)#int e0
Acme(config-if)#ip access-group 10 out
Controlling VTY (Telnet) Access
 Why??
• Without an ACL any user can Telnet into the
router via VTY and gain access
 Controlling access
• Create a standard IP access list
– Permitting only the host/hosts authorized to Telnet
into the router
• Apply the ACL to the VTY line with the
access-class command
Example
RouterA(config)#access-list 50 permit 172.16.10.3
RouterA(config)#line vty 0 4
RouterA(config-line)#access-class 50 in
(implied deny)
Extended IP Access Lists
 Allows you to choose...
– IP Source Address
– IP Destination Address
– Protocol
– Port number
Extended IP ACLs
Router(config)#access-list ?
<1-99>
IP standard access list
<100-199>
IP extended access list
<1000-1099> IPX SAP access list
<1100-1199> Extended 48-bit MAC address access list
<1200-1299> IPX summary address access list
<200-299>
Protocol type-code access list
<300-399>
DECnet access list
<600-699>
Appletalk access list
<700-799>
48-bit MAC address access list
<800-899>
IPX standard access list
<900-999>
IPX extended access list
Router(config)#access-list 110 ?
deny
Specify packets to reject
dynamic Specify a DYNAMIC list of PERMITs or DENYs
permit
Specify packets to forward
Extended IP ACLs
Router(config)#access-list 110 deny ?
<0-255> An IP protocol number
ahp
Authentication Header Protocol
eigrp
Cisco's EIGRP routing protocol
esp
Encapsulation Security Payload
gre
Cisco's GRE tunneling
icmp
Internet Control Message Protocol
igmp
Internet Gateway Message Protocol
igrp
Cisco's IGRP routing protocol
ip
Any Internet Protocol
ipinip
IP in IP tunneling
nos
KA9Q NOS compatible IP over IP tunneling
ospf
OSPF routing protocol
pcp
Payload Compression Protocol
tcp
Transmission Control Protocol
udp
User Datagram Protocol
Router(config)#access-list 110 deny tcp ?
A.B.C.D Source address
any
Any source host
host
A single source host
Extended IP ACL Steps
#1: Select the access list:
RouterA(config)#access-list 110
#2: Decide on deny or permit:
RouterA(config)#access-list 110 deny
#3: Choose the protocol type:
RouterA(config)#access-list 110 deny tcp
#4: Choose source IP address of the host or network:
RouterA(config)#access-list 110 deny tcp any
#5: Choose destination IP address
RouterA(config)#access-list 110 deny tcp any host 172.16.30.2
#6: Choose the type of service, port, & logging
RouterA(config)#access-list 110 deny tcp any host 172.16.30.2 eq
23 log
Steps (cont.)
RouterA(config)#access-list 110 deny tcp any host 172.16.30.2 eq
23 log
RouterA(config)#access-list 110 permit ip any 0.0.0.0
255.255.255.255
RouterA(config)#ip access-group 110 in
or
RouterA(config)#ip access-group 110 out
Example
Acme#config t
Acme(config)#access-list 110 deny tcp any host 172.16.10.5 eq
21
Acme(config)#access-list 110 deny tcp any host 172.16.10.5 eq
23
Acme(config)#access-list 110 permit ip any any
Acme(config)#int e0
Acme(config-if)#ip access-group 110 out
Monitoring IP Access Lists

Display all access lists & their parameters
show access-list

Show only the parameters for the access list 110
show access-list 110

Shows only the IP access lists configured
show ip access-list

Shows which interfaces have access lists set
show ip interface

Shows the access lists & which interfaces have access lists set
show running-config
Summary
 Configured IP standard access lists
 Configured IP extended access lists
 Configured IPX SAP filters
 Monitored & verified access lists