Re: [j-nsp] BGP4-MIB-v2
❦ 27 mars 2017 21:15 GMT, Jeff Haas : >> I totally understand it's not possible to just fix the issue. Your best >> bet is to convert the draft into a RFC and fix the issue here! ;-) > > After checking with Jürgen about RFC 4001 encoding (no better answer!) > he confirms that we're missing the variable length length field in our > generated OIDs. > > I'll make a point of filing a PR on this. As noted elsewhere in > thread, solving it might be ... interesting. Thanks! I won't hold my breath and will learn a bit more about YANG in the meantime. ;-) -- Make sure special cases are truly special. - The Elements of Programming Style (Kernighan & Plauger) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP4-MIB-v2
> On Mar 27, 2017, at 4:15 PM, Jeff Haas wrote: > > >> On Mar 27, 2017, at 3:03 PM, Vincent Bernat wrote: >> >> ❦ 27 mars 2017 19:26 GMT, Jeff Haas : >> >>> To your relevant next point: If the junos mib is in error, what to do about >>> it? >>> >>> Very likely fixing the issue will cause mass amounts of unhappiness as >>> people's existing scripts and mib walking code fails due to the new >>> sub-indices. >>> >>> do the right thing, create misery? Leave it as is, document that it's >>> wrong? >> >> I totally understand it's not possible to just fix the issue. Your best >> bet is to convert the draft into a RFC and fix the issue here! ;-) > > After checking with Jürgen about RFC 4001 encoding (no better answer!) he > confirms that we're missing the variable length length field in our generated > OIDs. > > I'll make a point of filing a PR on this. As noted elsewhere in thread, > solving it might be ... interesting. PR 1265504 -- Jeff ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP4-MIB-v2
> On Mar 27, 2017, at 3:03 PM, Vincent Bernat wrote: > > ❦ 27 mars 2017 19:26 GMT, Jeff Haas : > >> To your relevant next point: If the junos mib is in error, what to do about >> it? >> >> Very likely fixing the issue will cause mass amounts of unhappiness as >> people's existing scripts and mib walking code fails due to the new >> sub-indices. >> >> do the right thing, create misery? Leave it as is, document that it's >> wrong? > > I totally understand it's not possible to just fix the issue. Your best > bet is to convert the draft into a RFC and fix the issue here! ;-) After checking with Jürgen about RFC 4001 encoding (no better answer!) he confirms that we're missing the variable length length field in our generated OIDs. I'll make a point of filing a PR on this. As noted elsewhere in thread, solving it might be ... interesting. -- Jeff (trivial diff that will generate so much hate mail...) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP4-MIB-v2
On Mar 27, 2017, at 3:03 PM, Vincent Bernat mailto:ber...@luffy.cx>> wrote: ❦ 27 mars 2017 19:26 GMT, Jeff Haas mailto:jh...@juniper.net>> : To your relevant next point: If the junos mib is in error, what to do about it? Very likely fixing the issue will cause mass amounts of unhappiness as people's existing scripts and mib walking code fails due to the new sub-indices. do the right thing, create misery? Leave it as is, document that it's wrong? I totally understand it's not possible to just fix the issue. Your best bet is to convert the draft into a RFC and fix the issue here! ;-) It's technically possible to fix and use a cli knob to give compliant behavior. But then someone (likely me, based on on how bug work gets email dispatched) gets to own questions about that workaround for a decade. (Did I mention I didn't like SNMP?) Otherwise, use another table with the correct indexing? jnxBgpM2PeerTableNew := jnxBgpM2PeerData.2? Dunno if it's worth your time. I think you misunderstood my original point: https://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-15 Note that the draft is long expired. It was impossible to get vendors to want to implement it. Since *becoming* one of those vendors, I got some minor support to get the code restructured for the IETF MIB from an intern, but... well, it was intern code and didn't get through full commit criteria. If this is something the operational community has passion for, it could be done, but it'd normally get done through the usual product manager process. Or, if I get supremely bored and have copious spare time (ha!) I may just finish it. But I've been saying that for a few years now. -- Jeff ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP4-MIB-v2
❦ 27 mars 2017 19:26 GMT, Jeff Haas : > To your relevant next point: If the junos mib is in error, what to do about > it? > > Very likely fixing the issue will cause mass amounts of unhappiness as > people's existing scripts and mib walking code fails due to the new > sub-indices. > > do the right thing, create misery? Leave it as is, document that it's > wrong? I totally understand it's not possible to just fix the issue. Your best bet is to convert the draft into a RFC and fix the issue here! ;-) Otherwise, use another table with the correct indexing? jnxBgpM2PeerTableNew := jnxBgpM2PeerData.2? Dunno if it's worth your time. -- Localise input and output in subroutines. - The Elements of Programming Style (Kernighan & Plauger) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP4-MIB-v2
> On Mar 27, 2017, at 12:43 PM, Vincent Bernat wrote: >>> So, 192.0.2.47 should be encoded to 4.192.0.2.47. >> >> Probably no. >> >> The headache here is that the underlying type is RFC 4001's >> InetAddress. As you can see in the documentation in that RFC the >> expectation is that the InetAddressType is used to 'cast' the >> InetAddress to one of the underlying types; e.g. InetAddressIPv4. >> Let's pick on that example: >> >> InetAddressIPv4 ::= TEXTUAL-CONVENTION >>DISPLAY-HINT "1d.1d.1d.1d" >>STATUS current >>DESCRIPTION >>"Represents an IPv4 network address: >> >> Octets Contents Encoding >>1-4 IPv4 address network-byte order >> >> The corresponding InetAddressType value is ipv4(1). >> >> This textual convention SHOULD NOT be used directly in object >> definitions, as it restricts addresses to a specific format. >> However, if it is used, it MAY be used either on its own or in >> conjunction with InetAddressType, as a pair." >>SYNTAX OCTET STRING (SIZE (4)) > >> So, while you're correct with regard to variable types, the >> expectation is that this is "cast" into a fixed sized octet string, >> which has implied length. > > I didn't know about RFC 4001 so I may be mistaken, but it doesn't say > anything about the size requirement. Other than the comments in the MIB, > there is also no way to link InetAddress and InetAddressIPv4. This is > not just a matter of being able to pretty-print the IPv4, it's that we > cannot know how to split the index into its components. I generally agree with your analysis. We've fundamentally reached a "what did the authors of rfc 4001 have in mind". The whole idea of using this union was sort of gross and while things were still in MIB-land as IETF's main way of doing management stuff, confused a lot of people. So the question is whether it's variably sized, and if so, how to reconcile against the casting. However... > >> Given that net-snmp seems to recognize how to render the output from >> the MIB, I suspect others came to a similar conclusion. > > Net-SNMP is not able to render the output of the MIB correctly if the > size is not specified. See, without the size: > > $ snmptranslate -m BGP4-V2-MIB-JUNIPER > iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.10.64.0.3.1.10.64.0.1 > BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4.10.64.0.3.1.10.64.0.1 > > If I add the size: > > $ snmptranslate -m BGP4-V2-MIB-JUNIPER > iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.4.10.64.0.3.1.4.10.64.0.1 > BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4."10.64.0.3".ipv4."10.64.0.1" I know I've seen the bottom form of the output at some point. This makes me wonder if my memory is simply playing a trick on me, or it's what we do in one of our internal tool chains. Again, get the answer of what you really expect vs. what's in the code. To your relevant next point: If the junos mib is in error, what to do about it? Very likely fixing the issue will cause mass amounts of unhappiness as people's existing scripts and mib walking code fails due to the new sub-indices. do the right thing, create misery? Leave it as is, document that it's wrong? Again, I hate SNMP. :-) As mentioned, I'm conveniently at IETF. At least one of the authors of 4001 attends, so I should see if he's here. > > Other MIB implementations also using AddrType/Addr includes the size, > for example (on JunOS 14.1): > > $ snmpgetnext net-tor-0114-1 IP-MIB::ipAddressTable > IP-MIB::ipAddressIfIndex.ipv4."10.64.0.3" = INTEGER: 567 > $ snmpgetnext -On net-tor-0114-1 IP-MIB::ipAddressTable > .1.3.6.1.2.1.4.34.1.3.1.4.10.64.0.3 = INTEGER: 567 And this does support the idea that the code is wrong. -- Jeff ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP4-MIB-v2
❦ 27 mars 2017 16:10 GMT, Jeff Haas :
>> I have been reported a (simple) bug in the implementation of the
>> BGP4-V2-MIB-JUNIPER. I know that if I open a JTAC case about this, I
>> will be asked a lot of unrelated questions, then I would be told that
>> since this never really worked, this is not the scope for JTAC.
>>
>> So, as I know some Juniper people reads here, here is the bug. I'd be
>> happy to provide more details if needed.
>
> Read, yes. Read on a timely basis, no.
>
> I also happen to be the author of the ietf mib that Juniper based this
> MIB on. :-)
Glad I have caught your attention and thanks for taking the time to answer!
>>jnxBgpM2CfgPeerLocalAddr OBJECT-TYPE
>>SYNTAX InetAddress (SIZE (4..20))
>>MAX-ACCESS read-create
>>STATUS current
>>DESCRIPTION
>>"The address of the local end of the peering session."
>>::= { jnxBgpM2CfgPeerEntry 4 }
>>
>> (and similar for RemoteAddr). The important bit is the size: variable.
>>
>> With SNMP, when an index has a variable length, except if it's the last
>> one _and_ the MIB says the size is IMPLIED, the length should be
>> prepended to the value.
>>
>> So, 192.0.2.47 should be encoded to 4.192.0.2.47.
>
> Probably no.
>
> The headache here is that the underlying type is RFC 4001's
> InetAddress. As you can see in the documentation in that RFC the
> expectation is that the InetAddressType is used to 'cast' the
> InetAddress to one of the underlying types; e.g. InetAddressIPv4.
> Let's pick on that example:
>
> InetAddressIPv4 ::= TEXTUAL-CONVENTION
> DISPLAY-HINT "1d.1d.1d.1d"
> STATUS current
> DESCRIPTION
> "Represents an IPv4 network address:
>
>Octets Contents Encoding
> 1-4 IPv4 address network-byte order
>
> The corresponding InetAddressType value is ipv4(1).
>
> This textual convention SHOULD NOT be used directly in object
> definitions, as it restricts addresses to a specific format.
> However, if it is used, it MAY be used either on its own or in
> conjunction with InetAddressType, as a pair."
> SYNTAX OCTET STRING (SIZE (4))
> So, while you're correct with regard to variable types, the
> expectation is that this is "cast" into a fixed sized octet string,
> which has implied length.
I didn't know about RFC 4001 so I may be mistaken, but it doesn't say
anything about the size requirement. Other than the comments in the MIB,
there is also no way to link InetAddress and InetAddressIPv4. This is
not just a matter of being able to pretty-print the IPv4, it's that we
cannot know how to split the index into its components.
> Given that net-snmp seems to recognize how to render the output from
> the MIB, I suspect others came to a similar conclusion.
Net-SNMP is not able to render the output of the MIB correctly if the
size is not specified. See, without the size:
$ snmptranslate -m BGP4-V2-MIB-JUNIPER
iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.10.64.0.3.1.10.64.0.1
BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4.10.64.0.3.1.10.64.0.1
If I add the size:
$ snmptranslate -m BGP4-V2-MIB-JUNIPER
iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.4.10.64.0.3.1.4.10.64.0.1
BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4."10.64.0.3".ipv4."10.64.0.1"
Other MIB implementations also using AddrType/Addr includes the size,
for example (on JunOS 14.1):
$ snmpgetnext net-tor-0114-1 IP-MIB::ipAddressTable
IP-MIB::ipAddressIfIndex.ipv4."10.64.0.3" = INTEGER: 567
$ snmpgetnext -On net-tor-0114-1 IP-MIB::ipAddressTable
.1.3.6.1.2.1.4.34.1.3.1.4.10.64.0.3 = INTEGER: 567
--
I was gratified to be able to answer promptly, and I did. I said I didn't know.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP4-MIB-v2
> On Jan 20, 2017, at 9:29 AM, Vincent Bernat wrote:
>
> Hey!
>
> I have been reported a (simple) bug in the implementation of the
> BGP4-V2-MIB-JUNIPER. I know that if I open a JTAC case about this, I
> will be asked a lot of unrelated questions, then I would be told that
> since this never really worked, this is not the scope for JTAC.
>
> So, as I know some Juniper people reads here, here is the bug. I'd be
> happy to provide more details if needed.
Read, yes. Read on a timely basis, no.
I also happen to be the author of the ietf mib that Juniper based this MIB on.
:-)
>
>
> The MIB says:
>
>jnxBgpM2PeerEntry OBJECT-TYPE
>SYNTAX JnxBgpM2PeerEntry
>MAX-ACCESS not-accessible
>STATUS current
>DESCRIPTION
>"Entry containing information about the connection with
> a remote BGP peer."
>INDEX {
>jnxBgpM2PeerRoutingInstance,
>jnxBgpM2PeerLocalAddrType,
>jnxBgpM2PeerLocalAddr,
>jnxBgpM2PeerRemoteAddrType,
>jnxBgpM2PeerRemoteAddr
>}
>::= { jnxBgpM2PeerTable 1 }
>
> And jnxBgpM2PeerLocalAddr is:
>
>jnxBgpM2CfgPeerLocalAddr OBJECT-TYPE
>SYNTAX InetAddress (SIZE (4..20))
>MAX-ACCESS read-create
>STATUS current
>DESCRIPTION
>"The address of the local end of the peering session."
>::= { jnxBgpM2CfgPeerEntry 4 }
>
> (and similar for RemoteAddr). The important bit is the size: variable.
>
> With SNMP, when an index has a variable length, except if it's the last
> one _and_ the MIB says the size is IMPLIED, the length should be
> prepended to the value.
>
> So, 192.0.2.47 should be encoded to 4.192.0.2.47.
Probably no.
The headache here is that the underlying type is RFC 4001's InetAddress. As
you can see in the documentation in that RFC the expectation is that the
InetAddressType is used to 'cast' the InetAddress to one of the underlying
types; e.g. InetAddressIPv4. Let's pick on that example:
InetAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS current
DESCRIPTION
"Represents an IPv4 network address:
Octets Contents Encoding
1-4 IPv4 address network-byte order
The corresponding InetAddressType value is ipv4(1).
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
SYNTAX OCTET STRING (SIZE (4))
So, while you're correct with regard to variable types, the expectation is that
this is "cast" into a fixed sized octet string, which has implied length.
Given that net-snmp seems to recognize how to render the output from the MIB, I
suspect others came to a similar conclusion.
I also take your point that the idea of the InetAddress "union" would seem to
imply a variable length. However, this is perhaps a better question for the
authors of RFC 4001... most of whom don't care about SNMP these days and have
moved on to yang. :-)
-- Jeff (who has grown to know much about, and loathe, SNMP)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] BGP4-MIB-v2
Hey!
I have been reported a (simple) bug in the implementation of the
BGP4-V2-MIB-JUNIPER. I know that if I open a JTAC case about this, I
will be asked a lot of unrelated questions, then I would be told that
since this never really worked, this is not the scope for JTAC.
So, as I know some Juniper people reads here, here is the bug. I'd be
happy to provide more details if needed.
The MIB says:
jnxBgpM2PeerEntry OBJECT-TYPE
SYNTAX JnxBgpM2PeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry containing information about the connection with
a remote BGP peer."
INDEX {
jnxBgpM2PeerRoutingInstance,
jnxBgpM2PeerLocalAddrType,
jnxBgpM2PeerLocalAddr,
jnxBgpM2PeerRemoteAddrType,
jnxBgpM2PeerRemoteAddr
}
::= { jnxBgpM2PeerTable 1 }
And jnxBgpM2PeerLocalAddr is:
jnxBgpM2CfgPeerLocalAddr OBJECT-TYPE
SYNTAX InetAddress (SIZE (4..20))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The address of the local end of the peering session."
::= { jnxBgpM2CfgPeerEntry 4 }
(and similar for RemoteAddr). The important bit is the size: variable.
With SNMP, when an index has a variable length, except if it's the last
one _and_ the MIB says the size is IMPLIED, the length should be
prepended to the value.
So, 192.0.2.47 should be encoded to 4.192.0.2.47.
Let's suppose we need to encode:
jnxBgpM2PeerRoutingInstance: 0
jnxBgpM2PeerLocalAddrType: 1 (code for ipv4)
jnxBgpM2PeerLocalAddr: 192.0.2.47
jnxBgpM2PeerRemoteAddrType: 1 (code for ipv4)
jnxBgpM2PeerRemoteAddr: 192.0.2.48
We should have:
0.1.4.192.0.2.47.1.4.192.0.2.48
But JunOS (at least 13.3 and 14.1) is using:
0.1.192.0.2.47.1.192.0.2.48
--
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
