Hi,

On Mon, 31 Mar 2014 10:28:50 +0000 Mischa Diehm mischa.diehm@unibas.ch wrote:

...

we have FP activated in our datacenter and use Cisco Nexus (5,6,7)k. I'm not sure what caused the problem but NAV can't find MAC-addresses on these devices and even on catalysts behind them anymore. I don't know what algorithm is used to figure out where a MAC-address is attached but maybe someone who knows can clarify what is needed for that to work?

Not being a network engineer, I have no experience with FabricPath. I had to Google it, and from what I could glean from [1], it appears FabricPath throws traditional layer 2 bridging off the boat.

NAV collects MAC addresses from the forwarding tables in your switches. It appears that Cisco FabricPath doesn't using forwarding tables, but instead employs a proprietary system for routing ethernet frames.

In light of that, there is nothing the current version of NAV that will help you get layer 2 information out of this proprietary system. Cisco may have some MIBs available to get the relevant information, but I could not say how/when or if we would put support for in on our roadmap.

Cisco has released information for FP-MIBS under:

ftp://ftp.cisco.com/pub/mibs/v2/CISCO-FABRICPATH-TOPOLOGY-MIB.my ftp://ftp.cisco.com/pub/mibs/v2/CISCO-FABRICPATH-TOPOLOGY-CAPABILITY.my

Unfortunately I can't find any of this information supported on our Nexus 5K/6K yet.

ftp://ftp.cisco.com/pub/mibs/supportlists/nexus6000/Nexus6000MIBSupportList. html

Checking in a retrieved snmpwalk on a 6K. First check for a MAC-Adress behind a Portchannel trunk. Second grep for Mac behind a FabricPath Port:

root@m:~# grep -i "00 1e 7a cb d1 00" /root/tmp/nex6.txt iso.3.6.1.2.1.4.22.1.2.151060481.10.33.1.254 = Hex-STRING: 00 1E 7A CB D1 00 iso.3.6.1.2.1.4.35.1.4.151060481.1.4.10.33.1.254 = Hex-STRING: 00 1E 7A CB D1 00 iso.3.6.1.2.1.17.4.3.1.1.0.30.122.203.209.0 = Hex-STRING: 00 1E 7A CB D1 00 root@m:~# grep -i "00 50 56 b3 02 5a" /root/tmp/nex6.txt root@m:~#

This looks like the following running "show mac address-table" on the n6k:

* 3200 001e.7acb.d100 dynamic 40 F F Po2 * 3200 0050.56b3.025a dynamic 40 F F 1810.0.0

In the end of the second line 1810.0.0 is the FP ID of the neighbour n6k.

This said I guess once there is support for the MIBs it should be possible to retrieve and work with this information on NAV. What I don't understand is how NAV decides if the MAC is actually directly attached (Access Port Check?) and what the algorithm in place is. Finally it is not clear to me if it would be possible to adapt and include the FP information?

Cheers, Mischa

On Wed, 30 Apr 2014 12:44:27 +0000 Mischa Diehm mischa.diehm@unibas.ch wrote:

same for the other 3 nexus6k. I tried to fiend out what the problem is but actually could snmp-query these devices to retrieve the CAM information:

# snmpwalk -v2c -cpublic@2 nex6-urz1XXX.unibas.ch .1.3.6.1.2.1.17.4.3.1. ... iso.3.6.1.2.1.17.4.3.1.1.24.3.115.217.149.63 = Hex-STRING: XX 03 XX D9 XX 3F ...

gives me a lot of these.

I wonder if I did the wrong query or if anyone has an idea what the problem could be with getting the inforamtion out of n6k? I checked all the logfiles and couldn't find any errors there either. Any ideas?

I have no idea. This is in deed a cam table entry, but why NAV doesn't pick it up I cannot immediately say.

I believe I have access to some of NTNU's switches running in this configuration now, I can do a closer inspection next week - we're a bit busy with the rollout of NAV 4 to our customers at the moment.

Hi all,

sorry for the noise - I just installed a blank NAV instance (4.2.5) and tested with a N6K. I can now actually see MAC addresses of directly attached client systems. I might have the chance to test with a bunch of N77K the next weeks. I will report back how things went.

-m