05-11-2016 08:04 AM
As I understand it, at present the alarm logging suppression feature in XR can only match messages which are in the format %category-group-severity-code : message-text
However, the alarms that I am most likely to want to suppress are ones where the message was never supposed to be generated and the alarm does not contain %category-group-severity-code to match against.
For example cosmetic bugs CSCur77305 where lldp_agent produces three lines every time an interface flaps or CSCux75827 where if the router is a mid-point for a P2MP TE tunnel then every time the tunnel is re-optimised, the mrib process generates a message:
RP/0/RP0/CPU0:May 11 00:41:30.605 : lldp_agent[1097]: vimi decode: mbr_count: 6, mbr_ifh: 0x3800190, mbr_lon: 0, mbr_weight: 1, mbr number: 5
RP/0/RP0/CPU0:May 11 00:41:30.605 : lldp_agent[1097]: panini_spio_fill_bdl_mbr_info: mbr 0, ifh :0x3800190, pic 0x40000b11, status :0
RP/0/RP0/CPU0:May 11 00:41:30.605 : lldp_agent[1097]: panini_spio_fill_bdl_mbr_info: Success getting uidb_index for mbrifh: 0x3800190, uidb_index :0xb
RP/0/RP1/CPU0:May 10 01:37:55.636 : mrib[1171]: P2MP LMRIB: platform join frr mask, slotmask 0x2, slicemask 0x200
RP/0/RP0/CPU0:May 10 01:38:30.950 : mrib[1171]: P2MP LMRIB: platform unjoin frr mask, slotmask 0x0, slicemask 0x0
RP/0/RP1/CPU0:May 10 01:38:30.954 : mrib[1171]: P2MP LMRIB: platform unjoin frr mask, slotmask 0x0, slicemask 0x0
RP/0/RP0/CPU0:May 10 01:41:27.020 : mrib[1171]: P2MP LMRIB: platform join frr mask, slotmask 0x2, slicemask 0x200
So this logging suppression functionality appears to be currently unavailable for cases when a customer is possibly most likely to need to use it. I know there has been a lot of work on XR usability enhancements recently. Are there any plans to extend the feature so that it can be used as a workaround for issues like these?
05-11-2016 09:17 AM
Sadly, the right answer as you know is to make Cisco fix it on the front end. Rail on your account team for a SMU for this issue so that Cisco is aware that these are more than just cosmetic issues. We have had many many go-round about syslogs in the wrong format. I'd like to say that our complaints have been heard but seeing this post makes me doubt it. I'm not so sure I'd be in favor of allowing the suppression to work on cases like this because that gives them less incentive to do better software QA and do it right the first time.
05-12-2016 12:42 AM
Sure, if in your environment it's more than a cosmetic bug then get a SMU request in as it makes it more likely to be accepted and the rest of us get the benefit:).
For me, I think I'd like to have the option of a workaround even if I choose to wait for a fix but I do see where you're coming from.
I'm lucky that my account team don't need much railing. They've submitted successful requests for issues that arguably didn't satisfy the normal SMU criteria without us having to ask.
05-11-2016 09:20 AM
*duplicate post removed*
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide