Discussion:
[j-nsp] SNMP NMS support of Junos VLAN MIBs
Chuck Anderson
2015-12-09 16:31:15 UTC
Permalink
Has anyone tried to use or implement polling of the Q-BRIDGE-MIB on
any Juniper products, using either commercial or open source NMS
software or custom in-house software? What has been your experience
of the Juniper support of those SNMP products to correctly report
Port/VLAN memberships and VLAN/MAC FDB information?

Juniper EX-series (at least EX2200,3200,4200) 12.x and earlier has a
working Q-BRIDGE-MIB (dot1qVlanStaticEgressPorts) and JUNIPER-VLAN-MIB
(jnxExVlan). Because Q-BRIDGE-MIB refers only to internal VLAN
indexes, you need to use both MIBs to get Port/VLAN mappings including
the 802.1Q VLAN tag ID (jnxExVlanTag). This means custom software, or
an NMS vendor willing to implement the Juniper Enterprise MIBs.

All other Juniper Junos platforms only have Q-BRIDGE-MIB, but it is
broken (doesn't follow RFC 4363 standard PortList definition, instead
storing port indexes as ASCII-encoded, comma separated values),
apparently for a very long time. So again, you need custom software
or an NMS vendor willing to implement the broken Juniper version of
Q-BRIDGE-MIB (along with detecting which implementation is needed on
any particular device). This hasn't been a problem for us and in fact
went unnoticed, because we never cared to poll VLAN information from
our MX routers, only EX switches.

But now EX-series (and QFX-series) 13.x and newer with ELS have
dropped the Enterprise JUNIPER-VLAN-MIB (a good thing to not require
Enterprise MIBs to get the VLAN tag ID) and have adopted the broken
Q-BRIDGE-MIB that all the other Junos platforms have been using (a
very bad thing). I'm pushing to have Juniper fix this, but their
concern is that it may break SNMP software that has been assuming the
broken Q-BRIDGE-MIB implementation for all these years.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Ross Vandegrift
2015-12-11 15:11:18 UTC
Permalink
What has been your experience of the Juniper support of those SNMP
products to correctly report Port/VLAN memberships and VLAN/MAC FDB
information?
I did this with custom software, but it's been 5+ years. Details are
fuzzy, but here's what I recall.
Juniper EX-series (at least EX2200,3200,4200) 12.x and earlier has a
working Q-BRIDGE-MIB (dot1qVlanStaticEgressPorts) and JUNIPER-VLAN-MIB
(jnxExVlan). Because Q-BRIDGE-MIB refers only to internal VLAN
indexes, you need to use both MIBs to get Port/VLAN mappings including
the 802.1Q VLAN tag ID (jnxExVlanTag). This means custom software, or
an NMS vendor willing to implement the Juniper Enterprise MIBs.
Yea, this sounds familiar.
All other Juniper Junos platforms only have Q-BRIDGE-MIB, but it is
broken (doesn't follow RFC 4363 standard PortList definition, instead
storing port indexes as ASCII-encoded, comma separated values),
apparently for a very long time. So again, you need custom software
or an NMS vendor willing to implement the broken Juniper version of
Q-BRIDGE-MIB (along with detecting which implementation is needed on
any particular device).
I never ran into this, but it's not too surprising - I had unending
problems with poor Q-BRIDGE-MIB. We used at least Junos, Procurve, and
a few flavors of IOS 12. Only HP had a Q-BRIDGE-MIB that was correct
enough to use - and if you poked it wrong, the switch would crash.

So I just wonder - is there any off-the-shelf software that depends on
correct, vendor neutral Q-BRIDGE-MIB? I always needed platform specific
hacks.
I'm pushing to have Juniper fix this, but their
concern is that it may break SNMP software that has been assuming the
broken Q-BRIDGE-MIB implementation for all these years.
This response might be right - unless Q-BRIDGE-MIB implementations are
much more useful than they were five years ago, "fixing" it is just
going to break software from folks that bothered to get it working in
the first place.

On Junos, I got sick of all this and switched to netconf.

