Welcome, Guest. Please login or register.

Author Topic: Devices discovered in more than one location  (Read 4789 times)

spiffturk

  • Guest
Devices discovered in more than one location
« on: April 30, 2009, 05:27:06 PM »
So, I'm not sure if there's a solution to this or not, but I figured it warranted asking.  I'll try to keep this as short and to-the-point as I can while still furnishing relevant details.

The setup:

I have a Cisco 2851 with Cisco VoIP phones connected to it (for PoE).  Also connected to the 2851 is a Cisco 2950 via a trunk port.  Both the 2851 and the 2950 have vlan interfaces on vlan 881.  The phones are on vlan 681.  681 and 881 are both trunked between the 2851, fa1/35 and 2950, fa0/48.

The problem:

The phones show up in the mac-address-table.  On the 2851, the mac-address-table shows the correct interfaces for the phones.  On the 2950, the mac-address-table shows them as all on port fa0/48-- its trunk port to the 2851.

The 2950 is scanned after the 2851.  So when I run NeDi, and look for the phones as nodes, they all show up as connected to fa0/48 of the 2950 instead of the correct ports on the 2851.  When I scan just the 2851, the phones are detected in their proper place.  But when the 2950 is scanned after the 2851, NeDi appears to take the new values, discarding the "correct" ones.

I don't know if this is in any way a bug or unintended functionality; however, is there some way I can force the "right" value?  I don't mind reconfiguring the devices (presuming I can maintain proper functionality to the end users), if there's a setup that will fix this.  I'm open to any suggestions you guys might have.

One possibility I'd be open to, if it's available, is to disregard ARP tables entirely and look at only CDP neighbors to map locations-- though I don't know if NeDi can do that.  Looking at the "links" table gets me close to this for standard phones, but ATAs are apparently left out of the process that determines the links.

Thanks,

--
Will

rickli

  • Administrator
  • Hero Member
  • *****
  • Posts: 2680
    • View Profile
    • NeDi
Re: Devices discovered in more than one location
« Reply #1 on: April 30, 2009, 07:49:57 PM »
It's got nothing to do with the switch being discovered after the router, but the IF value defined in NeDi. I decided to prefer switches over routers as usually clients are connected this way.

A possible solution to this could be to interpret hybrids like the 2851 as switches hence not prefer "real" switches over it...but let's have a look at the .def file first. Add VLX to the Bridge parameter and let me know what happens...
Please consider Other-Invoices on your NeDi installation for an annual contribution, tx!
-Remo

spiffturk

  • Guest
Re: Devices discovered in more than one location
« Reply #2 on: May 01, 2009, 03:17:51 PM »
It's got nothing to do with the switch being discovered after the router, but the IF value defined in NeDi. I decided to prefer switches over routers as usually clients are connected this way.

Ahh.  That makes a lot of sense.  I hadn't thought about it that way, but it's pretty sound reasoning if we would just use things as they were intended :)

A possible solution to this could be to interpret hybrids like the 2851 as switches hence not prefer "real" switches over it...but let's have a look at the .def file first. Add VLX to the Bridge parameter and let me know what happens...

Well, if I understand your meaning, it didn't seem to help.  I added "VLX" after Bridge in the 2851's .def file, but it didn't seem to change anything.  If that's not what you meant, my apologies.  I don't really know anything about the .def files (any documentation out there about these?  are they some standard or are they NeDi-specific?)

I also think I just came across one more pertinent detail.  vlan681, on which the phones reside, is a VRF vlan, defined thusly:

interface Vlan681
 ip vrf forwarding voice
 ip address 10.201.0.1 255.255.255.0
end

The reason I think this may matter is because, on the 2851, if one does a "show ip arp", the phones aren't listed.  You have to run "show ip arp vrf voice".  I don't know if this has any impact on how NeDi pulls the information with SNMP, but it seemed worth mentioning.  This wouldn't be the first time this VRF crap has caused complications for us, so if it's the reason, i may use it as an excuse to start dismantling the VRF stuff, at least for this remote office.

