The Nortel Discovery Protocol (NDP) formerly called SynOptics Network Management Protocol (SONMP) is a data link layer (Layer 2) network protocol for topology discovery of Nortel devices. It’s very similar to the Cisco Discovery Protocol (CDP) if only just a little simpler.
I’ve used the Nortel Discovery Protocol on a number of occasions to help document and troubleshoot problems within a network. While Nortel’s Java Device Manager (GUI) provides support for displaying the topology table it leaves some very vital information out, specifically the remote card and port from where the connection is originating. You can however, view that information from the CLI interface of Nortel’s Ethernet Switches (ES) and Ethernet Routing Switches (ERS).
Here’s an example of the topology table from an Ethernet Routing Switch 5530 stack which is Split MultiLink Trunk (SMLT) connected to a cluster pair of Ethernet Routing Switch 8600s;
5530-24TFD#show autotopology nmm-table LSlot RSlot LPort IP Addr Seg ID MAC Addr Chassis Type BT LS CS RPort ----- --------------- -------- ------------ ---------------- -- --- ---- ----- 0/ 0 10.102.255.65 0x000000 00159BEACC00 5530-24TFD 12 Yes HTBT NA 1/23 10.102.1.5 0x000406 0004387070E8 Passport 8610 12 Yes HTBT 4/ 6 2/47 10.102.1.6 0x000406 000FCDF1E0E8 Passport 8610 12 Yes HTBT 4/ 6
You can see from the information above that ports 1/23 and 2/47 on the ERS 5530 connect to port 4/6 on the ERS 8600 Core A (10.102.1.5) and port 4/6 on the ERS 8600 Core B (10.102.1.6).
Looking at one of the core ERS 8600 switches we can see the following topology table;
ERS8600:5# show sys topology ================================================================================ Topology Table ================================================================================ Local Rem Port IpAddress SegmentId MacAddress ChassisType BT LS CS Port -------------------------------------------------------------------------------- 0/0 10.102.1.5 0x000000 000438707000 ERS8610 12 Yes HtBt 0/0 1/1 10.102.1.6 0x000101 000fcdf1e000 ERS8610 12 Yes HtBt 1/1 1/5 10.102.255.19 0x00012f 001e7e7b0c01 mBayStack4500-48GT-PWR 12 Yes HtBt 1/47 1/6 10.102.255.35 0x000130 000cf73c25c1 mBayStack470 12 Yes HtBt 1/48 1/7 10.102.255.60 0x00012f 0014c733e401 mBayStack5520-48T-PWR 12 Yes HtBt 1/47 2/20 10.102.1.9 0x000201 001d427b7040 ERS8610 12 Yes HtBt 2/1 4/1 10.102.1.6 0x000401 000fcdf1e0c0 ERS8610 12 Yes HtBt 4/1 4/4 10.102.255.45 0x000119 0011f9abc541 mBayStack470-24T 12 Yes HtBt 1/25 4/6 10.102.255.65 0x000117 00159beacc00 mERS5530-24TFD 12 Yes HtBt 1/23 4/7 10.102.255.75 0x000132 000e40eb4031 Passport1648 12 Yes HtBt 1/50 9/1 10.102.255.25 0x000119 00802deb6150 mBayStack450 12 Yes HtBt 1/25
You can see from this table that there are quite a few edge/closet switches connected to this specific ERS 8600 and you can quickly and easily identify which ports they are connected to.
Cheers!
has anyone heard of any upcoming updates to JDM (or the upcoming web based manager) to support the remote-port?
i don’t see how it would be terribly difficult to implement.
thanks for the heads-up; i didn’t realize the remote interface was displayed in the CLI.
Hi, Good to find some information on this topic!
Could you advise how you update/modify the table?
I have recently removed a vlan interface ip address from our 1624 routing switch. The IP i removed seems to be used for its descovery address, therfore it still shows in all our other tables on the other switches.
I can connect to the switch ok on other interfaces but the tables wont update one of these IPs.
Any sugestions would be welcome…
Thanks,
Alex
Hi Alex,
The topology table is read-only in nature, you can’t update it.
It’s only updated through the switch software when it observes SONMP packets being received on switch ports. I suspect if you reboot your ERS 1624 you’ll see the IP address update itself. You could also try disabling/enabling the feature and see if that brings it back to life.
Good Luck!
Hi Michael,
Makes sense. Will give a disable/enable a go, with a reboot as a last resort.
Thanks for your response!
Alex
Hi Alex, Michael,
From my understanding this is a mere layer 2 protocol thus it should work even if the ip address changed. I have seen similar odd things in ESM which uses NDP for its topology discovery. ESM messes up the topology completely after some switches were moved to a different port.
Also try to flush the ARP cache and FDB. This helped me quite a few times.
Cheers
Bas
btw: nice website you have michael!!!
Hi Bas,
I totally agree… the functionality isn’t breaking per say but the IP address being reported by the NDP (SONMP) topology packets is no longer “valid” because Alex deleted the IP interface in question from the source switch (at least that’s how I understood his issue).
I was suggesting that if he disabled and re-enables the topology discovery feature that the switch software might select a new IP address. I know that later versions of ERS 8600 software allowed you to set/specify the IP address used in the topology packets. An example would be to use a CLIP interface that would always be valid.
With respect to Enterprise Switch Manager (ESM) all it does is read the table from each switch and try to build a physical topology map. Again, the table is read-only so ESM can’t “mess up” the table. If you physically move switches around then the map will need to be updated to remove the old links and create the new links. What’s more likely happening is that ESM needs to completely rescan and rebuild the topology. I have a few Perl scripts that walk the topology tables of over 500 switches and help to automatically build topology maps. It’s a great tool to have and really help cut down on the documentation.
The only switch that I’ve seen have issues is the BayStack 450 switch. It would occasionally ignore SONMP/NDP packets and it had an issue in one software release where if you had “DiscardUnTaggedFrames” enabled it would discard the SONMP/NDP packets as well.
Cheers!
Hi Bas, Michael,
It seems the ERS 1624 takes it’s first available IP address for NDP packets, so I can now see why you would want to have the ability to specify the IP instead, as in the 8600 you mentioned.
I have tried disabling/enabling the topology first on the single 1624, and then on ALL other switches but still I see the ‘invalid’ IP address being re-populated in all switch tables.
I was considering the ARP/FDB flush as you suggest Bas, although I have now a window to give the 1624 a reboot, so may just wait till then.
I’m not overly concerned with this issue as I know the topology tables are only used for ESM and as long as I can still access each device one way or another, in the meantime, I’m happy.
Also, to add a little extra info… I ran a show tech and searched for any references to the old IP and I did find the IP as follows… (I have edited the IP output to *.*.*.*)
—-
Interface:
—————
cpp (unit number 1):
Flags: (0x62) DOWN BROADCAST ARP RUNNING
Type: UNDEFINED
Internet address: *.*.*.*
Broadcast address: *.*.255.255
Netmask 0xffff0000 Subnetmask 0xffff0000
Ethernet address is 00:1d:af:0c:c0:01
I’m not going to pretend I know what the cpp interface is…
Cheers,
Alex
Hi,
do anybody know why MAC-Addresses reported by NDP are sometimes different from the real neightbor MAC by 1Bit (last bit)?
Is this device-type-depending?
I try to implement this to a NMS, but don’t understand why neightbor-MAC is sometimes correct, sometimes different.
Hi Steffen,
The MAC address reported in the topology table is the base MAC of the switch. The MAC address reported in the ARP and/or MAC/FDB will be based on the base MAC address but it will be one for the interfaces.
Cheers!
I am looking through some topologies discovering and documenting a customers network. There seems to be some discrepancies with respect the ip address reported. For example in one table I have:
8/9 192.168.168.168 0x000409 e02636c9b0e0 ERS8806 12 Yes HtBt 4/9
The above does not exist. The one and only vlan on this interface has a totally different ip address. The other end reports the correct ip for the neighbour.
The version reporting the bad address is 7.0.0.0.
The version reporting the good address is 7.1.5.3
Does anyone know, for one what the algorithm is for the reported address in the case where there are multiple vlans. I suspect it to be the highest vlan but am not sure.
There is a command available to set the IP address used in the topology packets, although I don’t recall it right now.
Cheers!
Hi Michael McNamara,
On the same line of Steffen’s point…
I have observed that the SONMP table shows different MAC than the MAC of the remote port (of the remote stackable device). Two observations made here:
1. In some cases, the remote MAC on the SONMP Table is similar to the MAC of its neighbor stackable device.
2. In some cases, the remote MAC on the SONMP Table ends with “1” of the MAC of its neighbor stackable device.
Any idea when these behaviors are observed?
Any procedure/algorithm used to publish the MAC in case of #2?
Extract from your example:
===========================================================================
MAC of stackable devices ends with “1”:
1/5 10.102.255.19 0x00012f 001e7e7b0c01 mBayStack4500-48GT-PWR 12 Yes HtBt 1/47
1/6 10.102.255.35 0x000130 000cf73c25c1 mBayStack470 12 Yes HtBt 1/48
1/7 10.102.255.60 0x00012f 0014c733e401 mBayStack5520-48T-PWR 12 Yes HtBt 1/47
MAC of stackable devices ends with “0”:
4/6 10.102.255.65 0x000117 00159beacc00 mERS5530-24TFD 12 Yes HtBt 1/23
9/1 10.102.255.25 0x000119 00802deb6150 mBayStack450 12 Yes HtBt 1/25
===========================================================================
Regards,
Krishna