[j-nsp] ARP Table Timer vs. MAC Table Timer on Juniper

Saku Ytti saku at ytti.fi
Wed Dec 20 04:24:32 EST 2017


On 20 December 2017 at 00:13, NK NSP <nknwklist at gmail.com> wrote:

> "Hardware Resource exhaustion" comes into mind for keeping shorter value
> for MAC Table. Keeping the value high enough can bite you when there is a
> flood of traffic from random sources. It can lead to MAC table overruns and
> could keep the genuine host MAC entries out of MAC table.
>
> I guess many vendors have similar timer strategy. Just configure MAC age
> timer to be higher than ARP timeout timer.

This argument seems improbable, possibly entirely wrong.

Imagine you have CAM limit of 10 MAC addresses, and your real speakers
is 5 MAC addresses,
where there is constant traffic.

Then you get host flooding random MAC addresses, 1 frame per MAC, 1
frame per second

Scenario 1) MAC timeout of 1s
- Nothing bad happens, table never gets congested as the non-speaking
random MAC addresses get removed earlier, so congestion does not
happen

Scenario 2) MAC timeout of 10s
- At second 5, our CAM is full, and we need to use what ever strategy
code decides to workaround
    a) stop learning, flood new
    b) stop learning, drop
    c) reprogram round-robin from top (yuck, haven't seen this)
    d) reprogram oldest (would require counter, unlikely to be available)


Maybe with other numbers and assumptions we can find advantage in
higher MAC timeout, but I am having hard time figuring where larger
MAC timeout makes the device less vulnerable to CAM exhaustion. Larger
MAC timeout also may reduce convergence in some situation. Only
benefit I can see is that it reduces learning rate, if you are hitting
platform limits on programming the CAM. Depending on platform learning
is SW or HW.
Having said that, when was last time you had CAM exhaustion, I've
never ran into that outside lab where I've intentionally done it? And
why did you not limit MACs on each edge-port to ensure no exhaustion
can occur?

I've never increased MAC timeout, and don't see the point. I however
continue to recommend reducing ARP timeout to 300s or less. But if
reducing ARP timeout absolutely is not possible, then I agree you
should increase MAC timeout, which means increasing it from 300s to 4h
if you have any Cisco L3 speakers.

-- 
  ++ytti


More information about the juniper-nsp mailing list