MAC aging
WR switches keep the learnt MAC addresses beyond the aging time (default is 300 seconds).
It was observed during the address caching capacity and learning rate tests of RFC 2889 benchmarking using the Xenabay traffic analyzer. If 'aging time' is chosen as address reset condition, then test is failed (even at the relative low frame rate of 20 frame/s). In this case, the RTU table keeps many dynamic entries, which have aging value of '0'. This behavior is observed in all software versions including v4.2, v5.0.1 v6.0 and v6.1. Attempts to remove them manually with 'rtu_stat remove all 1' also failed (trials done only on v6.1).
Example of 'rtu_stat' output (and this is special/rare case with duplicate entries) is given below:
MAC Dst.ports FID Type Age [s]
----------------------------------------------------------------------------------
...
02:f4:bc:00:05:00 2 0 DYNAMIC (hash 138:2) 359
02:f4:bc:00:05:00 2 0 DYNAMIC (hash 138:2) 0
02:f4:bc:00:05:01 2 0 DYNAMIC (hash 119:2) 359
02:f4:bc:00:05:01 2 0 DYNAMIC (hash 119:2) 0
02:f4:bc:00:05:02 2 0 DYNAMIC (hash 17a:2) 359
02:f4:bc:00:05:02 2 0 DYNAMIC (hash 17a:2) 0
As example of how MAC aging affects the RFC 2889 tests, the results of the address caching capacity test are attached (software = v6.1, frame size = 512 bytes, learning rate = 20 frame/s):
- xena2889-report-20231023-194401.pdf: test failed, "aging time = 350 seconds' is chosen for the address learning reset condition. Here, switch starts to forward test packets (100, 1074) properly, no flooding. At iteration with the critical number of packets (1561) it floods, and then it remains to flood in all further iterations with lowering number of the test packets (1317, 1195, ..., 1075, 1074). Test is failed, because the switch floods even with the same number of packets (1074), with which no flooding has happened in previous iteration.
- xena2889-report-20231023-195822.pdf: same test, but passed, "switching test ports" is chosen for the reset condition. In this setup, test runs as expected: switch forwards the test packets (100, 1074, #1561, 1317, 1439) properly in all iterations except those with critical/high number of packets (1561).