Re: [OSPF] Suppression of frequent OSPF traps

Acee Lindem <acee.lindem@ericsson.com> Thu, 07 February 2013 13:57 UTC

Return-Path: <acee.lindem@ericsson.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E3F21F84BB for <ospf@ietfa.amsl.com>; Thu, 7 Feb 2013 05:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2Xj2ZkZc2lB for <ospf@ietfa.amsl.com>; Thu, 7 Feb 2013 05:57:52 -0800 (PST)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD4E21F841C for <ospf@ietf.org>; Thu, 7 Feb 2013 05:57:52 -0800 (PST)
X-AuditID: c6180641-b7f926d000000e79-77-5113b2dfcdc6
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 96.81.03705.FD2B3115; Thu, 7 Feb 2013 14:57:51 +0100 (CET)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 08:57:50 -0500
From: Acee Lindem <acee.lindem@ericsson.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Thread-Topic: Suppression of frequent OSPF traps
Thread-Index: Ac4FMBLXaJkjhGSRQQG4dKYuhwxwxgANPMeA
Date: Thu, 07 Feb 2013 13:57:50 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470BDDF9@eusaamb101.ericsson.se>
References: <F9336571731ADE42A5397FC831CEAA02122E8FD3@ILPTWPVEXMB02.ecitele.com>
In-Reply-To: <F9336571731ADE42A5397FC831CEAA02122E8FD3@ILPTWPVEXMB02.ecitele.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.135]
Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470BDDF9eusaamb101ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonXPf+JuFAg65nuhaHD85is5i69QOz Rcu9e+wWM2f8YbRYvfY7mwOrx5TfG1k9Nv07zuixZMlPpgDmKC6blNSczLLUIn27BK6MnW83 sBXsmMVY8frkepYGxnutjF2MnBwSAiYSq9v62SBsMYkL99YD2VwcQgJHGCU2zTvADuEsY5T4 N/k1E0gVm4COxPNH/5hBbBEBa4m5N46DFTELzGKUePv8NthYYQEDiTcX7kAVGUrMu/4VqIgD yDaSeN6nAxJmEVCR+H5xBthMXgFvia0/e8DKhQQCJK6eOwwW5xQIlNj7dg/YdYxA130/tQYs ziwgLnHryXwmiKsFJJbsOc8MYYtKvHz8jxXCVpb4PucRC0R9vsSZrQuZIXYJSpyc+YRlAqPo LCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj6F6rSUObf/DhKxmASPHKkaO0uLUstx0 I8NNjMDYPCbB5riDccEny0OM0hwsSuK8oa4XAoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw Cpbt25ayhtc47XuP67xHnFmSsYYSO05JR1rP+xmxcHpMSNzsTWvbSljva/Ad+jcjMWUdb4GS 7owbR3Okz31y/fzX+XXDqb+3tQ8HOcyr056/8FpzovPx5a+Ovd2isq7qzF193UztzkPLKr9Z b/8YHHTPPuLZtGXMoUf3MFivmeVbFayneO++vhJLcUaioRZzUXEiADItJfObAgAA
Cc: "ospf@ietf.org" <ospf@ietf.org>, Sidd Aanand <Sidd.Aanand@ecitele.com>, Srinivas Goli <Srinivas.Goli@ecitele.com>
Subject: Re: [OSPF] Suppression of frequent OSPF traps
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2013 13:57:53 -0000

Sasha,
See inline.
On Feb 7, 2013, at 7:38 AM, Alexander Vainshtein wrote:

Dear all,
My colleagues and I are interested in interpretation of the following text from RFC 4750 - OSPF Version 2 Management Information Base<http://tools.ietf.org/html/rfc4750>:

     ospfIfConfigError NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfIfIpAddress,
             ospfAddressLessIf,
             ospfPacketSrc,  -- The source IP address
             ospfConfigErrorType, -- Type of error
             ospfPacketType
             }
          STATUS       current
          DESCRIPTION
             "An ospfIfConfigError trap signifies that a
             packet has been received on a non-virtual
             interface from a router whose configuration
             parameters conflict with this router's
             configuration parameters.  Note that the event
             optionMismatch should cause a trap only if it
             prevents an adjacency from forming."
          ::= { ospfTraps 4 }

The highlighted text could be interpreted that the trap is sent every time an offending packet has been received.
This could easily result in an incessant flow of traps (e.g., if you receive offending Hello packets from a misconfigured router on the LAN segment).

Hence two  questions:
1.       Is the interpretation mentioned above valid?

Yes. If you don't have rate limiting for your traps, your SNMP implementation is broken. Furthermore, an implementation should be allow traps to be selectively enabled and disabled.
For example, here is the command from my implementation:

[local]se-acee(config-ctx)#router ospf 1
[local]se-acee(config-ospf)#snmp traps ?
  all                 Enable sending all supported OSPF traps
  ifauthfailure       Enable sending ospfIfAuthFailure traps
  ifconfigerror       Enable sending ospfIfConfigError traps
  ifrxbadpacket       Enable sending ospfIfRxBadPacket traps
  ifstatechange       Enable sending ospfIfStateChange traps
  maxagelsa           Enable sending ospfMaxAgeLsa traps
  nbrstatechange      Enable sending ospfNbrStateChange traps
  originatelsa        Enable sending ospfOriginateLsa traps
  txretransmit        Enable sending ospftxretransmit traps
  virtifauthfailure   Enable sending ospfVirtIfAuthFailure traps
  virtifconfigerror   Enable sending ospfVirtIfConfigError traps
  virtifrxbadpacket   Enable sending ospfVirtIfRxBadPacket traps
  virtifstatechange   Enable sending ospfIfVirtIfStateChange traps
  virtiftxretransmit  Enable sending ospfVirtIfTxRetransmit traps
  virtnbrstatechange  Enable sending ospfVirtNbrStateChange traps

Hope this helps,
Acee
P.S. If you really want to see some traps, enable ospfOriginateLas and ospfMaxAgeLsa on a core router.



2.       If not, what is the valid interpretation and associated expected behavior?

Regards, and lots of thanks in advance,
     Sasha


This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.