PIM-SSM – IP Multicast and Network Management

PIM Source-Specific Multicast (PIM-SSM) is a variant of PIM-SM that builds trees that are rooted in just one source. SSM, defined in RFC 3569, eliminates the RPs and shared trees of sparse mode and only builds an SPT. SSM trees are built directly based on the receipt of group membership reports that request a given source. SSM is suitable for when well-known sources exist within the local PIM domain and for broadcast applications.

MSDP

Multicast Source Discovery Protocol (MSDP), described in RFC 3618, is used to interconnect multiple PIM-SM domains. MSDP reduces the complexity of interconnecting multiple PIM-SM domains by allowing the PIM-SM domains to use an interdomain source tree.

With MSDP, the RPs exchange source information with RPs in other domains. Each PIM-SM domain uses its own RP and does not depend on the RPs in other domains.

When an RP in a PIM-SM domain first learns of a new sender, it constructs a Source-Active (SA) message and sends it to its MSDP peers. All RPs that intend to originate or receive SA messages must establish MSDP peering with other RPs, either directly or via an intermediate MSDP peer.

The SA message contains the following information:

  • The source address of the data source
  • The multicast group address
  • The IP address of the RP

Sources cause PIM to register with the RP, and MSDP can tell RPs in other domains of their sources. Each MSDP peer receives and forwards the message away from the RP address in a “peer-RPF flooding” fashion (with respect to forwarding SA messages). The Multicast Routing Information Base (MRIB) is examined to determine which peer toward the originating RP of the SA message is selected.

Summary of Multicast Protocols

Table 5-3 summarizes IP Multicast protocols.   

Table 5-3 IP Multicast Protocols

IP Multicast ProtocolDescription
IGMPA host sends an IGMP query message to the router, and the switch adds the host to the multicast group and permits that port to receive multicast traffic.
PIM-SMThis protocol assumes that no hosts want to receive multicast traffic unless specifically requested.
BIDIR-PIMThis protocol never builds a shortest path tree.
PIM-SSMThis protocol eliminates the RPs and shared trees and only builds an SPT.
MSDPThis protocol is used to interconnect multiple PIM-SM domains.

IPv6 Multicast Addresses – IP Multicast and Network Management

IPv6 retains the use and function of multicast addresses as a major address class. IPv6 prefix FF00::/8 is allocated for all IPv6 multicast addresses. IPv6 multicast addresses are described in RFC 2373. The EIGRP for IPv6, OSPFv3, and RIPng routing protocols use multicast addresses to communicate between router neighbors.

The format of the IPv6 multicast address is described in Chapter 2, “Internet Protocol Version 6 (IPv6) Design.” Table 5-4 lists the common multicast addresses.

Table 5-4 Well-Known Multicast Addresses

Multicast AddressMulticast Group
FF01::1All nodes (node-local)
FF02::1All nodes (link-local)
FF01::2All routers (node-local)
FF02::2All routers (link-local)
FF02::5OSPFv3 routers
FF02::6OSPFv3 DRs
FF02::9Routing Information Protocol (RIPng)
FF02::AEIGRP routers
FF02::BMobile agents
FF02::CDHCP servers/relay agents
FF02::DAll PIM routers

Network Management Design

After a new network is designed, installed, and configured, it must be managed by the operations team. Network management tools are used to gather operating statistics and to manage devices. These network management devices use protocols such as SNMP and RMON to obtain information on network performance.

Statistics are gathered on WAN bandwidth utilization, router CPU and memory utilization, and interface counters. Configuration changes are also made through network management tools such as Cisco Prime. The ISO defines five types of network management processes that are commonly known as FCAPS:

  • Fault management: Refers to detecting and correcting network fault problems
  • Configuration management: Refers to baselining, modifying, and tracking configuration changes
  • Accounting management: Refers to keeping track of circuits for billing of services
  • Performance management: Measures the network’s effectiveness at delivering packets
  • Security management: Tracks the authentication and authorization information

Network management is supported by the elements listed in Table 5-5.

Table 5-5 Network Management Elements

Network Management ElementDescription
Network management system (NMS)Runs the applications that manage and monitor managed devices.
Network management protocols and standardsUsed to exchange management information between the NMS and the managed devices. The key protocols and standards are SNMP, MIB, and RMON.
Managed devicesManaged by the NMS.
Management agentsReside in the managed devices and include SNMP agents and RMON agents.

