Subject: [Lsr] RFC4750: OSPF Version 2 Management Information Base

From: Tulasi Rami Reddy N <[email-masked]>
Date: Wed, 9 Dec 2020 16:27:26 +0530

Hi ,

OSPFv2 adjacency will be formed on a numbered LAN only when
           1. Common IP subnet
2.matching network mask.
>From the

Thanks,
TUlasi.

---

From: Tulasi Rami Reddy N <[email-masked]>
Date: Wed, 9 Dec 2020 16:41:15 +0530

[ 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)   --------     (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-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 9 Dec 2020 12:45:49 +0000

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-masked]> on behalf of Tulasi Rami Reddy N <[email-masked]>
Date: Wednesday, December 9, 2020 at 6:11 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

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.

                          netMaskMismatch (7),
           }

  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?

"

Thanks,
Tulasi.
On Wed, Dec 9, 2020 at 4:27 PM Tulasi Rami Reddy N <[email-masked]<mailto:[email-masked]>> wrote:
Hi ,

Thanks,
TUlasi.

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 9 Dec 2020 18:47:33 +0530

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) <acee=
[email-masked]> 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-masked]> on behalf of Tulasi Rami Reddy N <
> [email-masked]>
> *Date: *Wednesday, December 9, 2020 at 6:11 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
>
>
>
> *ospfIfRxBadPacket *notification or *netMaskMismatch  *notification?
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 9 Dec 2020 13:39:37 +0000

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-masked]> on behalf of Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wednesday, December 9, 2020 at 8:18 AM
To: "Acee Lindem (acee)" <acee=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Tulasi Rami Reddy N <[email-masked]>
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) <acee=[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> on behalf of Tulasi Rami Reddy N <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 9, 2020 at 6:11 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

                          netMaskMismatch (7),
           }

"

Thanks,
Tulasi.

Thanks,
TUlasi.
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 9 Dec 2020 19:21:04 +0530

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-masked]> 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-masked]> on behalf of Muthu Arul Mozhi Perumal <
> [email-masked]>
> *Date: *Wednesday, December 9, 2020 at 8:18 AM
> *To: *"Acee Lindem (acee)" <acee=[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Tulasi Rami Reddy N <
> [email-masked]>
> 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
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 9 Dec 2020 15:22:04 +0000

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-masked]>
Date: Wednesday, December 9, 2020 at 8:51 AM
To: Acee Lindem <[email-masked]>
Cc: "Acee Lindem (acee)" <acee=[email-masked]>, "[email-masked]" <[email-masked]>, Tulasi Rami Reddy N <[email-masked]>
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> on behalf of Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 9, 2020 at 8:18 AM
To: "Acee Lindem (acee)" <acee=[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Tulasi Rami Reddy N <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

Hi Acee,

Regards,
Muthu

                          netMaskMismatch (7),
           }

"

Thanks,
Tulasi.

Thanks,
TUlasi.

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 9 Dec 2020 23:26:28 +0530

Thanks, Acee. I thought about the ospfIfConfigError trap with the noError
code. Would have been nice if noError was defined as 255 with 13 to 254
defined for future definitions, but that ship already sailed far and out :)

Regards,
Muthu

On Wed, Dec 9, 2020 at 8:52 PM Acee Lindem (acee) <[email-masked]> wrote:

> 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-masked]>
> *Date: *Wednesday, December 9, 2020 at 8:51 AM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *"Acee Lindem (acee)" <acee=[email-masked]>, "
> [email-masked]" <[email-masked]>, Tulasi Rami Reddy N <[email-masked]>
> 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
>
>
>