In case it will help, I've attached the verbose output of a run of NeDi with just the 2851 and 2950 in the seedlist.

Thanks again for the help,

--
Will

rickli

  • Administrator
  • Hero Member
  • *****
  • Posts: 2680
    • View Profile
    • NeDi
Re: Devices discovered in more than one location
« Reply #3 on: May 01, 2009, 03:46:40 PM »
As you can see in your output, the VRFs are not impacting the SNMP ARP table. But I don't see the bridge forwarding table being read on the router, which should be the case if you really put Bridge(tab)VLX...
Please consider Other-Invoices on your NeDi installation for an annual contribution, tx!
-Remo

spiffturk

  • Guest
Re: Devices discovered in more than one location
« Reply #4 on: May 01, 2009, 04:07:08 PM »
Well, my .def file does have Bridge{tab}VLX:

Code: [Select]
-bash-3.2$ head sysobj/1.3.6.1.4.1.9.1.578.def
# Definition for 1.3.6.1.4.1.9.1.578 created by Defgen 1.1 on 17.Oct 06 18:24
# removed bridge forwarding by Remo 20.Dec 2006

# General
SNMPv 2HC
Type cisco2851
OS IOS
Icon rsbn
Bridge VLX
Dispro CDP
-bash-3.2$

And from the output, don't the Fi/Fp/etc. on this line indicate that it is reading the forwarding table?

Code: [Select]
...
ARP:00110abb66da=10.11.0.82 on Vl881 PuFi881 Fp881 Fi1 Fp1 Fi681 Fp681    0/1-29s
------------------------------------------------------------------------------------
Took 0 minutes
...

If I'm misreading the output, I apologize.  If I'm wrong, then what should I be looking for in the output?

--
Will

rickli

  • Administrator
  • Hero Member
  • *****
  • Posts: 2680
    • View Profile
    • NeDi
Re: Devices discovered in more than one location
« Reply #5 on: May 01, 2009, 05:39:02 PM »
No worries, you're on the right track  ;)

What happens if you put normal instead of VLX?
Please consider Other-Invoices on your NeDi installation for an annual contribution, tx!
-Remo

spiffturk

  • Guest
Re: Devices discovered in more than one location
« Reply #6 on: May 04, 2009, 06:51:06 PM »
OK, I seem to have lost my mind.  I've done the following:

I re-initialized the database (nedi.pl -i), and ran it with the three types of "Bridge" I've come across so far (none, "VLX" and "normal"), re-initializing before each one.  Now the phones on the 2851 don't seem to be showing up as nodes at all.  They're detected as devices, but not as nodes.  The two phones on the 2950, however, are detected correctly as nodes, on the correct interfaces.

...am I going insane?

--
Will

rickli

  • Administrator
  • Hero Member
  • *****
  • Posts: 2680
    • View Profile
    • NeDi
Re: Devices discovered in more than one location
« Reply #7 on: May 04, 2009, 10:23:27 PM »
Nah, you should have seen me while developing  :o

When using normal or VLX do you see any FWC: or FWS: lines with a nedi.pl -v?

The problem is that the switch should still be preferred over the router for assigning nodes. But if your phones are recognized as devices it would be ideal (that's what I tried to achieve anyways). What type are those phones?
Please consider Other-Invoices on your NeDi installation for an annual contribution, tx!
-Remo

duanew

  • Guest
Re: Devices discovered in more than one location
« Reply #8 on: May 05, 2009, 02:17:12 AM »
I had wondered how this worked.  Often I get multiple entries for a mac address where one is a vlan and one is the physical interface.  I thought this could be resolved by ignoring virtual interfaces for mac addresses.

In our Data Centre we centralise the routing on a pair of Catalyst 6500 which connect dozens of access switches which provide the server connections.  The IP details are in the Layer 3 device and the mac address in the layer 2.  Mostly NeDi reads this correctly.

This may be complicated further with virtualisation.  We have many hundreds of virtual servers and now all new servers are deployed as virtual (VMWare ESX).  I think NeDi stills handles this OK.

The good thing is it discovers all the virtuals and the physicals so we can see what is on each port.