Glossary - NetBrain€¦ · 3. Are ‘ebgp-multihop’ and ‘update source’ commands configured on eBGP neighbor device? Procedure Logic: Step 1 Decide whether BGP is configured

Glossary

Built-In Automation Procedures

Table of Contents

Section 1: Troubleshooting ..................................................................................................................................... 3

1.1 Interface Level Check ......................................................................................................................................... 3

1.2 Device Level Check ............................................................................................................................................. 5

1.3 Routing ............................................................................................................................................................... 7

1.4 Switching .......................................................................................................................................................... 22

1.5 Multicasting ...................................................................................................................................................... 26

1.6 QoS ................................................................................................................................................................... 29

Section 2: Compliance Verification ....................................................................................................................... 30

Section 3: Change Verification .............................................................................................................................. 31

Section 4: Advanced Mapping .............................................................................................................................. 33

Section 5: Customized Inventory .......................................................................................................................... 35

Section 6: Traffic Path Analysis ............................................................................................................................. 36

NetBrain Technologies Inc. 65 Network Drive, 1

st Floor

Burlington, MA 01803

+1 800 605 7964 [email protected] www.netbraintech.com

mailto:[email protected]

http://www.netbraintech.com/

NETBRAIN ENTERPRISE SUITE 5.0: FEATURE HANDBOOK 2

Overview

This document provides a glossary of NetBrain’s built-in Automation Procedure library. These procedures are designed to

accelerate cumbersome and time-consuming network management tasks, such as troubleshooting, compliance verification,

change verification, and inventory management. The sections below provide a list of the procedures available in each

category with a description of the procedure and an explanation of how it works.

Every Automation Procedure has a logical workflow, which accesses the command line interface to gather network and

analyze data before returning results. The example procedure below illustrates the logic and sample output for a procedure

which detects speed/duplex mismatches.

Example Procedure: Is Speed/Duplex Mismatched

Logical Flow: Is Speed/Duplex Mismatched

Output: Is Speed/Duplex Mismatched

Important Note:

A large benefit of Automation Procedures is that they are highly customizable and easy to create, without scripting or

programming experience. While this document describes NetBrain’s built-in Automation Procedures, it is important to note

that these procedures provide only a sample of what can be accomplished through network automation.


Section 1: Troubleshooting

Complex troubleshooting logic can be translated into executable and repeatable procedures. This can help save hours of troubleshooting time, especially when resources are limited. With procedures, domain experts can transcribe their knowledge about a specific technology or troubleshooting technique which all engineers on the team can benefit from. The following sections are divided into common troubleshooting problems.

Categories of Troubleshooting Procedures

Interface Level Check Device Level Check Routing Switching Multicasting QoS

1.1 Interface Level Check Interface level procedures are designed to detect interface errors or interface misconfigurations. The built-in interface level procedures are listed below.

1. Is Speed/Duplex Mismatched This procedure checks whether speed and duplex values are consistent across connected interfaces. Discrepancies are highlighted in the map.

Procedure Logic: Step 1: Get CDP neighbor details (show cdp neighbors detail) Step 2: Check local interface speed and duplex (show interface) Step 3: Compare speed/duplex from local interface with neighbor interface

2. Does Any Interface Have Errors This procedure will check for input, output, CRC, and collision errors as well as output drops and more.

Procedure Logic: Retrieve show interface command twice and calculate the delta of each parameter. If the delta is greater than 0, you will see the warning message.

Related Command: show interface


3. Has Any Interface Configuration

Changed This procedure will check whether the interfaces' configuration, filtered by Design Reader, has changed.

Related Design Reader Filter: /Router/Interface Configuration

Note: Show command data must be benchmarked for comparison to work successfully.

4. Has Any Interface Status Changed This procedure will check whether any interface status changes have occurred.

Procedure Logic: Determine if interface IP address, status and protocol have changed

Related Command: show ip interface brief

Note: Show command data must be benchmarked for comparison.

5. Is Any Interface MTU Mismatched This procedure checks whether connected interface MTU values are consistent, and highlights discrepancies on the map.

Procedure Logic: Step 1 Get CDP neighbor details on local device to identify adjacent interfaces Related command: show cdp neighbors detail Step 2 Check MTU on local interface Related command: show interface Step 3 Compare MTU on local interface with MTU on neighbor interface

Note: This procedure requires CDP to be enabled on each device.

6. Is Any Interface Traffic Utilization High This procedure will check whether interface input and output traffic utilization is greater than a specified value (20% by default). If the interface input or output utilization is over threshold, warning messages will be displayed.

Procedure Logic: Step 1 Gather interface traffic utilization metrics Related Command: show interface Step 2 Determine if Input traffic utilization is above threshold Step 3 Determine if output traffic utilization is above threshold

7. Is Any Interface Flapping

This procedure checks whether any interface link status or protocol status are flapping.

Procedure Logic: Issue 'show logging' command and monitor for change in interface status or protocol status

Related Command: show logging


1.2 Device Level Check Device level procedures are designed to check device health and detect abnormal activity or behavior. The built-in device level procedures are listed below.

1. Comprehensive Device Check This procedure checks the basic health and status of a device, including reachability, recent reboots, connected modules, etc.

Checklist: 1)Ping devices from its Network Server 2)Is next-hop neighbor reachable 3)Did device reboot recently 4)Check device module status. 5)Is configuration changed 6)Is interface status changed 7)Is CPU usage high 8)Is Memory usage high 9)Check FAN and Temperature status Input: 1) Enter the threshold system uptime value (24 hours by default). 2) Enter the threshold CPU utilization value (60% by default). 3) Enter the threshold memory utilization value (60% by default). 4) Enter the threshold temperature value (60 degrees Celsius by default).

2. Did Device Reboot Recently This procedure indicates whether the device reboot occurred in specified hours (24 hours by default).

Procedure Logic: Get system uptime information from “show version” command and calculate the uptime to x hours. If the system uptime is less than 24 hours, you can see a warning message. Related Command: show version

Input: Specify number of hours (24 by default).

3. Is CPU Utilization High This procedure indicates if device CPU utilization is greater than a specified value (60% by default).

Procedure Logic: If device CPU utilization exceeded the threshold value in the previous 5 seconds, you will see warning messages while running this procedure. Related Command: show process cpu

Input: Enter the desired CPU utilization threshold value.

