• September 19, 2020, 05:10:16 PM
Welcome, Guest. Please login or register. Registration is free.
Did you miss your activation email?

Author Topic: Another COM issue/question  (Read 6239 times)

0 Members and 1 Guest are viewing this topic.

Offline CptnBlues63

  • Sr. Member
  • ****
  • Posts: 100
Another COM issue/question
« on: June 27, 2014, 04:32:38 PM »
Ok, so when I login to UCM and click on COM the "home" tab displays a topology diagram of the switches in my network.  Sadly, it doesn't quite show all of them.  Several switches aren't appearing and I've check throughout COM and on the switches themselves and still can't figure out why those particular switches don't appear in the topology diagram after doing a discovery.

The particulars:

Closets 2, 4 and 6 do not appear in the topology diagram.

Closet 2 connects to closet 1 via a fiber MLT.  Closet 1 in turn connects to our core switches via fiber SMLT.  Closet two is a three switch stack with two 5510's and a 5520.  A 5510 is the "base" of this stack.  Closet 1 is a two switch stack with dual 5510's.

Closets 4 and 6 connect to closet 5 via single copper uplinks.  Closet 5 in turn connects back to the cores via a fiber SMLT.  Closets 4 and 6 are single 5520's.  Closet 5 has a three switch stack with dual 5510's and a single 5520 with a 10 as base(stack down 10, 10, 20).

Now, I have a single 5520 in my office which connects to closet 10 (a two switch stack with a 5520 as base and a 10 kicker) and 10 in turn has a fiber SMLT to the cores.  The switch in my office does appear on the topology diagram.

Sorry about getting so wordy but I wanted to give you an accurate picture.

Here's hoping someone has an idea what's going on with the switches in those three closets and also what I can do to get them to appear in the topology diagram.

TIA

 


Offline Johan Witters

  • Sr. Member
  • ****
  • Posts: 252
    • BKM Networks
Re: Another COM issue/question
« Reply #1 on: July 01, 2014, 09:49:10 AM »
I had this happening once, but that appeared to be an incorrectly set gateway on the "ghost" switches.

Have you checked your discovery settings (timeout, number of hops etc)


Johan
Kind regards,

Johan Witters

Network Engineer
BKM NV

Offline Dominik

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1564
    • Networkautobahn
Re: Another COM issue/question
« Reply #2 on: July 03, 2014, 01:59:14 AM »
Whenf a switch is not discoverd by COM it can have several causes.

I would start with this check list my investigation:
-is the not discoverd switch via ping reachable from the COM server ?
-has the switch the correct SNMP community ?
-has the switch the correct ipmgr access list , so that the COM is allowed to do SNMP access
-are the correct credentials configured in the COM for the switch
-is the correct Seed device configured
-are the correct numbers of hops configured for the discovery options.
-is there a Firewall between the COM and the switches that can block the SNMP packets ?


In most of the cases you have missed one of the points mentioned above.
In fact the COM has dicoverd other switches from your network you have no general problem with the COM.

Good Luck
Itīs always the networks fault!
networkautobahn.com

Offline CptnBlues63

  • Sr. Member
  • ****
  • Posts: 100
Re: Another COM issue/question
« Reply #3 on: July 09, 2014, 04:11:46 PM »
Whenf a switch is not discoverd by COM it can have several causes.

I would start with this check list my investigation:
-is the not discoverd switch via ping reachable from the COM server ?
-has the switch the correct SNMP community ?
-has the switch the correct ipmgr access list , so that the COM is allowed to do SNMP access
-are the correct credentials configured in the COM for the switch
-is the correct Seed device configured
-are the correct numbers of hops configured for the discovery options.
-is there a Firewall between the COM and the switches that can block the SNMP packets ?


In most of the cases you have missed one of the points mentioned above.
In fact the COM has dicoverd other switches from your network you have no general problem with the COM.

Good Luck

-is the not discoverd switch via ping reachable from the COM server ?
It is.  I not only pinged it from the server but telnet'd into the interface to confirm the rest of the questions that I can.

-has the switch the correct SNMP community ?
Yes

-has the switch the correct ipmgr access list , so that the COM is allowed to do SNMP access
If by this you mean "Telnet Menu >> TELNET/SNMP/Web Access Configuration" then "yes"

-are the correct credentials configured in the COM for the switch
Yes

-is the correct Seed device configured
No idea!  Where would I check to see what seed device has been configured?  Also, is there a specific criteria on which one choses said "seed"?  (In case it isn't configured, then I'll know which one to use).