Ross
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Phil Mayers
2015-12-11 15:26:24 UTC
Permalink
Post by Ross Vandegrift
I never ran into this, but it's not too surprising - I had unending
problems with poor Q-BRIDGE-MIB. We used at least Junos, Procurve, and
a few flavors of IOS 12. Only HP had a Q-BRIDGE-MIB that was correct
enough to use - and if you poked it wrong, the switch would crash.
Likewise, I've seen problems with the Q-BRIDGE on Extreme and Cisco.
I've always ended up using some vendor-specific method (except for the
pre-Huawei 3Com kit, which had excellent SNMP support in full standards
compliance AFAICT).
Post by Ross Vandegrift
On Junos, I got sick of all this and switched to netconf.
+1 (though Junoscript, in my case)

ssh ***@switch 'show ethernet-switching table | display xml'

...is always the poor-mans version ;o)

SNMP was an impressive effort for its time, and it could have been
great, but it's getting less and less usable as vendors pay less and
less attention to it. I've seen a number of devices from a number of
vendors get *worse* SNMP support over the last couple of years /
software releases.

In addition for something like the P/Q bridge FDB, the requirement for
the table to be sorted by OID can often be a substantial CPU impact, as
naive implementations sort the table on every getnext.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Chuck Anderson
2015-12-11 17:16:11 UTC
Permalink
Post by Phil Mayers
Post by Ross Vandegrift
I never ran into this, but it's not too surprising - I had unending
problems with poor Q-BRIDGE-MIB. We used at least Junos, Procurve, and
a few flavors of IOS 12. Only HP had a Q-BRIDGE-MIB that was correct
enough to use - and if you poked it wrong, the switch would crash.
Likewise, I've seen problems with the Q-BRIDGE on Extreme and Cisco.
I've always ended up using some vendor-specific method (except for
the pre-Huawei 3Com kit, which had excellent SNMP support in full
standards compliance AFAICT).
Post by Ross Vandegrift
On Junos, I got sick of all this and switched to netconf.
+1 (though Junoscript, in my case)
...is always the poor-mans version ;o)
SNMP was an impressive effort for its time, and it could have been
great, but it's getting less and less usable as vendors pay less and
less attention to it. I've seen a number of devices from a number of
vendors get *worse* SNMP support over the last couple of years /
software releases.
In addition for something like the P/Q bridge FDB, the requirement
for the table to be sorted by OID can often be a substantial CPU
impact, as naive implementations sort the table on every getnext.
For those of us who wish to/need to use commercial NMS software, are
there any that support NETCONF? And NETCONF isn't the answer yet
anyway to cross-vendor standardization, at least not until standard
YANG models are developed. At least Q-BRIDGE-MIB exists as a
standard.

Here are some commercial NMS products that we've looked at that we
would like to get working with our Juniper gear:

AKIPS MAC/IP/Switch reports
Statseeker's MAC/IP/Switch Port Table report
PatchManager SwitchBridge (Switch Port/VLAN documentation function)
Efficient IP's NetChange-IPL SNMP network monitor for switch port/VLAN/MAC tracking
InfoBlox NetMRI (SNMP network monitor)
BlueCat Network Discovery/Reconciliation (SNMP network monitor)
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Dale Shaw
2015-12-12 05:33:44 UTC
Permalink
Hi Chuck,
Post by Chuck Anderson
Here are some commercial NMS products that we've looked at that we
[...]
Post by Chuck Anderson
Statseeker's MAC/IP/Switch Port Table report
[...]

This works already, from v3.7.x or possibly v3.8 and newer, if memory
serves.

Cheers,
Dale
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Chuck Anderson
2015-12-13 16:30:56 UTC
Permalink
Post by Dale Shaw
Hi Chuck,
Post by Chuck Anderson
Here are some commercial NMS products that we've looked at that we
[...]
Post by Chuck Anderson
Statseeker's MAC/IP/Switch Port Table report
[...]
This works already, from v3.7.x or possibly v3.8 and newer, if memory
serves.
It does not work on EX4300 or QFX5100 because Juniper adopted the
broken Q-BRIDGE-MIB there starting in Junos 13.1. Nor does it work on
any MX because the broken Q-BRIDGE-MIB has been there for a very long
time now.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Phil Mayers
2015-12-14 12:40:05 UTC
Permalink
Post by Chuck Anderson
For those of us who wish to/need to use commercial NMS software, are
there any that support NETCONF? And NETCONF isn't the answer yet
anyway to cross-vendor standardization, at least not until standard
YANG models are developed. At least Q-BRIDGE-MIB exists as a
standard.
On the commercial NMSes, no idea. I would hope that commercial products
would provide a way to integrate external datasources, but maybe not.