4. Is Debugging On This procedure checks if debugging is enabled.

Related Command: show debugging


5. Is Flash Memory Sufficient This procedure checks whether device flash memory utilization is greater than a specified value (80% by default). If device flash memory utilization is above threshold, you will see warning messages while running this procedure.

Procedure Logic: Get the flash memory information from 'show flash' command, then calculate the flash memory utilization.

Related Command: show flash

Input: Desired flash memory utilization value.

6. Is Memory Utilization High This procedure checks whether device memory utilization is greater than a specified value (60% by default).

If device memory utilization is above threshold, you will see warning messages while running this procedure. Related Command: show process memory

Input: Enter the desired memory utilization threshold value (60% by default)

7. Is Temperature High

This procedure checks whether device temperature is greater than a specified value (60 Celsius by default).

If device temperature is over threshold, you will see warning messages while running this procedure. Related Command: show environment

Input: Enter the desired threshold temperature (60 Degree Celsius by default)


1.3 Routing Routing procedures are designed to detect faulty dynamic routing configuration or to highlight routing configuration parameters on the map. They can also detect changes in route tables over time. This section is organized by routing protocol.

1.3.1 BGP

1. Is BGP Neighbor Not Coming Up This procedure is used to check the following three common mistakes in BGP configuration.

1. Is AS number consistent in neighbor device?

2. Is Ping successful to neighbor device

3. Are ‘ebgp-multihop’ and ‘update-source’ commands configured on eBGP neighbor device?

Procedure Logic: Step 1 Decide whether BGP is configured on current device. If we don't find the "router bgp" keyword within the configuration files of the device stored in the current baseline, the procedure will stop and exit. Step 2 Find the BGP neighbor with BGP state is "Idle" Related Commands: show ip bgp summary

Step 3 Check if the AS number is consistent on the peer devices Step 4 Check the reachability between peer devices using Ping command Related Commands: Ping

Step 5 Check if the "ebgp-multihop" and "update-source" command are configured on eBGP peer device

2. Has BGP Configuration Changed This procedure is used to check whether the BGP configuration filtered by Design Reader has changed.

Related Design Reader Filter:

/Router/BGP/All BGP Configuration

3. Has BGP Neighbor Changed This procedure is used to check whether the BGP neighbor status has changed.

Procedure Logic: Check if the neighbor’s AS number or BGP state have changed. Related Command: show ip bgp neighbors


4. Has BGP Route Entry Changed This procedure is used to check whether the BGP route table, summary networks, or subnets have changed.

Procedure Logic: Parse route entries learned from BGP and compare with historical data. "show ip route summary" is used to retrieve the show command data and parse the results. Refer to the sample in the right block for the parameters we will parse (Networks and Subnets) Related Command: show ip route summary

5. Have BGP Protocol Parameters

Changed This procedure checks whether the BGP protocol parameters have changed. If BGP parameters are different from what was benchmarked, the system will generate warning messages highlighting the differences.

Procedure Logic: Parse BGP Parameters and compare with historical data. Related Command: show ip protocols

Refer to the sample in the right block for the parameters that are parsed.

6. Highlight BGP Configuration This procedure will automatically draw BGP devices and highlight the BGP configuration filtered by Design Reader on the Qmap.


/Router/BGP/All BGP Configuration

7. Highlight BGP Default Route Originate This procedure will automatically draw BGP devices and highlight the BGP default route configuration filtered by Design Reader on the Qmap.


/Router/BGP/Default Route Originate

8. Highlight BGP Redistribution This procedure will automatically draw BGP devices and highlight the BGP redistribution configuration filtered by Design Reader on the Qmap.


/Router/BGP/Redistribution

9. Highlight BGP Route Summary This procedure will automatically draw BGP devices and highlight BGP route summary configuration filtered by Design Reader on the Qmap.


/Router/BGP/Route Summary


10. Is BGP Neighbor Flapping This procedure is used to check whether the BGP neighbor is flapping.

Procedure Logic: Check if the neighbor uptime is less than 10 seconds. Note: you can change the threshold value in the procedure trigger. Related Command: show ip bgp summary

1.3.2 EIGRP

1. Are EIGRP Parameters Consistent This procedure checks whether EIGRP protocol parameters (K-value and auto summary) are consistent for selected devices. If either parameter is inconsistent, NetBrain will highlight the discrepancies on the Qmap.

Procedure Logic: Step 1 Find EIGRP Parameters and push them to global output table:

$$k_value. $$auto_sum. Related Command: show ip protocols Step 2 Compare auto summary results for all devices. Step 3 Compare K values for all devices.

2. Has EIGRP Configuration Changed This procedure is used to check whether EIGRP configuration has changed. Changes will be highlighted on the map.

Procedure Logic: Compare the current data with the baseline data to determine whether the EIGRP configuration has changed.

3. Has EIGRP Neighbor Changed This procedure is used to check whether EIGRP neighbors have changed.

Procedure Logic: Parse the eigrp neighbor info and compare the current status with the benchmarked status. The following two parameters are evaluated:

Neighboring IP address

Neighboring Interface Related Command: show ip eigrp neighbors


4. Have EIGRP Parameters Changed This procedure checks whether EIGRP protocol parameters have changed. If EIGRP parameters are different from benchmarked values, the system will generate warning messages.

Procedure Logic: Step 1 Decide whether EIGRP is configured on current device. If "router eigrp" keyword doesn't exist within the configuration files of the device stored in the current baseline, the procedure will stop and exit. Step 2 Parse EIGRP parameters and compare with historical data. "show ip protocols" is used to retrieve the show command data and the results are parsed. Refer to the sample in the right block for the parameters we will parse. Related Command: show ip protocols

5. Have EIGRP Route Entries Changed This procedure is used to check whether the EIGRP route table, summary networks, or Subnets have changed.

Procedure Logic: Parse route entries learned from EIGRP and compare with historical data. Related Command: show ip route summary

6. Highlight Routers with Active EIGRP

Routes This procedure highlights devices with active EIGRP routes. An active EIGRP route is the state in EIGRP routing when a network change occurs and a feasible successor is not found by a EIGRP router for a given route. In this case, the router goes into active state, and queries its neighbors for routing information to the desired network.

Procedure Logic: Step 1 Decide whether EIGRP is configured on current device. If "router eigrp" keyword doesn't exist within the configuration files the procedure will stop and exit. Step 2 Find Active EIGRP routes and highlight in the map. Related Command: show ip eigrp topology active

