NetMRI collects large quantities of low-level device data that can be viewed at any time. During troubleshooting, experienced admins can use low-level device information to help solve problems. The tool for viewing any device's diverse array of information is called the Device Viewer.
To open the Device Viewer for any device: Click the device's hyperlink anywhere it appears in NetMRI displays.
...
Note: Because they are simple browser pop-up windows, multiple Device Viewers can be open simultaneously.
...
The Device Viewer's Device/Network Explorer section (Device Viewer –> Device/Network Explorer) shows a substantial body of critical information about a selected device relative to other network elements. Device/Network Explorer conveys many details about the relative location of the device in the network, and aspects of its operating state. The "location" of the device is described by its SNMP identity, with many other pieces of information about the network switch, router, or other entity.
Before device identification, NetMRI verifies SNMP, Telnet and SSH ports by access to these ports during normal operation. Any device that supports the tcpConnState SNMP table and is accessible are polled for additional open TCP ports.
Active port scanning can be enabled at the Settings icon –> Setup –> Collection and Groups –> Global tab.
...
Note: Additional information can be displayed using the Columns option available via column header menus.
...
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The Identification page (Device Viewer –> Device/Network Explorer –> Device Identification) displays identification information—gathered from a variety of collectors—for the device currently displayed in the Device Viewer. This page lists the identification discovery sources used to determine the device (normally SNMP), a listing of the discovered SNMP Data, and the operating system. Identification information is used to initially determine the type of device being accessed. Because identification information from different sources (listed in the Identification Discovery Sources table) is sometimes conflicting or incorrect, it is possible that a device type or name will initially be incorrect. Over time, as more detailed data is gathered from the device, the device type and/or name are corrected.
The SNMP Data table lists SNMP and OS information, if available, about the device.
The O/S History table lists all the OS versions discovered by NetMRI over time, for the specific device.
Checking Device Locations
The Device Location page (Device Viewer –> Device/Network Explorer –> Device Location) shows the location of a selected device relative to other network elements. Connectivity information is listed across Switchport, Subnet, Network Views and VLAN tabs. Device Location shows all switch ports adjacent to the selected device where applicable, the subnetworks to which the device connects (in the Subnets tab) and VLANs (in the VLANs tab) containing the device.
In the Network Views tab, the device’s local interfaces are listed with their respective Network View membership and their VRF Network Name if applicable to the device.
Viewing Component Inventory
The Component Inventory page (Device Viewer –> Device/Network Explorer –> Component Inventory) lists all hardware information for the device, if SNMP data is available. Specific data depends on the vendor platform, and may include hardware revision, firmware revision, model number and serial number. The page lists all installed interfaces and the chassis for the device. The chassis listing also provides the network device’s serial number and model number. Additional information can be displayed using the Columns option available via column header menus.
Viewing Open Services on a Device
The Open Services page (Device Viewer –> Device/Network Explorer –> Open Services) lists all TCP and UDP ports that are currently open on the device. This feature not only gives you a picture of what the selected device is doing–it doing – it can also give you a quick view of possible security holes in the device’s basic configuration. Based on the device type, NetMRI will expect certain services to be configured on the device, and those values will appear in the Expected Service column as the protocol name. Devices will often show services such as telnet, BootP, or SNMP as a service. Services that are detected as being actively used on the device appear in the Verified Service column.
Should a Listen Address value appear as 0.0.0.0, it indicates that the service is configured to run on all ports on the device.
...
The CDP Neighbors page (Device Viewer –> Device/Network Explorer –> CDP Neighbors) lists information from any Cisco devices that support and transmit announcements from the proprietary data-link-layer Cisco Discovery Protocol (CDP). The table lists all remote devices that have exchanged information with the current device using CDP announcements, including the local interface ID receiving CDP announcements; the neighbor's IP address; the neighboring device's DNS name and interface ID; the reported neighbor's "platform," which is the model of the CDP-supporting switch or router; and the Neighbor Capabilities, which indicates the basic functions of each
CDP-neighboring device.
...
Note: This menu item will not appear in the Device Viewer for non-Cisco devices.
...
You can also select additional columns of information for detected CDP neighbors, including the following:
...
The LLDP Neighbors page (Device Viewer –> Device/Network Explorer –> LLDP Neighbors) supports all devices running the LLDP protocol. The table lists all remote devices that are LLDP neighbors of the current device, listed against all local interfaces that report LLDP neighbors; and provides collected information regarding those devices from LLDP, including their identity, capabilities and their own respective neighbors.
...
Note: This menu item will not appear in the Device Viewer for devices that do not support the LLDP protocol.
...
You can also select additional columns of information for detected LLDP neighbors, including the following:
- VRF –The network view belonging to the local interface that is connected to the discovered neighbor. This membership relation is inherited from the 'Network View' assignment of the local VRF in charge of this interface traffic.
- Network View –The network view belonging to the local interface.
- Neighbor Network View –The network view to which the neighboring interface belongs, if applicable.
- Neighbor Version–shows – shows the complete IOS software version;
- Neighbor ifindex–a – a standards-defined value for SNMP used as a unique identifying number associated with physical and logical interfaces, in this case for the LLDP protocol;
- Neighbor MAC, which shows the physical-layer MAC address of each LLDP-reporting neighboring interface.
...
For Ethernet switches and L2/L3 switch-routers, NetMRI provides the device management history for the device currently shown in the Device Viewer. The key values are the First Seen and Last Seen values, which show the date and time when the device was first discovered and polled by NetMRI and the timestamp for the most recent device polling occurrence.
In rare cases you may see this option in the Device Viewer for a Firewall. By default, the Device History table shows eight columns of data, including the following:
- First Seen —The — The timestamp for the first occasion where the device was successfully discovered by NetMRI;
- Last Seen—The — The timestamp indicating when the device was last polled by NetMRI. If the device is still connected, this field will reflect current timestamp values from the last network polling by the appliance;
- Device Name —The — The configured device name;
- IP Address —The — The IP address of the device;
- DNS Name —The — The DNS name for the device;
- Description —The — The description that was collected for the device;
- Poll Duration—The — The period of time in seconds required for the most recent polling cycle for the device. This value may change from poll cycle to poll cycle.
...
Note: The Switch Port Management feature set makes heavy use of the Interface Viewer for checking interface configurations and status. The information in the Device Viewer –> Interfaces page, discussed in this section, is only a subset of the information available in the Interface Viewer.
...
The Interfaces section (Device Viewer –> Interfaces) provides a survey of key discovered data for all interfaces of the chosen networking device. Each interface link in the table provides a shortcut menu with several useful port management features:
Interface Viewer–Opens – Opens an Interface Viewer window for the selected port;
Interface LIve Viewer –Opens – Opens the Interface Live Viewer for the selected port;
Set Admin Status–Allows – Allows the NetMRI user, if they have the correct privileges, to set the chosen port to administratively Up or administratively Down without requiring a command-line connection to do so;
Edit Description–Edit – Edit the interface description field of the chosen interface in the table;
Edit VLAN Membership
–Change – Change the VLAN assignment for the chosen port, without requiring an SSH or Telnet connection to the device. Anchor bookmark447 bookmark447
...
The Device Viewer –> Interfaces –> Configurati, the records from the device's Neighbor Discovery Protocol processes are shown.
Should you display this page for a firewall device, you will see a list of the Inside, Outside and DMZ interfaces for the firewall, appearing as the standard interface information for the device, including the Configuration page lists all the interfaces supported by the device and their basic port configurations. By default, the table lists the VRF Name for the interface (if any), the configured speed, administrative state, duplex settings, admin state and operational state, and the timestamp for the last configuration change. Additional information can be displayed using the Columns option available via column header menus.
The Configuration page conveys a substantial quantity of information about the list of interfaces for a device, much of which is hidden by default. Useful data points include the following:
- VRF Name: the virtual network to which the interface belongs;
- Network View: The NetMRI Network View to which the interface belongs.
...
Note: Virtual network information shown in this table reflects the same data gathered from a device’s (IOS example) show ip vrf interface
command.
...
If the administrative and operational states for an interface are inconsistent, data in that row are displayed in red.
- To view comprehensive data for an interface: Click a hyperlink in the Interface column. This displays the Interface Viewer in a separate window.
Viewing the Device’s Address Table
The Device Viewer –> Interfaces –> Address Table page lists the ARP table records captured by NetMRI during device discovery and polling; ARP tables consist of the IP addresses and MAC addresses assigned to the interfaces supported by the device. Effectively, this page shows the ARP table for the selected router or switch device. It also shows the VRF Name for each interface (if any). If the device is running IPv6, the records from the device’s Neighbor Discovery Protocol processes are shown.
Should you display this page for a firewall device, you will see a list of the Inside, Outside and DMZ interfaces for the firewall, appearing as the standard interface information for the device, including the Interface name, Description, IP Address and MAC Address.
Should you display this page for a switch, the Interfaces table also lists the VLAN assignment for each port.
To view comprehensive data for an interface: Click a hyperlink in the Interface column.
...
You can check licensing status for NetMRI–managed firewall devices in the Device Viewer. The License page (Device Viewer –> Firewall –> License) applies only to Firewall devices and the information provided is derived from the vendor license information for the device itself (e.g. licensing purchased from Cisco), not for any licensing in NetMRI.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
For devices with routing capability that are locally configured to support virtual routing and forwarding (VRF) instances, the VRF Table page provides the complete list of present VRF instances in the device. The VRF Table pane lists the VRF instance with columns in the following order:
- VRF Name –The – The listed name of each discovered VRF instance in the device.
- Network View – The network view to which the VRF instance is associated.
- VRF RD–VRFs – VRFs use route distinguishers to distinguish one set of routes (one VRF) from another. The route distinguisher is a unique number pre-pended to each route within a VRF to identify it as belonging to that particular VRF. The discovered route distinguisher value is listed here if a virtual network uses this value. (For related information, see Summarizing Route Targets.)
- VRF Description–Displays – Displays the description if the VRF instance is configured with a description on the device;
- Route Limit–If – If configured for the VRF, shows the maximum number of allowed routes permitted for the VRF instance;
- Warning Limit –If – If configured, shows the warning threshold to prevent exceeding the Route Limit count;
- Current Count –The current number of routes in the VRF instance;
- Timestamp –The date and time during which the device's VRF instances were last polled by NetMRI. By default, rows are sorted ascending alphabetically based on VRF names.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The ARP/ND Table page displays the MAC address-to-IP address (ARP table) mappings most recently retrieved from the device, applied specifically to IPv4 devices. If the device supports IPv6, Neighbor Discovery mappings, including link-local values, also appear here (hence the ND in the table name). If the device is dual-stack, both sets of values appear. If the IP address matches a device that has already been discovered, the corresponding hyperlink can be used to open the Device Viewer for that device.
A column titled Network View lists the network view in which each local interface is participating. NetMRI hides this column by default. This value appears only for VRF-aware devices. If a device's interface is not attached to a VRF interface, its data is routed through the global routing table for the device and lists the global network view used for that network.
Another column, VRF Name, lists the local virtual routing and forwarding (VRF) instance in the router to which the interface is bound.
Most device categories,
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
Note: For IPv6 routing table information, next hops are specified as link-local IP addresses. If the next hop's
link-local address is also known to NetMRI, the address field appears as a hyperlink to the Device Viewer page for that device, enabling viewing of all link-local and global addresses for the next hop.
...
The Route Table page shows the routing information most recently retrieved from the device, including hyperlinks to corresponding interfaces and "next hop" devices. If the device supports IPv6, this table view also shows the current router's neighbors' link-local addresses as next hops in the table.
A column titled Network View lists the network view in which each of the device's local interfaces is participating. NetMRI hides this column by default. If a device's interface is not attached to a VRF interface, its data is routed through the global routing table for the device and lists the global network view used for that network.
Another column, VRF Name, lists the local virtual routing and forwarding (VRF) instance in the router to which the interface is bound, if any.
...
Note: At the top of the Route Table page, the Routing Problems and Unreachables table provides a number of specific issue counts related to the device: No Route Discards, Routing Discards, ICMP Redirect Messages, ICMP Destination Unreachable Messages, ICMP Redirects Sent, and ICMP Time Exceeded Messages.
...
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The EIGRP page is available for routers supporting the Enhanced Interior Gateway Routing Pro
Anchor | ||||
---|---|---|---|---|
|
Local Interface
...
– Each listed interface participating in the EIGRP protocol.
Network View
...
– Lists the NetMRI network view assigned to each local device interface connecting to the discovered EIGRP neighbor.
Neighbor IP Address –The adjacent neighbor for each EIGRP interface in the router, for which the current router keeps state information.
Neighbor Name –The configured name for each neighboring router.
Neighbor Uptime –The time period for which the neighbor adjacency has been active.
EIGRP Retransmit Count –The aggregate number of times the current device has sent retransmissions to the specific neighbor (usually Hellos or updates), because it's not getting EIGRP acknowledgments back. High numbers indicate a network problem between the current device and its neighbor.
EIGRP Retry Count –The aggregate number of times the current device h
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
Note: NetMRI fully supports the collection of IPv6 dynamic routing protocol data, including OSPF and BGP.
...
The OSPF page lists the characteristics for the selected device if it is running the Open Shortest Path First protocol, a popular internal gateway routing protocol. The Device Viewer OSPF page divides into two tables:
- An OSPF Area Table listing the OSPF administrative Areas to which the router belongs,
- An OSPF Neighbor Table listing all routers and router interfaces to which the current router has established OSPF adjacencies and exchanged link-state databases.
The OSPF Area Table panel displays the following relevant data columns
Anchor | ||||
---|---|---|---|---|
|
- Area–the – the OSPF administrative networks to which the router belongs. In many circumstances, an OSPF router may belong to two or more Areas, including the Area0 backbone;
- AreaID–the – the dotted-quad version of each OSPF area ID;
- Authentication Type –The authentication protocol, if any, employed by the OSPF router in that specific Area.
OSPF authentication operates on a point-to-point basis, usually using MD5 hashing; - AS External Type–Indicates – Indicates whether the area in which the router is participating is a standard Area or a Stub area;
- Border Router Count–indicates – indicates the number of OSPF area border routers in each local area. Such routers are typically area border routers (ABRs) or Autonomous System border routers (ASBR);
- Route Table Calcs –The number of incidences where the router has been forced to run the Dijkstra algorithm on the network, to calculate the SPF database for the Area. Ideally, the value in this field should read zero or close to zero, indicating that no recalculations have been necessary since the router joined the OSPF Area. If a router experiences issues or an unstable link (flapping), higher numbers of recalcs are an indicator;
- Autonomous System Count –the – the number of ASes in which each Area in the Area Table operates;
- Link-State Advertisements –The number of link-state advertisements (LSAs) the
router has sent to other neighbors during the course of information exchanging with other OSPF routers.Anchor bookmark463 bookmark463 - Link-State Checksum –The checksum value listed in the device's router link-state advertisement header;
- Network View–shows – shows the NetMRI network view containing the local VRF or VRFs associated with the listed OSPF area.
The OSPF Neighbor Table displays the following information:
- Neighbor Name –The discovered name of the OSPF neighbor router;
- Neighbor IP Address –The IP address of the adjacent neighboring interface;
- Network View–Lists – Lists the NetMRI network view associated to the device's interface that connects to its discovered OSPF neighbor. Clicking the link opens the Network View Viewer window, which lists the AssociatedVRFs and the ImportedVRFs for the network view.
- Neighbor Router ID –The configured Router ID for the neighboring OSPF router (different value from the neighboring interface);
- Neighbor State –In – In a functioning OSPF adjacency, this value will show as Full.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The BGP page lists the basic characteristics for routers in which Border Gateway Protocol is active. The table displays information about all known BGP4 neighbors for the current device. IPv4 and IPv6 versions of BGP are supported. If the router does not support BGP, this page will remain blank. Any
Anchor | ||||
---|---|---|---|---|
|
The BGP Neighbor Table displays the following information by default (other fields can be added to the table):
Local Addr–Local IP address of the individual ports of the current device;
Network View–Lists the NetMRI network view associated to the device's interface that connects to its discovered BGP neighbor. Clicking the link opens the Network View Viewer window, which lists the Associated VRFs and the Imported VRFs for the network view.
Local Port–The Interface ID;
Neighbor Addr–The neighboring interface running BGP4, that has established an adjacency with the listed local port;
Neighbor Port–The neighboring port's interface ID;
Neighbor AS–The Autonomous System (AS) to which the neighboring interface belongs;
Neighbor Name–The name of the router host for the neighboring interface;
RP Peer Device Type
...
– Route Processor peer device type (if applicable), indicates the peer route processor type if line card-based forwarding table synchronization is supported. Possible values include RSP for a Cisco 7500-class router and GRP (gigabit router processor) in a Cisco 12000-class router line card;
Connection State
...
– Reflects the current BGP connection state of the BGP peer when the network was last polled by NetMRI. Typically, the state of a full BGP peer is Established. Seeing anything but an Established state in this field may indicate issues. Other possible states include Idle, Connect, Active, OpenSent, and OpenConfirm. BGP sessions begin in an Idle state when the device initializes the resource it needs for the upcoming session. It then transitions to state Connect while the peers establish their TCP connection for BGP. Once the TCP connection is established between the peer interfaces the routing protocol moves to the OpenSent state. (If the TCP connection fails, the peers enter the Active state.) OpenSent indicates that the device has received an Open message from the peer, and then determines the AS to which the neighbor belongs. OpenConfirm indicates that the device is wait
Anchor | ||||
---|---|---|---|---|
|
Last State Change –The timestamp for the last detected occasion that the current device changed its BGP state on the current interface in the table.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The HSRP page lists the characteristics for all Cisco routers supporting the Hot Standby Routing Protocol and Virtual Router Redundancy Protocol, which are typically used for Cisco VPN concentrators. Tables in this page list all HSRP groups supported by the device, and additional details for each group.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
NetMRI performs data collection and analysis of router operational data that pro
Anchor | ||||
---|---|---|---|---|
|
The QoS page and its tables apply only to QoS information for Cisco routers, displaying the number of packets and drops per Quality of Service queue during the time period (above the table) selected for the page. The QoS page divides into three tabs:
QoS Table
...
– Shows the broad picture of QoS operation in the chosen device.
QoS Daily Table
...
– Daily performance records of the current router's QoS configuration.
Raw QoS Data
...
– Raw packet counts for each of the queues for the currently selected router.
Proper QoS operation depends on two factors. First, configuration must be done correctly across many devices. Any difference in configuration may result in packets not being properly queued, resulting in high latency, jitter or packet loss, particularly on congested links.
The second factor involves monitoring the operational characteristics of QoS. Operational characteristics include elements such as packet volume per queue and packet drops per queue. These are reflected in the QoS Table and QoS Daily Table. The operational data can indicate network misconfigurations and data flow changes that no longer match assumptions made during the network's design.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
NetMRI automatically identifies routers configured with QoS and collects operational data on each configured queue. There are no configuration options within NetMRI that affect identification of queues and collection of operational data. The analysis identifies operational signatures of potential problems such as oversubscribed interfaces.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Any QoS queue that is dropping packets is identified. The relative priority of the queue determines the severity level of the issue that is generated in the Issue List. The table below shows the severity generated for each queue's Per-Hop Behavior (PHB) and DSCP value that are commonly associated with applications. Drops in high priority queues will generate Error issues, while medium priority queues generate Warning issues. The lowest priority queues, including the scavenger queue, generate Info issues.
...
? |
---|
...
Classification | ? | ||
---|---|---|---|
Application | PHB | DSCP |
...
...
Issue Severity | |||
---|---|---|---|
Link Layer keepalives | CS7 | 56 | Error |
Routing | CS6 | 48 | Error |
Voice | EF | 46 | Error |
CS5 | 40 | Error | |
AF43 |
...
38 |
...
Info | |||
AF42 | 36 | Warning | |
Interactive Video | AF41 | 34 | Error |
Streaming Video | CS4 | 32 | Error |
AF33 |
...
30 |
...
Info | |||
AF32 | 28 | Warning | |
Mission Critical | AF31 | 26 | Error |
Call Signaling | CS3 | 24 | Error |
AF23 |
...
22 |
...
Info | |
AF22 |
...
20 |
...
Info | |||
Transactional Data | AF21 | 18 | Warning |
Network Management | CS2 | 16 | Warning |
AF13 |
...
14 |
...
Info | |
AF12 |
...
12 |
...
Info | |
Bulk Data | AF11 |
...
10 |
...
Info | |
Scavenger | CS1 |
...
8 |
...
Info | ||
Best Effort | 0 | 0 |
...
...
Info |
...
When a high priority queue drops packets, it indicates that insufficient bandwidth may be allocated to that queue. Sometimes this occurs because the queue definition is based on network traffic volume assumptions that no longer apply. For example, a queue configured to handle four simultaneous voice calls may be dropping packets because more than four simultaneous calls are being handled.
Conversely, when many (or all) queues are dropping packets, the entire link may be oversubscribed and the only valid remediation is to add more bandwidth. In this scenario, the high priority queues use nearly all the bandwidth and will still drop packets because the offered load is greater than the available bandwidth. Because there is little remaining bandwidth, low priority queues will also drop packets.
When a QoS queue drop is detected during the analysis of the collected data, an issue appears on the issue list. Clicking on the issue hyperlink opens the issue in the Issue Viewer, where information is displayed about each queue that experienced the drops. The Issue Viewer provides several hyperlinks to access related information.
- To open the Device Viewer: Click a hyperlink in the IP Address column.
- To open the Interface Viewer: Click a hyperlink in the Interface column.
- To open the Quality of Service Viewer: Click a hyperlink in the Policy Name column.
The Quality of Service Viewer provides charts showing dropped packets (quantity and percentage) versus time.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
The device viewer's VLANs page (Device Viewer –> Switch –> VLANs) provides a summary table for all of the VLANs provisioned in the selected switch.
The Active VLANs (Device Viewer –> Switch –> VLANs –> Active VLANs) table provides some important information for checking the switch's VLAN configuration and its status in the network.
The Active VLANs table lists all VLANs being supported by the device, including the root bridge for each VLAN and elements such as the Root Priority, Switch Priority, Root Cost, and the Spanning Tree Protocol. Root Bridge Priority values are used in the election process of a root bridge for a particular VLAN.
A root bridge is selected by setting a switch's root priority value to a lower value in comparison to other switches. The root bridge priority value defaults to 32768 for most platforms and the maximum value is 65535; the minimum value is 0. The bridge priority value is combined with the MAC address ID for the switch to determine the spanning-tree root bridge for the network. This resulting value propagates through the switched network in Bridge Protocol Data Units (BPDUs) from the root bridge, to ensure that the devices in the switched network agree on the identity of the root bridge.
Should all switches in the network retain the same value, an election takes place in which the switch with the lowest MAC address becomes the root bridge. Many older Ethernet switches may have lower Ethernet MAC address values and may thus be automatically elected as the root bridge for many VLANS in the network, even though the switch will not have the processing or memory to handle the load. To ensure the 'correct' switch is elected as the root, the best practice is to set the desired core switch's bridge priority to a relatively low value such as 8000; then, a second root bridge is chosen as a backup root and its priority set to a slightly higher value.
Listed in the Active VLANs page, the switch priority of a VLAN is the value defined in the local switches' configuration as the candidate value for election as the root.
The root cost value in the table is the cumulative cost of all links in the current VLAN leading to the root bridge. VLANIDs that show a value of 0 are not participating in the spanning tree.
The Spanning Tree Protocol column reports the version of the spanning tree protocol being run on each switch interface. A normal value for this column is ieee8021d.
...
Note: For Cisco devices, the root switch on the spanning tree network may be found by entering a show spanning-tree command on the switches participating in each VLAN. You can use the Open Telnet Session or Open SSH Session features in NetMRI to connect to managed devices.
...
The VLAN Configuration table (Device Viewer –> Switch –> VLANs –> VLAN Configuration) lists configuration information for each VLAN supported by the device. Configuration settings for each VLAN include the three key STP timers Hello Time, Max Age and Fwd Delay for both the local bridge (on each VLAN, these are called Current values) and its root bridge (called Bridge values). For the current switch's VLANs, the Current Hello Time shows the time intervals between the transmission of configuration bridge PDUs (BPDUs), which flow outward from the root bridge as notifications of its root status to the other switches in the spanning tree.
The Current Max Age is the time period that an installed root's BPDU is stored by the selected switch. (The Cisco default value is 20 seconds.) The Current Fwd Delay value is the time period, in seconds that the current device spends in the Listening and Learning states. Among other things, it indicates how long the bridging table ages before the device switches from Forwarding mode to Listening mode. Fwd Delay also affects how quickly the switch responds to a change in topology.
The Bridge Hello Time, Bridge Max Age and Bridge Fwd Delay values are the corresponding values dictated by the root bridge through its BPDUs to all the other bridges in the switched network, including to the current device. Most deployments require careful consideration before changing spanning tree protocol timing values, and such values should normally be modified only at the root bridge.
The figure above illustrates the principles. The root bridge advertises its Bridge Max Age = 2000, Bridge Hello Time
= 200, and Bridge Fwd Delay = 1500 in the BPDUs it sends to the other switches in the network through VLAN 60. Those values are in turn used by the other switches in the network to configure their respective Max Age, Hello Time and Fwd Delay settings (all labeled as Current in the table). In the current switch, those three STP timer values are set to the same values because they are determined by the three values communicated through the root bridge BPDUs.
...
This page provides a quick view of the forwarding configuration for all switch ports in the current device. The Forwarding page lists the VLAN ID, local interface IDs, MAC address, IP address, neighboring device name and device type, and the neighboring interface ID for each switchport in the current device. Each Local Interface and neighboring Interface listing is a link to the Interface Viewer for the port.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
- Timestamp –The date and time when the device was last queried by NetMRI.
- Interface–Lists – Lists the interface for the device. As an example, for Cisco devices you will typically see interfaces such as
Do0
fordot11radio 0
. This item is also a link to the Interface Viewer. - Station ID–If – If configured, the numeric value station ID number for the device. Defaults to 0.
- Service set ID (SSID) –The natural-language service set identifier.
- Role–Indicates – Indicates the role in the radio network defined for the device, if any (uses the Cisco
station-role
command). Possible values include Root Bridge (roleRoot
), Non-Root Bridge, Root Bridge with Wireless Clients, Non-Root Bridge with Wireless Clients, and Universal Workgroup Bridge. 2 - WEP Enabled–Indicates – Indicates whether the WEP protocol is enabled for use on the device. WEP uses static encryption keys and is generally considered to be obsoleted by the newer WPA (Wi-Fi Protected Access) protocol.
- WEP Allowed–Indicates – Indicates whether WEP authentication is allowed on the device.
- WEP Errors–the – the count of WEP errors detected by the wireless device.
- Key Len 1-4–the – the specified WEP key lengths, if any.
...
The SSIDs page lists the service set identifiers defined on the current wireless access point device. The SSID is a unique identifier that wireless networking devices use to establish and maintain wireless connectivity. Multiple access points on a network or subnetwork may use the same SSIDs. As an example, Cisco Aironet devices support up to 16 SSIDs and support different configuration settings for each SSID. All SSIDs are simultaneously active; depending on configuration, wireless client devices can associate to the access point using any SSID. Data points include:
- Interface–Lists – Lists the interface for the device. As an example, for Cisco devices you will typically see interfaces such as
Do0
fordot11radio 0
. This item is also a link to the Interface Viewer. - SSID Index–the – the index value for the listed service set ID.
- SSID –The natural-language service set identifier.
- Max Stations –A – A radio setting defining the maximum number of connected client stations for the wireless device. The default setting is 255.
- MIC Algorithm–A – A WEP encryption setting that prevents certain attacks on WEP-encrypted packets. If none is used, this value reads
micNone
. - Permute Algorithm–Lists – Lists the WEP permute algorithm configured for each SSID. This setting defines how the WEP encryption key is permuted between key renewal periods for stations associated with the radio interface.
- Broadcast SSID–Also – Also called Guest Mode in Cisco IOS. (The default guest SSID is identified in Aironet devices as
tsunami
.) Any access point will have either a single guest-mode SSID or none. This data point identifies the guest SSID advertised by the access point beacon for guest use, if any.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The
...
Authentication page lists the current wireless access point’s authentication settings groups. Each group has at least one unique setting to distinguish it. Data points include:
- Interface – Lists the interface for the device. As an example, for Cisco devices you will typically see interfaces such as
Do0
fordot11radio 0
. This item is also a link to the Interface Viewer. - Auth Enabled –Shows – Shows whether authentication is required in the authentication configuration group. This field will show a value of Yes or No.
- EAP Required–Indicates – Indicates whether the access point requires the Extensible Authentication Protocol to provide dynamic WEP keys to wireless devices. Will show a value of Yes or No.
- EAP Method–If – If enabled, possible EAP values include Open or Shared Key authentication.
- MAC Auth Required –Indicates – Indicates whether the AP uses MAC Address authentication, using the wireless client's MAC address to verify with an authentication server whether the MAC is allowed on the network. Will show a value of Yes or No.
- MAC Auth Method–If – If enabled, this indicates whether EAP authentication is required for MAC address authentication or if a MAC address list is being used. An access point configured for EAP authentication forces all client devices that associate to it, to perform EAP authentication.
- Default VLAN–Cisco – Cisco Aironet wireless access points use three VLANs: VLAN 2, VLAN 20 and VLAN 30. One is set as the 'native' VLAN, one as the SSID administrative VLAN, and one as the SSID guest VLAN. The value shown here is the discovered listing for the default native VLAN on the radio interface.
- Auth Algorithm –The – The discovered SSID authentication algorithm that is configured for each settings group.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
Note: After a device is discovered by NetMRI, its detected Name, Device Type (Switch, Router, Switch-Router, etc...) or its management IP address can be edited by hand in this section. Doing so will remove the device from auto-discovery. To re-enable auto-discovery for that device, go to the Network Explorer–>Discovery page and delete the device from the table. NetMRI will then re-discover the device after its defined time period between Discovery passes elapses.
...
The Device Viewer provides a General Settings page (Device Viewer–> Settings & Status–> General Settings) in which you can do the following:
- Enable/disable SNMP data gathering for the device;
- Under SNMP Status, select Enabled to enable SNMP collection for the current device; select Disabled to disable SNMP collection.
- Enable SNMP debugging as a troubleshooting aid;
- Under SNMP Debug, select Enabled to enable SNMP debugging for the device. For more information, see Collecting Troubleshooting Data.
- Override the device Name and Type determined automatically by the appliance. This triggers rediscovery. For more information, see Overriding Device Names and Types in the Device Viewer;
- Override the config change setting specified in the Device Group to define config collection for the device as Locked or Unlocked;
- Set the Reboot Time, in YYYY-mm-dd hh:mm:ss format, for devices up longer than 497 days.
...
Note: The General Settings page can be accessed only by users with the Admin role.
...
The Device Group Membership section lists the device groups of which the device is a member.
The Device Group Settings section lists the settings for the highest ranking device group that includes the device as a member, and a number of scanning and discovery-related statuses specific to the device, including the following:
...
In all cases, a state of N/A indicates either the device has not been fully discovered and cannot currently support the feature, or the feature does not apply to the device.
...
Note: You can define individual devices' SNMP and CLI credentials. For more information, see Adding and Testing SNMP Credentials for a Device and Adding and Testing CLI Credentials for a Device.
...
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
To rename a device: Type a new name in the Name field, then click the Update Device button. You can also define the network through which the device will be managed by NetMRI, change its discovered device type. and change the device's data collection settings.
- For VRF-aware devices, you can change the Management IP address for the device by choosing it from the Management Address dropdown menu. The menu lists all IP addresses for the device, each shown with their associated network view, with the current management IP for the device selected in the list. (The listed management IPs fall within the discovery ranges of the Collector appliance or standalone appliance that manages the device.)
By choosing a different Management Address, the associated NetMRI appliance uses the scan interface on which the Management IP is defined. This feature is useful for devices that participate in multiple network views, as it enables the administrator to define which network view the device is managed through. (In many cases the Management Address list shows only a single network view such as the default Network 1; in these cases, all available addresses exist only in the single network view.)
- For VRF-ignorant devices, this page shows a Management Network View dropdown menu. The list shows all network views for the device's associated Collector or standalone NetMRI appliance, that each have an assigned scan interface. You may see multiple network views. In cases of this type, possible route-leaking may be taking place from other VRF-aware devices that makes it possible for the current device to be managed from within two or more VRFs; though the device is VRF-ignorant, you can choose the network for which you consider the device to be a member for management purposes.
- If the NetMRI appliance manages only one network, the Management Network View dropdown will not appear;
- When the selected device in the Device Viewer is configured to allow only one of its interfaces as its Management address, the Management Address dropdown will not appear. Thus, it is possible for a device to show neither menu, or to show both.
NetMRI attempts to determine the device Type when the device is first discovered. If this determination is incorrect, you can override the device type as described above. To change the device type determined by NetMRI, open the Type list, click the correct device type, then click the Update Device button.
If a device matching the new type already exists for this IP address, NetMRI deletes the current device and no further action is allowed in the current Device Viewer window.
...
Note: The Type list shows only the device types known to NetMRI. If no appropriate type exists in the list for the current device, please contact Infoblox Technical Support so they can add that type to the automatic discovery process.
...
To stop collecting SNMP data from the device: Set the SNMP Status option to Disabled, then click Update Device.
...
To show or hide passwords: In the Show Passwords field, select Yes (to show) or No (to obscure).
To change the community string: Type the correct string in the RO Community field, then click Update Device.
NetMRI automatically attempts to determine the SNMP community string for each discovered device, and periodically checks the community string to determine whether the string has changed.
...
Note: If the SNMP community string cannot be determined, enter it in the RO Community field as described above, or add it in the Settings icon –> Setup –> Credentials page.
...
To specify the SNMP version understood by the device: Choose the correct SNMP Version option, then click Update Device.
To specify whether a configuration change is authorized for the device: Select the appropriate Config Change option, then click Update Device.
By default, Config Change is set to Group Default (i.e., configuration authorization is inherited from the group settings). If the device's Config Change setting should differ from the group, select Locked or Unlocked, as appropriate.
To enter the correct reboot time: Type the time (in YYYY-mm-dd hh:min:ss syntax) in the Reboot Time field, then click Update Device.
The SNMP sysUpTime counter wraps back to zero at about 497 days, making it difficult to determine exactly how long the device has been operating. Use the Reboot Time field to record the true uptime, as described above.
To remove the device from the network database: Click Delete Device, then click OK in the confirmation window. This deletes the device and closes the Device Viewer window.
...
Note: When a network device is not responding, NetMRI generates an issue indicating the device is down. If the device has actually been removed from the network, or its address has been changed, remove the device from the network database as described above.
...
If a non-network device (e.g., workstation, printer) doesn't appear in the network-wide ARP table during a given day and NetMRI can't contact during that day, the device is automatically removed from the database. Further, any device (regardless of type) is removed from the database if the appliance hasn't been able to contact it for seven days in a row.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
On rare occasions, Infoblox Technical Support may ask you to collect information about SNMP communications between NetMRI and a device. You will then be directed to send the SNMP log to Infoblox for analysis. 1.
- Open the Device Viewer and go to Settings & Status –> General Settings.
- Set the SNMP Debug option to Enabled, then click the Update Device button.
- Allow NetMRI to run for a time (typically an hour or two) specified by Infoblox Technical Support.
- As directed, send the SNMP log to Infoblox for analysis.
- Set the SNMP Debug option to Disabled, then click the Update button.
...
NetMRI provides an intelligent interface to the selected device's event logs. Event logs are collected only for interactions that the device has with NetMRI.
The Logs page (Device Viewer –> Settings & Status –> Logs) displays logs documenting interactions NetMRI has had with the device.
To download the log: Click the Text hyperlink above the left corner.
After a moment, the browser will show a dialog requesting to download an archive file for the logs from the selected device. The archive contains a concatenated text file, with the logs from the last few days of device operation.
Device credentials are a critical element in ensuring a device can be managed. You can add SNMP and CLI credentials to any individual discovered device. For more information, see Adding and Testing SNMP Credentials for a Device and Adding and Testing CLI Credentials for a Device.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
- The Device License Status tab, which provides two columns of information:
Licensed: Indicates whether the selected device is counted toward the limit allowed by the NetMRI license. A No listing indicates that NetMRI has discovered more network devices than the license allows.
Network Device: Indicates whether the device is considered one of the device types that are fully analyzed and eligible to be counted as a licensed device. - Data Collection tab: Lists times at which the most recent collection from various data sources was completed. The sources from which device support information is collected are listed under the Data Source column, and include the device's routing table (ipRouteTable), environment monitoring (DeviceEnvMon), and numerous other data sources as applicable to the specific device type. The End Time for the last data collection is also listed.
- Device Support tab: Lists various types of information supported for collection on the current device. The Value column is an indicator of NetMRI knowing that a given device supports the given type of data collection (SNMP, for example). A No value indicates that a type of data collection is not supported for the given device; the value shown here does not prevent NetMRI from collecting the given data. NetMRI may still attempt to collect the given data.
...