Loading

×Sorry to interrupt
This page has an error. You might just need to refresh it.
[NoErrorObjectAvailable] Uncaught ReferenceError: addCTracking is not defined
Failing descriptor: {markup://c:KM_ArticleThemeLayout}

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Smarts NPM: "ABRNotInBackbone" event is generated even though L2/3 Switch or router is physically connected to backbone device (383119)

Last Updated: 12/17/2018Categories: TroubleshootingTotal Views: 4493Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Symptoms

Switch or router is not functioning in Smarts NPM as Area Boarder Router (ABR)

The following system behaviors may be observed with this issue:

Router or switch device seems to be erroneously alerting and generating "ABRNotInBackbone" events in Smarts NPM.

Smarts NPM generates "ABRNotInBackbone" alerts to indicate that a Layer 2/3 switch or router is not configured as an Area Boarder Router (ABR) and is not connected to area 0.0.0.0, even though the switch/router is physically connected to area 0.0.0.0

Cause

The switch or router device is not correctly configured as an ABR, resulting in missing data in the SNMP response and causing Smarts NPM to generate the "ABRNotInBackbone" alerts.  This is not an issue in the Smarts NPM software, but occurs when devices are not properly configured.

In particular, the OIDs are either empty or not present that identify the area to which the interfaces of a device are connected.  The OID that Smarts NPM uses to check the OSPF interfaces and their area connections is the ospfIfAreaId (OID .1.3.6.1.2.1.14.7.1.3).  If this OID does not have any indexes with interfaces connected to 0.0.0.0 in it, then the Smarts will generate the ABRNotInBackbone alert for any Layer 2 or Layer 3 device that is otherwise configured as an ABR.

Devices are identified to Smarts NPM as being configured as ABR devices by having the ABR flag in OID 1.3.6.1.2.1.14.1.4.0 set to 1.  If the value of this OID is 1, then an interface must have a connection to area 0.0.0.0 (backbone).  The ABRNotInBackbone alert is generated when devices that have ABR flag in OID 1.3.6.1.2.1.14.1.4.0 set to 1 but are not showing any interfaces with a connection to the backbone.

Resolution

To address this issue, the Switch/Router device will need to be re-configured to make the missing OIDs appear. This is done by adding a network statement that identifies the switch/router as a backbone device, identifying router IDs, and updating the OSPF configuration as follows:

Log into the router command line interface and run the following command:

sh configuration | beg router ospf <ospf session number>

<ospf session number> is the ospf session that the Smarts software is throwing the alert about

Identify and record the router ID.

The format of the router ID will be: router-id w.x.y.z

Run the following command to add the network statement that will identify the router as a backbone device:

network w.x.y.z <subnet> area 0

Example
On a router with IP address 10.16.21.5 and backbone subnet 0.0.0.0, the command would be as follows:

network 10.16.21.5 0.0.0.0 area 0

Run the following command and confirm that the network statement with the router ID was added:

sh configuration | beg router ospf <ospf session number>

After completing the preceding steps, the router configuration should be updated and the router device should start updating the SNMP values to contain the OIDS necessary to clear the Smarts NPM ABRNotInBackbone alerts.

Related Information

How to determine which interfaces are connected to the backbone

The OID that identifies which areas to which the interfaces of a device are connected uses the following format:

<OSPF MIB OID>.<OSPF interface IP address>.<OSPF addressLess interface flag>

The index for the OID is <OSPF interace IP address>.<OSPF addressLess interface flag>.

So, to check the OID containing the OSPF interfaces area ID, you need to find the OID with the following components:

<OSPF MIB OID> = .1.3.6.1.2.1.14.7.1.3
<OSPF interface IP address> = x.x.x.x
<OSPF addressLess interface flag> = a

It would look like the following in the SNMP MIB walk:

.1.3.6.1.2.1.14.7.1.3.x.x.x.x.a: <value>

In the SNMP MIB walk output above, <value> represents the area ID that the interface is connected. For the backbone, the <value> will be 0. For any other area ID, the <value> will be calculated as follows:

((a*256+b)*256+c)*256+d
where a,b,c,d come from the area ID.

For example, an area ID of 1.2.3.4 would have a <value> of a=1, b=2, c=3, d=4 and be calculated as follows:

(1*256+2)*256+3)*256+4) = 1540

For example consider an interface on IP address 10.16.21.45, where the interface is not IP addressless and the interface is connected to area 0.0.0.0, the SNMP MIB walk output for this device would be the following:

1.3.6.1.2.1.14.7.1.3.10.16.21.45.0: 0

If a device does have an IP addressless interface, then the  <OSPF interface IP address>  will be the interface IfIndex, and the <OSPF addressLess interface flag> will be set to 1.

For example lets assume we have a device that is an area boarder router (ABR) and it has an interface that is IP addressless that is connected to the backbone.  Lets say this interface has an IfIndex = 5.  Then the ospfIfAreaId oid would have the following components:

<OSPF MIB OID> = .1.3.6.1.2.1.14.7.1.3
<OSPF interface IP address> = <IfIndex> = w.x.y.z
<OSPF addressLess interface flag> = a

It would look like the following in the MIB walk: .1.3.6.1.2.1.14.7.1.3.w.x.y.z.a: <value>

For our example the values of the components would be as follows:

<OSPF MIB OID> = .1.3.6.1.2.1.14.7.1.3
<OSPF interace IP address> = <IfIndex> = 0.0.0.5
<OSPF addressLess interface flag> = 1

So the ospfIfAreaId would look like the following in the SNMP MIB walk:

.1.3.6.1.2.1.14.7.1.3.0.0.0.5.1: 0

When the issue described by this article is encountered, look for OIDs with the following formats:

.1.3.6.1.2.1.14.7.1.3.W.X.Y.Z.1: 0
OR
.1.3.6.1.2.1.14.7.1.3.W.X.Y.Z.0: 0

If neither of these formats are present, then the device is not correctly configured and the Smarts alert is correct.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

No results for undefined

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

Related Versions:

VMware Smart Assurance - SMARTS

Take Our Survey

Support Assistant