7. Highlight EIGRP Configuration This procedure draws EIGRP devices and highlights their configurations on the Qmap.

Procedure Logic: Highlight EIGRP Configuration Design reader is used in this procedure to filter EIGRP configurations. Related design reader filter: /Router/EIGRP/All EIGRP Configuration Files

8. Highlight EIGRP Passive Interface This procedure discovers passive interfaces and highlights them on the Qmap.

Procedure Logic: Highlight EIGRP Passive Interfaces

Retrieve passive interface Related Command: show ip protocols


9. Highlight EIGRP Redistribution This procedure draws EIGRP devices and highlights their redistribution configurations on a Qmap.

Procedure Logic: Highlight EIGRP redistribution configuration Design reader is used in this procedure to filter EIGRP redistribution configurations. Related design reader filter: /Router/EIGRP/Redistribution

10. Highlight EIGRP Route Summary This procedure draws EIGRP devices and highlights their route summary configurations on the Qmap.

Procedure Logic: Highlight EIGRP route summary configuration Design reader is used in this procedure to filter EIGRP route summary configurations. Related design reader filter: /Router/EIGRP/Route Summary

11. Is EIGRP Neighbor Flapping This procedure is used to check whether EIGRP neighbors are flapping.

Procedure Logic: If EIGRP neighbor uptime is less than 10 seconds, mark neighbor as flapping. Note: This default uptime value can be modified in Probe1, Trigger1. Related Command: show ip eigrp neighbors

12. Map Specified EIGRP AS Devices This procedure will automatically draw all EIGRP devices in same AS number that you specified. Input: Specify one or more AS numbers

Procedure Logic: NetBrain will draw all devices running the defined AS number onto the current Qmap page. Related Filter: Filter router eigrp $as_number for configuration files

1.3.3 OSPF

1. Are OSPF Router IDs Duplicate

This procedure will check whether the OSPF router IDs are duplicate.

Procedure Logic: Add the OSPF router ID to the global output table. Check whether the router ID is already in the global output table. If so, the router ID is duplicate. Related Command: show ip protocols


2. Has OSPF Configuration Changed This procedure is used to check whether the OSPF configuration has changed.

Procedure Logic: Compare the current data with the baseline data to determine whether the OSPF configuration has changed. Design reader is used in this procedure to filter OSPF configuration. Related Design Reader Filter:

/Router/OSPF/All OSPF Configuration

3. Has OSPF Interface Changed

This procedure is used to check whether the OSPF interface has changed.

Procedure Logic: Compare the current data with the baseline data to determine whether the OSPF interface has changed. Related Command: show ip ospf interface

4. Has OSPF Neighbor Changed

This procedure is used to check whether the OSPF neighbor has changed.

Procedure Loigc: Compare the current data with the baseline data to determine whether the OSPF neighbor has changed. Related Command: show ip ospf neighbor

5. Have OSPF Parameters Changed

This procedure is used to check whether the OSPF parameters have changed. Note that if multiple OSPF processes are configured on a device, only the first process will be checked.

Procedure Logic: Compare the current data with the baseline data to determine whether the OSPF parameters have changed.

Related Command: show ip protocols

The following parameters will be referenced for comparison: 1)Outgoing update filter list for all interfaces 2)Incoming update filter list for all interfaces 3)Router ID 4)ABR role 5)ASBR role 6)Redistributions 7)Area number 8)Normal area number 9)Stub area number 10)NSSA area number 11)Maximum path 12)Network numbers 13)Reference bandwidth 14)Passive interfaces 15)Routing information sources 16)Routing information source distance Default distance


6. Have OSPF Route Entries Changed

This procedure is used to check whether the OSPF route table, summary networks, or subnets have changed.

Procedure Logic: Parse route entries learned from OSPF and compare with historical data. "show ip route summary" is used to retrieve the show command data and parse the results. Refer to the sample in the right block for the parameters we will parse (Networks and Subnets) . Related Command: show ip route summary

7. Highlight OSPF Configuration

This procedure will draw OSPF devices and highlight their configuration on the Qmap.

Procedure Logic: Highlight OSPF Configuration Design reader is used in this procedure to filter OSPF configuration. Related Design Reader Filter:

/Router/OSPF/All OSPF Configuration

8. Highlight OSPF Passive Interfaces

This procedure finds passive interfaces and highlights them on the Qmap.

Procedure Logic: Highlight OSPF Passive Interfaces Retrieve the passive interface info and parse the results, as shown on the sample map in the right pane. Related Command: show ip ospf interface

9. Highlight OSPF Redistribution

This procedure is used to highlight the OSPF redistribution configuration and the ASBRs on the Qmap.

Procedure Logic: Highlight OSPF redistribution and ASBR Design reader is used in this procedure to filter OSPF redistribution configuration. Related Design Reader Filter:

/Router/OSPF/Redistribution

10. Highlight OSPF Route Summary

This procedure is used to highlight the OSPF route summary configuration on the Qmap.

Procedure Logic: Highlight OSPF route summary configuration Design reader is used in this procedure to filter OSPF route summary configuration.


/Router/OSPF/Route Summary


11. Is OSPF Interface Cost Mismatched

This procedure is used to check whether the OSPF interface cost is mismatched. An OSPF metric cost mismatch among connected interfaces can lead to asymmetric routing. When a metric cost value is not explicitly stated, default values are derived based upon configured bandwidth.

Procedure Logic: Check OSPF cost on both sides and compare the results. Related Commands:

1)show ip ospf neighbor

2)show ip ospf interface

show ip ospf interface <interface name>

12. Is OSPF Interface DOWN

This procedure is used to check whether the OSPF interface is DOWN.

Procedure Logic: Check whether the OSPF interface is not in UP/UP state. Related Command: show ip ospf interface

13. Is OSPF Interface MTU Mismatched

This procedure is used to check whether the OSPF interface MTU is mismatched.

Procedure Logic: Check the OSPF interface MTU on both sides and compare the results. Related Commands:


show ip interface

14. Is OSPF Interface Network Type

Mismatched This procedure will check whether the OSPF interface network type is mismatched.

Procedure Logic: Check the OSPF network type on both sides and compare the results. Related Commands:


show ip ospf interface <interface name>

15. Is OSPF Neighbor Flapping

