注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

北边的风

IT 钓鱼 养生

 
 
 

日志

 
 

cisco MAC address (00:00:00:00:00:00)解决方法  

2016-10-28 15:12:18|  分类: IT心得 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

Tracking down an invalid source mac address

 

up vote

13

down vote

favorite

1

I have inherited support of a remote site which contains a Cisco 4500 and is connected to ~2 dozen cisco access switches - primarily 2960s with a couple of 3750s and 3560s. Not all access switches are directly connected to the 4500 - there is some daisy chaining of switches which was apparently done as a result of inadequate cabling. Recently i've noticed serror messages on the 4500 which indicate frames have been received with an invalid source mac address:

 

*Sep 10 09:29:48.609: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 102563 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Te5/1 in vlan 1460

 

The device connected to Te5/1 is an access switch (Cisco 3750). It in turn is connected to 6 other access switches. After a bit of googling it appears the 4500 is the only cisco platform which logs invalid source mac addresses. From my reading, other platforms (2960, 3750, etc) seem to forward the frames along but don't log them as invalid, nor do they add an entry to the mac address-table. I suspect the root cause of the invalid source mac addresses could be a faulty nic, a software bug or perhaps a misconfigured vmware server. What tools are available on the access switches to track down the offending port?

 

cisco switch layer2

shareimprove this question

edited Sep 12 '13 at 6:15

 

Daniel Yuste Aroca

1,76441541

asked Sep 11 '13 at 5:05

 

User12345

4722516

1             

Deleted my post, didn't realize that they weren't visible at all. If the switch won't put them in CAM then I guess your best bet is to run SPAN session on switches but even then it would be tricky to find the source port. Another option would be to disable unknown unicast and see if anything breaks. I'm surprised that communication works though. If a host with that MAC sends something outside it subnets the GW would have to ARP to see the MAC of the host and encapsulate the frame, does the GW have any weird ARP mappings? – Daniel Dib Sep 11 '13 at 7:16

2             

According to supportforums.cisco.com/docs/DOC-36000 these frames should be dropped in HW so at least it shouldn't affect performance of the switches. – Daniel Dib Sep 11 '13 at 7:20

1             

Yes, according to that link: "Please note that packets with invalid MAC address will be dropped anyway, all other Cisco Catalyst switches are silently dropping these packets in HW, 4k platform is explicitly generating logging message when such event is observed." ...but I know this can't really be the case since the 4500 is complaining about frames that are arriving on Te5/1 which is the port connected to the 3750. This would indicate the 3750 is forwarding the frames w/ the invalid source mac despite what DOC-36000 says. – User12345 Sep 11 '13 at 10:20

             

Divide & Conquer! – generalnetworkerror Sep 12 '13 at 8:12

add a comment

3 Answers

active oldest votes

up vote

6

down vote

Generally when I have seen this, it comes from a poorly configured VM (often hosted on a user machine). Depending on the situation and environment, they can be difficult to track down (saw a lot of these at a University in the CS and ECE department buildings which moved and came/went as students did).

 

You have a couple great answers already, but another option you can pursue is to add the following config to the downstream switches (37xx, 36xx, 29xx):

 

   mac address-table static 0000.0000.0000 vlan <VLAN ID> drop

This will drop any traffic with this MAC rather than forward it on and since it should be done in hardware (barring any features/problems that cause MAC lookups to be done in software), it shouldn't have a negative impact on performance.

 

shareimprove this answer

answered Sep 12 '13 at 22:38

 

YLearn?

15.4k43273

             

Thank you for this suggestion. This will prevent the frames from being forwarded across the trunks to other switches which is a big win. Is there a way through logging or debug commands to observe a port dropping frames based on this configuration? – User12345 Sep 13 '13 at 13:49

             

@fcorrao, unfortunately not with this configuration. You would have to try doing what Gerben suggested and use a MAC ACL or Dave's suggestion of capturing traffic off the ports. But my take on it is that only the misconfigured device will be adversely affected, so either they will make it known or they won't even notice themselves. – YLearn? Sep 13 '13 at 14:36

add a comment

up vote

1

down vote

You could try if the frames can be blocked using a MAC ACL on interfaces and/or on vlans on the access switches. By applying the blocks selectively and checking if the error messages on the 4500 disappear or not, you can home in on the source of the traffic.

 

Moving cables around to see if the port mentioned in the error message on the 4500 follows could also help, but might prove tricky in a production environment.

 

shareimprove this answer

answered Sep 11 '13 at 20:19

 

Gerben

2,9581026

add a comment

up vote

0

down vote

It appears to me that this error is not affecting network performance, as you discovered the log messages on your own, rather than your being inundated with user complaints. This leads me to suspect that the issue lies with some connected, but partially configured or misconfigured software or service that is not currently in use.

 

Your best course may be to let this sleeping dog lie, until such time as some user reports a problem. Alternatively, if you have the time to spare, you can run SPAN sessions as @Daniel Dib suggested, and give the output close scrutiny until you determine a suspect port or device.

  评论这张
 
阅读(57)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017