Understanding Prime NAM Traffic Sources
Before you can monitor data using Prime NAM software, you must direct specific traffic flowing through a switch or router to the Prime NAM. This appendix explains the various data sources that you can configure for Prime NAM.
This appendix contains the following topics:
For details on supported data sources, see the NAM Compatibility Matrix.
Data Source Overview
Prime NAM uses various data sources to deliver its performance troubleshooting functionality:
To understand which methods to use to direct specific traffic to the Prime NAM software, see Table A-1 .
Table A-1 Methods of Directing Traffic
|
|
|
You can direct a set of physical ports, a set of VLANs, or a set of EtherChannels to the Prime NAM. Selecting an EtherChannel as a SPAN source is the same as selecting all physical ports comprising the EtherChannel as the SPAN source. On some NAM platforms, using SPAN allows for NAM configuration without having to use the switch. See, Forwarding SPAN Traffic. |
Switch Remote SPAN (RSPAN)1
|
You can monitor packet streams from remote switches, assuming that all traffic from a remote switch arrives at the local switch on a designated RSPAN VLAN. Use the RSPAN VLAN as the SPAN source for the NAM. |
Encapsulated Remote Switched Port Analyzer (ERSPAN)1
|
You can monitor traffic on one or more ports, or one or more VLANs, and send the monitored traffic to one or more destination ports using ERSPAN. ERSPAN sends traffic to a network analyzer such as a SwitchProbe device or other Remote Monitoring (RMON) probe. ERSPAN supports source ports, source VLANs, and destination ports on different routers or switches, which provides remote monitoring of multiple routers or switches across your network. See Forwarding ERSPAN Traffic. |
NetFlow Data Export (NDE)
|
Prime NAM analyzes NetFlow from Managed Devices (Routers/Switches) You can monitor NetFlow records directly from remote switches or routers. You must configure the NetFlow packet source to the Cisco NAM from a local switch or remote router using the device CLI. For received NetFlow traffic, a default site will be created including all interfaces from that device. See Configuring Sites. SPAN and NetFlow sources can be in effect simultaneously. See Forwarding NetFlow Traffic. |
|
Used as a southbound interface for configuration and data retrieval from switches and routers. Prime NAM uses web services as the northbound interface for data objects. The software continues to support baseline manageability features of SNMP such as MIB-2 and IF-TABLE for the NAM, and the health status and interface statistics that can be used by external products like Fault and Configuration Management offerings (for example, CiscoWorks LMS and Prime Infrastructure). |
|
Applies to Cisco NAM appliances only. For details, see your appliance installation guide.
|
|
You can enable CEF traffic monitoring on one or more ports and send the monitored CEF traffic to an UCSE NAM. See Understanding How the Prime NAM Uses VACLs in Catalyst Switch |
The Data Sources page (Setup > Traffic > NAM Data Sources) lists the data sources configured for your Cisco NAM. Table D-2 describes the fields in the NAM Data Sources window.
Table A-2 summarizes the traffic sources that are used for Prime NAM monitoring.
Table A-2 Summary of Traffic Sources for Prime NAM Monitoring
|
|
|
|
|
|
|
|
VACL capture |
Yes |
Yes |
Yes |
N/A |
NetFlow Data Export NDE (local) |
Yes |
Yes |
Yes |
Yes |
NetFlow Data Export NDE (remote) |
Yes |
Yes |
Yes |
Yes |
SPAN |
Yes |
Yes |
No |
No |
ERSPAN |
Yes |
Yes |
No |
No |
Ports and Hardware Details
NAM-3 and NAM-NX1 each have two dataports.. Each dataport can accept one SPAN session. Depending on the managed device operating system (OS) version, the number of SPAN sessions allowed may vary. Most IOS versions support two SPAN sessions. Nexus OS may support more than two SPAN sessions.
Depending on the IOS running on the Supervisor, port names are displayed differently. Newer versions of IOS software display a port name as Gi2/1 to represent a Gigabit port on module 2 port 1. In the VSS, a port name might be displayed as Gi1/2/1 to represent a Gigabit port on switch 1, module2, port 1. On NAM-NX1, a port name might be displayed at Ethernet1/1/1.
Some Cisco switches do not support SNMP MIB objects that are required by NAM when configuring SPAN sessions. On these switches, you can use the switch device CLI command to configure the SPAN session for NAM. Alternatively, for the NAM appliances only, if the NAM managed device supports NetConf interface over SSH, you can configure the NAM to use NetConf to configure SPAN sessions on the managed device.
Understanding How the Prime NAM Uses SPAN
A switched port analyzer (SPAN) session is an association of a destination port with a set of source ports, configured with parameters that specify the monitored network traffic. You can configure up to two SPAN sessions in a Catalyst 6500 chassis. Newer Cisco IOS images may support more than two SPAN sessions. Consult the Cisco IOS document for the number of SPAN sessions supported per switch or router.
Table A-3 describes the types of SPAN sources and the possible ways to configure them.
Table A-3 SPAN Sources
|
Configured with one of the following:
|
Any set of physical ports
|
- Prime NAM (the GUI)
- Switch CLI
|
|
- Prime NAM (the GUI)
- Switch CLI
|
Any set of VLANs configured on the local switch
|
- Prime NAM (the GUI)
- Switch CLI
|
See Table D-3 for a description of the fields on the SPAN Sessions window.
Table A-4 lists the possible SPAN states. The SPAN state displays in parenthesis in the Source - Direction column.
Table A-4 Possible SPAN States
|
|
|
SPAN source is valid and packet traffic from the source is copied to the SPAN destination (NAM Dataport). |
|
Packet traffic from the source is not copied to the SPAN destination (NAM Dataport). |
|
For NAM-NX1 only, the Supervisor displays this when packets are forwarded to the NAM. |
|
For NAM-NX1 only, the Supervisor displays this when packets are not forwarding to the NAM. |
The NAM-3 platform provides two possible destination ports for SPAN and VLAN access control list (VACL) sessions. Multiple SPAN sessions to the Prime NAM are supported, but they must be destined for different ports. The Prime NAM destination ports for use by the SPAN graphical user interface (GUI) are named DATA PORT 1 and DATA PORT 2 by default. In the CLI, NAM-3 SPAN port is named dataport1 and dataport2.
For more information about SPAN and how to configure it on the various Cisco NAM platforms, see your device documentation on Cisco.com.
Note Due to potentially very high volume of ERSPAN traffic from the source, we recommend that you do not terminate the ERSPAN session on the Cisco NAM management port. Instead, you should terminate ERSPAN on the switch, and use the switch’s SPAN feature to SPAN the traffic to Cisco NAM dataports.
Understanding How the Prime NAM Uses VACLs in Catalyst Switch
A VLAN access control list can forward traffic from either a WAN interface or VLANs to a dataport on the NAM. A VACL provides an alternative to using SPAN; a VACL can provide access control based on Layer 3 addresses for IP and IPX protocols. The unsupported protocols are access controlled through the MAC addresses. A MAC VACL cannot be used to access control IP or IPX addresses.
There are two types of VACLs: one that captures all bridged or routed VLAN packets and another that captures a selected subset of all bridged or routed VLAN packets. Catalyst operating system VACLs can only be used to capture VLAN packets because they are initially routed or bridged into the VLAN on the switch.
A VACL can provide access control for all packets that are bridged within a VLAN or that are routed into or out of a VLAN or, with Release 12.1(13)E or later releases, a WAN interface. Unlike regular Cisco IOS standard or extended ACLs that are configured on router interfaces only and are applied on routed packets only, the VACLs apply to all packets and can be applied to any VLAN or WAN interface. The VACLs are processed in the hardware.
A VACL uses Cisco IOS access control lists (ACLs). A VACL ignores any Cisco IOS ACL fields that are not supported in the hardware. Standard and extended Cisco IOS ACLs are used to classify packets. Classified packets can be subject to a number of features, such as access control (security), encryption, and policy-based routing. Standard and extended Cisco IOS ACLs are only configured on router interfaces and applied on routed packets.
After a VACL is configured on a VLAN, all packets (routed or bridged) entering the VLAN are checked against the VACL. Packets can either enter the VLAN through a switch port or through a router port after being routed. Unlike Cisco IOS ACLs, the VACLs are not defined by direction (input or output).
A VACL contains an ordered list of access control entries (ACEs). Each ACE contains a number of fields that are matched against the contents of a packet. Each field can have an associated bit mask to indicate which bits are relevant. Each ACE is associated with an action that describes what the system should do with the packet when a match occurs. The action is feature dependent. Catalyst 6500 series switches and Cisco 7600 series routers support three types of ACEs in the hardware: IP, IPX, and MAC-Layer traffic. The VACLs that are applied to WAN interfaces support only IP traffic.
When you configure a VACL and apply it to a VLAN, all packets entering the VLAN are checked against this VACL. If you apply a VACL to the VLAN and an ACL to a routed interface in the VLAN, a packet coming into the VLAN is first checked against the VACL and, if permitted, is then checked against the input ACL before it is handled by the routed interface. When the packet is routed to another VLAN, it is first checked against the output ACL applied to the routed interface and, if permitted, the VACL configured for the destination VLAN is applied. If a VACL is configured for a packet type and a packet of that type does not match the VACL, the default action is deny.
When configuring VACLs, note the following:
- VACLs and context-based access control (CBAC) cannot be configured on the same interface.
- TCP Intercepts and Reflexive ACLs take precedence over a VACL action on the same interface.
- Internet Group Management Protocol (IGMP) packets are not checked against VACLs.
Note You cannot set up VACL using the Prime NAM interface.
For details on how to configure a VACL with Cisco IOS software, see Cisco.com.
For details on how to configure a VACL on a WAN interface and on a LAN VLAN, see Forwarding VACL Traffic.
Configuring ACL Capture on Nexus 7000 Series
Nexus ACL capture allows you to capture IP ACL, PORT ACL, MAC ACL and VLAN ACL. You can configure an ACL capture in order to selectively monitor traffic on an interface or VLAN. When you enable the capture option for an ACL rule, packets that match this rule are either forwarded or dropped based on the specified permit or deny action and will also be copied to an alternate destination port for further analysis.
To configure VACL capture to NAM-NX1 port-channel, all configurations are done on Nexus 7000 switches, and configuration is not required on NAM.
For detailed configuration, refer section Configuring VLAN ACLs in Cisco Nexus 7000 Series NX-OS Configuration Guide.
A simple configuration example on Nexus 7000 device is given below:
----
enable acl capture in default vdc, this CLI disable acl logging automatically
hardware access-list capture
ip access-list tcpany
10 permit tcp any any capture session 1
ip access-list udpany
20 permit udp any any capture session 3
vlan access-map tcp-map 10
match ip address tcpany
action forward
statistics per-entry
vlan access-map udp-map 20
match ip address acl-02
action forward
statistics per-entry
-----
apply access-map to appropriate vlans
vlan filter tcp-map vlan-list 55-65
vlan filter udp-map vlan-list 58
----
config acl intf 4/23
interface Ethernet4/23
ip port access-group tcpany ingress
----To filter udp at ingress interface, change intf 4/23 as below:
interface Ethernet4/23
ip port access-group udpany ingress
----
config monitor session
monitor session 1
type acl-capture
destination analysis module 3 data-port 1
no shut
See Nexus 7000 ACL Capture/ VACL Support & Limitations FAQ for details.
Understanding How the Prime NAM Uses NetFlow
The Prime NAM uses NetFlow as a format for the ongoing streaming of aggregated data, based on the configured set of descriptors or queries of the data attributes in NAM. NetFlow Data Export (NetFlow) is a remote device that allows you to monitor port traffic on the NAM; the Prime NAM can collect NetFlow from local or remote switches or routers for traffic analysis.
To use an NetFlow data source for the Prime NAM, you must configure the remote device to export the NetFlow packets. The default UDP port is 3000, but you can configure it from the Prime NAM CLI as follows:
root@nam3-61.cisco.com# netflow input port ?
<port> - input NetFlow port number
The distinguishing feature of the NetFlow v9 format, which is the basis for an IETF standard, is that it is template-based. Templates provide an extensible design to the record format, a feature that must allow future enhancements to NetFlow services without requiring concurrent changes to the basic flow-record format.
For more detailed information about Prime NAM and NetFlow, see Forwarding NetFlow Traffic.
For specific information about creating and managing NetFlow queries, see the Cisco Network Analysis Module API Programmer’s Guide (contact your Cisco account representative if you need to refer to this document).
Understanding NetFlow Interfaces
To use a device as an NetFlow packet data source for the Prime NAM, you must configure the device itself to export NetFlow packets to UDP port 3000 on the NAM. You might need to configure the device itself on a per-interface basis. A NetFlow packet device is identified by its IP address. In the NAM, the default UDP port of 3000 can be changed with a Prime NAM CLI command (see Configuring NetFlow on Devices).
You can define additional NetFlow packet devices by specifying the IP addresses and (optionally) the community strings. Community strings are used to upload convenient text strings for interfaces on the managed devices that are monitored in NetFlow records.
Remote NetFlow packet devices may export information pertaining to any or all of their individual interfaces. The Prime NAM keeps track of the interface associated with any flow information received from the device. On the NDE Interface Analysis page (Analyze > Traffic > NDE Interface), you can view information for any selected interface on the device. This page will display the interface utilization or throughput over time, as well as show the top Applications, Hosts, and DSCP groups in both the input and output directions for the interface.
Understanding NetFlow Flow Records
A NetFlow packet contains multiple flow records. Each flow record has two fields:
- Input SNMP ifIndex
- Output SNMP ifIndex
Note This information might not be available because of NetFlow feature incompatibility with your Cisco IOS version, or because of a NetFlow flow-mask configuration.
In most cases, turning on NetFlow on an interface populates the NetFlow cache in the device with flows that are in the input direction of the interface. As a result, the input SNMP ifIndex field in the flow record has the ifIndex of the interface on which NetFlow was turned on. Sample NetFlow Network, Figure A-1, shows a sample network configuration with a NetFlow router.
Figure A-1 Sample NetFlow Network
Table A-5 lists the reported flows if NetFlow is enabled on interface a.
Table A-5 Reporting Flow Records
|
|
|
a |
b |
Yes |
a |
c |
Yes |
b |
c |
No |
b |
a |
No |
c |
a |
No |
c |
b |
No |
Managing NetFlow Data Sources
A data source entry must exist on Prime NAM in order for it to accept NetFlow records from an external device. Data source entries may be created manually using the Prime NAM web GUI or the CLI. When manually creating a data source, you may specify any name you want for the data source.
For convenience, manual creation of NetFlow data sources is not necessary. There is an “autocreate” feature which is enabled by default. With the autocreate feature, a new data source will automatically be created for each device which sends NetFlow packet traffic to the Prime NAM when the first packet is received.
Autocreated NetFlow data sources will be assigned a name in the format NetFlow-<IP Address>-ID-<Integer>, where <IP Address> is the IP address of the exporting device, and <Integer> is the Engine-ID that the device populates in the packets (part of the NetFlow Data Export standard). An example might be “NetFlow-10.10.0.1-ID-12” for device 10.10.0.1 sending NetFlow packets with the Engine ID field set to 12. You can edit these autocreated data sources and change the name if you want to, as well as optionally specifying SNMP credentials for the device, as described later in this guide.
Understanding How the Prime NAM uses CEF
NAM uses CEF to monitor all IP traffic on a router interface. For Cisco 2900 Series or Cisco 3900 Series Integrated Services Router Generation 2 (Cisco ISR G2) support Prime NAM, you can configure to monitor CEF traffic on many data ports to copy and forward all IP traffic to NAM monitoring interface on a Cisco ISR G2.
The Cisco Unified Computing Server type E (Cisco UCSE) can host Prime NAM and other services. See UCSE product introduction for more details:
http://www.cisco.com/c/en/us/products/servers-unified-computing/ucs-e-series-servers/index.html
For the list of router platforms and IOS releases support UCSE, see section “Verifying Compatibility” in Getting Started Guide for Cisco UCS E-Series Servers and the Cisco UCS E-Series Network Compute Engine.
Understanding UCSE Physical Interfaces
Internal PCIE/MGF ports are named as GE0/GE1 and the front panel ports are named as GE2/GE3.
In CIMC GUI, PCIE/MGF ports are named as GE1/GE2 and front panel ports are named as GE3/GE4.