Reset Search
 

 

Article

MLAG changes mac learning mode to be software from hardware

« Go Back

Information

 
TitleMLAG changes mac learning mode to be software from hardware
Question
When MLAG is peered on the switch, all the ports change the mac learning mode to be software from hardware.
Environment
  • EXOS All
Answer
In the MLAG environment, all the mac addresses need to be checkpointed and synced up between the two peered switches by software.
For this reason, when MLAG peering is established (even without any MLAGs), all the ports change the mac learning mode to be software from hardware.
In the software learning mode, all the traffic whose source mac addresses doesn't exist in the hardware FDB table is lifted to the CPU for learning source mac address.
Once source mac address gets learned in the CPU, it is pushed down and installed to the hardware table, and the traffic stops being lifted to the CPU.

The following command is to verify current mac learning mode for ports. 

 
# debug hal show platform learning 
-----------------------
pibGlobalSoftwareLearning 1
pibNoLearningWithForwarding 1
pibDisableLearningVlan 0
pibHigigLearningDisable 
 1  0  0  0  0  0  0  0  0  0 
-----------------------
Learning disabled VLANs
-----------------------
Port learning info
------------------
1:1     L--os---
1:2     L--os---
1:3     L--os---
1:4     L--os---
<Omitted>
-----------------------------------------------------------------
*** pif_t fields ***
L - fdbLearning, F - noLearningWithFwd
*** pibSpecificPifData_t fields ***
o - software_learning_only, s - software_learning
v - no_learn_vlan, w - no_learn_with_fwd
X - isXlateOn
-----------------------------------------------------------------
The cpu queue 3 is dedicated for the software mac learning and this can be verified with the following commands. 
 
<BD8K and Summit>
# debug hal show cpu-queue <slot #>    #### Slot # is only for BD8K
Slot: 1
Queue Info Unit:0
    Queue 0: PPS 0. CurPkts 0. TotPkts 64340. Disc rate 0, qlen 0.
    Queue 1: PPS 0. CurPkts 0. TotPkts 0. Disc rate 0, qlen 0.
    Queue 2: PPS 0. CurPkts 0. TotPkts 30527233. Disc rate 0, qlen 0.
    Queue 3: PPS 0. CurPkts 0. TotPkts 3662107. Disc rate 0, qlen 0.
    Queue 4: PPS 0. CurPkts 0. TotPkts 0. Disc rate 0, qlen 0.
    Queue 5: PPS 0. CurPkts 0. TotPkts 37538. Disc rate 0, qlen 0.
    Queue 6: PPS 0. CurPkts 0. TotPkts 189323. Disc rate 0, qlen 0.
    Queue 7: PPS 0. CurPkts 0. TotPkts 3923571. Disc rate 0, qlen 0.

<BDX8>
# debug hal show emcm cpu-queue-stats slot <MM #> 
Printing CPU Q statistics for slot=13 unit=0
Cos         PktCount        ByteCount
0              8667         1421388
1                 0               0
2           1220665       200189060
3          12869925      2110667800
4                 0               0
5              6844         1122416
6            172694        28321816
7           9900008      1687991037
8                 0               0
9                 0               0
10                0               0
11         19951917       299163103
When observing high CPU utilization in the MLAG environment, checking utilization of the cpu queue 3 would help determine the cause.
(along with "debug hal show congestion" output.)

 
Additional notes
Note: As the software mac learning mode involves precessing in the CPU, the event that causes FDB flush like "clear fdb" command could
result in high CPU utilization and congestion by traffic lifted for source mac learning.

Note: The mac learning mode is also changed to be software only for the ports with Private VLAN and MAC security features enabled/configured. 

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255