I take your point about Netconf versus SNMP, and I don't disagree with
you that Juniper should really fix this - "it's been broken for ages" is
a pretty poor excuse, they could always provide a config knob to toggle
on the new behaviour.

But I just don't see them fixing it.

Re: YANG - at this point I'd take reliable, comprehensive APIs with
*any* reasonably sane, documented data models, standard or otherwise.
We're a long way from being able to rely on standard data models IMO,
which is unfortunate but a reality.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Chuck Anderson
2016-11-18 18:37:32 UTC
Permalink
Post by Phil Mayers
Post by Chuck Anderson
For those of us who wish to/need to use commercial NMS software, are
there any that support NETCONF? And NETCONF isn't the answer yet
anyway to cross-vendor standardization, at least not until standard
YANG models are developed. At least Q-BRIDGE-MIB exists as a
standard.
On the commercial NMSes, no idea. I would hope that commercial
products would provide a way to integrate external datasources, but
maybe not.
I take your point about Netconf versus SNMP, and I don't disagree
with you that Juniper should really fix this - "it's been broken for
ages" is a pretty poor excuse, they could always provide a config
knob to toggle on the new behaviour.
But I just don't see them fixing it.
They fixed it in 14.1X53-D40 and made it configurable. Add this
configuration to make Q-BRIDGE-MIB follow the standard defintion of
PortList:

set switch-options mib dot1q-mib port-list bit-map

[edit switch-options]
+ mib {
+ dot1q-mib {
+ port-list bit-map;
+ }
+ }
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Luis Balbinot
2016-11-20 01:26:23 UTC
Permalink
Check out Observium. I don't know about this specific MIB, but it correctly
detects vlan memberships for me.
Post by Chuck Anderson
Has anyone tried to use or implement polling of the Q-BRIDGE-MIB on
any Juniper products, using either commercial or open source NMS
software or custom in-house software? What has been your experience
of the Juniper support of those SNMP products to correctly report
Port/VLAN memberships and VLAN/MAC FDB information?
Juniper EX-series (at least EX2200,3200,4200) 12.x and earlier has a
working Q-BRIDGE-MIB (dot1qVlanStaticEgressPorts) and JUNIPER-VLAN-MIB
(jnxExVlan). Because Q-BRIDGE-MIB refers only to internal VLAN
indexes, you need to use both MIBs to get Port/VLAN mappings including
the 802.1Q VLAN tag ID (jnxExVlanTag). This means custom software, or
an NMS vendor willing to implement the Juniper Enterprise MIBs.
All other Juniper Junos platforms only have Q-BRIDGE-MIB, but it is
broken (doesn't follow RFC 4363 standard PortList definition, instead
storing port indexes as ASCII-encoded, comma separated values),
apparently for a very long time. So again, you need custom software
or an NMS vendor willing to implement the broken Juniper version of
Q-BRIDGE-MIB (along with detecting which implementation is needed on
any particular device). This hasn't been a problem for us and in fact
went unnoticed, because we never cared to poll VLAN information from
our MX routers, only EX switches.
But now EX-series (and QFX-series) 13.x and newer with ELS have
dropped the Enterprise JUNIPER-VLAN-MIB (a good thing to not require
Enterprise MIBs to get the VLAN tag ID) and have adopted the broken
Q-BRIDGE-MIB that all the other Junos platforms have been using (a
very bad thing). I'm pushing to have Juniper fix this, but their
concern is that it may break SNMP software that has been assuming the
broken Q-BRIDGE-MIB implementation for all these years.
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Colton Conor
2018-07-08 16:51:32 UTC
Permalink
Chuck,

