Why is the default for iparp max entries 8192?


It seems that user traffic would be negatively affected if entries are not stored because the configured max is too low.

We recently began looking at some networks that were at the cap 8192, so we increased the cap to 16284. After the increase we found these networks had between 10,000 and 13,000 entries.

I was talking to TAC yesterday and he seemed to indicate that having more arp entries would decrease the performance of the switch. I could see how exceeding the hardware limit could hurt switch performance but I don't believe that is not what I am trying to do.

This is an X460-G2 running 16.x.x.x

Thanks,

3 replies

Userlevel 7
Hi,

I believe this is an historical reason behind the 8K setting.

Indeed, with X460G2, you can scale way above... in hardware (look at config forwarding internal-tables to find the different limits)

The command you are referencing has nothing to do with HW limit, btw. This is for the SW part (you do speak of config iparp max_entries, right?). You need to keep it above the real network size to avoid iparp cache thrashing.

If you have not enough HW entries, that command would increase the software cache and software forwarding. That must be the reason TAC said it could hurt the performance.

To know your HW usage, look at the output of show iproute reserved-entries statistics.
Grosjean, Stephane wrote:

Hi,

I believe this is an historical reason behind the 8K setting.

Indeed, with X460G2, you can scale way above... in hardware (look at config forwarding internal-tables to find the different limits)

The command you are referencing has nothing to do with HW limit, btw. This is for the SW part (you do speak of config iparp max_entries, right?). You need to keep it above the real network size to avoid iparp cache thrashing.

If you have not enough HW entries, that command would increase the software cache and software forwarding. That must be the reason TAC said it could hurt the performance.

To know your HW usage, look at the output of show iproute reserved-entries statistics.

Stephane,

That was our thought as well, it didn't make sense that letting it use more of the hardware tables would hurt performance.

You said "The command you are referencing has nothing to do with HW limit, btw. This is for the SW part"
I understand that config iparp max_entries is for the software limit, but it appeared that the software limit affected the hardware limit. Everything I see makes it looks like the dynamic entries increase along with the hardware tables which seems to indicate if you only allow 8194 entries in software the tables will also stop at that cap.

Thanks, 
Userlevel 7
Grosjean, Stephane wrote:

Hi,

I believe this is an historical reason behind the 8K setting.

Indeed, with X460G2, you can scale way above... in hardware (look at config forwarding internal-tables to find the different limits)

The command you are referencing has nothing to do with HW limit, btw. This is for the SW part (you do speak of config iparp max_entries, right?). You need to keep it above the real network size to avoid iparp cache thrashing.

If you have not enough HW entries, that command would increase the software cache and software forwarding. That must be the reason TAC said it could hurt the performance.

To know your HW usage, look at the output of show iproute reserved-entries statistics.

Yes, I believe you are correct for the effect of iparp max_entries. I wanted to stress that HW limit is not configured by that command (for UFT capable switches, it's internal-tables that does it).

Reply