cisco6500 arp broadcast

[sanketpatel]

Hi there,

we have Cisco6513 switches,distribution layer in HSRP.It generates ARP broadacst for each ip address of all vlans' subnets.when i captaured the packets it shows the source mac-address is MSFC's mac address for all ARP requests.

Can anybody suggest me why it is happening and whts the soln for that?

thanks in advance.

[Richard Burts]

sanket

Perhaps I am not understanding correctly something in your question. It seems to me that you are describing normal behavior. If the MSFC is going to route for hosts in several VLANs then it needs to ARP for those hosts so that it can learn the correct MAC address for each host. And when a device sends out an ARP request the source MAC should be the MAC of the device which originated the ARP request - which is the MSFC. If there is some problem here which I have not understood then perhaps you can clarify it and help me understand what the problem is? What were you expecting to be the source MAC in the ARP requests?

HTH

Rick

[sanketpatel]

thansk for replying..

Actually MSFC is ARPing for all ip addresses for entire subentes, even ip addresses not in use.

i.e.

vlan 22 with 22.22.22.0/24 only five ip addresses are in use 22.22.22.3-7 .though MSFC ARPing for 22.22.22.1-254 and it happens very rapidly.so ARP table shows thousands of incomplete entries.

[Richard Burts]

sanket

When the MSFC ARPs like that it usually is because it is trying to forward something to those addresses. Is it possible that someone or somethig is probing your network and generating packets to every address?

HTH

Rick

[sanketpatel]

Rick,

I have snifed all vlans.but i didndt found anthing unusual...I can see ARP broadcast from MSFC only.

I have found on cisco site that we have to make "arp timeout" and "mac-add aging time" same!!!

[Richard Burts]

sanket

Setting the arp timeout and the aging time to be the same is a good idea. But it addresses a different problem. I suggest that you go ahead and make that change (I strongly suggest that you shorten the arp timeout rather than lengthen the aging time). And I suspect that after the changes you will find that the MSFC continues to ARP for those addresses.

I would suggest another way to investigate this issue. If you use debug ip packet with an access list that specifies that range of addresses it might show something about what is happening. It might be something like this:

config t

ip access-list 199 permit ip any 22.22.22.0 0.0.0.255

ip access-list 199 permit ip 22.22.22.0 0.0.0.255 any

end

term mon

debug ip packet 199

If it generates any output then perhaps you would post that output so that we could see what is going on.

HTH

Rick

[sanketpatel]

I can't put access-list.its in production and very criticle.

I would appreciate if you can suggest me any other soln.

thanks

[Istvan_Rabai]

Hi Rick,

I'm sorry to intervene into your communications, but this is a very interesting topic for me.

Sanket,

What Rick is suggesting is quite right.

Can you do this debugging out of working hours or when the time is not so critical?

The benefit you eventually may gain out of this investigation can be way more than the harm of loading your switch with a little bit of debugging.

This may happen to be even a security issue.

Thanks:

Istvan

[Richard Burts]

Istvan

There is no need to be sorry. I believe that the more people that participate the better the insight will be and the more likely we are to find a good solution.

Sanket

I appreciate that some devices in production are so critical that policies will not permit debugging on them. I believe that my debugging was the more simple and direct method to investigate this issue but if debugging is not feasible then I do have another suggestion. Put an access list inbound on every interface that the MSFC processes (or if there is an existing access list then add at the beginning of the access list). The access list should be something like this:

access-list 101 permit ip any 22.22.22.0 0.0.0.255 log

access-list 101 permit ip any any

This access list will not deny any traffic or impact any traffic entering the MSFC. But there will be hits on the first line if there is traffic received with a destination in that network and it will send entries to syslog (or to logging buffer if it is enabled or to terminal monitor) which will allow you to identify these packets.

HTH

Rick

[sanketpatel]

Thanks guys,

I have already put change management request hopefuly today I'll apply access-list and after that I'll update you

Again thank you for your co-operation.

[joel.amao]

I would suggest you debug to a buffer instead.Since you are unsure about the amount of traffic that is resulting in this latent activity.

logging buffered debugging 10000

no logging console

[Richard Burts]

Joel

It is true that the aspect of running debug that has the most impact on a router is sending the debug output to the console (which it does by default). And it is true that the single thing we can do that has the most effect in reducing the impact of debug is to prevent the debug output from going to the console.

And your suggestion of no logging console will prevent debug output from going to the console. But it also prevents all other output from going to the console. We can get the same benefit to debug without losing other messages by configuring logging console information. This will prevent debug output but allow other output to continue to go to the console.

HTH

Rick

[sanketpatel]

hi NetPros,

I have confirm with access-list and also with sniffer .All the ARP broadcast generated by MSFC only.I am confused.