This procedure will check whether the OSPF neighbor is flapping.

Procedure Logic: Check whether the neighbor uptime is less than 10 seconds to detect flapping. Note: You can change the threshold value in the procedure trigger. Related Command: show ip ospf neighbor detail


16. Is OSPF Neighbor Not Advertising

Default Routes

This procedure will check if the OSPF neighbor is not properly advertsing default routes. The most common causes for an OSPF router not to advertise the default route are:

The default-information originate command is missing.

The default route is missing from the neighbor's routing table.

A neighbor is trying to originate a default into a stub area.

The NSSA ABR/ASBR is not originating the Type 7 default.

Procedure Logic: Step1 Check whether the "default-information originate" is configured under the OSPF process. Step2 Check area type and number. Related Command: show ip ospf <process ID>

Step3 Check whether the device is not generating the default route. Related Command: show ip ospf <process ID>

database external 0.0.0.0

17. Is OSPF Neighbor Stuck in 2-WAY

This procedure is used to check whether the OSPF neighbor is stuck in 2-WAY.

Procedure Logic: Step1 Check whether the OSPF neighbor is in 2-WAY state. Related Commands:show ip ospf neighbor

Step2 Check whether all neighbors via one interface are stuck in 2-WAY state. Related Commands:show ip ospf neighbor <interface

name>

Tip: If all the routers on an Ethernet segment are configured with priority 0, no routers on the segment will be in FULL state with any other router. This creates problems. At least one router on the segment must have a priority that is not set to 0.

18. Is OSPF Neighbor Stuck in EXSTART

or EXCHANGE

This procedure is used to check whether the OSPF neighbor is stuck in EXSTART/EXCHANGE. EXSTART/EXCHANGE is an important state during the OSPF adjacency process. In this state, the router elects a master and a slave as well as the initial sequence number. The entire database is exchanged during this state. If a neighbor is stuck in EXSTART/EXCHANGE for a long time, it is an indication of a problem. This procedure checks the most common causes of the problem: 1)Mismatched interface MTU

Procedure Logic: Step1 Check whether the OSPF neighbor is stuck in EXSTART/EXCHANGE state. Related Command: show ip ospf neighbor

Step2 Check MTU on both sides. Related Command: show ip interface <interface

name>

Step3 Check router ID on both sides. Related Command: show ip ospf interface <interface

name>

Step4 Ping EXSTART/EXCHANGE neighbor to check unicast


2)Duplicate router IDs on neighbors 3)Unicast connectivity is broken 4)Can’t ping across with more than certain MTU size.

connectivity. Related Command: Ping

Step5 Ping EXSTART/EXCHANGE neighbor with 1518 bytes to check Layer 2 connectivity. Related Command: Ping

19. Is OSPF Neighbor Stuck in INIT

This procedure is used to check whether the OSPF neighbor is stuck in INIT. When a router receives an OSPF Hello from a neighbor, it sends the Hello packet that includes that neighbor's router ID. If it doesn't include the neighbor's router ID, the neighbor will be stuck in INIT. This is an indication of a problem. The first packet that a router receives will cause the router to go into INIT state. The most common possible causes of this problem are as follows:

An access list on one side is blocking OSPF Hellos.

Multicast capabilities are broken on one side (6500 switch problem).

Authentication is enabled on only one side (virtual link example).

The frame-relay map/dialer map statement on one side is missing the broadcast keyword.

Hellos are getting lost on one side at Layer 2.

This procedure checks the following issues which might be the cause: 1) Access list on one side is blocking OSPF hellos

2) Authentication is enabled only on one side

Procedure Logic: Step1 Check whether the OSPF neighbor is stuck in INIT state. Related Command: show ip ospf neighbor

Step2 Check the authentication under the OSPF interface. show ip ospf interface <interface name>

Step3 Check the access list under the OSPF interface. show ip interface <interface name>


20. Is OSPF Reference Bandwidth

Consistent

This procedure is used to check whether the OSPF reference bandwidth is consistent between devices.

Procedure Logic: Step1 Select the first reference bandwidth value as the base value for checking the OSPF reference bandwidth consistency. Step2 Compare the other reference bandwidth values with the base value. Related Command: show ip protocols

Global Output Variables:

$$reference_BWs: This table variable records all the reference bandwidth informations.

$$different_BWs: This table variable records the reference bandwidth informations which are different from the baseline reference bandwidth.

You can export the global output table to .csv file when running procedure.

1.3.4 RIP

1. Has RIP Configuration Changed

This procedure is used to check whether RIP configuration filtered by Design Reader is changed.

Procedure Logic: This procedure utilizes the following Design Reader filter to detect changes: /Router/All RIP Configuration

2. Has RIP Interface Changed

This procedure is used to check whether the RIP interface Has changed.

Procedure Logic Compare results from 'show ip protocols' to a previous benchmark to detect changes. Related Command: show ip protocols

3. Is RIP Interface Down

This procedure is used to check whether the RIP interface is Down.

Step 1) Detect if current device is running RIP Related Command: show ip protocols

Step 2) Detect if RIP interfaces are Down Related Command: show ip interface brief


1.3.5 IS-IS

1. Are Area Addresses Mismatched

This procedure is used to check whether the IS-IS area addresses are mismatched.

Procedure Logic: Check the area addresses on both sides. If all area addresses are not in the neighbor area addresses list, an area address mismatch has occured. Step 1 Get Local IS-IS Interface Level and Tag Step 2 Check Local IS-IS Area IDs Step 3 Get Neighbor IS-IS Interface Level and Tag Step 4 Check Neighbor IS-IS Area IDs Related Command: show clns protocol <CLNS domain>


/Router/ISIS/All ISIS Configuration

2. Are Level 1 and Level 2 Interfaces

Mismatched This procedure is used to check whether the IS-IS level-1 and level-2 interfaces are mismatched.

Procedure Logic: Check IS-IS levels on both the local and neighbor interfaces to detect mismatches. Design reader is used in this procedure to filter IS-IS configuration. Related Design Reader Filter:


3. Are System IDs Duplicate

This procedure is used to check whether the system IDs are duplicate.

Procedure Logic: Step 1 Add the system ID to the global output table. Step 2 Check whether the system ID is already in the global output table. If so, the system ID is duplicate. Step 3 Highlight duplicate system IDs on the map. Related Command: show clns

Global Output Variables:

$$system_ids: This table variable records all the system IDs.

$$duplicate_ids: This table variable records the duplicate system IDs.

You can export the global output table to .csv file when running procedure.


4. Has IS-IS Configuration Changed

This procedure is used to check whether the IS-IS configuration has changed.

Procedure Logic: Compare the current data with the baseline data to determine whether the IS-IS configuration has changed. Design reader is used in this procedure to filter IS-IS configuration. Related Design Reader Filter:


5. Has IS-IS Interface Changed

This procedure is used to check whether the IS-IS Interface has changed.

Procedure Logic: This procedure will automatically compare the current data with the baseline data to determine whether the IS-IS interface has changed. Related Command: show clns interface

The following parameters are indexed for comparison: 1)IS-IS interfaces 2)IS-IS interface physical state 3)IS-IS interface protocol state 4)IS-IS interface CLNS protoco 5)IS-IS interface CLNS MTU 6)IS-IS interface circuit type 7)IS-IS interface level-1 metric 8)IS-IS interface level-1 priority 9)IS-IS interface level-1 circuit ID 10)IS-IS interface level-1 DR ID 11)IS-IS interface active level-1 adjacency number 12)IS-IS interface level-2 metric 13)IS-IS interface level-2 priority 14)IS-IS interface level-2 circuit ID 15)IS-IS interface level-2 DR ID 16)IS-IS interface active level-2 adjacency number

6. Has IS-IS Neighbor Changed

This procedure is used to check whether the IS-IS neighbor has changed.

Procedure Logic: Compare the current data with the baseline data.

Related Command: show isis neighbors

7. Have IS-IS Parameters Changed

This procedure will check whether the IS-IS parameters have changed. Note that if multiple IS-IS processes are configured on a device, only the first process will be checked.

Procedure Logic: Compare the current data with the baseline data to determine whether the IS-IS parameters have changed. Related Command: show ip protocols

The following Parameters are checked:

1)Outgoing update filter list for all interfaces

2)Incoming update filter list for all interfaces

3)Redistribution

4)Address Summarization


5)Maximum Path

6)Active interfaces

7)Passive interfaces

8)Routing information sources

9)Routing information source distance

Default distance

8. Have IS-IS Route Entries Changed

This procedure is used to check whether the IS-IS route table, summary networks, or subnets have changed.

Procedure Logic: Parse route entries learned from IS-IS and compare with historical data. "show ip route summary" is used to retrieve the show command data and parse the results. Refer to the sample in the right block for the parameters we will parse (Networks and Subnets) . Related Command: show ip route summary

9. Highlight IS-IS Configuration

This procedure is used to highlight the IS-IS configuration.

Procedure Logic: Highlight IS-IS Configuration Design reader is used in this procedure to filter IS-IS configuration. Related Design Reader Filter:


10. Highlight IS-IS Passive Interfaces

This procedure is used to find passive interfaces under IS-IS configuration and highlight them on the Qmap.

Procedure Logic: Highlight IS-IS Passive Interfaces Related Command: show ip protocols

11. Highlight IS-IS Redistribution

This procedure is used to highlight the IS-IS redistribution configuration on the map.

Procedure Logic: Highlight IS-IS Redistribution Configuration Design reader is used in this procedure to filter IS-IS redistribution configuration. Related Design Reader Filter:

/Router/ISIS/Redistribution

12. Highlight IS-IS Route Summary

This procedure is used to highlight the IS-IS route summary configuration on the Qmap.

Procedure Logic: Highlight IS-IS Route Summary Configuration Design reader is used in this procedure to filter IS-IS route summary configuration. Related Design Reader Filter:

/Router/ISIS/Route Summary


13. Is IS-IS Adjacency Stuck in INIT

This procedure is used to check IS-IS adjacencies which are stuck in INIT. The most common causes for an adjacency getting stuck in INIT state are mismatched interface MTU and misconfigured authentication parameters. This procedure checks the following issues which might be the cause: 1)Mismatched MTU 2)IS-IS hello padding 3)Misconfigured authentication

Procedure Logic: Step1 Check whether IS-IS adjacency is stuck in INIT state. Related Command: show isis neighbors

Step2 Check the IS-IS authentication under IS-IS interface. Related Command: show running-config interface

<interface name>

Step3 Check the MTU and hello padding under IS-IS interface.

Related Command: show clns interface <interface

name>

14. Is IS-IS Interface DOWN

This procedure will check whether the IS-IS interface is down.

Procedure Logic: Check whether the IS-IS interface is not in UP/UP state. Related Command: show clns interface

15. Is IS-IS Interface Metric Mismatched

This procedure is used to check whether the IS-IS interface metric is mismatched.

Procedure Logic: Check the IS-IS metric on both sides. Related Commands:

1)show isis neighbors

2)show clns interface

show clns interface <interface name>

16. Is IS-IS Neighbor Flapping

This procedure is used to check whether the IS-IS neighbor is flapping.

Procedure Logic: Check whether the neighbor uptime is less than 10 seconds. Note: You can change the threshold value in procedure trigger.

Related Command: show clns neighbor detail


1.4 Switching Switching procedures are designed to detect layer-2 network issues and highlight layer-2 design parameters (such as VTP, HSRP, and VLAN design) on the map.

1. Do VTP Statistics Have Errors This procedure determines whether config revision errors and digest errors are increasing on the switches in the live network.

Procedure Logic: Check VTP configuration revision number errors and configuration digest errors from the show vtp statistics command, as shown in the Qmap to the right. Related Command: show vtp statistics

Explanation of these two kinds of errors: If a configuration revision error is observed, this can be resolved by changing the VLAN database so that a VTP database with a higher revision number than the revision number of the competing databases is created. For example, on a switch that acts as the primary VTP server, add or delete a false VLAN in the administrative domain. The updated revision is propagated throughout the domain and overwrites the database for all devices. When all the devices in the domain advertise an identical database, the error no longer appears. A common reason for these digest errors is that the VTP password is not configured consistently on all VTP servers in the VTP domain. Troubleshoot these errors as a misconfiguration or data corruption issue.

2. Does a Device Have Unknown HSRP

Peers

This procedure detects whether there are unknown HSRP neighbors in the network. If there are unknown HSRP neighbors found from the show standby brief command, please verify Physical Layer connectivity and the HSRP router configuration (both local and remote). If the physical layer connectivity is correct, check for mismatched VTP modes.

