On Thu, 28 Feb 2019 22:06:27 +
Theo Voss wrote:
> do you have an ER (Enhancement Request) ID for us to beg our SE/sales
> rep for in order to support this?
I just requested from a local rep. When and if I get one I'll respond
to this thread.
John
The case was 2018-0913-0086
We didn't open ER
Nitzan
On Fri, Mar 1, 2019 at 12:06 AM Theo Voss wrote:
> Hi all,
>
> do you have an ER (Enhancement Request) ID for us to beg our SE/sales rep
> for in order to support this?
>
> Best regards,
> Theo Voss
>
> > Am 28.02.2019 um 23:00 schrieb
Hi all,
do you have an ER (Enhancement Request) ID for us to beg our SE/sales rep for
in order to support this?
Best regards,
Theo Voss
> Am 28.02.2019 um 23:00 schrieb Nitzan Tzelniker :
>
> I open TAC case about it few months ago
> We tried hard with our SE and the JTAC but the developers
I open TAC case about it few months ago
We tried hard with our SE and the JTAC but the developers didnt agreed to
add it
Maybe if more people will push it they will add it as QFX/SRX/EX ... does
not have craft interface and they support this MIB
BTW you can also try to monitor it with Netconf or
On Thu, 28 Feb 2019 20:48:52 +
Simon Lockhart wrote:
> I'm running 18.1R2.5 on these - wonder if they add it back in on later
> versions...
Not available on 18.4R1.8.
John
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
On Thu Feb 28, 2019 at 03:33:44PM -0500, Tom Beecher wrote:
> Weird.. those still show as valid through 18.4...
I'm running 18.1R2.5 on these - wonder if they add it back in on later
versions...
Simon
___
juniper-nsp mailing list
Once upon a time, Simon Lockhart said:
> On Thu Feb 28, 2019 at 03:19:36PM -0500, Tom Beecher wrote:
> > These don't work on the 204?
> >
> > Red Alarm: jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
> > Yellow Alarm: jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1
>
> They don't seem to exist on
On Thu, 28 Feb 2019 20:19:36 +
Tom Beecher wrote:
> These don't work on the 204?
>
> Red Alarm: jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
> Yellow Alarm: jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1
No.
$ snmpwalk -v2c -c foobar 192.0.2.1 1.3.6.1.4.1.2636.3.4.2.3.1
Weird.. those still show as valid through 18.4...
On Thu, Feb 28, 2019 at 3:31 PM Paul Stewart wrote:
> Wow that does suck … have used those alarm OID’s for a very long time with
> Juniper boxes ….
>
> > On Feb 28, 2019, at 3:27 PM, Simon Lockhart wrote:
> >
> > On Thu Feb 28, 2019 at
Wow that does suck … have used those alarm OID’s for a very long time with
Juniper boxes ….
> On Feb 28, 2019, at 3:27 PM, Simon Lockhart wrote:
>
> On Thu Feb 28, 2019 at 03:19:36PM -0500, Tom Beecher wrote:
>> These don't work on the 204?
>>
>> Red Alarm: jnxRedAlarmState
On Thu Feb 28, 2019 at 03:19:36PM -0500, Tom Beecher wrote:
> These don't work on the 204?
>
> Red Alarm: jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
> Yellow Alarm: jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1
They don't seem to exist on either MX10003 or MX204...
$ snmpwalk -v 2c -c xxx
These don't work on the 204?
Red Alarm: jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
Yellow Alarm: jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1
On Thu, Feb 28, 2019 at 2:51 PM Tarko Tikan wrote:
> hey,
>
> > i just found out that it seems not to be possible to poll Yellow/Red
> Alarm (Count
hey,
i just found out that it seems not to be possible to poll Yellow/Red Alarm
(Count or State) on MX204 via SNMP.
This is pretty sad, juniper, please fix this.
Polling for redAlarmCount > 0 or yellowAlarmCount > 0 has been a good
generic solution to cover a lot of ground quickly.
--
I expect you don't like the idea of syslog for the same reason as SNMP traps...
So perhaps you could craft something using SLAX? I would be a little surprised
if someone hasn't already done this somewhere:
Hi Guys,
i just found out that it seems not to be possible to poll Yellow/Red Alarm
(Count or State) on MX204 via SNMP.
On other platforms the craft panel (craftd) handles that alarms and its not
there on MX204 so you can't use it.
Also there seems to be no alternative OID to poll for Alarms
Hi!
Somewhat stupid question: while experimenting with rpki, I found that
while rfc8097 declares origin validation state as extended community
(0x4300:0.0.0.0:N in juniper configuration terms), Juniper documentation
uses standard communities 0x4300:N for this purpose:
16 matches
Mail list logo