The protocols and tools described in this chapter perform some of these functions. SNMP is the underlying protocol used for network management. Agents are configured in managed devices (routers) that allow the NMS to manage the devices. RMON is used for advanced monitoring of routers and switches. CDP is a Cisco proprietary protocol that enables the discovery of Cisco devices. NetFlow is a network monitoring solution that allows for greater scalability than RMON. Syslog allows system messages and error events to be gathered for review.

SNMP – IP Multicast and Network Management

Simple Network Management Protocol (SNMP) is an IP application layer protocol that has become the standard for the exchange of management information between network devices. SNMP, which was initially described in RFC 1157, is a simple solution that requires little code to implement and allows vendors to build SNMP agents on their products.

SNMP runs over User Datagram Protocol (UDP) and therefore does not inherently provide for sequencing and acknowledgment of packets, but it still reduces the amount of overhead used for management information.

SNMP Components

SNMP has three network-managed components:

  • The managed devices: A managed device is a router or LAN switch or any other device that contains an SNMP agent. Managed devices collect and store management information and make this information available to the NMS. SNMP community strings (passwords) are configured on routers and switches to allow for SNMP management.
  • The agent: The agent is the network management software that resides in the managed device. The agent gathers the information and puts it in SNMP format. It responds to the manager’s request for information and generates traps.
  • The NMS: The NMS has applications that are used to monitor and configure managed devices. It is also known as the manager. The NMS provides the bulk of the processing resources used for network management. It polls agents on the network and correlates and displays the management information.

Figure 5-3 shows the relationship between these components.

Figure 5-3 SNMP Components

Network Management Design Considerations

Network routers and switches need to be monitored and managed remotely. Network architects must keep in mind several design considerations for NMS systems and solutions.

In-Band Versus Out-of-Band Network Management

A network architect should define VLANs and reserve IP address subnets for network management. These addresses are used to allocate network management IPs for routers, switches, and firewalls. For in-band network management, the IP subnet used is part of the internal routing domain and is trunked like any other VLAN in the network. One common solution is to use a loopback address for network management, separate from the loopback address used for routing. An in-band solution is not segmented from the primary traffic and address bandwidth usage. One possible way to segment the management traffic is to use a dedicated management VRF and assign the management interface of network devices to this VRF.

For an out-of-band (OOB) management solution, a separate network is built for access devices via the OOB or auxiliary ports of devices. Note that OOB network management should have separate credentials (for logging in to devices) and should not be used as a backup to the primary network that is being managed. The OOB management network does not use bandwidth of the primary network; a separate infrastructure has to be built. OOB networks can grant and revoke access privileges and be configured to allow only SSH, NTP, FTP, and SNMP protocols.

Network Management Traffic Prioritization

Although network management traffic may not be considered as critical as voice and video traffic, it does merit some prioritization. In Cisco QoS classification and marking recommendations, network management traffic is given a Layer 3 classification of CS1 PHB (DSCP 16) or Layer 2 CoS of 2.

MIB – IP Multicast and Network Management

A Management Information Base (MIB) is a collection of information that is stored on the local agent of a managed device. MIBs are organized hierarchically and are accessed by the NMS. MIBs are databases of objects organized in a tree-like structure, with each branch containing similar objects. Each object has an object identifier (number) that uniquely identifies the managed object of the MIB hierarchy. Read and write community strings are used to control access to MIB information.

The top-level MIB object IDs belong to different standards organizations, and lower-level object IDs are allocated to associated organizations. Standard MIBs are defined by RFCs. Vendors define private branches that include managed objects for their products. Figure 5-4 shows a portion of the MIB tree structure. RFC 1213 describes the MIBs for TCP/IP. Cisco defines the MIBs under the Cisco head object. For example, a Cisco MIB can be uniquely identified by either the object name iso.org.dod.internet.private.enterprise.cisco or the equivalent object descriptor 1.3.6.1.4.1.9.

Figure 5-4 MIB Tree Structure

Each manageable feature in the MIB is called an MIB variable. The MIB module is a document that describes each manageable feature that is contained in an agent. The MIB module is written in Abstract Syntax Notation 1 (ASN.1). Three ASN.1 data types are required: name, syntax, and encoding. The name serves as the object identifier. The syntax defines the object’s data type (integer or string). The encoding data describes how information associated with a managed object is formatted as a series of data items for transmission on the network. The following are examples of standard managed objects that can be obtained from the MIB tree:

  • Interfaces
  • Buffers
  • Memory
  • Standard protocols

