cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1544
Views
0
Helpful
19
Replies
Highlighted
Beginner

ASA 5505 FirePOWER Network Discovery : MAC Addresses

Hello,

 

I have Network discovery enabled but I'm seeing many MAC addresses (so far 1213) being discovered which don't correlate to any internal hosts I have. Operating system for these MAC address is also in the pending state.

 

If I drill down to the host profile for the MAC address the 'Host Protocols' is represented as a number.

 

Here's a few screen grabs showing the issue as described above.

 

 

 

19 REPLIES 19
Beginner

Hi Craig,

Hi Craig,

Any progress with this one? I have a similar issue however all of my hosts have disappeared from the IPv4 list and are now under the MAC list....

Highlighted
Beginner

Resolved my issue.

Resolved my issue.

Previously my network discovery policy rule specified "Any" for "network" and defined specific "Interfaces" for the "Zones". This stopped working for some reason and all hosts appeared under the MAC list instead of IPv4.

So I defined my "networks" along with the "zones". Hosts are now correctly identified with IPv4 details.

Highlighted
Participant

I have this same issue, but I

I have this same issue, but I had the Zone already defined as the Inside arm of my ASA and the network was all RFC1918 addresses.  I have correct hosts showing up under IPv4 hosts, but have 1583 hosts under MAC.  I've just redefined the Network in my discovery policy to only be the true internal network private address block I'm using.  I'll see if it changes.

Highlighted
Participant

No changes other than more

No changes other than more hosts showing up on the mac address block.. It's now at 2056. versus 43 under IPv4 which is more accurate.

Highlighted
Beginner

I have the same issue on

I have the same issue on multiple installations. As soon as a v6 sensor is in place I get these mac addresses in the network discovery database. v5.4 sensors no problem. Have you ever been able to fix this?

Highlighted
Beginner

I'm seeing the same problem

I'm seeing the same problem on my home lab 5506-X (running 6.0.1.1).  Very odd.

Highlighted
Cisco Employee

Hello John,

Hello John,

The issue that you are facing looks like due to the  following bug :-

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuw51866/?reffering_site=dumpcr

This issue is expected to be fixed in the upcoming release 6.0.1.2 which will be released soon.

Rate and mark correct if the post helps you

Regards

Jetsy

Highlighted
Beginner

I have received a hotfix for

I have received a hotfix for this from Cisco TAC but it doesn't solve the MAC address issue. It's a bit weird, when you put the firepower sensor in monitor mode and clear the firesight network discovery database then the FP sensor doesn't discover any mac addresses. Not a single MAC address, even after a few days...

The moment you move the sensor back inline you'll see the MAC addresses appear in the network discovery database. So it looks like it has something to do with fragments of packets that are left over after blocking a connection...

Has anyone else seen the same?

Highlighted
Beginner

I have seen the problem in

I have seen the problem in two installations, maybe more but have not checked yet.

Any updates from Cisco? What the heck is going on?

Highlighted
Beginner

Yes unfortunately we're still

Yes unfortunately we're still seeing this on all deployments - even those utilizing the absolute latest version of FirePOWER / FireSIGHT (6.1.0).  No word from Cisco although I have not been pressing them terribly hard on this lately as I've had other issues with the platform (like the SFR blocking traffic but not displaying any logs in FireSIGHT when such a block occurs)!

Highlighted
Beginner

Regarding your issue with

Regarding your issue with blocking traffic and no logs in FireSIGHT. I've also observed this but I do see 'drop logs' on the ASA (5506) syslog but nothing logged in FireSIGHT stating the reason for the drop.

Have a look at the following:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuz32616

Highlighted
Beginner

Yeah we saw that bugID

Yeah we saw that bugID recently as well - although it certainly doesn't tell us much does it?  I've also worked with TAC multiple times and was told it was an issue with a preprocessor and/or inline-normalization that was dropping packets before the FMC had a chance to log them (which shouldn't even be allowed but I digress).

Have had about as much movement/answers from Cisco on this issue as I have the MAC address discovery...

Highlighted
Beginner

Hi there, sorry for the late

Hi there, sorry for the late response but I have been very busy lately.

Finally received a response from Cisco. For the bug information, have a look at:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuz17020

The bug is due to be fixed in these versions: 6.0.1.4, 6.1.0.2, 6.2.0.0. They all are slated to be released early next year...

Hope that helps.

Highlighted

We had this problem ever

We had this problem ever since we moved to version 6.

Currently we are on 6.1.0 across the board, and the problem persists.

Analysis->Hosts->Network Map-> 94K mac addresses and growing.

So whatever the problem was/is in CSCuw51866 it is not solved in any of the 6.x.x version we have tried (which is pretty much all of them).

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here