OSPFNeighborRelationship event triggered

Products

VMware Smart Assurance

Issue/Introduction

Symptoms:

There are at least two reasons why this event would be triggered. This article aims to help you investigate and troubleshoot both reasons.

The two reasons are:
A: OSPFNeighborRelationship event triggered when device on one side of relationship no longer in OSPF topology
B: The OSPFNeighborRelationship event is triggered when there is a duplicate IP address seen using the dxa-topology-sync.asl Script.

Environment

Network Protocol Manager (NPM) 10.1.x

Cause

The neighbor is not part of the OSPF areas or there is a duplicate IP address in the neighbor relationship.

Resolution

1: Configure OSPF neighbor correctly by removing device that is no longer on network from configuration of device remaining in repository. If correctly configured SMARTS OSPF domain will prune the Neighbor connection to a half link.

2: Remove the duplicate IP address.

Additional Information

A: The neighbor is not part of the OSPF Areas.

Remove only the OSPF Device (e.g device1/81.144.19.216) remaining in SMARTS repository still configured to be the neighbor of device (e.g 10.1.1.1). This is an Example notification where 10.1.1.1 is no longer in OSPF SMARTS repository :

OSPF-NBR-device1/2 [Fa0/1] [81.144.19.216] [PoP LAN2 vcat2 port 6/14, CN1011]-81.144.19.216->10.1.1.1

To verify correct OSPF configuration on device:

1. If it's a Cisco device, check OSPF configuration using CLI by running "show ip ospf neighbors". Example output below may list device (e.g 10.1.1.1) no longer in repository configured as an OSPF Neighbor :

device1#show ip ospf neighbor

81.144.126.126 10 2WAY/DROTHER 00:00:14 10.1.1.1 FastEthernet0/1

81.144.126.127 10 2WAY/DROTHER 00:00:12 81.144.19.213 FastEthernet0/1

2. Carry out a sm_snmpwalk of the OSPF MIB on the device remaining in the repository (e.g 81.144.19.216) to verify if the device removed (e.g 10.1.1.1) from the repository is still present in the MIB, Example output below :

smarts1#sm_snmpwalk --oid=.1.3.6.1.2.1.14.4.1 smarts

SNMP version v2c is not supported; trying SNMP version v1 ...
Saving MIB walk to file(s) smarts.walk' 'smarts.mimic' 'smarts.snap' ...
End of MIB walk

smarts#more smarts.snap

.1.3.6.1.2.1.14.4.1.1.3.8.0.1.1.81.144.17.77.10.1.1.1 IP-ADDRESS 03080001
.1.3.6.1.2.1.14.4.1.1.3.8.0.1.1.81.144.17.78.81.144.17.78 IP-ADDRESS 03080001
.1.3.6.1.2.1.14.4.1.1.3.8.0.1.1.81.144.17.79.81.144.17.79 IP-ADDRESS 03080001
.1.3.6.1.2.1.14.4.1.1.3.8.0.1.1.81.144.17.80.81.144.17.80 IP-ADDRESS 03080001
.1.3.6.1.2.1.14.4.1.1.3.8.0.1.1.81.144.17.128.81.144.17.128 IP-ADDRESS 03080001
.1.3.6.1.2.1.14.4.1.1.3.8.0.1.1.81.144.17.129.81.144.17.129 IP-ADDRESS 03080001

B: A duplicate IP address in the neighbor relationship will cause this.

If you suspect this may be the case, you will see this type of message in your NPM domain log:

dxa-topology-sync.asl: [<domain name>] 'IP::IP-<IPaddress_1>' mapped to 'DuplicateIP::IP-<IPaddress_1>'
XXXX-OSPF_en_US_UTF-8.log(525595): June 16, 2016 10:08:07 AM GMT+00:00 +789ms 7088505 3635456320 WARN Discovery #3 DXA_MESSAGE-DXA_ECLASSMAPPED dxa-topology-sync.asl: [<domain name>] 'IP::IP-<IPaddress_2>' mapped to 'DuplicateIP::IP-<IPaddress_2>'
XXXXX-OSPF_en_US_UTF-8.log(619027): June 17, 2016 6:07:34 AM GMT+00:00 +539ms 8623133 3629152576 WARN Discovery #8 DXA_MESSAGE-DXA_ECLASSMAPPED dxa-topology-sync.asl: [<domain name>] 'IP::IP-<IPaddress_3>' mapped to 'DuplicateIP::IP-<IPaddress_3>'

The resolution here is to speak with your network admin about having the duplicate device removed.