jpl3

Re: New Interface filtering UI to import discovery results Is there any way to apply these filters to existing devices, or would I have to delete/rediscover nodes to use them?

We've just begun deploying Juniper EX VCs and could really use this feature.

Thanks Rob, but it didn't give me the count I was expecting. I had two nodes go down, and it returned '55'. If I goto the 'All Active Alerts' view in the GUI, it shows '2 Nodes' under 'Objects that triggered this alert'. 55 may correlate to other devices on that network that were in an unmanaged state.

I configured a 'Node Down' alert using the new 'alert when a certain number of objects meet the alert criteria' feature. (Yay!! I've been waiting for this one). When the alert is triggered and shows up in All Active Alerts it shows the number of objects that triggered the alert under the 'Object that triggered this alert'…

Great enhancements, thanks.

I see them as two separate DISCOVERY filtering features. The MINI PORT feature would be based on interface type or description (which I could also use), whereas check for an L2 discovery protocol (CDP/LLDP) would have a far broader scope. Another useful DISCOVERY filter would be vendor OID.

Alert Central has tons of potential. I wish development was a bit faster. It does have the SMS gateway mechanism, and there's been some talk of something more sophisticated in the future, like push notifications. I really like the idea of feeding all alert sources into one place, where it's accessible by others, rather…

That worked, thanks.

I'd like to test this template too. thanks.. john

> We only monitor network to network ports BB, I'm curious how you did this - I can't figure how to do this short of editing each node after (subnet) discovery. I've got a few thousand nodes ,so that's not practical. Ideally I'd like a discovery option that could limit discover to interfaces running a link discovery…

Does it work if you drop the 'context' and 'read/write' fields? Can you use (net-snmp) snmpget, eg. snmpget -v3 -l authNoPriv -a md5 -A snmp#personal$v3 -u snmpuser system.sysDescr.

Hi Peter, That's what I thought, but I had user data well beyond (years) the data retention settings. I went ahead and deleted the old user records from the UDT_User* tables with database manager. -john

Thanks for the useful info sja, and the link to the video. I've downloaded a trial version of kiwi syslog to check out.

Thanks for the helpful info njoylif.

that was a big help, thanks Jonathan. Do you know what the valid values are for SSLEnabled? I have one entry with port=80 and SSLEnabled=0, and another port=443 and SSLEnabled=2.

This looks really promising. We've been using FoE for a couple years, but recently excluded it from a new SW server architecture we've set up. It added a lot of complexity, and made OS updates a real pain. We added additional hardware fault tolerance and dropped FoE.

I've got the same (as yet unresolved) issue.

You could enable snmp debugging on the switch - term mon debug snmp headers I'm using SNMP V3 successfully on our C35xx switches, though I'm doing 'auth' only (no priv), and read-only. NPM doesn't do any snmp writes anyway that I'm aware of. Also, I leave the 'SNMPv3 Context' field blank. -john