Procedure Logic: Step 1 Detect whether HSRP is configured on the current device. If the "standby" keyword is not found within the configuration files of the device stored in the current baseline, the procedure will stop and exit. Step 2 Check whether the standby router is unknown. The show standby brief command is used to check the status of standby devices. If an unknown keyword is listed within the Standby column (as shown in the sample map in the right block), the system will generate a warning message to indicate this has occurred. Related Command: show standby brief


3. Has the HSRP Role Changed This procedure locates any HSRP role changes on your HSRP devices and displays them on the map.

Procedure Logic: Step 1 Detect whether HSRP is configured on the current device. If the "standby" keyword is not found within the configuration files of the devices stored in the current baseline, the procedure will stop and exit.

Step 2 Parse the HSRP role for each group and compare with historical data. Devices with status changes will be highlighted on the Qmap. All corresponding data will be saved as map notes, as shown in the Qmap to the right. Related Command: show standby

4. Has the Root Bridge Changed

This procedure determines whether the root ID has changed for each VLAN.

Procedure Logic:

The Root ID for each VLAN is parsed from the show spanning-tree command and compared with historical data. If the root ID has changed for one or more VLANs, the system will produce warning messages. Related Command: show spanning-tree

5. Has the STP Port Status Changed for

Specified VLANs

This procedure determines whether the interface status for STP has changed for a specified VLAN. Enter a VLAN ID when prompted and compare the spanning tree status for the specified VLAN.

Procedure Logic:

Step1 Find device/interface status and draw to the current map After entering the VLAN ID, the system will use the 'show spanning-tree vlan $$VLAN_ID command' ($$VLAN_ID will be converted to specified value) to retrieve the live data. The system will parse the port status (forwarding or blocked) and compare it with historical data. Step2 Draw device notes to the map If any changes exist, map notes outlining the changes will be created linking to the corresponding device.

6. Highlight HSRP Devices This procedure is used to highlight HSRP devices with their roles.

Procedure Logic: Step 1 Detect whether HSRP is configured on the current device. If the "standby" keyword is not found within the configuration files of the devices stored in the current baseline, the procedure will stop and exit. Step 2 Parse the HSRP role for each group and highlight the results on the Qmap.

If this device is the active device for all groups, the device will be highlighted as "HSRP Active"


If this device is a standby device for all groups, the device will be highlighted as "HSRP Standby"

If this device is the active device for some groups but a standby for other groups, the device will be highlighted as "HSRP Active/Standby"

Related Command: show standby

7. Highlight STP for Specified VLANs This procedure draws the L2 topology for the SPT of a specific VLAN. Right-click on the Qmap and select Run Procedure to check the devices within the current Qmap page. When the system prompts, enter a VLAN ID and draw the spanning tree status for the specified VLAN.

Procedure Logic: Find Device/Interface status and display on the current map After entering the VLAN ID, the system will use the 'show spanning-tree vlan $$VLAN_ID' command ($$VLAN_ID will be converted to specified value) to retrieve the live data. The system will automatically locate the root for this VLAN and draw a note on Qmap. Ports in forwarding or blocked status will be highlighted on the Qmap.

8. Highlight VLAN This procedure highlights VLAN information for switches. The input global variable has a default value of "All", meaning that the system will highlight all VLANs. Enter one or multiple VLAN IDs for the system to only highlight selected VLANs. Right-click on the Qmap and select Run Procedure to check devices within the current Qmap page.

Procedure Logic: Highlight VLAN from show command results This procedure uses show commands (show interface status for Cisco IOS SW and show port status for Cisco Catalyst SW) to find related interfaces for VLANs, and then highlights them on the current Qmap.

Related Commands:

1) show interface status

2) show port status

9. Is Any Interface Switchport Mode

Mismatched This procedure checks whether the connected interfaces' switchport mode configuration is consistent, and draws the result on a L2 Qmap.

Procedure Logic: Step 1 Collect CDP neighbor information. Related Commands: show cdp neighbors detail

Step 2 Check the local interface swtichport mode for all devices on the map. Related command: show interface <interface name>

switchport

Step 3 Compare neighbor interface information to see if any are mismatached and draw the reslut on a L2 Qmap. Tips: CDP needs to be enabled on devices for procedure to process successfully.


10. Is the Number of Port-Channel Active

Members 0 This procedure checks whether switches have invalid Port-Channel configuration(with 0 active members) and will draw relevant devices and corresponding notes to the Qmap.

Procedure Logic: Step 1 Collect Port-Channel information. Related Command: show ip interface brief

Step 2 Locate devices that have Port-Channels with 0 active members configured. Related Command: show interface port-channel

$PO_list

Step 3 Automatically highlight and create notes on the Qmap for these devices.

11. Is the Stackable Switch Version

Mismatched

This procedure checks whether the stackable switches' versions are consistent, and then draws the result on the Qmap.

Related Command: show switch


1.5 Multicasting Multicasting procedures are designed to help visualize multicast design, which is dynamic in nature. Procedures also help detect changes in multicast configuration.

1. Has Multicasting Configuration

Changed This procedure checks whether multicasting configuration has changed.

Procedure Logic: Parse the configuration file for two benchmark states and identify configuration changes in multicasting. Related Design Reader Filter:

/Router/All Multicasting Configuration

2. Has PIM Interface Changed

This procedure checks whether the PIM interface has changed.

Procedure Logic: Compare the current data with the baseline data to determine whether the PIM interface has changed. Related Command: show ip pim interface

3. Has PIM Neighbor Changed

This procedure checks whether the IP PIM neighbor has changed.

Procedure Loigc: Compare the current data with the baseline data to determine whether the PIM neighbor has changed. Related Command: show ip pim neighbor

4. Highlight Multicasting Configuration

This procedure is used to highlight the multicasting configuration.

Procedure Logic: Highlight Mulcasting Configuration Design reader is used in this procedure to filter multicasting configuration. Related Design Reader Filter:

/Router/All Multicasting Configuration

5. Is PIM Interface Down

This procedure checks whether the PIM interface status is down.

Procedure Logic: Check whether the PIM interface is not in UP/UP state. Related Command: show ip pim interface detail


6. Map Downstream Shared Tree

This procedure maps the downstream shared tree.

