Juniper QFX trunk fix #497
Conversation
|
Hi @po1vo |
May be it is. The code pulls tagging status of interfaces and assumes that tagged ones are trunks and non-tagged are access ports. Which to me sounds valid. Any particular reason to use MibSupport instead of EXTMOD ? |
|
BEWARE: HERE BE DRAGONS! Be very wary of doing things this way: you are extremely likely to cause breakage. It's worth noting that until the most recent firmware updates (April 2018), Huawei devices did not mark trunk devices correctly (they were marked as ethernet instead of aggregate or LAG), nor did it add the trunk devices into the lagmib slave list, nor did it remove the trunk components from the 802.1d bridge MIB. (this has all been fixed in Quidways and Access Routers. Cloudengine fixes will roll out in July, Access controllers are TBD) HOWEVER: it DID put all this stuff into private Huawei MIBs. Brocade, HP(3com) and Juniper devices all share the same fault and all have the same private MIB solution. The are all derived from Comware (3com) ancestry It is far preferable to use those private MIBs rather than trying to "guess". You are far less likely to "tie your shoelaces together" if you stick to the manufacturer-documented way of doing things (This is also known as "Assumption is the mother of all f***ups") If you want the Huawei MIBs references I can provide them and can probably obtain the Juniper, Hp(3com) and Brocade references too. The included PDF documents in the reference contain specific examples for extracting this informatiion from the private MIBs I also point you to the work recently done on Netdisco to fix Huawei breakage as it is relevant to what you want to do for Juniper - this patch in particular has a lot of stuff which you might find useful: netdisco/snmp-info@f2fdbb0 You are more than welcome to come and ask questions/seek help about manufacturer-specific stuff in the #netdisco and #net-snmp channels on freenode. |
|
g-bougard: if you want to test this on the huawei snmpwalks I have provided I can tell you if it has worked things out correctly, but, I'm pretty sure that the method described won't be able to tell which slaves belong to which trunks or be able to tell the difference between a trunk, stacking connection, or Trill interconnect and it may break unpredictably in future on still-unknown equipment. It might work for Juniper switches, but I feel that trying to infer based on guesses from incomplete information in the IETF/RFC public MIBs is the wrong way of doing things when the proper way is to consult the manufacturer's MIB reference and use their approved method - even if that means "use the manufacturer's private MIB" The wisdom of their "approved method" not being "we put this all correctly into the Public MIB" is another matter - and one that will only be fixed if customers complain (loudly) about broken SNMP returns. In this case Juniper do provide a documented way of getting their trunking information and it should be used. Using undocumented methods or attempting to a kludge is a fast way into a path of eternal pain and teeth-gnashing when they change the API. And that's without even going into the problem of comware-derived systems using independent index tables for ifmib, lldp, qbdridge and vlans (which is 100% RFC-compliant, just unexpected) po1vo: start here: https://apps.juniper.net/mib-explorer/ I believe the answer you are looking for is in the JUNIPER-L2CP-FEATURES-MIB, under jnxL2cpObjects. Rolling this stuff into a Juniper MIB would be a lot better solution. |
|
@Stoatwblr , thank you for the info. Though it seems to me you're misunderstanding the purpose of the patch. It is to find out 802.1Q status, not LAG. I've searched private Juniper MIBs, but couldn't find anything suitable for QFX models. |
|
po1vo: trunk as in qbridge MIB tagged port? you need to be aware of the independent indexing issue. As you work your way up ranges of ports (especially across shelves or cards), you'll find yourself running into "off-by-N" problems. Fusioninventory currently assumes that all the ifmib/lldp/qbbridge/vlan indexes are synchronised (they're not on Comware) AND that they're contiguous+start at 0/1 (they have "holes" and they may start at an arbitrary number). The only safe way to proceed is to do a two-step process to link each of the indexes back to a port, which is what netdisco does. It may seem like a waste of time if you're using Cisco equipment - until you're NOT using Cisco equipment. Doing it the safe way means that the answers are correct every time. |
I'm sorry, but i understood none of what you wrote. By trunk ports i mean networks ports which carry 802.1Q tagged frames. |
No other methods worked for me.
As a side note, since it's a very specific case, i can put this code into a separate module, e.g. FusionInventory::Agent::Tools::Hardware::Juniper