Send netdisco-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: Cisco N5k Trunk VLANs not found for ports on FEX
(Jeroen van Ingen)
2. Re: Cisco N5k Trunk VLANs not found for ports on FEX
([email protected])
3. Re: Netdisco2 sometimes misses connected hosts data & SSH
Collector (Muris)
--- Begin Message ---
Hi,
btw, quick glance over an old full snmpwalk: maybe VTP-MIB instances
aren't present for these ports, but CISCO-VLAN-MEMBERSHIP-MIB do appear
to be present. So perhaps we can create a workaround in
SNMP::Info::Layer3::Nexus.pm.
I've got a pretty long task list, but I'll try to keep it in mind... and
please don't hesitate to create a ticket for this at
https://github.com/netdisco/snmp-info/issues.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
On 06/29/2017 10:59 AM, Jeroen van Ingen wrote:
Hi Christian,
Good question. I checked and re-checked, but we only see correct
port-channel data for ports on the 5596's themselves. Data for
port-channels on FEX is incomplete: no proper relation between the
logical port-channel interface and its member interfaces in Netdisco
when a FEX is involved, and VLAN information is incorrect when the
port-channel interface is configured with "switchport mode trunk".
SNMP on Nexus has been flaky from the start (and not only SNMP); I'm
looking forward to our next datacenter network overhaul which probably
won't use a solution with "fabric extenders" en hopefully won't use
Cisco switches.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
On 06/25/2017 02:45 PM, Christian Ramseyer wrote:
Thanks Jeroen! Just to make sure, does "reporting VLAN membership on
trunks just fine" include ports that are on fabric extenders (FEX)? It
seems only to affect these ports in our environment. Probably one of the
many peculiarities in NX-OS SNMP.
Anyways, one of our Cisco guys is trying to get support on this, I'll
post an update if something comes from that.
Christian
On 22.06.17 11:43, Jeroen van Ingen wrote:
Hi Christian,
Hmm, maybe it's a limitation or bug in the older NX-OS versions. It's
been ages since we ran a 5.x release so I don't remember if we ever had
this issue.
We currently run 6.0(2)N2(1) on the 5596's in one data center and
7.1(3)N1(2) on the 5596's in our other DC; both report VLAN membership
on trunks just fine.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
On 06/20/2017 12:09 PM, Christian Ramseyer wrote:
Hi guys
Given this setup:
204 Po204(SU) Eth LACP Eth106/1/7(P) Eth107/1/7(P)
*** # show fex 106 detail | include 1/7
Eth106/1/7 Up Po106
*** # show fex 107 detail | include 1/7
Eth107/1/7 Up Po107
interface port-channel204
description ***
switchport mode trunk
switchport trunk allowed vlan 461,475-476
Netdisco does not show anything in the VLAN Membership. The problem is
AFAICT Cisco-based, as the FEX ports are not included in VTP-MIB, e.g.
for vlanTrunkPortDynamicStatus:
interface: 369098955 port-channel204
.1.3.6.1.4.1.9.9.46.1.6.1.1.14.369098955 = No Such Instance currently
exists at this OID
Has anybody already noticed this or maybe even found a workaround? Our
N5k here still run 5.2(1)N1(9), but from the resolved issues in
5.2(1)N1(9a) and 5.2(1)N1(9b) it doesn't look like they would be any
help.
Christian
--- End Message ---
--- Begin Message ---
I don't know if this is related, but I'm having issues with a pair of Nexus
9396 switches since I upgraded to 7.0(3)I5(1) from 6.1(2)I3(3a). Some
device mac addresses weren't showing up at all, but some are. Most of my
devices are plugged into FEXes. All of my port channels are on the 9396's
themselves--not on FEXes. So far in my troubleshooting I've noticed that an
snmpbulkwalk of Q-BRIDGE-MIB::dot1qTpFdbPort only has about half of the
entries compared to snmpwalk of Q-BRIDGE-MIB::dot1qTpFdbPort.
I've opened a ticket with Cisco about the GETBULK issue, and tried adding
sub bulkwalk_no { return 1; } to Nexus.pm. Now some of the missing mac
addresses are showing up on the port-channel going to the other switch. The
port-channel does not show up as an uplink--the Ethernet interfaces that are
in that channel group do.
-----Original Message-----
From: Jeroen van Ingen [mailto:[email protected]]
Sent: Thursday, June 29, 2017 10:04 AM
To: Christian Ramseyer <[email protected]>
Cc: [email protected]
Subject: Re: [Netdisco] Cisco N5k Trunk VLANs not found for ports on FEX
Hi,
btw, quick glance over an old full snmpwalk: maybe VTP-MIB instances
aren't present for these ports, but CISCO-VLAN-MEMBERSHIP-MIB do appear
to be present. So perhaps we can create a workaround in
SNMP::Info::Layer3::Nexus.pm.
I've got a pretty long task list, but I'll try to keep it in mind... and
please don't hesitate to create a ticket for this at
https://github.com/netdisco/snmp-info/issues.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
On 06/29/2017 10:59 AM, Jeroen van Ingen wrote:
> Hi Christian,
>
> Good question. I checked and re-checked, but we only see correct
> port-channel data for ports on the 5596's themselves. Data for
> port-channels on FEX is incomplete: no proper relation between the
> logical port-channel interface and its member interfaces in Netdisco
> when a FEX is involved, and VLAN information is incorrect when the
> port-channel interface is configured with "switchport mode trunk".
>
> SNMP on Nexus has been flaky from the start (and not only SNMP); I'm
> looking forward to our next datacenter network overhaul which probably
> won't use a solution with "fabric extenders" en hopefully won't use
> Cisco switches.
>
>
> Regards,
>
> Jeroen van Ingen
> ICT Service Centre
> University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
>
>
> On 06/25/2017 02:45 PM, Christian Ramseyer wrote:
>> Thanks Jeroen! Just to make sure, does "reporting VLAN membership on
>> trunks just fine" include ports that are on fabric extenders (FEX)? It
>> seems only to affect these ports in our environment. Probably one of the
>> many peculiarities in NX-OS SNMP.
>>
>> Anyways, one of our Cisco guys is trying to get support on this, I'll
>> post an update if something comes from that.
>>
>> Christian
>>
>>
>>
>> On 22.06.17 11:43, Jeroen van Ingen wrote:
>>> Hi Christian,
>>>
>>> Hmm, maybe it's a limitation or bug in the older NX-OS versions. It's
>>> been ages since we ran a 5.x release so I don't remember if we ever had
>>> this issue.
>>>
>>> We currently run 6.0(2)N2(1) on the 5596's in one data center and
>>> 7.1(3)N1(2) on the 5596's in our other DC; both report VLAN membership
>>> on trunks just fine.
>>>
>>>
>>> Regards,
>>>
>>> Jeroen van Ingen
>>> ICT Service Centre
>>> University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
>>>
>>>
>>> On 06/20/2017 12:09 PM, Christian Ramseyer wrote:
>>>> Hi guys
>>>>
>>>> Given this setup:
>>>>
>>>> 204 Po204(SU) Eth LACP Eth106/1/7(P) Eth107/1/7(P)
>>>>
>>>> *** # show fex 106 detail | include 1/7
>>>> Eth106/1/7 Up Po106
>>>> *** # show fex 107 detail | include 1/7
>>>> Eth107/1/7 Up Po107
>>>>
>>>>
>>>> interface port-channel204
>>>> description ***
>>>> switchport mode trunk
>>>> switchport trunk allowed vlan 461,475-476
>>>>
>>>>
>>>> Netdisco does not show anything in the VLAN Membership. The problem is
>>>> AFAICT Cisco-based, as the FEX ports are not included in VTP-MIB, e.g.
>>>> for vlanTrunkPortDynamicStatus:
>>>>
>>>> interface: 369098955 port-channel204
>>>> .1.3.6.1.4.1.9.9.46.1.6.1.1.14.369098955 = No Such Instance currently
>>>> exists at this OID
>>>>
>>>> Has anybody already noticed this or maybe even found a workaround? Our
>>>> N5k here still run 5.2(1)N1(9), but from the resolved issues in
>>>> 5.2(1)N1(9a) and 5.2(1)N1(9b) it doesn't look like they would be any
>>>> help.
>>>>
>>>> Christian
----------------------------------------------------------------------------
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
Hi, anyone else experienced this or has a problem with this aspect?
I have noticed this occuring in the L2 networks, mac addresses float
between port channels and user ports
Hoping someone could look at it..
Thanks
On Sun, Jun 25, 2017 at 2:52 PM, Muris <[email protected]> wrote:
> Also I want to mention that i am using the SSH collector on Nexus core
> devices , where the 3850s / and HP Comware connects. As its running mpls
> with vrfs, it collects the arp data, and is then able to correctly assign
> where hosts belong on the edge switchports, its just ive come accross this
> floating of hosts issue now in the L2 network segments.
> Note: the IP's dont conflict even there is many vrfs, they dont use the
> same IP/Subnets so this aspect is fine.
>
> On Sun, Jun 25, 2017 at 2:43 PM, Muris <[email protected]> wrote:
>
>> Hi Oliver, thanks again for looking into.
>>
>> There is no mac_suck bleed set at all, i cannot see anything with that in
>> deployment config.
>>
>> Sometimes it reports possible uplink, and sometimes it doesnt.
>>
>> Its not vendor specific either.. for example i have these scenarios also
>> happening. All the interconnectivity is L2 trunks
>>
>> HP Comware Switch1 <> HP Comware Core Switch <> HP Comware Switch2
>>
>> If the hosts sit on Switch1, sometimes i can see them on the port
>> channel/Bridge Aggregation on switch2's uplink as well (but not on core
>> switch). If i do a mac/arp on Switch1 they re-appear correctly there on the
>> ports and things are fine for a little while, then when the process does a
>> mack suck on switch 2, things get taken off Switch1, then put on the port
>> channel on Switch2. Things kind of cycle like this between the devices and
>> also as ive described above, which makes it difficult to see when finding
>> where a hosts are connected as it keeps floating.
>>
>> I also have the same problem with Cisco 3850 switches and L2 trunks
>>
>> L3 Device Nexus 7k << L2 Trunk>> 2x 3850 stack <<<L2 Trunk>>> 2 x 3850
>> stack <<L2 Trunk>> Nexus 7k L3 Device
>>
>> hosts can float on the trunks back and forth from user ports, so one
>> minute you looking up a device it appears correctly on a switchport, and
>> you check an hour later, its gone off that switchport and appearing on one
>> of the trunks. Again sometimes these appear as no uplink, or maybe uplink.
>>
>> I would be so happy if this can be rectified in some way. Maybe an option
>> to override and specify its definite uplink dont accumulate macsuck/arpnip
>> data on the specific problematic uplink, but this could be a administrative
>> issue especially in dealing with thousands of devices..be easier having it
>> automatically know its certainly an uplink from lldp/cdp.
>> All CDP/LLDP is enabled on the network however.
>>
>> With having blade chassis/servers connected to switches I would like to
>> know whats on the port channels to these macs/arps etc, so it would need to
>> differentiate between a switch and something else, if automatic fix took
>> place to filter data on uplinks.
>>
>> As it occurs accross multiple platforms, it must be something with the
>> discovery process that its not getting correctly.
>>
>> Any help as always is greatly appreciated so i can have it working well.
>>
>> Thankyou, Muris
>>
>> On Sun, Jun 25, 2017 at 4:04 AM, Muris <[email protected]> wrote:
>>
>>> Hi Oliver,
>>>
>>> Thanks for replying.
>>>
>>> Here is my exact problem as I have spent 2 days analysing it, as it took
>>> me ages to figure out whats happening with the large amount of devices,
>>> lets say I have this setup at the moment:
>>>
>>> Switch1
>>> CoreSwitch1
>>>
>>> Between switches its setup as L2 with port channels.
>>>
>>> Now for example..
>>>
>>> 1)When I run a arpnip/macsuck on Switch1, everything appears fine.
>>> 2)When it comes along to run a macsuck/arpnip on CoreSwitch1, the
>>> arpnip/macsuck info disappears off the ports from Switch1, but instead
>>> shows up on the portchannel on CoreSwitch1 that links to switch1 with all
>>> the hosts from Switch1.
>>> 3)Then when the next arpnip/macsuck is done on Switch1, all the data
>>> appears on Switch1 ports and disappears off the CoreSwitch1 port channel.
>>> Its almost like one moment its on one switch, next moment its on the next,
>>> keeps swapping backwards and to when each arpnip/mac suck is probed.
>>> So all mac/arp comes on the port channel on core switch, then released,
>>> on, then released , depending when each probe is done. Switch1 shows data
>>> on and off on each probe.
>>>
>>> If all the data is appearing correctly on Switch1 on all the ports, how
>>> can I prevent the uplink on CoreSwitch1 show all the arp/mac when its
>>> polled. Ive been trying for hours looking through the documentation how to
>>> prevent this occurring, but didn’t find anything.
>>>
>>> Its almost like I need something to specify its an uplink, don’t add any
>>> macs/arps on this port..or I could be just missing something else im not
>>> seeing.
>>>
>>> Thanks Muris
>>>
>>>
>>> On 24/6/17, 6:57 pm, "Oliver Gorwits" <[email protected]> wrote:
>>>
>>> Hi Muris
>>>
>>> Please can you describe in a little more detail what's missing from
>>> the
>>> web interface - is it the MAC addresses of nodes on the ports, or
>>> the IP
>>> addresses of those nodes, or the neighbor relations to other devices?
>>> Each of these is gathered by a different process.
>>>
>>> You could try slowing down the pollers by setting sleep_time:
>>>
>>> workers:
>>> tasks: 'AUTO * 4'
>>> sleep_time: 2
>>>
>>> This makes each worker pause a little after it polls (the default is
>>> one
>>> second). If your problem is UDP overload on your server then it might
>>> help.
>>>
>>> regards,
>>> oliver.
>>>
>>> On 2017-06-23 11:37, Muris wrote:
>>> > Hi All,
>>> >
>>> > I would like to say thanks to the person who came up with the SSH
>>> > Collector for Nexus/ASA devices its really awesome and working
>>> well.
>>> > Can it also connect via telnet ?
>>> >
>>> > I have come up with a problem, as i have around 3000 devices, for
>>> some
>>> > reason the macksuck and arp, on the automatic arpnips/walks dont
>>> fully
>>> > populate the data for a switch, when i go into the switch some
>>> ports
>>> > show up but blanks next to them on connected devices..
>>> >
>>> > However, if i manually force a discover/arpnip/macwalk through the
>>> > webinterface the data populates straight away.
>>> >
>>> > Is there any reason for this? How can it completely do it automated
>>> > without me refreshing a device manually? (Well the netdisco-backend
>>> > should be doing it but some reason some data dissapears when
>>> > displayed)
>>> >
>>> > I was thinking the SSH Collector of arps maybe could be conflicting
>>> > with netdisco arps to populate data...not sure..but at the moment
>>> > needing the ssh collector due to mpls and nexus with vrfs etc.
>>> >
>>> > To cater for this many devices, i have 8 CPUs set on a Xeon machine
>>> > with 16gb ram, and running the backend worker on AUTO * 4 in
>>> > deployment config.
>>> >
>>> > Postgresql is optimised with pgtune, and running latest netdisco
>>> > version released 22/06/17
>>> >
>>> > Any troubleshooting/recommendations would be appreciated :)
>>> >
>>> > Thankyou, Muris
>>> >
>>> >
>>> > ------------------------------------------------------------
>>> ------------------
>>> > Check out the vibrant tech community on one of the world's most
>>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> >
>>> > _______________________________________________
>>> > Netdisco mailing list
>>> > [email protected]
>>> > https://lists.sourceforge.net/lists/listinfo/netdisco-users
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
--- End Message ---
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
