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

Products

• VMware Smart Assurance

Issue/Introduction

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

Environment

VMware Smart Assurance - SMARTS

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:

1. 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

2. Identify and record the router ID.
   • The format of the router ID will be: router-id w.x.y.z
3. 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

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

sh configuration | beg router ospf <ospf session number>

5. 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.

Additional 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.