Hi mriyaz,
thanks for your reply. The serial console stays responsive, so I have tried to collect some stats from the commands.
I have simulated a lighter version of the IPv6 multicast "flood", just enough to trigger the IRB not available.
CPU utilization went from somewhere around 10 percent per user and kernel, and 0 per interrupts:
5 sec CPU utilization: User 8 percent Background 0 percent Kernel 6 percent Interrupt 0 percent Idle 86 percent
to
5 sec CPU utilization: User 20 percent Background 0 percent Kernel 15 percent Interrupt 4 percent Idle 61 percent
On the queue subject:
Without the multicast flood, MCQ_DROP_ lines are missing from the output, and the MC_PERQ_BYTE(28) is in order of tens of thousands. With the flood, the drops could be clearly seen:
root@eight:RE:0% cprod -A fpc0 -c 'set dc bc "show c cpu"' HW (unit 0) IBCAST.cpu0 : 3,090,549 +2 1/s ING_NIV_RX_FR.cpu0 : 6,454,862 +2 1/s MC_PERQ_PKT(8).cpu0 : 13,845,492 +10 MC_PERQ_PKT(14).cpu0 : 14,126 +1 MC_PERQ_PKT(16).cpu0 : 3,939,840 +7 MC_PERQ_PKT(19).cpu0 : 43,736,339 +427 1/s MC_PERQ_PKT(28).cpu0 : 52,214,959 +17,153 87/s MC_PERQ_PKT(33).cpu0 : 22,367,484 +294 MC_PERQ_PKT(34).cpu0 : 17,237,213 +45 MC_PERQ_PKT(43).cpu0 : 12,787,910 +52 MC_PERQ_BYTE(8).cpu0 : 1,945,899,342 +3,148 445/s MC_PERQ_BYTE(14).cpu0 : 959,596 +68 41/s MC_PERQ_BYTE(16).cpu0 : 365,627,616 +786 57/s MC_PERQ_BYTE(19).cpu0 : 9,152,981,497 +80,180 4,494/s MC_PERQ_BYTE(28).cpu0 : 42,519,089,155 +23,662,826 3,771,190/s MC_PERQ_BYTE(33).cpu0 : 1,768,896,420 +25,026 913/s MC_PERQ_BYTE(34).cpu0 : 1,185,830,552 +3,702 560/s MC_PERQ_BYTE(43).cpu0 : 1,175,344,202 +4,282 768/s MCQ_DROP_PKT(28).cpu0 : 1,946,432 +1,522 123/s MCQ_DROP_BYTE(28).cpu0 : 2,658,538,788 +1,832,544 323,657/s
So the drops are clearly happening... since I can't find anything other in my config that could cause this, I'm probably going to contact our partner with this, to see what they have to say about it.
Best regards,
-Pavel