cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5759
Views
12
Helpful
9
Replies

Extending ARP cache and timeout values

mariov652
Level 1
Level 1

Hi,

We have a static network run with two separate switches (not connected to eachother).

Because the PC's, routers, firewalls etc. are hardly ever moved, does anyone know if we may run into problems if we increase the arp cache and timeout entries on our switches, PC's and routing equipment?

Our intention is to minimize the arp broadcasts within the various LAN's. We are not having performance problems and I understand 'if it ain't broke, don't touch' but I'd like to hear your comments on this subject.

Thanks,

1 Accepted Solution

Accepted Solutions

What you see is pretty normal.

ARP timeout = 4 hours

MAC timeot = 5 minutes

The MAC table will lose track of "some" devices that went inactive for a while and now some other device wants to talk to them, since the ARP entry is still valid but the MAC was lost, the switch will flood the packet (or some consecutive packets) but as soon as the host replies back, the MAC will be learned again and the flooding stops.

This is normal in any network so what you want to keep track is the time (normally in miliseconds or less) between the first flooded packet and the last. If the timeframe is really short then don't worry. In your capture is only 0.001 sec. But if the same flow continues for a long time then it would be worth to expore further.

In you case increasing the ARP won't help at all, maybe increasing the MAC timer but I will keep it as it is if I were you

View solution in original post

9 Replies 9

Peter Paluch
Cisco Employee
Cisco Employee

Hi,

If the networks are really "static" as you have indicated, I do not think it will be a problem to increase the ARP timeout.

I see a problem, though, in case of a configuration error (like a mistake in an IP address) or malicious activity (ARP spoofing). If that happens, it is possible that an incorrect ARP entry will be lurking in the ARP cache longer than usual, causing inconveniences.

Also, I have ecountered problems with certain virtual machines that like to change their MAC address after they configure their IP stack, forgetting to emit a gratuitous ARP reply. The surrounding stations including routers may learn the previous IP/MAC mapping and after the MAC has changed, the station is not reachable anymore until the ARP entry expires.

Best regards,

Peter

Mario

The ARP timeout on a Cisco router is already pretty long (especially as compared to the timeout of the average PC). So I do not see a lot of value in changing the ARP timeout on your routers. A layer 2 switch will only ARP (and only maintain in its ARP cache) addresses accessed by the management interface of the switch. So I do not see much benefit in changing the ARP timeout of your layer 2 switches. I can see some benefit if you want to change the ARP timeout of your PCs and servers.

HTH

Rick

HTH

Rick

mariov652
Level 1
Level 1

Thank you both for your replies. They both make sense.

One other reason we were thinking of increasing the ARP values is because we have noticed TCP and directed traffic between 2 systems in a VLAN is sometimes broadcasted out to all ports within the VLAN (seen on other stations while in promiscous mode).

Our thinking was that the switch was 'losing track' of the location of one of the two systems and consequently broadcast the packets out. As I write this though this explanation doesn't really make sense.

Could this be related to ARP or is there something else I should be considering?

Hello,

Hmm, if a TCP conversation is occassionally "broadcasted" out to all ports of a switch then that's not a problem of ARP at all. Notice that even with those TCP segments "broadcasted" out, the MAC address of the recipient is a unicast MAC. If a switch had this MAC in its MAC address table, it would not broadcast it through all ports. So this seems to be a problem of the MAC address table in your switch.

By default, entries in the MAC address table expire after 300 seconds of inactivity. This timeout can be shortened, for example, when STP detects a topology change. I suspect this could be a possible cause.

Can you also confirm by looking at the command "show mac address-table count" if the MAC address table on your switch is not overfilled?

Best regards,

Peter

I've attached the mac address table of the switch in question. It's a very simple setup with the switch divided into 2 VLANS connecting PC's and two routers. No routing through the switch is taking place.

I've also attached a capture of an example 'view' taken from a monitoring server in the same VLAN. No port mirroring is in place.

The monitoring server has IP Address x.x.x.26 in the respective VLAN's/Networks with promiscious mode enabled during capture.

As can be seen, we clearly pickup TCP and other traffic that is supposed to be direct communication between 2 other devices on the network.

I hope you or someone else may be able to shed some light as to why we are seeing this.

Hello,

This is really curious. What exact type/model of switch do you have? Also, can you post its complete configuration here (with sensitive data removed, of course)?

Thanks in forward.

Best regards,

Peter

What you see is pretty normal.

ARP timeout = 4 hours

MAC timeot = 5 minutes

The MAC table will lose track of "some" devices that went inactive for a while and now some other device wants to talk to them, since the ARP entry is still valid but the MAC was lost, the switch will flood the packet (or some consecutive packets) but as soon as the host replies back, the MAC will be learned again and the flooding stops.

This is normal in any network so what you want to keep track is the time (normally in miliseconds or less) between the first flooded packet and the last. If the timeframe is really short then don't worry. In your capture is only 0.001 sec. But if the same flow continues for a long time then it would be worth to expore further.

In you case increasing the ARP won't help at all, maybe increasing the MAC timer but I will keep it as it is if I were you

Hello,

Thank you for your reply. I understand that MAC addresses in a switch eventually expire. What I was surprised about was that the switch apparently needs some time (more than I expected!) to process the newly learnt MAC address. I have never thought that the learning takes longer than transmitting that frame.

Ahhh, those mysteries of hardware construction... :-) Thank you for enlightening me!

Best regards,

Peter

Thank you for confirming with those details.

(Thanks also to Peter for helping too).

It has helped me understand this better.

Best regards,

Mario

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: