Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Richard A Steenbergen writes: > Any software which relies on static ifIndex mappings between polling > cycles is fundamentally flawed, period, end of discussion. There is > absolutely no excuse for this, it is beyond trivial to map data by > ifDescr, and the SNMP spec even tells you that ifIndex is not to be > used for this kind of thing. I totally agree up to this point. However... > I really don't understand why people still can't figure out how to do > this. ...doing MIB table indexing/object naming right in general is hard. It is easy as long as you restrict yourself to the interfaces table, or only allow things within the same table (e.g. ifDescr, ifName for interfaces) as names. Beyond that, it gets complicated pretty quickly. For example, wouldn't it be nice if you could specify interfaces by IPv4 address or subnet, or by VLAN name/number in a measurement tool? Now the tool would have to do a multi-step mapping using another table. I don't know about Juniper, but Cisco has these great sensor MIBs for stuff such as transceiver monitoring - those use the ENTITY-MIB as the basis for indexing, and that's also complex to use. I hear that Juniper has SNMP access to per-filter entry statistics - how's the indexing done for that? You'd want to be able to specify "the counter corresponding to number of bytes matched for the line that matches IPv6 TCP-port 08 traffic in the inbound ACL on interface ", that continues to work even as the ACL is modified. > Here is an example of a very compact poller which does efficient > retrieval using snmp bulk walk. All you need is php and the netsnmp > lib, it's just a wrapper to a very simple C implementation which is > 100x more efficient that the utter crap you'll find in mrtg, rtg, > etc. Thanks for the kind words, RAS, that is mostly my code (-: btw. I'm moving my Perl SNMP library to http://code.google.com/p/snmp-session/) While I don't necessarily disagree that the code is crap (e.g. missing SNMPv3 support, bad support for use with asynchronous event loops), I cannot let it stand uncommented that it is 100x less efficient than yours/Net-SNMP's. It is true that the Perl code is written in pure Perl and without much regard for efficiency in the construction and deconstruction of SNMP PDUs - in particular, lot of garbage and overhead is created as it assembles/disassembles everything using small Perl strings. So if the CPU load of the SNMP work (as opposed to storage and other processing) gives you problems on the manager (client) side, then I'm sorry about that. On the other hand, my code has some features that makes it easier on the SNMP agents, i.e. underpowered router CPUs (OK, your Junipers may be less underpowered than my stupid Ciscos, but still). In particular, it has a much nicer interface to walking tables (map_table / snmpmaptable) than most other libraries. I'll also note that there have never been any known buffer overflow bugs or memory leaks with my library. > You can easily use this to interface with any number of tools like > rrdtool, sql, etc. > http://www.e-gerbil.net/ras/snmp-php Your code has to let the router walk the entire interfaces table once for each column OID in $oidlist; using my library, you could walk all the columns of a table in parallel. That's not only less management traffic and less processing load for the router, but you can also start acting on entire table rows as you go (and maybe break the loop early when you have found what you're looking for). Best regards, -- Simon. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
I'm late jumping into this conversation, but are you using virtual-chassis by chance? Did the order of the individual units change when you upgraded? Chris Adams wrote: > Once upon a time, Tore Anderson said: > >> * Chris Adams >> >>> Never used Cisco I guess? >>> >> I have. As Steinar haug has already pointed out, IOS supports keeping >> ifIndexes static. Fortunately someone had the good sense to enable that >> feature, so they've never caused me any problems. >> > > I guess I had already switched to Cricket (where it didn't matter) > before they added that option, and then we ditched Cisco for Juniper. > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.237 / Virus Database: 270.10.23/1953 - Release Date: 02/14/09 > 18:01:00 > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Once upon a time, Tore Anderson said: > * Chris Adams > > Never used Cisco I guess? > > I have. As Steinar haug has already pointed out, IOS supports keeping > ifIndexes static. Fortunately someone had the good sense to enable that > feature, so they've never caused me any problems. I guess I had already switched to Cricket (where it didn't matter) before they added that option, and then we ditched Cisco for Juniper. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
* Chris Adams > Never used Cisco I guess? I have. As Steinar haug has already pointed out, IOS supports keeping ifIndexes static. Fortunately someone had the good sense to enable that feature, so they've never caused me any problems. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Once upon a time, Tore Anderson said: > Speaking of Extreme, by the way... Juniper is the first vendor whose > gear has changed ifIndexes on me, ever. Never used Cisco I guess? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
> Even though current JUNOS behaviour can be considered spec-compliant I > would still like to see the ifIndexes being kept static - it would be a > great feature enhanchement for those of us that (unwittingly) chose SNMP > software that doesn't handle ifIndexes changing. As I pointed out in my > first message, it can't be that hard - just reserve some space for the > private ifIndexes and start the public ones from, say, 1000. (This is > what my Extreme switches does.) Our experience is that the ifIndexes *are* kept across upgrades. I think we have had them change *once* on one of our Juniper routers. > Speaking of Extreme, by the way... Juniper is the first vendor whose > gear has changed ifIndexes on me, ever. Then I'm afraid you haven't been in the field for very long. (Hint: Look up the documentation for the Cisco command "snmp-server ifindex persist" and try to figure out how long Cisco had been selling boxes with SNMP before that command showed up...) > I assume most of the people on this list are not application developers, > but network administrators - at least I am not. So I/we are stuck with > whatever pieces of software is available, and changing an already- > established setup is probably going to be a big project in most cases. > Considering that not even the ubiquitous MRTG handles changing ifIndexes > by default I think static ifIndexes would be a worthwhile feature for > Juniper to implement in an upcoming JUNOS release. As already mentioned - in most cases it *is* static. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
* Richard A Steenbergen > Normally I'm the one yelling at Juniper when they do something stupid > and break things for no reason, but honestly... I admit that the tone in my first e-mail to this thread was over the line, and for that I do apologise. I hope nobody got offended. It was extremely frusterating to spend much of the day cleaning up the unexpected graph mess that resulted from the JUNOS upgrade - I certainly had more interesting tasks planned. Hearing from Malte that the issue had already been reported to JTAC, but that they didn't seem to care, made me quite angry and upset. I should have kept my breath for ten seconds before replying, though. I do appreciate that Patrik is looking into the issue now. > Any software which relies on static ifIndex mappings between polling > cycles is fundamentally flawed, period, end of discussion. There is > absolutely no excuse for this, it is beyond trivial to map data by > ifDescr, and the SNMP spec even tells you that ifIndex is not to be > used for this kind of thing. I realise that now. However, such pieces of software are in use by many people (five people in this thread alone as far as I can see), and when the ifIndex changes, it causes severe breakage for us. Even though current JUNOS behaviour can be considered spec-compliant I would still like to see the ifIndexes being kept static - it would be a great feature enhanchement for those of us that (unwittingly) chose SNMP software that doesn't handle ifIndexes changing. As I pointed out in my first message, it can't be that hard - just reserve some space for the private ifIndexes and start the public ones from, say, 1000. (This is what my Extreme switches does.) Speaking of Extreme, by the way... Juniper is the first vendor whose gear has changed ifIndexes on me, ever. > I really don't understand why people still can't figure out how to do > this. I assume most of the people on this list are not application developers, but network administrators - at least I am not. So I/we are stuck with whatever pieces of software is available, and changing an already- established setup is probably going to be a big project in most cases. Considering that not even the ubiquitous MRTG handles changing ifIndexes by default I think static ifIndexes would be a worthwhile feature for Juniper to implement in an upcoming JUNOS release. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
On Fri, Feb 13, 2009 at 08:51:23AM +0100, Tore Anderson wrote: > * Malte von dem Hagen > > > we filed that as a PR for the EX-Series we updated from 9.1 to 9.2 a > > while ago, and got the response from JTAC that this is expected behaviour. > > Unbelievable. This provokes me! I really hope that the idiot(s) that > made this design desicion are no longer working at Juniper. Normally I'm the one yelling at Juniper when they do something stupid and break things for no reason, but honestly... Any software which relies on static ifIndex mappings between polling cycles is fundamentally flawed, period, end of discussion. There is absolutely no excuse for this, it is beyond trivial to map data by ifDescr, and the SNMP spec even tells you that ifIndex is not to be used for this kind of thing. I really don't understand why people still can't figure out how to do this. Here is an example of a very compact poller which does efficient retrieval using snmp bulk walk. All you need is php and the netsnmp lib, it's just a wrapper to a very simple C implementation which is 100x more efficient that the utter crap you'll find in mrtg, rtg, etc. You can easily use this to interface with any number of tools like rrdtool, sql, etc. http://www.e-gerbil.net/ras/snmp-php -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
It's a simple UNIX file 'dcd.snmp_ix' ("I believe Juniper guys don't change
format/syntax of the file with each upgrade."), if you back
/var/db/dcd.snmp_ix while upgrading your JUNOS software and then later
restore it.
ja...@r1> file list /var/db/dcd.snmp_ix
Regards,
Masood
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Patrik Olsson
Sent: Friday, February 13, 2009 5:19 PM
To: Chris Adams; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SNMP interface index change after upgrade to 9.2
I use Cacti (it is free), have not seen this issue (yet). I think I will
poke around in it a bit, but I am with Chris and Tom in the spirit.
Cheers
Patrik
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Dear all, I do have the same problem. I am using M320, M120. I upgrade from 9.1R2.10 to 9.3R1.7, and my flow analysis can't get the right result because one of my analysis depends on the interface snmp index. Hope Juniper guy can response and get it fixed. cheers, Ethern On Fri, Feb 13, 2009 at 3:51 PM, Tore Anderson wrote: > * Malte von dem Hagen > >> we filed that as a PR for the EX-Series we updated from 9.1 to 9.2 a >> while ago, and got the response from JTAC that this is expected behaviour. > > Unbelievable. This provokes me! I really hope that the idiot(s) that > made this design desicion are no longer working at Juniper. > > Hey, Juniper, if you're reading this: Do you think that I ENJOY wasting > hours of my to clear up the mess this «feature» has caused, you're sadly > mistaken! Not only is it fscking annoying - I use the data in my graphs > for accounting too (and I think that's pretty common to do), so now > valuable data used for invoicing customers is lost forever. > > And this was only for the MXes! My EXes have 100s of graphs... I don't > want to even think about the hassle it would be to fix all of those > manually. > >> Public interfaces get snmp ifIndex numbers *after* private interfaces, >> so every time the private interfaces (whatever they exactly are) change, >> the index numbers of public interfaces will change as well. And yes, >> that is big PITA and very lame. > > Jesus. So reserve some room for the private interfaces and enumerate > public ones staring from ifIndex 100 or 1000 or whatever, then. That > wasn't too hard now was it? > > Juniper: to simpy say that this is just «expected behaviour» is > COMPLETELY UNACCEPTABLE, it's a DEFECT, and it NEEDS to be FIXED. > > *fumes* > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- = Ethern M., Lin, Network Division Computing Center, ACADEMIA SINICA Phone: +886-2-2789-9953 Fax : +886-2-2783-6444 = ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Once upon a time, Tore Anderson said: > It has been pointed out that not even MRTG, which I assume is the most > used traffic graphing suite, handles ifIndex changing (by default). > Keying off something else, like ifName, adds unnecessary overhead on the > polling station. I switched from MRTG to Cricket almost 10 years ago, in part because of this. Cricket can map on basically anything; it is very useful for all kinds of monitoring (not just router interface names). It keeps the overhead down by storing the index with the data. When it requests new data, it asks for the data and map field (e.g. ifDescr), and only if the map field no longer matches does it walk the whole tree to update the map (and when it walks the tree, it remembers it for mapping other interfaces). > I found that RFC 2863 says the following about ifIndex: > > The value for each interface must remain constant at least from one > re-initialization of the entity's network management system to the > next re-initialization. > > I'm not exactly sure what «re-initialization of the entity's network > management» means, but I guess a JUNOS upgrade probably qualifies. > Anyway, the «at least» part implies to me that it's even better if it's > constant across those re-initializations too. Any reboot (or even a daemon restart) is a re-initialization of the network management system. This was an issue when the first modular routers came out; it was years before router vendors offered any option to keep (or at least try to keep) static ifIndex values. Software has had a very long time to adapt, but I guess it hasn't all caught up yet. What if your router/switch fails, and you replace with a spare? The ifIndex values will all change then as well, since the stored ifIndex values are not in the regular config. It is much better to have software that handles that for you than to depend on static ifIndex values. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Once upon a time, Malte von dem Hagen said: > Am 13.02.2009 13:15 Uhr, Chris Adams schrieb: > > Um, how about using modern software that doesn't assume static > > interface > > IDs? Interface IDs are never guaranteed to be static, so proper > > SNMP > > software should handle them changing. > > what, if not ifIndex, should be a reasonable index for Interfaces? > Neither ifName nor interface descriptions possibly stored in vendor > specific MIBs are suitable values for constant reference. Why do you consider ifDescr or ifName to be unsuitable? How do you configure your routers/switches, if not with interface names? > It is the ifIndex by design. Its main purpose IS referencing > interfaces, > and a simple update of the OS must not change them. I consider this as > broken, like Tore does. The purpose if ifIndex is to index the ifEntry list, nothing more. It is only specified to be constant as long as the system is not rebooted. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Hej, Am 13.02.2009 13:15 Uhr, Chris Adams schrieb: > Um, how about using modern software that doesn't assume static interface > IDs? Interface IDs are never guaranteed to be static, so proper SNMP > software should handle them changing. what, if not ifIndex, should be a reasonable index for Interfaces? Neither ifName nor interface descriptions possibly stored in vendor specific MIBs are suitable values for constant reference. It is the ifIndex by design. Its main purpose IS referencing interfaces, and a simple update of the OS must not change them. I consider this as broken, like Tore does. rgds, Malte signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
I use Cacti (it is free), have not seen this issue (yet). I think I will poke around in it a bit, but I am with Chris and Tom in the spirit. Cheers Patrik BEGIN:VCARD VERSION:2.1 N:Olsson;Patrik FN:Patrik Olsson ORG:;EMEA Tech Dev TEL;WORK;VOICE:+46-733927834 TEL;CELL;VOICE:+46-733927834 ADR;WORK:;Stockholm;Arstaangsvagen 1A, bv;Stockholm;;S11743;Sweden LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Stockholm=0D=0AArstaangsvagen 1A, bv=0D=0AStockholm S11743=0D=0ASweden EMAIL;PREF;INTERNET:pols...@juniper.net REV:20070904T103433Z END:VCARD ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Once upon a time, Tore Anderson said: > Hey, Juniper, if you're reading this: Do you think that I ENJOY wasting > hours of my to clear up the mess this «feature» has caused, you're sadly > mistaken! Not only is it fscking annoying - I use the data in my graphs > for accounting too (and I think that's pretty common to do), so now > valuable data used for invoicing customers is lost forever. Um, how about using modern software that doesn't assume static interface IDs? Interface IDs are never guaranteed to be static, so proper SNMP software should handle them changing. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Hi Tom, * Tom Storey > If using MRTG, and particularly if you use cfgmaker, you could always > specify the "-ifref=descr" option. I'm using Munin (http://munin.sf.net/). Unfortunately, its SNMP collectors relies on the ifIndex to remain constant, so I am out of luck. I appreciate you taking the time to send me the tip, though. Thank you! Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
On 13/02/2009, at 6:21 PM, Tore Anderson wrote: Hey, Juniper, if you're reading this: Do you think that I ENJOY wasting hours of my to clear up the mess this «feature» has caused, If using MRTG, and particularly if you use cfgmaker, you could always specify the "-ifref=descr" option. This will cause interface names rather than interface indexes to be placed in the generated config. This way if the ifIndex changes your graphs dont break. However, this would require at least one more SNMP operation each time MRTG runs to associate ifNames with ifIndexes (I am unsure if MRTG will do one walk to get a list of all ifNames and associated ifIndexes, or if it does it per interface). But at least you wont have to suffer the agony of updating all of your MRTG configs to accomodate changed ifIndexes. I too got over doing this, and now dont generate any MRTG configs using cfgmaker without the above option. Example from one of my MRTG configs, though its from a Cisco: Target[myrouter_FastEthernet0_0.2]: \FastEthernet0/0.2:pub...@myrouter: Give it a try. Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
* Patrik Olsson > Did you see this in your MX240s aswell? Yes. I'll repeat myself: > An upgrade of two of my MX 240ies today, going from 9.3R1.7 to > 9.4R1.8, resulted in all of my graphs becoming hosed. Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Tore, Did you see this in your MX240s aswell? Patrik Sean Clarke> I believe this to be fixed in 9.4R1 , it's PR 408714, although the release notes don't mention it - perhaps it was a "confidential" PR hence not Sean Clarke> published in the release notes of 9.4 Sean Clarke> It was only affecting EX-series, not M/T/MX etc Sean Clarke> Sean Clarke> Hope this helps (a bit) BEGIN:VCARD VERSION:2.1 N:Olsson;Patrik FN:Patrik Olsson ORG:;EMEA Tech Dev TEL;WORK;VOICE:+46-733927834 TEL;CELL;VOICE:+46-733927834 ADR;WORK:;Stockholm;Arstaangsvagen 1A, bv;Stockholm;;S11743;Sweden LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Stockholm=0D=0AArstaangsvagen 1A, bv=0D=0AStockholm S11743=0D=0ASweden EMAIL;PREF;INTERNET:pols...@juniper.net REV:20070904T103433Z END:VCARD ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Hej, Tore Anderson wrote: It doesn't happen due to reboots, but due to JUNOS upgrades. Like I wrote in my original e-mail, after upgrading from 9.3R1.7 to 9.4R1.8 all of my graphs stopped working. (The original poster reported it happened going from 9.1R1.8 to 9.2R2.15.) The «you'll just have to live with it» answer Malte got from JTAC is unacceptable coming from a high-end vendor like Juniper. From a cheap no-name vendor it would be understandable, but I pay a premium for my Juniper gear and therefore I expect better. it does not happen due to *every* JunOS upgrade, but only if private interfaces snmp infrastructure changes between releases (said JTAC). Not that this relieves the pain... rgds, Malte ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Hi Patrik, * Patrik Olsson > I wont speak for EX, since I am not sure. But for M/MX/T/TX the SNMP > index for interfaces (used for graphing for instance) should not change > due to reboot. I have not seen that in my small lab at least. > > What JUNOS version do you see this in? It doesn't happen due to reboots, but due to JUNOS upgrades. Like I wrote in my original e-mail, after upgrading from 9.3R1.7 to 9.4R1.8 all of my graphs stopped working. (The original poster reported it happened going from 9.1R1.8 to 9.2R2.15.) The «you'll just have to live with it» answer Malte got from JTAC is unacceptable coming from a high-end vendor like Juniper. From a cheap no-name vendor it would be understandable, but I pay a premium for my Juniper gear and therefore I expect better. Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
I wont speak for EX, since I am not sure. But for M/MX/T/TX the SNMP index for interfaces (used for graphing for instance) should not change due to reboot. I have not seen that in my small lab at least. What JUNOS version do you see this in? Cheer Patrik -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Tore Anderson Sent: den 13 februari 2009 08:51 To: Malte von dem Hagen Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SNMP interface index change after upgrade to 9.2 * Malte von dem Hagen > we filed that as a PR for the EX-Series we updated from 9.1 to 9.2 a > while ago, and got the response from JTAC that this is expected behaviour. Unbelievable. This provokes me! I really hope that the idiot(s) that made this design desicion are no longer working at Juniper. Hey, Juniper, if you're reading this: Do you think that I ENJOY wasting hours of my to clear up the mess this has caused, you're sadly mistaken! Not only is it fscking annoying - I use the data in my graphs for accounting too (and I think that's pretty common to do), so now valuable data used for invoicing customers is lost forever. And this was only for the MXes! My EXes have 100s of graphs... I don't want to even think about the hassle it would be to fix all of those manually. > Public interfaces get snmp ifIndex numbers *after* private interfaces, > so every time the private interfaces (whatever they exactly are) change, > the index numbers of public interfaces will change as well. And yes, > that is big PITA and very lame. Jesus. So reserve some room for the private interfaces and enumerate public ones staring from ifIndex 100 or 1000 or whatever, then. That wasn't too hard now was it? Juniper: to simpy say that this is just is COMPLETELY UNACCEPTABLE, it's a DEFECT, and it NEEDS to be FIXED. *fumes* -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp BEGIN:VCARD VERSION:2.1 N:Olsson;Patrik FN:Patrik Olsson ORG:;EMEA Tech Dev TEL;WORK;VOICE:+46-733927834 TEL;CELL;VOICE:+46-733927834 ADR;WORK:;Stockholm;Arstaangsvagen 1A, bv;Stockholm;;S11743;Sweden LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Stockholm=0D=0AArstaangsvagen 1A, bv=0D=0AStockholm S11743=0D=0ASweden EMAIL;PREF;INTERNET:pols...@juniper.net REV:20070904T103433Z END:VCARD ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
* Malte von dem Hagen > we filed that as a PR for the EX-Series we updated from 9.1 to 9.2 a > while ago, and got the response from JTAC that this is expected behaviour. Unbelievable. This provokes me! I really hope that the idiot(s) that made this design desicion are no longer working at Juniper. Hey, Juniper, if you're reading this: Do you think that I ENJOY wasting hours of my to clear up the mess this «feature» has caused, you're sadly mistaken! Not only is it fscking annoying - I use the data in my graphs for accounting too (and I think that's pretty common to do), so now valuable data used for invoicing customers is lost forever. And this was only for the MXes! My EXes have 100s of graphs... I don't want to even think about the hassle it would be to fix all of those manually. > Public interfaces get snmp ifIndex numbers *after* private interfaces, > so every time the private interfaces (whatever they exactly are) change, > the index numbers of public interfaces will change as well. And yes, > that is big PITA and very lame. Jesus. So reserve some room for the private interfaces and enumerate public ones staring from ifIndex 100 or 1000 or whatever, then. That wasn't too hard now was it? Juniper: to simpy say that this is just «expected behaviour» is COMPLETELY UNACCEPTABLE, it's a DEFECT, and it NEEDS to be FIXED. *fumes* -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
* David Ball > Anyone else notice this? Am I incorrect in my previous assumption > that Juniper had solved this issue of SNMP index changes across > reboots? They still haven't, unfortunately. An upgrade of two of my MX 240ies today, going from 9.3R1.7 to 9.4R1.8, resulted in all of my graphs becoming hosed. A major pain in the arse! Grrr... -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
On Monday 27 October 2008, David Ball wrote: > I thought Juniper had sorted out their interface SNMP index > numbering such that they would remain the same, even following a > reboot? I've been running a simple MRTG instance to monitor some > 10Gig core links since 8.4 with no problems. Are you sure ? Interface's indexes have change after reboot in 7.5R2.8 and 8.1R4.3 if some interfaces was added or removed. -- Regards, Sergey ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
thanks, Hangu. Unfortunately it appears as though the contents of this file (must) have changed between 9.1R1.8 and 9.2R2.15. Unfortuately, I'm not sure I can confirm that, as I have no more T-640s running 9.1. I have an MX running 9.1, but its file will certainly differ, as there are completely different interfaces. May open ticket with JNPR. Thnx folks. David On 26/10/2008, Hangu Jeong <[EMAIL PROTECTED]> wrote: > Your assumption is correct, actually router maintain snmp index as below > file, > So there is no snmp index changes across reboots. > > router# file show /var/db/dcd.snmp_ix > /* file-format-version: 1 */ > /* > * mib2d-generated /var/db/dcd.snmp_ix > * Version: MIB2D release 9.2R1.10 built by builder on 2008-08-07 07:24:26 > UTC > * Written: Mon Oct 27 13:16:51 2008 > > -Hangu > > On Mon, Oct 27, 2008 at 1:24 PM, David Ball <[EMAIL PROTECTED]> wrote: > >> I thought Juniper had sorted out their interface SNMP index >> numbering such that they would remain the same, even following a >> reboot? I've been running a simple MRTG instance to monitor some >> 10Gig core links since 8.4 with no problems. I recently upgraded from >> 9.1R1.8 to 9.2R2.15 on my T-Series and most (note: not ALL) of the >> core 10Gig links I was monitoring (MRTG) all had a change in their >> SNMP index number. For example, ge-0/0/0 was previously SNMP index >> #32, but now appears as #355. >> Anyone else notice this? Am I incorrect in my previous assumption >> that Juniper had solved this issue of SNMP index changes across >> reboots? >> >> David >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
David, On Sun, 26 Oct 2008, David Ball wrote: I thought Juniper had sorted out their interface SNMP index numbering such that they would remain the same, even following a reboot? I've been running a simple MRTG instance to monitor some 10Gig core links since 8.4 with no problems. I recently upgraded from 9.1R1.8 to 9.2R2.15 on my T-Series and most (note: not ALL) of the core 10Gig links I was monitoring (MRTG) all had a change in their SNMP index number. For example, ge-0/0/0 was previously SNMP index #32, but now appears as #355. Anyone else notice this? Am I incorrect in my previous assumption that Juniper had solved this issue of SNMP index changes across reboots? We saw the same behaviour after an upgrade from 8.5 to 9.1R1. All indexes remained the same except for the one from an AE-interface. This changed it's index after the upgrade. Anybody any clue why this happened? Regards, Jac -- Jac Kloots Network Services SURFnet bv ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Your assumption is correct, actually router maintain snmp index as below file, So there is no snmp index changes across reboots. router# file show /var/db/dcd.snmp_ix /* file-format-version: 1 */ /* * mib2d-generated /var/db/dcd.snmp_ix * Version: MIB2D release 9.2R1.10 built by builder on 2008-08-07 07:24:26 UTC * Written: Mon Oct 27 13:16:51 2008 -Hangu On Mon, Oct 27, 2008 at 1:24 PM, David Ball <[EMAIL PROTECTED]> wrote: > I thought Juniper had sorted out their interface SNMP index > numbering such that they would remain the same, even following a > reboot? I've been running a simple MRTG instance to monitor some > 10Gig core links since 8.4 with no problems. I recently upgraded from > 9.1R1.8 to 9.2R2.15 on my T-Series and most (note: not ALL) of the > core 10Gig links I was monitoring (MRTG) all had a change in their > SNMP index number. For example, ge-0/0/0 was previously SNMP index > #32, but now appears as #355. > Anyone else notice this? Am I incorrect in my previous assumption > that Juniper had solved this issue of SNMP index changes across > reboots? > > David > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SNMP interface index change after upgrade to 9.2
I thought Juniper had sorted out their interface SNMP index numbering such that they would remain the same, even following a reboot? I've been running a simple MRTG instance to monitor some 10Gig core links since 8.4 with no problems. I recently upgraded from 9.1R1.8 to 9.2R2.15 on my T-Series and most (note: not ALL) of the core 10Gig links I was monitoring (MRTG) all had a change in their SNMP index number. For example, ge-0/0/0 was previously SNMP index #32, but now appears as #355. Anyone else notice this? Am I incorrect in my previous assumption that Juniper had solved this issue of SNMP index changes across reboots? David ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
