Return-Path: 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 ; 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 ; 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 ; 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 To: Alexander Vainshtein Thread-Topic: Suppression of frequent OSPF traps Thread-Index: Ac4FMBLXaJkjhGSRQQG4dKYuhwxwxgANPMeA Date: Thu, 7 Feb 2013 13:57:50 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470BDDF9@eusaamb101.ericsson.se> References: In-Reply-To: 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" , Sidd Aanand , Srinivas Goli 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 13:57:53 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470BDDF9eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 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." ::=3D { 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 receiv= e 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 implementati= on is broken. Furthermore, an implementation should be allow traps to be se= lectively 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 ospf= MaxAgeLsa on a core router. 2. If not, what is the valid interpretation and associated expected b= ehavior? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof. --_000_94A203EA12AECE4BA92D42DBFFE0AE470BDDF9eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <1F8433C23FF5034A9D2EB1CA395D2D13@ericsson.com> Content-Transfer-Encoding: quoted-printable 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:
 
&= nbsp;    ospfIfConfigError NOTIFICATION-TYPE
&= nbsp;         OBJECTS { ospfRouterI= d, -- The originator of the trap
&= nbsp;            osp= fIfIpAddress,
&= nbsp;            osp= fAddressLessIf,
&= nbsp;            osp= fPacketSrc,  -- The source IP address
&= nbsp;            osp= fConfigErrorType, -- Type of error
&= nbsp;            osp= fPacketType
&= nbsp;            }
&= nbsp;         STATUS  &nb= sp;    current
&= nbsp;         DESCRIPTION
&= nbsp;            &qu= ot;An ospfIfConfigError trap signifies that a
  &= nbsp;          packet has been received on a non-virtual
  &= nbsp;          interface from a router whose configuration
  &= nbsp;          parameters conflict with this router's
  &= nbsp;          configuration parameters.  Note that the event
&= nbsp;            opt= ionMismatch should cause a trap only if it
&= nbsp;            pre= vents an adjacency from forming."
&= nbsp;         ::=3D { ospfTraps 4 }=
<= o:p> 
The highlighted text could be interpreted that the trap is sent every time an offending packet ha= s been received.
This could easily result in an incessant flow of traps (e.g., if you receiv= e offending Hello packets from a misconfigured router on the LAN segment).<= o:p>
 
Hence two  questions:
1.       Is the interpreta= tion mentioned above valid?

Yes. If you don't have rate limiting for your traps, your SNMP impleme= ntation 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                 Ena= ble sending all supported OSPF traps
  ifauthfailure       Enable sending ospfIfAuthFai= lure traps
  ifconfigerror       Enable sending ospfIfConfigE= rror traps
  ifrxbadpacket       Enable sending ospfIfRxBadPa= cket traps
  ifstatechange       Enable sending ospfIfStateCh= ange traps
  maxagelsa           Enable sending osp= fMaxAgeLsa traps
  nbrstatechange      Enable sending ospfNbrStateC= hange traps
  originatelsa        Enable sending ospfOrig= inateLsa traps
  txretransmit        Enable sending ospftxre= transmit traps
  virtifauthfailure   Enable sending ospfVirtIfAuthFailure t= raps
  virtifconfigerror   Enable sending ospfVirtIfConfigError t= raps
  virtifrxbadpacket   Enable sending ospfVirtIfRxBadPacket t= raps
  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 t= he 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 info= rmation 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.


--_000_94A203EA12AECE4BA92D42DBFFE0AE470BDDF9eusaamb101ericsso_--