From the Cisco private tree, you can obtain the following additional information:

  • Small, medium, and large buffers
  • Primary and secondary memory
  • Proprietary protocols (such as Enhanced Interior Gateway Routing Protocol [EIGRP])

SNMP Versions

SNMP was initially defined in RFC 1157. Since then, SNMP has evolved, and each new version has added new message types.

SNMPv1

SNMPv1, defined in RFC 1157, is a simple request-and-response protocol. The NMS manager issues a request, and managed devices return responses. The data types are limited to 32-bit values. SNMPv1 uses four protocol operations with five message types to carry out the communication:

  • Get Request: Retrieves the value of a specific MIB variable.
  • GetNext Request: Retrieves the next instance of the MIB variable.
  • Get Response: Contains the values of the requested variable.
  • Set Request: Specifies a request from the manager to the agent to set an MIB variable. It can be used to modify the agent’s configuration.
  • Trap: Transmits an unsolicited alarm condition.

Figure 5-5 shows the SNMPv1 message types.

Figure 5-5 SNMPv1 Message Types

The NMS manager uses the Get operation to retrieve the value-specific MIB variable from an agent. The GetNext operation is used to retrieve the next object instance in a table or list within an agent. The Get Response contains the value of the requested variable.

The NMS manager uses the Set operation to set values of the object instance within an agent. For example, the Set operation can be used to set an IP address on an interface or to bring an interface up or down. Agents use the Trap operation to inform the NMS manager of a significant alarm event. For example, a trap is generated when a WAN circuit goes down.

SNMPv2 – IP Multicast and Network Management

SNMPv2, defined in RFCs 1901 and 1902, is an evolution of the initial SNMPv1. SNMPv2 offers improvements to SNMPv1, including additional protocol operations. The Get, GetNext, and Set operations used in SNMPv1 are exactly the same as those used in SNMPv2. The SNMP Trap operation serves the same function as in SNMPv1, but it uses a different message format.

SNMPv2 defines two new protocol operations:

  • GetBulk: Reduces repetitive requests for MIB variables.
  • Inform Request: Alerts an SNMP manager about specific conditions with confirmation.

The NMS manager uses the GetBulk operation to retrieve large blocks of data, such as multiple rows in a table. This is more efficient than repeating GetNext commands. If the agent responding to the GetBulk operation cannot provide values for all the variables in a list, it provides partial results. The Inform operation allows one NMS manager to send trap information to other NMS managers and to receive information. The difference between Inform Request and Trap is that Inform Request requires an acknowledgment. Another improvement is that data type values can be 64 bits.

Table 5-6 summarizes SNMP message types.

Table 5-6 SNMP Message Types

SNMP MessageDescription
Get RequestRetrieves the value of a specific MIB variable.
GetNext RequestRetrieves the next issuance of the MIB variable.
Get ResponseContains the values of the requested variable.
Set RequestModifies the value of an MIB variable.
TrapTransmits an unsolicited alarm condition.
GetBulkReduces repetitive requests for MIB variables.
Inform RequestAlerts an SNMP manager about specific conditions with a confirmation.
SNMPv3

SNMPv3 was developed to correct several deficiencies in the earlier versions of SNMP, especially related to security. SNMPv3, defined in RFCs 3410 through 3415, provides authentication and privacy via usernames and access control through key management. SNMPv3 also verifies each message to ensure that it has not been modified during transmission. SNMPv3 removes the use of community-based authentication strings sent in plaintext over the network. It is recommended that SNMPv1 and SNMPv2 be used only for read-only access and that SNMPv3 be used with read/write access.

SNMPv3 introduces three levels of security:

  • noAuthNoPriv: No authentication and no encryption
  • authNoPriv: Authentication and no encryption
  • authPriv: Authentication and encryption

Authentication for SNMPv3 is based on the Hash-based Message Authentication Code–Message Digest 5 (HMAC-MD5) and HMAC–Secure Hash (HMAC-SHA) algorithms. The Cipher Block Chaining–Data Encryption Standard (CBC-DES) standard is used for encryption.

Table 5-7 summarizes SNMP security levels.

Table 5-7 SNMP Security Levels

VersionLevelAuthenticationEncryption
SNMPv1NoAuthNoPrivCommunity stringNone
SNMPv2NoAuthNoPrivCommunity stringNone
SNMPv3NoAuthNoPrivUsernameNone
SNMPv3AuthNoPrivMD5 or SHANone
SNMPv3AuthPrivMD5 or SHADES, 3DES, AES

Other Network Management Technologies – IP Multicast and Network Management

This section covers technologies used to gather network information, such as RMON, NetFlow, CDP, LLDP, and syslog.

RMON

Remote Monitoring (RMON) is a standard monitoring specification that enables network monitoring devices and console systems to exchange network monitoring data. RMON provides more information than SNMP, but it also requires more sophisticated data collection devices (network probes). RMON looks at MAC-layer data and provides aggregate information on the statistics and LAN traffic.

Enterprise networks deploy network probes on several network segments; these probes report back to the RMON console. RMON allows network statistics to be collected even if a failure occurs between a probe and the RMON console. RMON1 is defined in RFCs 1757 and 2819, and additions for RMON2 are defined in RFC 2021.

The RMON MIB is located at iso.org.dod.internet.mgt.mib.rmon or the equivalent object descriptor 1.3.6.1.2.1.16. RMON1 defines nine monitoring groups, each of which provides specific sets of data. An additional group beyond these nine is defined for Token Ring. Each group is optional, so vendors do not need to support all the groups in the MIB. Table 5-8 shows the RMON1 groups.

Table 5-8 RMON1 Groups

Group IDGroup NameDescription
1StatisticsContains real-time statistics for interfaces, including packets sent, bytes, cyclic redundancy check (CRC) errors, and fragments.
2HistoryStores periodic statistical samples for later retrieval.
3AlarmGenerates an alarm event if a statistical sample crosses a threshold.
4HostProvides host-specific statistics.
5HostTopNLists the most active hosts.
6MatrixStores statistics for conversations between two hosts.
7FiltersAllows packets to be filtered.
8Packet CaptureAllows packets to be captured for subsequent analysis.
9EventsGenerates event notifications.
RMON2

RMON1 is focused on the data link and physical layers of the OSI model. As shown in Figure 5-6, RMON2 provides an extension for monitoring upper-layer protocols.

Figure 5-6 RMON1 and RMON2 Compared to the OSI Model

RMON2, defined in RFC 2021, extends the RMON group with the MIB groups listed in Table 5-9.

Table 5-9 RMON2 Groups

Group IDGroup NameDescription
11Protocol DirectoryLists the protocols the device supports.
12Protocol DistributionProvides traffic statistics for each protocol.
13Address MappingContains network-to-MAC-layer address mapping (IP address to MAC address).
14Network Layer HostContains statistics for traffic sent to or from network layer hosts.
15Network Layer MatrixContains statistics for conversations between two network layer hosts.
16Application Layer HostContains application layer statistics for traffic sent to or from hosts.
17Application Layer MatrixContains application layer statistics for conversations between pairs of hosts.
18User HistoryContains periodic samples of specified variables.
19Probe ConfigurationProbes parameter configuration.

NetFlow 2 – IP Multicast and Network Management

The NetFlow export or transport mechanism sends the NetFlow data to a collection engine or network management collector. Flow collector engines perform data collection and filtering. They aggregate data from several devices and store the information. Different NetFlow data analyzers can be used, depending on the intended purpose. NetFlow data can be analyzed for the following key applications:

  • Accounting and billing: Service providers can use NetFlow data for charging based on bandwidth and application usage and quality of service (QoS).
  • Network planning and analysis: NetFlow data can be used to determine link and router capacity.
  • Network and security monitoring: NetFlow data can be used to visualize real-time traffic patterns.
  • Application monitoring and profiling: NetFlow data can be used to get time-based views of application usage.
  • User monitoring and profiling: NetFlow data can be used to identify customer and user network utilization and resource application.
  • NetFlow data warehousing and mining: NetFlow data can be warehoused for later retrieval and analysis.

Looking ahead, Cisco has introduced Flexible NetFlow as the next generation in flow technology. Flexible NetFlow has many benefits beyond the Cisco traditional NetFlow functionality available for years in Cisco hardware and software.

The key advantages to using Flexible NetFlow are as follows:

  • Flexibility and scalability of flow data beyond traditional NetFlow
  • The ability to monitor a wider range of packet information to produce new information about network behavior that was not available previously
  • Enhanced network anomaly and security detection
  • User-configurable flow information to perform customized traffic identification and the ability to focus and monitor specific network behavior
  • Convergence of multiple accounting technologies into one accounting mechanism