Did this Junos issue ever get resolved?
Post by Chuck Anderson
Has anyone tried to use or implement polling of the Q-BRIDGE-MIB on
any Juniper products, using either commercial or open source NMS
software or custom in-house software? What has been your experience
of the Juniper support of those SNMP products to correctly report
Port/VLAN memberships and VLAN/MAC FDB information?
Juniper EX-series (at least EX2200,3200,4200) 12.x and earlier has a
working Q-BRIDGE-MIB (dot1qVlanStaticEgressPorts) and JUNIPER-VLAN-MIB
(jnxExVlan). Because Q-BRIDGE-MIB refers only to internal VLAN
indexes, you need to use both MIBs to get Port/VLAN mappings including
the 802.1Q VLAN tag ID (jnxExVlanTag). This means custom software, or
an NMS vendor willing to implement the Juniper Enterprise MIBs.
All other Juniper Junos platforms only have Q-BRIDGE-MIB, but it is
broken (doesn't follow RFC 4363 standard PortList definition, instead
storing port indexes as ASCII-encoded, comma separated values),
apparently for a very long time. So again, you need custom software
or an NMS vendor willing to implement the broken Juniper version of
Q-BRIDGE-MIB (along with detecting which implementation is needed on
any particular device). This hasn't been a problem for us and in fact
went unnoticed, because we never cared to poll VLAN information from
our MX routers, only EX switches.
But now EX-series (and QFX-series) 13.x and newer with ELS have
dropped the Enterprise JUNIPER-VLAN-MIB (a good thing to not require
Enterprise MIBs to get the VLAN tag ID) and have adopted the broken
Q-BRIDGE-MIB that all the other Junos platforms have been using (a
very bad thing). I'm pushing to have Juniper fix this, but their
concern is that it may break SNMP software that has been assuming the
broken Q-BRIDGE-MIB implementation for all these years.
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Chuck Anderson
2018-07-08 17:07:02 UTC
Permalink
Yes. Juniper added a configuration knob to cause PortList to work
according to the standard on Junos ELS for at least EX4300, EX3400
etc:

set switch-options mib dot1q-mib port-list bit-map

in Junos versions at least as old as 14.1X53-D45 and 15.1X53-D57.3.
It also appears to commit in Junos 17.3R2 for MX, but I haven't tested
the functionality.
Post by Dale Shaw
Chuck,
Did this Junos issue ever get resolved?
Post by Chuck Anderson
Has anyone tried to use or implement polling of the Q-BRIDGE-MIB on
any Juniper products, using either commercial or open source NMS
software or custom in-house software? What has been your experience
of the Juniper support of those SNMP products to correctly report
Port/VLAN memberships and VLAN/MAC FDB information?
Juniper EX-series (at least EX2200,3200,4200) 12.x and earlier has a
working Q-BRIDGE-MIB (dot1qVlanStaticEgressPorts) and JUNIPER-VLAN-MIB
(jnxExVlan). Because Q-BRIDGE-MIB refers only to internal VLAN
indexes, you need to use both MIBs to get Port/VLAN mappings including
the 802.1Q VLAN tag ID (jnxExVlanTag). This means custom software, or
an NMS vendor willing to implement the Juniper Enterprise MIBs.
All other Juniper Junos platforms only have Q-BRIDGE-MIB, but it is
broken (doesn't follow RFC 4363 standard PortList definition, instead
storing port indexes as ASCII-encoded, comma separated values),
apparently for a very long time. So again, you need custom software
or an NMS vendor willing to implement the broken Juniper version of
Q-BRIDGE-MIB (along with detecting which implementation is needed on
any particular device). This hasn't been a problem for us and in fact
went unnoticed, because we never cared to poll VLAN information from
our MX routers, only EX switches.
But now EX-series (and QFX-series) 13.x and newer with ELS have
dropped the Enterprise JUNIPER-VLAN-MIB (a good thing to not require
Enterprise MIBs to get the VLAN tag ID) and have adopted the broken
Q-BRIDGE-MIB that all the other Junos platforms have been using (a
very bad thing). I'm pushing to have Juniper fix this, but their
concern is that it may break SNMP software that has been assuming the
broken Q-BRIDGE-MIB implementation for all these years.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Loading...