-are the correct numbers of hops configured for the discovery options.
I'm not sure about this either and don't know where to check.  I meant to ask Johan about "discovery" and it's associated settings but I've been busier than a one legged man in an...........well, you know..........lol........and this is the first chance I've had in a while to come back here in a while and ask.

-is there a Firewall between the COM and the switches that can block the SNMP packets ?
Nope

Thanks!
« Last Edit: July 09, 2014, 04:15:12 PM by CptnBlues63 »

Offline imorris

  • Rookie
  • **
  • Posts: 18
Re: Another COM issue/question
« Reply #4 on: July 09, 2014, 06:15:52 PM »
Hello Captain,

couple of essentials.  Under the Admin drop down you need to ensure that there is an entry (or several) in the Device Credentials that covers the device address range(s) along with the snmp settings (and ssh etc).
You then open Admin\Preferences and ensure you have a comma-separated list of all your core device IP addresses.  The discovery process attaches to each seed address, discovers what is attached to that device, attaches to each and discovers what is attached to that etc, etc.  The hop-count limits how far away from the seed device to stop discovering.

A useful step in diagnosing connectivity issues is to have Wireshark run on the COM server with a capture filter set to only capture dialog to/from the device you are having trouble with.  In the past I have also briefly allowed telnet and snmpv2 so that plain-text content can be analysed.  This was very useful when setting up BCM backups ... particularly timers for Wifi controllers and the fact that if an edge device has "term len 0" set, the backup fails.  The fail message within COM/BCM is pretty general.

Good luck

Ian

Offline CptnBlues63

  • Sr. Member
  • ****
  • Posts: 100
Re: Another COM issue/question
« Reply #5 on: July 10, 2014, 10:25:24 AM »
Hello Captain,

couple of essentials.  Under the Admin drop down you need to ensure that there is an entry (or several) in the Device Credentials that covers the device address range(s) along with the snmp settings (and ssh etc).
You then open Admin\Preferences and ensure you have a comma-separated list of all your core device IP addresses.  The discovery process attaches to each seed address, discovers what is attached to that device, attaches to each and discovers what is attached to that etc, etc.  The hop-count limits how far away from the seed device to stop discovering.

A useful step in diagnosing connectivity issues is to have Wireshark run on the COM server with a capture filter set to only capture dialog to/from the device you are having trouble with.  In the past I have also briefly allowed telnet and snmpv2 so that plain-text content can be analysed.  This was very useful when setting up BCM backups ... particularly timers for Wifi controllers and the fact that if an edge device has "term len 0" set, the backup fails.  The fail message within COM/BCM is pretty general.

Good luck

Ian

Thanks for your response Ian, I appreciate it.

I looked through everything you mentioned and it all looks good.  Seed is set to core, hop count is 15 (max hops from core will be 3 here within my main building).  Credentials are correct with the correct range (.1 through .254) for that subnet.

Oddly enough, two of the switches that aren't being found are daisy chained to another switch (xxx.xxx.xxx.51).  There's also a third switch which does appear daisychained to .51  So that has me stumped and I'll likely print out the ASCII configs for all three to do a line-by-line comparison.  But I'm the guy that set all these switches up and I use the same template for all of them (QoS settings, passwords, SNMP credentials etc etc) so those settings should be the same.  But it's worth a look.

I'm sure eventually I'll get it figured out.


Offline kristjanhinn

  • Jr. Member
  • **
  • Posts: 25
    • http://ee.linkedin.com/pub/kristjan-hinn/5b/b55/a17
Re: Another COM issue/question
« Reply #6 on: July 11, 2014, 03:23:29 AM »
have you checked autotopology tables on the switches wich are not appearing on COM topology?

i had an issue like that https://forums.networkinfrastructure.info/nortel-ethernet-switching/vsp7000-ist-autotopology-problem/msg16125/#msg16125

Offline CptnBlues63

  • Sr. Member
  • ****
  • Posts: 100
Re: Another COM issue/question
« Reply #7 on: July 11, 2014, 11:00:09 AM »
have you checked autotopology tables on the switches wich are not appearing on COM topology?

i had an issue like that https://forums.networkinfrastructure.info/nortel-ethernet-switching/vsp7000-ist-autotopology-problem/msg16125/#msg16125


Thanks for the help.  I read your thread and checked that on the switches in question.  When I ran the "show autotopology" command on .51, it didn't show the two switches missing from my COM (ie: .41 and .61)  I unchecked the "discarduntaggedframes" on both sides of those links and they appeared when I ran the 'sho autotop nm' command the second time.