Procedure Logic: Step 1 Use the "show ip mroute <group>" command to find the outgoing interfaces in the (*, G). Step 2 Use the "show ip pim neighbor" command to find the next hops and the DRs. Step 3 Use the "show ip igmp group" command to determine whether the device is Last Hop Router or Reporter.

Related commands:

1)show ip mroute <group>

2)show ip pim neighbor

3)show ip igmp group

* Required Input Parameter: Multicasting group addresses

7. Map Downstream Source Tree

This is procedure is used to map the downstream source tree.

Procedure Logic: Step 1 Use the "show ip mroute <group>" command to find the outgoing interfaces in the (S, G). Step 2 Use the "show ip pim neighbor" command to find the next hops and the DRs. Step 3 Use the "show ip igmp group" command to determine whether the device is Last Hop Router or Reporter.

Related commands:




*Required Input Parameter:

1.Multicasting source addresses 2.Multicasting group addresses

8. Map Upstream Shared Tree

This is procedure maps the upstream shared tree.

Procedure Logic: Step 1 Use the "show ip mroute <group>" command to find the imcoming interface and the next hop in the (*, G). Step 2 Use the "show ip pim neighbor" command to find the DRs. Step 3 Use the "show ip igmp group" command to determine whether the device is Last Hop Router or Reporter.

Related commands:




*Required Input Parameter: Multicasting group addresses


9. Map Upstream Source Tree

This procedure maps the upstream source tree.

Procedure Logic: Step 1 Use the "show ip mroute <group>" command to find the imcoming interface and the next hop in the (S, G). Step 2 Use the "show ip pim neighbor" command to find the DRs. Step 3 Use the "show ip igmp group" command to determine whether the device is Last Hop Router or Reporter.

Related commands:




*Required Input Parameter:

1.Multicasting source addresses 2.Multicasting group addresses


1.6 QoS QoS procedures are designed to highlight QoS configuration and policy design on the map

1. Has QoS Configuration Changed

This procedure checks whether the QoS configuration filtered by Design Reader has changed.

Procedure Logic:

Step 1 Parse the system to detect CBWFQ configuration changes. Step 2 Parse the system to detect CAR configuration changes. Step 3 Parse the system to detect CQ configuration changes. Step 4 Parse the system to detect LLQ configuration changes. Step 5 Parse the system to detect PQ configuration changes. Step 6 Parse the system to detect WFQ configuration changes. Step 7 Execute the "Highlight QoS Configuration" procedure to highlight changes on the map automatically.


/Router/Quality of Service

2. Highlight QoS Configuration

This procedure highlights the QoS configuration filtered by Design Reader on the Qmap.

Procedure Logic: Leveraging Design Reader, the following configuration will be annotated on the map: 1)CBWFQ configuration 2)CAR configuration 3)CQ configuration 4)LLQ configuration 5)PQ configuration 6)WFQ configuration Related Design Reader Filter:

/Router/Quality of Service

3. Highlight Visible Interfaces Policy-

Map Status This procedure checks the visible interfaces "policy-map" status and highlights it on the Qmap. You can run this procedure twice to view the status change.

Related Command: show policy-map interface

<interface name>

4. Highlight Visible Interfaces Queue

Strategy This procedure highlights the interface queue strategy on the Qmap.

Related Command: show interface


Section 2: Compliance Verification Compliance procedures are designed to scan the network and detect non-compliant configuration, such as missing security parameters.

1. Is Login Authentication

Enabled This procedure checks whether login

authentication is enabled on each device.

Procedure Logic: The configuration file for each device is scanned to determine if login authentication is enabled.

Related Command: show running-config

2. Is Password Encryption Enabled

This procedure checks whether the device password encryption service is enabled.

Procedure Logic: Search "no service password-encryption" command in the configuration file.

3. Is Public or Private Keyword

Configured in SNMP Community String

This procedure checks whether the "public" or "private" keyword is configured in the SNMP community string.

Procedure Logic: Search the keyword "public" or "private" in the SNMP configuration.


Section 3: Change Verification Verification procedures are designed to test the network after a network change to validate network health.

1. Are Next Hop Neighbors

Reachable

This procedure checks the connectivity from one device on the Qmap to its visible neighbors.

Procedure Logic: Step 1 Collect visible interfaces from devices on the Qmap. Step 2 Ping next hop neighbor interfaces to ensure reachability. Related Commands: Ping

2. Has Key Route Entry Changed

This procedure checks whether the key route entries have changed.

Procedure Logic:

Procedure Logic: Step 1 Has routing protocol changed? Step 2 Has next hop changed? Step 3 Has outbound interface changed? Related Command: show ip route <destination>

Input: One or more important destination route entries.

3. Ping and Traceroute from

Network Devices to a Group of End Host

This procedure checks the connectivity between specified core device(s) and main server(s). If there is a ping failure, the procedure will check routes and perform traceroute automatically.

Procedure Logic: Step 1 Use the Ping command from the core device(s) to the main server. Related Commands: Ping

Step 2 Verify if the Ping has failed. Step 3 Run a traceroute from the main server if the device has a route, but the Ping has failed. Related Commands: Traceroute

Input: 1) Enter IP addresses of one or more devices. 2) Enter one or more destination IP addresses.


4. Ping from Network Devices to a

Group of End Host This procedure checks the connectivity between specified core devices and main servers using the Ping command.

Procedure Logic: Execute a ping from the specified network device(s) to a group of end host(s). Related Command: Ping

Input: 1) Enter IP addresses of one or more core devices. 2) Enter one or more destination IP addresses. Search the keyword "public" or "private" in the SNMP configuration.


Section 4: Advanced Mapping Advanced mapping procedures are designed to enhance NetBrain’s mapping capabilities. These procedures will highlight specific configuration parameters on the map, and create custom maps for specified areas (e.g. VTP domains, OSPF areas, etc.)

1. Highlight DHCP Server Config

This procedure finds devices configured as DHCP Servers and displays the following parameters on a Qmap (in the device notes). 1) Pool Name 2) Network 3) Gateway 4) DNS Server 5) Netbios Server


2. Highlight Devices in Same VTP

Domain

This procedure will identify all devices that belong to the same VTP domain and draw them on the Qmap. Each page within the Qmap will represent devices within the same VTP domain.

Procedure Logic: Identify VTP Domain and Mode, draw devices on the Qmap and note the device with operating mode “Server”. Related Commands:

1)show vtp status

show vtp domain