Flexible NetFlow is an integral part of Cisco IOS software that collects and measures data, allowing all routers or switches in the network to become sources of telemetry and monitoring devices. Flexible NetFlow allows extremely granular and accurate traffic measurements and high-level aggregated traffic collection. Because it is part of Cisco IOS software, Flexible NetFlow enables Cisco product-based networks to perform traffic flow analysis without external probes being purchased, thus making traffic analysis economical for large IP networks.

Flexible NetFlow can track the following packet information for Layer 2, IPv4, and IPv6 flows:

  • Source and destination MAC addresses
  • Source and destination IPv4 or IPv6 addresses
  • Source and destination TCP/User Datagram Protocol (UDP) ports
  • Type of service (ToS)
  • DSCP
  • Packet and byte counts
  • Flow timestamps
  • Input and output interface numbers
  • TCP flags and encapsulated protocol (TCP/UDP) and individual TCP flags
  • Sections of packets for deep packet inspection
  • All fields in the IPv4 header, including IP-ID and TTL
  • All fields in the IPv6 header, including Flow Label and Option Header
  • Routing information such as next-hop address, source autonomous system (AS) number, destination AS number, source prefix mask, destination prefix mask, BGP next hop, and BGP policy accounting traffic index

NetFlow – IP Multicast and Network Management

Cisco NetFlow enables tracking of IP flows as they are passed through routers and multilayer switches. An IP flow is a set of IP packets within a specific time slot that share a number of properties, such as the same source address, destination address, type of service, and protocol number. NetFlow information is forwarded to a network data analyzer, network planning tools, RMON applications, or accounting and billing applications. NetFlow allows for network planning, traffic engineering, usage-based network billing, accounting, denial-of-service monitoring capabilities, and application monitoring. One big benefit is that NetFlow provides the necessary data for billing of network usage. The most recent version of NetFlow is NetFlow version 9, which is defined in RFC 3954. The NetFlow protocol itself has been superseded by Internet Protocol Flow Information Export (IPFIX). Based on the NetFlow version 9 implementation, IPFIX is on the IETF standards track with RFCs 7011 and 7015.

As shown in Figure 5-7, NetFlow consists of three major components:

Figure 5-7 NetFlow Components

  • NetFlow accounting: Collects IP data flows entering router or switch interfaces and prepares data for export. It enables the accumulation of data on flows with unique characteristics, such as IP addresses, applications, and classes of service.
  • Flow collector engines: Capture exported data from multiple routers and filters and aggregate the data according to customer policies and then store this summarized or aggregated data. Examples of collectors are Cisco NetFlow Collector, SolarWinds, and CA NetQoS.
  • Network data analyzers: Display a graphical user interface (GUI) and analyze NetFlow data collected from flow collector files. This allows users to complete near-real-time visualization or trending analysis of recorded and aggregated flow data. Users can specify the router and aggregation scheme and the desired time interval.

The benefits of using NetFlow include the following:

  • Ability to obtain detailed information with minimal impact to the network devices
  • Ability to customize the data captures for each interface
  • Ability to include data timestamping across a large number of devices
  • Ability to meter network traffic providing data for billing based on network usage
  • Ability to detect and mitigate threats

Routers and switches are the network accounting devices that gather the statistics. These devices aggregate data and export the information. Each unidirectional network flow is identified by both source and destination IP addresses and transport layer port numbers. NetFlow can also identify flows based on IP protocol number, type of service, and input interface. NetFlow data records contain the following information:

  • Source and destination IP addresses
  • Source and destination TCP/UDP ports
  • Type of service (ToS)
  • Packet and byte counts
  • Start and end timestamps
  • Input and output interface numbers
  • TCP flags and encapsulated protocol (TCP/UDP)
  • Routing information (including next-hop address, source and destination autonomous system number, and destination prefix mask)
  • Data analyzers

NetFlow Compared to RMON and SNMP – IP Multicast and Network Management

NetFlow enables you to gather more statistical information than RMON with fewer resources. It provides greater detail on the collected data, with date- and timestamping. NetFlow has greater scalability and does not require network probes. NetFlow reports on traffic statistics and is push based, whereas SNMP reports primarily on device statistics and is pull based.