I rescanned with COM but they're still not appearing there.  *shrug*

So I thought I'd cross check with the switch in my office.  Like .41 and .61, it's daisychained to another switch with a single copper link.  But unlike the other two, it actually does appear in COM.  It had the "discarduntaggedframes" checked at both ends and appeared when I ran the "sho autotop nm" command.

So I'm still confused..........LOL  But will keep pecking away at this until I find out what exactly is causing those particular switches not to appear.

I really appreciate all the help folks!

Offline kristjanhinn

  • Jr. Member
  • **
  • Posts: 25
    • http://ee.linkedin.com/pub/kristjan-hinn/5b/b55/a17
Re: Another COM issue/question
« Reply #8 on: July 12, 2014, 09:39:13 AM »
you can also set the missing switch as seed switch on COM and see if it then appears. If its still missing then there must be somekind of access problem on COM to missing switch connection. If im not mistaken COM is reading autotopology tables on switches and generating its topology from this. If autotopology tables are ok then it should appear on COM.

Offline CptnBlues63

  • Sr. Member
  • ****
  • Posts: 100
Re: Another COM issue/question
« Reply #9 on: July 14, 2014, 10:03:22 AM »
you can also set the missing switch as seed switch on COM and see if it then appears. If its still missing then there must be somekind of access problem on COM to missing switch connection. If im not mistaken COM is reading autotopology tables on switches and generating its topology from this. If autotopology tables are ok then it should appear on COM.

We've opened a ticket with Avaya on this.  It's only 4 switches but it IS still annoying............LOL

Thanks everyone for the help, I appreciate it a lot!

Offline Dominik

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1564
    • Networkautobahn
Re: Another COM issue/question
« Reply #10 on: July 15, 2014, 06:03:11 PM »
You can try it with a ticket at the Avaya support.

I would suggest that you are missing something, when autotopology does not see the direct connected switch
there is a problem with your switch configuration.

Does the two switches have the same management VLAN ?
Is the management VLAN on all  uplinks configured ?
Itīs always the networks fault!
networkautobahn.com

Offline CptnBlues63

  • Sr. Member
  • ****
  • Posts: 100
Re: Another COM issue/question
« Reply #11 on: July 16, 2014, 10:44:02 AM »
You can try it with a ticket at the Avaya support.

I would suggest that you are missing something, when autotopology does not see the direct connected switch
there is a problem with your switch configuration.

Does the two switches have the same management VLAN ?
Is the management VLAN on all  uplinks configured ?

Ok so here's what autotopology sees from one of the switches that doesn't appear in COM:

CC04sw01#sho autotop nm
LSlot                                                                     RSlot
LPort IP Addr          Seg ID  MAC Addr     Chassis Type     BT LS   CS   RPort
----- --------------- -------- ------------ ---------------- -- --- ----  -----
 0/ 0 xxx.xxx.33.41   0x000000 00159B54D001 5520-48T-PWR     12 Yes HTBT    NA
 1/48 xxx.xxx.33.51   0x000117 000E409C0000 5510-48T         12 Yes HTBT   1/23


The other switch that doesn't appear, that is daisychained to the same switch as above:

CC06sw01#sho autotop nm
LSlot                                                                     RSlot
LPort IP Addr          Seg ID  MAC Addr     Chassis Type     BT LS   CS   RPort
----- --------------- -------- ------------ ---------------- -- --- ----  -----
 0/ 0 xxx.xxx.33.61   0x000000 00130A2BFC01 5520-48T-PWR     12 Yes HTBT    NA
 1/48 xxx.xxx.33.51   0x000104 000E409C0000 5510-48T         12 Yes HTBT   1/ 4


Below from the switch the two above connect to:

CC05sw01#sho autotop nm
LSlot                                                                     RSlot
LPort IP Addr          Seg ID  MAC Addr     Chassis Type     BT LS   CS   RPort
----- --------------- -------- ------------ ---------------- -- --- ----  -----
 0/ 0 xxx.xxx.33.51   0x000000 000E409C0000 5510-48T         12 Yes HTBT    NA
 1/ 4 xxx.xxx.33.61   0x000130 00130A2BFC01 5520-48T-PWR     12 Yes HTBT   1/48
 1/23 xxx.xxx.33.41   0x000130 00159B54D001 5520-48T-PWR     12 Yes HTBT   1/48
 1/31 xxx.xxx.33.143  0x000130 E8056D954400 5520-48T-PWR     12 Yes HTBT   1/48
 1/47 xxx.xxx.33.251  0x00070b 001A8F21A10A ERS 8810         12 Yes HTBT   7/11
 1/48 xxx.xxx.33.249  0x00070b 0016CA81810A ERS 8810         12 Yes HTBT   7/11


