Hi Muthu, In that case, I would just send ospfIfRxBadPacket – it contains the local and remote IP addresses in the trap data. Or, you could use ospfIfConfigError and you could set the error to noError since there isn’t one explicitly defined for this situation. Good Luck, Acee
From: Muthu Arul Mozhi Perumal <[email protected]> Date: Wednesday, December 9, 2020 at 8:51 AM To: Acee Lindem <[email protected]> Cc: "Acee Lindem (acee)" <[email protected]>, "[email protected]" <[email protected]>, Tulasi Rami Reddy N <[email protected]> Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base Hi Acee, We aren't generating any trap today for the subnet mismatch case. We wanted to get some feedback on what would be an appropriate trap to generate from a usability standpoint, if we want to generate one.. Regards, Muthu On Wed, Dec 9, 2020 at 7:09 PM Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: Hi Muthu, There isn’t a specific case for this specific error so I wouldn’t reuse the any of the specific ones with the trap. Like I said, some implementations don’t generate any OSPF MIB trap for this case. What are you doing today? Thanks, Acee From: Lsr <[email protected]<mailto:[email protected]>> on behalf of Muthu Arul Mozhi Perumal <[email protected]<mailto:[email protected]>> Date: Wednesday, December 9, 2020 at 8:18 AM To: "Acee Lindem (acee)" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Tulasi Rami Reddy N <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base Hi Acee, This is a configuration error, right? Wouldn't ospfIfConfigError trap be more appropriate? There is no good error code for this case in ospfConfigErrorType, though. Perhaps, RFC4750 could have reserved some error codes for future definitions? Regards, Muthu On Wed, Dec 9, 2020 at 6:16 PM Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: Hi Tulasi, You definitely shouldn’t generate the netMaskMismatch trap as this is for mask mismatch detection on hello packets. You could generate the ospfIfRxBadPacket but many do not for this case. Thanks, Acee From: Lsr <[email protected]<mailto:[email protected]>> on behalf of Tulasi Rami Reddy N <[email protected]<mailto:[email protected]>> Date: Wednesday, December 9, 2020 at 6:11 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base [ Sorry, My previous mail was truncated] Hi , OSPFv2 adjacency will be formed on a numbered LAN only below both conditions are met: 1. Common IP subnet 2. Matching network mask. From the OSPFv2 MIB, there is only one error defined. ospfConfigErrorType OBJECT-TYPE SYNTAX INTEGER { netMaskMismatch (7), } I believe this is for the case 2 (when mask is mismatched). Let's take below example: RTA (11.1.1.2/24<http://11.1.1.2/24>) -------- (10.1.1.1/24<http://10.1.1.1/24>) RTB Here, src IP is not matching to the Rx interface IP subnet, then what is the error type to be set? Should this be considered as generic input processing error and only generate ospfIfRxBadPacket notification or netMaskMismatch notification? Should we need a new type here? " The generic input processing of OSPF packets will have checked the validity of the IP header and the OSPF packet header." Thanks, Tulasi. On Wed, Dec 9, 2020 at 4:27 PM Tulasi Rami Reddy N <[email protected]<mailto:[email protected]>> wrote: Hi , OSPFv2 adjacency will be formed on a numbered LAN only when 1. Common IP subnet 2.matching network mask. From the Thanks, TUlasi. _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