3. Highlight Interfaces with WCCP

Enabled

This procedure finds interfaces with enabled WCCP and highlights them on the Qmap.

Related Command: show ip wccp interfaces

4. Highlight OSPF Backbone Area

This procedure will highlight all interfaces running in OSPF area 0, determine ABR devices, then draw and highlight them on the Qmap.

Procedure Logic: Step 1 Find and highlight ABR. Related command: show ip ospf

Step 2 Highlight interfaces running in OSPF Backbone Area. Related command: show ip ospf interface

Step 3 Check OSPF neighbor state and detect neighbors that do not have state value "FULL". Related command: show ip ospf neighbor


5. Highlight Specified BGP AS

Devices This procedure will draw all BGP devices in the specified AS number.


6. Highlight Stackable Switches

This procedure finds stackable switches and draws devices on the Qmap. The Qmap will record basic information such as switch count, port count, master, etc.

Procedure Logic: Step 1 Determine if the given switch is a stacked switch. Step 2 Calculate stacked switch port count and draw on the Qmap.

Related command: show version


Section 5: Customized Inventory Customized inventory procedures are designed to enhance the inventory database by dynamically adding fields to the database (e.g. IOS image, interface media, etc.)

1. IOS Image File [Device

Attribute]

This procedure adds a customized device attribute <IOS Image File> by issuing the "show version" command, parsing the system image file information, and then adding this attribute to the device. You can view the value in device properties pane by selecting the “Properties” option in the device right-click menu.

Procedure Logic: Step 1 Issue the command "show version" to each device on the map. Step 2 Collect the IOS image file information for all devices. Step 3 Add the IOS image file attribute to each device. Related Command: show version

2. Interface Media Type [Interface

Attribute]

This procedure adds a customized interface attribute <Interface Media Type> by retrieving the "show interface" command, parsing the interface media type, and then adding this attribute to the interface. You can view the value in the device properties pane by selecting the “Properties” option in the device right-click menu, and then selecting the “Interface” tab page.

Procedure Logic: Step 1 Issue the "show interface" command. Step 2 Parse the interface media type for each device. Step 3 Add the newly collected attributes to the interfaces. Related Command: show interface

3. Module Status [Module

Attribute]

This procedure adds a customized module attribute <Module Status> by issuing the "show module" command, parsing the module status information, then adding this attribute to module. You can view the value in the device properties pane by selecting the “Properties” option in the device right-click menu, then selecting the “Interface” tab page.

Procedure Logic: Step 1 Issue the command "show module" to each device on the map. Step 2 Collect the module status information for all devices. Step 3 Add the module status attribute to each device. Related Command: show module


Section 6: Traffic Path Analysis Traffic path procedures are designed to enhance NetBrain’s built-in A-to-B mapping capabilities. These procedures add support for mapping through MPLS clouds and NAT devices.

1. General Path Procedure

This procedure finds next hop info to destination via show ip route x.x.x.x command, if no specified routing entry exists, the procedure will use show ip route 0.0.0.0 to find the default route.

Procedure Logic Step1 Check whether VRF is configured on inbound interface

Related Command：show ip vrf

Step2 Check whether NAT is configured on inbound interface

Related Command：show run interface $$in_if

Step3 Check specific routing entry to the destination

Related Command：show ip route $$dest_ip

Step4 Check default route to the destination

Related Command：show ip route 0.0.0.0

2. Path Across MPLS Cloud BGP

This procedure calculates path across MPLS Cloud with CE and MPLS Cloud communication via BGP protocol.

Procedure Logic： Step1 Check whether CE and the MPLS Cloud are communicated via BGP. The system will run follow-up probes if BGP is enabled.

Related Command：show ip bgp summary

Step2 Find the rooting entry to destination on last hop CE, and get the prefix

for the matching entry.

Related command：show ip route $$dest_ip

Step3 Find out which CE advertised the same route to MPLS Cloud via BGP as we found from the last hop CE.

Related Command：show ip bgp neighbors $$mpls_ip

advertised-routes

Step4 On the device advertised the route to destination, issue show ip route x.x.x.x command to find the specific routing entry to the destination.


Step5 If no specific routing entry exists for the destination, find the next hop info via default route.



3. Path Across MPLS Cloud IGP

This procedure calculates path across MPLS Cloud with CE and PE communication via IGP routing protocol.

Procedure Logic： Step1 Check whether CE and the MPLS Cloud are communicated via BGP. The system will run follow-up probes if IGP is used between them. Related Command: show ip bgp summary

Step2 Find the rooting entry to destination on last hop CE, and get the prefix for the matching entry.


Step3 On the CE devices connected to the MPLS cloud, find the route entry to the destination (the results matching that we found on last hop CE is recognized as a match and the next hop IP cannot be an IP address on MPLS cloud.) Related Command: show ip route $$dest_ip

4. Path Across MPLS Inbound PE

This procedure finds destination route on inbound PE device.

Procedure Logic Step1 Find VRF name and RD for inbound interface.


Step2 Find whether specific route entry exists in the VRF for the destination.

Related Command：show ip route vrf $P1.vpn_name

$$dest_ip

Step3 The system will use the default route if no specific route entry exists

Related Command：show ip route vrf $P1.out_vrf

0.0.0.0

5. Path Across MPLS Outbound

PE This procedure finds destination route on outbound PE device.

Procedure Logic： Step1 Find out the correct VRF info via the RD value exported from “Path across MPLS Inbound PE”.


Step2 Find whether specific route entry exists in the VRF for the destination.

Related Command： show ip route vrf $P1.out_vrf

$$dest_ip

Step3 The system will use the default route if no specific route entry exists.

Related Command：show ip route vrf $P1.out_vrf

0.0.0.0


6. Path Across NAT Device

This procedure calculates path across NAT devices.

Procedure Logic Step1 Check whether NAT is configured on inbound interface.

Related Command：show run interface $$in_if

Step2 Check whether the corresponding entry exists in the NAT table for the source IP address or destination IP address.

Related Command：show ip nat translations

Step3 Find the specific routing entry to the NAT’d address for the destination.


Step4 Find the default routing entry to the NAT’d address for the destination if no specific route entry exists.


Documents

Glossary - NetBrain€¦ · 3. Are ‘ebgp-multihop’ and ‘update source’ commands configured on eBGP neighbor device? Procedure Logic: Step 1 Decide whether BGP is configured