Where:
xxx.xxx.33.41 = CC04sw01 (closet 4, switch 1)
xxx.xxx.33.61 = CC06sw01 (closet 6, switch 1)
xxx.xxx.33.51 = CC05sw01 (closet 5, switch 1)

xxx.xxx.33.249 and xxx.xxx.33.251 are the core switches with VRRP address of xxx.xxx.33.250

Yes, VLAN 1 (net 33) is on all uplink ports.
Autotopology does see the switches that don't appear in com.

If you look at the output for CC05sw01 you'll see one other switch, xxx.xxx.33.143, which does appear in COM. 

Considering I use the same template as a basis to configure all switches and that template includes SNMP settings (including community strings) why do these two switches (and 3 others) in my environment not show up in COM, yet 100+ other switches all do?  I've tried everything here and really do appreciate the help but after checking everything posted here and beating my own brains out, we finally put in the call to Avaya.  I will most definitely report back here, especially if they help us fix the issue, so as to (hopefully) help someone else with a similar issue in the future.

At this point, I'm just hoping it's not something simple and stupid which leaves me with not one, but both feet in my mouth...........LOL

Offline Dominik

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1564
    • Networkautobahn
Re: Another COM issue/question
« Reply #12 on: July 17, 2014, 09:11:43 AM »
OK,  that is not the normal behavior.
Even when COM can not discover a particular device it should be shown as an unmanged (orange)  device
In the topo as long it is in the nmn topology table of an device that can be discovered.

With software version has your Com and the ers 5k that can not discovered.
What happened when you put the not discovered device as an additional seed device and Run a discovery?
Itīs always the networks fault!
networkautobahn.com

Offline CptnBlues63

  • Sr. Member
  • ****
  • Posts: 100
Re: Another COM issue/question
« Reply #13 on: July 17, 2014, 11:39:48 AM »
OK,  that is not the normal behavior.
Even when COM can not discover a particular device it should be shown as an unmanged (orange)  device
In the topo as long it is in the nmn topology table of an device that can be discovered.

With software version has your Com and the ers 5k that can not discovered.
What happened when you put the not discovered device as an additional seed device and Run a discovery?

The undiscovered switches:

xxx.xxx.33.21 (v6.3.1)
xxx.xxx.33.41 (v6.3.1)
xxx.xxx.33.61(v6.3.1)
xxx.xxx.33.72 (v4.2.0)
xxx.xxx.33.74 (v6.2.7)
xxx.xxx.33.81 (v4.2.3)
xxx.xxx.33.171 (v6.2.7)

The COM software is as follows:
Configuration and Orchestration Manager
Version: 3.0.2
Revision: 25
Build Date: 20130726.035958


I have discovered switches with the same SW/FW revisions as the undiscovered.  When I put the undiscovered IP's in as seed, it doesn't find them.

I have Avaya looking at it now too.  Their engineer had me send him my log files and he checked through  them.  According to him, the switches in question are responding to SNMP requests, they're just not appearing in the topology view.  I've tried using the MIB browser at their request but it stops at "fetching" regardless of which switch I scan.  I may have them stumped...........we'll see.

They're now asking for a remote session to access the COM interface.  I will likely give them access to my PC and watch over their shoulder as they troubleshoot.

Offline CptnBlues63

  • Sr. Member
  • ****
  • Posts: 100
Re: Another COM issue/question
« Reply #14 on: July 22, 2014, 11:37:12 AM »
Ok, problem solved with the help of an Avaya Engineer.

The problem was my coworker, who installed and did the initial setup on COM, had created context groups.  Aside from the default "all" context group he created one for our main center, and one each for our 3 remote locations.

I was working out of the context group for our main center which COM opens to by default.  After a bit of checking around the Engineer had me open the Device Group Manager (under Devices) and check if the missing switches were in the "All" context group.  They were.  After that it was simply a matter of opening our main center group and adding those switches to it.  Now, all switches in my main center appear in the COM topology view.

Problem solved.

Again, thanks to everybody that tried to help.  I appreciate it a lot and learned a bunch through trying the different suggestions.    :)