schmidt@informatik.
haw-hamburg.de
Network Management
> Objectives of Network Management
> The SNMP Architecture
> The Management Information Base
> SNMPv* Protocols
> Network Management Systems
> RMON / RMON II
> Switched Networks:
from Spanning Tree to SMON
schmidt@informatik.
haw-hamburg.de
2
Motivation
> Large distributed networks
> Many heterogeneous components
> Critical basic functions
> Advanced, complex consumer services
> High availability requirements
⇒ Tools & technologies needed to monitor & analyse,
operate & adapt large networks & services
schmidt@informatik.
haw-hamburg.de
3
Who Needs Management ?
> Users & Roles
– Authentication & Identity – Addressing
– Roaming Profiles & Services
> Applications & Services
– Mail, DNS, …
– IP Telephony, Broadcasting
> Devices & Infrastructure
– Routers, Switches, Servers, … – Bandwidth, Buffers, Policies
schmidt@informatik.
haw-hamburg.de
4
How to Approach a Standard Solution ?
Define a simple, general concept to act on ‘Managed Nodes’:
– Abstract, adaptable information model – Overall architecture, supplying
only basic functions, no applications – Lightweight technology framework
for easy implementation
– Standards for machine independent
encoding and communication
schmidt@informatik.
haw-hamburg.de
5
OSI Management:
Functional Areas
Fault Management:
Detection, isolation and correction of abnormalities for managed nodes
Configuration and name management:
Identify, control, collect data from & provide data to managed objects
Performance management:
Evaluate behaviour and effectiveness of managed objects
Accounting management:
Enable charge for use of managed objects and identify costs
Security management:
Document security essentials and protect managed objects
schmidt@informatik.
haw-hamburg.de
6
Simple Examples:
Visualisation of Service Loads
Internet Traffic Monitoring
Mail Monitoring
schmidt@informatik.
haw-hamburg.de
7
Example II:
Complex Topology
schmidt@informatik.
haw-hamburg.de
8
Example III:
Intricate End-to-End Service
schmidt@informatik.
haw-hamburg.de
9
The Standard SNMP
Simple Network Management Protocol - Defines the only (seriously) available standard for general management tasks (suitable also for non-IP devices)
> 1988 defined as a short-term solution (RFC 1157)
> Current version 2 (SNMPv3) (RFCs 3414, 3416)
> Employs simple datagram messaging (UDP)
> SNMP is part of a general NMM model:
– Managed Nodes are equipped with SNMP agents
– Management application located at a powerful Network Management Station – Defines Proxy Agents to include non-SNMP systems
– Machine independent information structure encoding in ASN.1
schmidt@informatik.
haw-hamburg.de
10
Information Structure
> SMI: Structure and Identification of Managed Information (RFC 1155) – Information model for describing the general structure (contextual
arrangement, types,...) of management entities – Generic Type: Managed Object
– Generic Data Structure: 2-dim. Table
> MIB: Management Information Base (MIB-II RFC 1213) – Description of concrete managed objects
– Open concept for representation of management data
> SNMP: Simple Network Management Protocol
– Defines the communication between SNMP agents and management station
schmidt@informatik.
haw-hamburg.de
11
Architecture of
SNMP Systems
schmidt@informatik.
haw-hamburg.de
12
SMI
Managed Objects represent managed resources as state or event variables Problems:
– Objects used to represent particular resources must be the same at each system
– A common scheme for representation must be used to support interoperability
SMI provides
– a standardized technique for defining the structure of a particular MIB
– a standardized technique for defining individual objects, including syntax and (possible) values of each object
– a standardized technique for encoding object values
schmidt@informatik.
haw-hamburg.de
13
MIB
Type and organisation of Managed Objects (MOs) are application/vendor specific
Minimal agreement:
– Syntax and semantic of managed objects MIB provides
– object arrangement and names in a virtual database Object Identifier (OID)
– used to register MOs in a virtual tree structure – uniquely identifies any MO within this tree
– allows for coexistence of standardized and private MOs Example: internet OBJECT IDENTIFIER : := 1.3.6.1
sysOjectID OBJECT IDENTIFIER : := 1.3.6.1.2.1.1.2
schmidt@informatik.
haw-hamburg.de
14
Object Identifiers
rootISO (1) Organizations (3)
DoD (6) Internet (1)
directory (1) mgmt (2) experimental (3) private (4)
mib (1) enterprises (1)
system (1) ... tcp (6) ibm (2) ... hp (11)
Tabellen oder Managed Objects Weitere Subtrees, Tabellen oder Managed Objects
schmidt@informatik.
haw-hamburg.de
15
The
MIB
Tree
schmidt@informatik.
haw-hamburg.de
16
MIB-II (RFC 1213)
MIB-II is the generic Management Information Base for any manageable Internet node (generic SNMP device). It is organized as
iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1) - system (1)
- interface (2) - at (3)
- ip (4) - icmp (5) - tcp (6) - udp (7) - egp (8)
- transmission (10) - snmp (11)
Extensions/ additional subtrees can be defined via
• a new subtree under mib-2
(for general standard MIBs)
• a new subtree under mgmt or experimental
(for experimental MIBs)
• a private extension under the private subtree.
schmidt@informatik.
haw-hamburg.de
17
More Standard MIBs
> RFC 1493 – Bridge MIB
> RFC 1611 – DNS Server MIB
> RFC 1643 – Ethernet MIB
> RFC 1657 – BGP4 MIB
> RFC 1659 – RS232-like HW
> RFC 1696 – Modem MIB
> RFC 1697 – RDBMS MIB
> RFC 1724 – RIPv2 MIB
> RFC 2006 – Mobile IP MIB
> RFC 2096 – IP forwarding table
> RFC 2206 – RSVP MIB
> RFC 2213 – Integrated Services
> RFC 2249 – Mail monitoring
> RFC 2465 – IPv6 general
> RFC 2466 – ICMPv6
> RFC 2959 – RTP
> RFC 3747 – Differentiated Services
> Internet Draft – MIPv6
> …
schmidt@informatik.
haw-hamburg.de
18
Definition of Managed Objects
Every MO is derived from a ASN.1 macro defined in SMI (RFC 1155).
• It defines: Name, Access, Status, Syntax and descriptions
OBJECT-TYPE MACRO : : = BEGIN
TYPE NOTATION : : = “SYNTAX” type (TYPE ObjectSyntax)
“ACCESS” Access
“STATUS” Status DescrPart
VALUE NOTATION : : = value (VALUE ObjectName)
Access : : = “read-only”|”read-write”|”write-only”|”not-accessible”
Status : : = “mandatory”|”optional”|”obsolete”|”deprecated”
DescrPart : : = “DESCRIPTION” value (description DisplayString)|empty
…
DisplayString : : = OCTET STRING SIZE (0..255) END
schmidt@informatik.
haw-hamburg.de
19
ASN.1 Types
Universal Types:
integer, octetstring, null, objectidentifier, sequence, sequence-of
Application Types for SNMP (v1/v2):
• Counter32/Counter64 nonnegative, incremented, wraps at max
• Unsigned32/Gauge32 nonnegative, in-/decreased, rests at max
• TimeTicks nonnegative, time since [10 ms]
• IpAddress 32-bit IPv4 address
• Opaque pass arbitrary data as octetstring
schmidt@informatik.
haw-hamburg.de
20
MIB Encoding in ASN.1
IF-MIB DEFINITIONS ::= BEGIN IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64, Integer32, TimeTicks, mib-2, NOTIFICATION-TYPE
FROM SNMPv2-SMI [...]
interfaces OBJECT IDENTIFIER ::= { mib-2 2 } ifNumber OBJECT-TYPE
SYNTAX Integer32 MAX-ACCESS read-only STATUS current
DESCRIPTION
"The number of network interfaces (regardless of their current state) present on this system."
::= { interfaces 1 } ifTable OBJECT-TYPE ....
....
ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry MAX-ACCESS not-accessible
[...]
::= { interfaces 2 } ifEntry OBJECT-TYPE
SYNTAX IfEntry [...]
INDEX { ifIndex } ::= { ifTable 1 }
IfEntry ::= SEQUENCE { ifIndex InterfaceIndex, ifDescr DisplayString, ifType IANAifType, ifMtu Integer32, […]
The Simple Network
Management Protocol (SNMP)
schmidt@informatik.
haw-hamburg.de
21
SNMP carries the communication between Network Management Agents and Stations.
> Asynchronous, simple Request / Response protocol
> Uses UDP for transport
> Requests are atomic and require exactly one response
> Provides requests
– to read data
– to manipulate data
– to receive alarm messages
> Simple, unencrypted Community String for authentication (v1)
schmidt@informatik.
haw-hamburg.de
22 SNMP manager
UDP port 162
SNMP agent
UDP port 161 UDP port 161 UDP port 161 get-request
get-response
get-next-request
get-response
get-response
trap set-request
SNMP
schmidt@informatik.
haw-hamburg.de
23
SNMP Message
schmidt@informatik.
haw-hamburg.de
24
SNMPv2/3
o
SNMPv2 extends SNMPv1 by
o Manager-Manager Messages (InformRequest) o GetBulkRequest PDU
o Extends SMI (e.g. 64 bit data types)
o
SNMPv3 = SNMPv2 + Security + Administration
o Completely backward compatible to SNMPv1 and SNMPv2*
o User-based Security Model (USM): Authentication & Encryption o View-based Access Control (VACM): Regulates Access on MIB
schmidt@informatik.
haw-hamburg.de
25
SNMPv3
> Provide management security: authentication & encryption
– include a secure Set request applicable over public networks
> Use existing work – comply with previous versions
> Define an architecture for
– longevity & extensibility – development in parts – minimal implementations
> Keep SNMP as simple as possible
schmidt@informatik.
haw-hamburg.de
26
SNMPv3 Architecture
> SNMPv3 follows a strictly modular architecture, designing basics for agent and NMS
> SNMPv3 engine consists of basic modules
Dispatcher – Message Processing – Security – Access Control
> Applications use the service of the engine
> Option for several Security Models
> New message format to distinguish contexts & security
models
schmidt@informatik.
haw-hamburg.de
27
SNMPv3 Architecture
OTHER
NOTIFICATION ORIGINATOR COMMAND
RESPONDER COMMAND
GENERATOR
NOTIFICATION RECEIVER
PROXY FORWARDER
SNMP APPLICATIONS
SNMP ENGINE
MESSAGE PROCESSING SUBSYSTEM
DISPATCHER SECURITY
SUBSYSTEM
ACCESS CONTROL SUBSYSTEM
SNMP ENTITY
OTHER
schmidt@informatik.
haw-hamburg.de
28
SNMPv3 Architecture: Manager
NOTIFICATION RECEIVER COMMAND
GENERATOR
PDU DISPATCHER
COMMUNITY BASED SECURITY MODEL
USER BASED SECURITY MODEL
OTHER
SECURITY MODEL SECURITY SUBSYSTEM
SNMPv1
SNMPv2C
SNMPv3
OTHER
MESSAGE PROCESSING SUBSYSTEM
MESSAGE DISPATCHER
TRANSPORT MAPPINGS
ORIGINATOR NOTIFICATION
schmidt@informatik.
haw-hamburg.de
29
SNMPv3 Architecture: Agent
PDU DISPATCHER
COMMUNITY BASED SECURITY MODEL
USER BASED SECURITY MODEL
OTHER
SECURITY MODEL SECURITY SUBSYSTEM
SNMPv1
SNMPv2C
SNMPv3
OTHER
MESSAGE PROCESSING SUBSYSTEM
MESSAGE DISPATCHER
TRANSPORT MAPPINGS
MANAGEMENT INFORMATION BASE
VIEW BASED ACCESS CONTROL
ACCESS CONTROL SUBSYSTEM
NOTIFICATION ORIGINATOR COMMAND
RESPONDER
schmidt@informatik.
haw-hamburg.de
30
SNMPv3 Message Structure
msgVersion msgID msgMaxSize
msgFlags msgSecurityModel
msgSecurityParameters
contextEngineID contextName
PDU
USED BY MESSAGE PROCESSING SUBSYSTEM USED BY SNMPv3 PROCESSING MODULE
USED BY SECURITY SUBSYSTEM
USED BY ACCESS CONTROL SUBSYSTEM AND APPLICATIONS
schmidt@informatik.
haw-hamburg.de
31
SNMPv3 Documents
RFC 2570 Internet Network Management Framework V3 RFC 2571 SNMP Architecture
RFC 2572 Message Processing and Dispatching for SNMP RFC 2573 SNMP Applications
RFC 2574 User-Based Security Model (USM)
RFC 2574 View-based Access Control Model (VACM)
RFC 3584 Coexistence between V1, V2, and V3 of the Internet - standard Network Management Framework
schmidt@informatik.
haw-hamburg.de
32
Network Management Systems
The SNMP model only defines the management framework, but no applications. This is left to network management systems (NMS).
They focus on:
– Collection and processing of data about the network – Visualisation of the network structure and states – Discovery and localisation of failures & alarms – Automatic failure recovery (if possible)
– High level network configuration support – Network accounting
Examples: HP OpenView, IBM Tivoli, CA Unicenter TNG, Aprisma Spectrum and many small solutions
schmidt@informatik.
haw-hamburg.de
33
Example: Aprisma Spectrum
schmidt@informatik.
haw-hamburg.de
34
Predefined Access Views
schmidt@informatik.
haw-hamburg.de
35
Network Topology View
schmidt@informatik.
haw-hamburg.de
36
Navigation into Detail View
schmidt@informatik.
haw-hamburg.de
37
Alarm Management
schmidt@informatik.
haw-hamburg.de
38
Spectrum Architecture
schmidt@informatik.
haw-hamburg.de
39
Spectrum Icons
schmidt@informatik.
haw-hamburg.de
40
Icon Functions
schmidt@informatik.
haw-hamburg.de
41
Link States
schmidt@informatik.
haw-hamburg.de
42
Web View
schmidt@informatik.
haw-hamburg.de
43
Network Management Systems (2)
> Discovery + Polling: Discovery and monitoring of basic network topology via ICMP und SNMP
> Generic MIB-II: Discovery and operation of standard node functions (e.g. interfaces)
> Standard MIBs: Discovery and operation of specific standard functions (e.g. switching, routing, …)
> Private MIBs: Discovery and operation of vendor specific functions (e.g. HP printers ...)
> For every specific function or device (i.e. MIB) explicit model information are needed in in the NMS <
schmidt@informatik.
haw-hamburg.de
44
Network Discovery
> Router Discovery: From Seed Router (by IP address) identify IP networks
> Node Discovery: Identify model (by IP address/range) via
sysObjectID, … and Default Attribute
> Auto discovery:
– Subsequent discovery of routers bridges/switches and nodes from IP network
– Identification of logical subnets and physical links (from ARP caches/Bridge forwarding tables)
– Construction of network topology
schmidt@informatik.
haw-hamburg.de
45
Topology Discovery for Switched Ethernetworks
Problem: How to learn topology of all switches in a L2 network Approach: Use Forwarding Databases Fixof port x at switch i
Direct Connection Theorem: Assume FDBs are complete, then ports x and y of switches i and k are directly connected
⇔ Fix ∩ Fky = ∅ and Fix ∪ Fky = {All MAC addresses}
Shared Segment Theorem: If FDBs are complete, then for all switches with connecting ports to one shared segment all
members of the shared segment must be found in FDBs of the same, connecting port
Lowekamp, O’Hallaron T. Gross: Topology Discovery in Large Ethernet Networks, ACM SIGCOMM01, San Diego, 2001
schmidt@informatik.
haw-hamburg.de
46
Simple Switch Connections
Facing incomplete information, how can we decide about the ports connecting switches?
Approach: Rule out by conflicts interfaces violating Ethernet’s acyclic-condition
Private MIB Module:
Ascend Dial-UP Router
schmidt@informatik.
haw-hamburg.de
47
schmidt@informatik.
haw-hamburg.de
48
Navigation into Private MIB
schmidt@informatik.
haw-hamburg.de
49
Utilization Overview
schmidt@informatik.
haw-hamburg.de
50
Session View
schmidt@informatik.
haw-hamburg.de
51
Limitations of SNMP Standard Perspective
> Network manager obtains state view through device MIB
> Standard MIB represents data purely local to the device
> NM retrieves network operation data by polling devices and aggregating information
Problems:
o Polling is inefficient (WAN-Links!)
o NM cannot look ‘directly’ into the network
o Monitoring cannot be configured at the device side
schmidt@informatik.
haw-hamburg.de
52
Remote Network Monitoring
- Basic Ideas -
> Most network devices are able to capture/ analyse traffic on their local subnet
> Use dedicated devices as ‘Network Monitors’ and report aggregated/ analysed data to the network manager
> Use SNMP set operation to configure monitoring
> Remain conformal to SNMP/ SMI formal framework, but add new semantic to it
⇒ RFC 1757 defines RMON, network monitors are called
‘RMON Probes’
schmidt@informatik.
haw-hamburg.de
53
RMON Goals
> Off-line operation: collect data locally without polling
> Proactive monitoring: log continuously and run diagnostics, notify management if necessary
> Problem detection and reporting: perform active or passive probing to check for errors and congestion
> Value-added-data: perform specific data analysis
> Multiple managers: cooperate with multiple managers
simultaneously
schmidt@informatik.
haw-hamburg.de
54
What RMON does
> Provides data model for the collection, pre-analysis and reporting of (L2) segment related network data
> RMON probes are remotely ‘programmable’, i.e.
configuration of variables and action invocation
> All probe ↔ NMS communication via SNMP But:
> RMON cannot analyse data exchange between
segments
schmidt@informatik.
haw-hamburg.de
55
How RMON works
Problem: How to invoke user-defined functions on a remote monitor and where to store the data?
Approach: All functions at the monitor are defined and implemented in terms of table rows.
Problem 2: How to configure remote tables from multiple managers via SNMP?
Solution: Split information into a (rw) Control Table and
a (ro) Data Table
schmidt@informatik.
haw-hamburg.de
56
RMON Table Structure
rm1ControlTable
ControlIndex ControlParameter ControlOwner ControlStatus
1 5 monitor valid(1)
2 26 manager valid(1)
3 19 watchdog underCreation(3)
1 1 46
2 1 96
2 2 85
3 - -
nonexistent
Create Request
Under Creation
valid invalid
by agent by manager
rm1DataTable
ControlIndex DataIndex DataValue
schmidt@informatik.
haw-hamburg.de
57
Placing RMON Probes
• Dedicated Probes
• Software Probes on standard hardware
• Integrated Probes
• Multisegment Probes in switch chassis etc
schmidt@informatik.
haw-hamburg.de
58
RMON MIB Tree
Root
ISO Org
DoD Internet Mgmt
MIB 1 & 2
RMON
MIB 1
MIB 2
Private
1. Statistics
9. Event 7. Filter 8. Capture 6. Matrix
5. Host Top N 4. Hosts
3. Alarm 2. History
10. Token Ring
schmidt@informatik.
haw-hamburg.de
59
RMON MIB Groups
> Statistics: Basic (Ethernet) statistics of segment, i.e. packet types, drops, collisions, errors, lengths
> History*: Collects/accumulates data from statistics group according to configured times/intervals
> Alarm*: Configurable ‘Watchdog’ on watermarks for any MIB state variable, generates configurable alarms to NMS
> Host*: Generates traffic statistics per host (MAC address)
> Host TopN*: Generates per host ‘topN’ history based on host group data, data and time interval configurable
* group configurable
schmidt@informatik.
haw-hamburg.de
60
Example: Ethernet Statistics
schmidt@informatik.
haw-hamburg.de
61
RMON MIB Groups (2)
> Matrix*: Collects host-to-host traffic matrix (based on configured MAC addresses)
> Event*: Configurable logging/ trapping based on other RMON values
> Filter*: Filtering of dedicated L2-Pakets according to bits or states, including logical operations
> Packet Capture*: Definition of filter result buffers & buffer operations
! Caveat: RMON operations may place heavy load on devices, many RMON probes deactivate/don’t implement groups ≥ 4
* group configurable
schmidt@informatik.
haw-hamburg.de
62
Configure
RMON
schmidt@informatik.
haw-hamburg.de
63
Configured Host Monitoring
schmidt@informatik.
haw-hamburg.de
64
RMON at Praxis
schmidt@informatik.
haw-hamburg.de
65
Traffic Accounting per VLAN
schmidt@informatik.
haw-hamburg.de
66
Beyond RMON
RMON probes can only monitor traffic on the subnetwork-layer
– IP and upper layer protocols invisible – does not see ‘beyond’ a router
Higher layer protocol monitoring is placed in RMON-2
– Straight forward extension of the RMON MIB tree (including some added values in RMON-1 groups)
– Allows for logical end-to-end view of application communication – RFCs 2021, 2074/2895
schmidt@informatik.
haw-hamburg.de
67
RMON-2 MIB Extensions
MIB 1&2
MIB 1
MIB 2
Root
ISO Org
DoD Internet Mgmt Private
RMON1 1. Statistics
9. Event 7. Filter 8. Capture 6. Matrix 5. Host Top N 4. Hosts 3. Alarm 2. History
10. Token Ring
RMON2
11. Protocol Directory
19. Probe Configuration 17. Application-Layer Matrix 18. User History
16. Application-Layer Host 15. Network-Layer Matrix 14. Network-Layer Host 13. Address Map
12. Protocol Distribution
20. RMON Conformance
RMON
schmidt@informatik.
haw-hamburg.de
68
RMON-2 MIB Groups
> Protocol Directory: Master directory of all protocols that the probe can interpret
> Protocol Distribution: Aggregates statistics on traffic generated by each protocol + LAN segment
> Address Map: Matches each network address to a specific MAC address + (phys.) device port on this subnetwork
> Network-Layer Host: Host statistics on basis of network address
> Network Layer Matrix: Traffic statistics on host pairs based on network addresses
schmidt@informatik.
haw-hamburg.de
69
RMON-2 MIB Groups (2)
> Application-Layer Host: Statistics on traffic amounts in and out of hosts based on application-level addresses
> Application-Layer Matrix: Traffic statistics in and out of host pairs based on application-level addresses
> User History Collection: Periodic samples of user-specified variables and logs
> Probe Configuration: Defines standard configuration parameters for RMON probes
> RMON Conformance: Conformance requirements
schmidt@informatik.
haw-hamburg.de
70
RMON-2 Application View
schmidt@informatik.
haw-hamburg.de
71
Résumé on RMON
+ Largely extends perspective beyond standard SNMP + In detail configurable monitoring & analysis
+ Traffic matrix for hosts & applications for detailed views + Provides configurable events, alarms & packet analysis - Places heavy load on network components
- Full implementations rare, compatibility an issue - Data lost, when component crashes
- RMON-1 concept for shared, unswitched segments
schmidt@informatik.
haw-hamburg.de
72
Switched Networks
Switches provide Layer 2 intelligence:
> L2 forwarding – FDB found in Dot1dBridge MIB (RFC 1493)
> L2 redundancy – automatic configuration and adaptation of Spanning Trees (802.1D)
> Virtual segmentation on L2 – configuration of port-based Virtual LANs (VLAN – 802.1Q)
> L2 prioritisation – QoS support within subnet distribution (802.1p)
schmidt@informatik.
haw-hamburg.de
73
Ethernet Redundancy:
Spanning Tree (802.1D)
Problem: Inter-Switch redundancy generates Forwarder-Loops.
Solution: Dynamic Spanning Trees 1. Root Discovery:
Choose Switch with smallest serial # 2. Paths Generation: Shortest path to root
from any network. Remaining links on ‘stand by’.
3. Loop: Generate paths to discover topological changes.
o Spanning Tree slow –
Improvement: Fast Spanning Tree
schmidt@informatik.
haw-hamburg.de
74
Spanning Tree MIB
> Part of Bridge MIB (RFC 1493), Subgroup: dot1dStp
– dot1dStpPort - Spanning Tree Port Table – dot1dStpPortState – state of ports
– dot1dStpPortPriority – priority in Spanning Tree algorithm – Root identification – Root-ID/ cost/ port
– Timer – Life-/ hello-/ age- timer
– dot1dStpForwardDelay – time value of listening-to-forwarding
> Very useful to gain exact topology information
schmidt@informatik.
haw-hamburg.de
75
802.1Q/p - Tagging
Tag Protocol Identifier=0x8100 Canonical Format Identifier Priority Tagging für 802.1p VLAN ID: 802.1Q Zuordnung
schmidt@informatik.
haw-hamburg.de
76
Example:
VLAN
Topology
schmidt@informatik.
haw-hamburg.de
77
802.1Q/p VLAN MIB
Defined in dot1dBridge MIB extensions (RFC 2674):
> pBridgeMIB (6) – support for multiple traffic classes &
dynamic multicast filtering
– dot1dPriority – user priority treatment per port
– dot1dGarp – Generic Attribute Registration Protocol – dot1dGmrp – GARP Multicast Registration Protocol
> qBridgeMIB (7) – support for bridged Virtual LANs
– dot1qBase – per switch VLAN configuration – dot1qVLAN – per port VLAN configuration – dot1qTP – per port VLAN filtering database
– dot1qStatic – static entries in the filtering database
schmidt@informatik.
haw-hamburg.de
78
VLAN & Spanning Tree
schmidt@informatik.
haw-hamburg.de
79
Monitoring a Switched Network
Problem: RMON was made for shared segments – How to ob- tain a network monitoring view in today’s switched networks ? Approaches:
1. Place RMON Probe on every switch port
but: segmented view, no support for VLANs, priorities & LAG 2. Duplicate all traffic to one switch port with RMON probe
3. Collect traffic statistic within the switch fabric with RMON probe
Still missing: VLAN & Classification view
schmidt@informatik.
haw-hamburg.de
80
Switch Monitoring - SMON
> Standard MIB extension of RMON (RFC 2613)
> Provides internal switch monitoring and control of port- copy
> smonStats Group for VLAN traffic monitoring and priority statistics
> Proprietary SMON II activities – no IETF tracks
schmidt@informatik.
haw-hamburg.de
81
SMON MIB
schmidt@informatik.
haw-hamburg.de
82
Reading:
ªRose, Marshall T.: The Simple Book, Pearson 1996.
ª Stevens, Richard W.: TCP/IP Illustrated, Vol 1, Addison-Wesley 1994.
ª Stallings, William: SNMP, SNMPv2, SNMPv3 and RMON 1 and 2, Addison-Wesley 2001.
ª Aprisma: Getting Started for Administrators & Operators