NetFlow can be configured on individual Layer 3 interfaces on routers and Layer 3 switches. NetFlow provides detailed information on the following:

  • Source and destination IP addresses
  • Source and destination interface identifiers
  • TCP/UDP source and destination port numbers
  • Number of bytes and packets per flow
  • Source and destination autonomous system numbers
  • IP type of service (ToS)
CDP

Cisco Discovery Protocol (CDP) is a Cisco-proprietary protocol that can be used to discover only Cisco network devices. CDP is media and protocol independent, so it works over Ethernet, Frame Relay, ATM, and other media. The requirement is that the media support Subnetwork Access Protocol (SNAP) encapsulation. CDP runs at the data link layer of the OSI model. CDP uses Hello messages; packets are exchanged between neighbors, but CDP information is not forwarded. In addition to routers and switches, Cisco IP Phones and Cisco Unified Communications Manager (CUCM) servers advertise CDP information.

Being protocol and media independent is CDP’s biggest advantage over other network management technologies. CDP provides key information about neighbors, including platforms, capabilities, and IP addresses, which is significant for network discovery. It is useful when SNMP community strings are unknown when performing network discovery.

When displaying CDP neighbors, you can obtain the following information:

  • Local interface: The local interface that is connected to the discovered neighbor
  • Device ID: The name of the neighbor device and its MAC address or serial number
  • Device IP address: The IP address of the neighbor
  • Hold time: How long (in seconds) to hold the neighbor information
  • Device capabilities: The type of device discovered: router, switch, transparent bridge, host, IGMP, or repeater
  • Version: The IOS or switch OS version
  • Platform: The router or switch model number
  • Port ID: The interface of the neighboring device

Network management devices can obtain CDP information for data gathering. CDP should be disabled on untrusted interfaces, such as those that face the Internet, third-party networks, and other secure networks. CDP works only on Cisco devices.

Note

Disable CDP on interfaces for which you do not want devices to be discovered, such as Internet connections.

LLDP – IP Multicast and Network Management

Link Layer Discovery Protocol (LLDP), defined in the IEEE 802.1AB (LLDP) specification, is an option for discovering network devices in multivendor networks. LLDP performs functions similar to those of CDP. With LLDP, devices send information at a fixed interval from each of their interfaces in the form of an Ethernet frame with Ethertype 0x88CC. The information shared includes the following:

  • System name and description
  • Port name and description
  • VLAN name
  • IP management address
  • System capabilities
  • MAC/PHY layer information
  • Link aggregation
Syslog

Syslog, which is defined in RFC 3164, transmits event notification messages over the network. Network devices send the event messages to an event server for aggregation. Network devices include routers, servers, switches, firewalls, and network appliances. Syslog operates over UDP, so messages are not sequenced or acknowledged. The syslog messages are also stored on the device that generates the message and can be viewed locally.

Syslog messages are generated in many broad areas, called facilities. Cisco IOS has more than 500 facilities. Common facilities include the following:

  • IP
  • CDP
  • OSPF
  • TCP
  • Interface
  • IPsec
  • SYS operating system
  • Security/authorization
  • Spanning Tree Protocol

Each syslog message has a level, and the syslog level determines the criticality of an event. Lower syslog levels are more important. Table 5-10 lists the syslog levels.

Table 5-10 Syslog Message Levels

Syslog LevelSeverityDescription
0EmergencySystem is unusable.
1AlertTake action immediately.
2CriticalCritical conditions.
3ErrorError messages.
4WarningWarning conditions.
5NoticeNormal but significant events.
6InformationalInformational messages.
7DebugDebug-level messages.

Common syslog messages are interface up and interface down events. Access lists can also be configured on routers and switches to generate syslog messages when a match occurs. Each syslog message includes a timestamp, a level, and a facility. Syslog messages have the following format:

Click here to view code image

mm/dd/yy:hh/mm/ss:FACILITY-LEVEL-mnemonic:description

Syslog messages can use considerable network bandwidth. It is important to enable only syslog facilities and levels that are of particular importance.

Table 5-11 summarizes some of the protocols covered in this section.

Table 5-11 NetFlow, CDP, Syslog, and RMON

TechnologyDescription
NetFlowCollects network flow data for network planning, performance, accounting, and billing applications.
CDPProprietary protocol for network discovery that provides information on neighboring devices.
SyslogReports state information based on facility and severity levels.
RMONProvides aggregate information of network statistics and LAN traffic.