Re: [j-nsp] MPLS admin groups implementation

[Adam Vitkovsky]

> tim tiriche
> Sent: Friday, December 11, 2015 8:53 AM
>
> Hi,
>
> I have an existing MPLS network of 3 regions
>
> ASIA US and EUROPE
>
> I don't want LSP's within US to be established via ASIA or EUROPE and vice
> versa.
>
> I want to create an admin group call it: GOLD and apply an exclude on all US
> LSP's.
>
> the problem is this will cause LSP to bounce.  since i have my config in apply
> groups this change will affect all lsp's.  i want to know is this traffic 
> impacting if
> i have link protection in place?
>
> is there a graceful way to do this?
>
Doing a lot of assumptions here but maybe setting high metric on all 
inter-region links?

You can configure your LSPs with "adaptive" cmd -then make before break is 
enabled.
But I'm not sure if configuring LSP with adaptive will bounce it, it shouldn't 
I think, (but you can try yourself with a dummy lsp).

> second question, if i have a statement like this:
>
> lsp a-b
> admin-group exclude [gold silver]
>
> does that mean, if an interface has either gold OR silver an LSP will not
> choose the path or is it an AND?
>
The overall cli rule is if you specify multiple arguments of the same character 
it's OR and it's AND among arguments of different character.
For example:

admin-group {
exclude [ group-name1 OR group-name2 ];
AND
include-all [ group-names ];
AND
include-any [ group-names ];


adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPLS admin groups implementation

[tim tiriche]

High metric on all inter-regions would be the ideal and simpler way.

I wasn't sure if i might be over looking or missing something.

Any real world experiences would be helpful.

-Tim

On Fri, Dec 11, 2015 at 2:26 AM, Adam Vitkovsky 
wrote:

> > tim tiriche
> > Sent: Friday, December 11, 2015 8:53 AM
> >
> > Hi,
> >
> > I have an existing MPLS network of 3 regions
> >
> > ASIA US and EUROPE
> >
> > I don't want LSP's within US to be established via ASIA or EUROPE and
> vice
> > versa.
> >
> > I want to create an admin group call it: GOLD and apply an exclude on
> all US
> > LSP's.
> >
> > the problem is this will cause LSP to bounce.  since i have my config in
> apply
> > groups this change will affect all lsp's.  i want to know is this
> traffic impacting if
> > i have link protection in place?
> >
> > is there a graceful way to do this?
> >
> Doing a lot of assumptions here but maybe setting high metric on all
> inter-region links?
>
> You can configure your LSPs with "adaptive" cmd -then make before break is
> enabled.
> But I'm not sure if configuring LSP with adaptive will bounce it, it
> shouldn't I think, (but you can try yourself with a dummy lsp).
>
> > second question, if i have a statement like this:
> >
> > lsp a-b
> > admin-group exclude [gold silver]
> >
> > does that mean, if an interface has either gold OR silver an LSP will not
> > choose the path or is it an AND?
> >
> The overall cli rule is if you specify multiple arguments of the same
> character it's OR and it's AND among arguments of different character.
> For example:
>
> admin-group {
> exclude [ group-name1 OR group-name2 ];
> AND
> include-all [ group-names ];
> AND
> include-any [ group-names ];
>
>
> adam
>
>
>
> Adam Vitkovsky
> IP Engineer
>
> T:  0333 006 5936
> E:  adam.vitkov...@gamma.co.uk
> W:  www.gamma.co.uk
>
> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
> of this email are confidential to the ordinary user of the email address to
> which it was addressed. This email is not intended to create any legal
> relationship. No one else may place any reliance upon it, or copy or
> forward all or any of it in any form (unless otherwise notified). If you
> receive this email in error, please accept our apologies, we would be
> obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or
> email postmas...@gamma.co.uk
>
> Gamma Telecom Limited, a company incorporated in England and Wales, with
> limited liability, with registered number 04340834, and whose registered
> office is at 5 Fleet Place London EC4M 7RD and whose principal place of
> business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPLS admin groups implementation

[tim tiriche]

The concern is, i have 6 LSP to every router in US and i am not sure if
there is a possibility of any of the LSP's using the high metric inter
region link.


On Fri, Dec 11, 2015 at 2:42 AM, tim tiriche  wrote:

> High metric on all inter-regions would be the ideal and simpler way.
>
> I wasn't sure if i might be over looking or missing something.
>
> Any real world experiences would be helpful.
>
> -Tim
>
> On Fri, Dec 11, 2015 at 2:26 AM, Adam Vitkovsky <
> adam.vitkov...@gamma.co.uk> wrote:
>
>> > tim tiriche
>> > Sent: Friday, December 11, 2015 8:53 AM
>> >
>> > Hi,
>> >
>> > I have an existing MPLS network of 3 regions
>> >
>> > ASIA US and EUROPE
>> >
>> > I don't want LSP's within US to be established via ASIA or EUROPE and
>> vice
>> > versa.
>> >
>> > I want to create an admin group call it: GOLD and apply an exclude on
>> all US
>> > LSP's.
>> >
>> > the problem is this will cause LSP to bounce.  since i have my config
>> in apply
>> > groups this change will affect all lsp's.  i want to know is this
>> traffic impacting if
>> > i have link protection in place?
>> >
>> > is there a graceful way to do this?
>> >
>> Doing a lot of assumptions here but maybe setting high metric on all
>> inter-region links?
>>
>> You can configure your LSPs with "adaptive" cmd -then make before break
>> is enabled.
>> But I'm not sure if configuring LSP with adaptive will bounce it, it
>> shouldn't I think, (but you can try yourself with a dummy lsp).
>>
>> > second question, if i have a statement like this:
>> >
>> > lsp a-b
>> > admin-group exclude [gold silver]
>> >
>> > does that mean, if an interface has either gold OR silver an LSP will
>> not
>> > choose the path or is it an AND?
>> >
>> The overall cli rule is if you specify multiple arguments of the same
>> character it's OR and it's AND among arguments of different character.
>> For example:
>>
>> admin-group {
>> exclude [ group-name1 OR group-name2 ];
>> AND
>> include-all [ group-names ];
>> AND
>> include-any [ group-names ];
>>
>>
>> adam
>>
>>
>>
>> Adam Vitkovsky
>> IP Engineer
>>
>> T:  0333 006 5936
>> E:  adam.vitkov...@gamma.co.uk
>> W:  www.gamma.co.uk
>>
>> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
>> of this email are confidential to the ordinary user of the email address to
>> which it was addressed. This email is not intended to create any legal
>> relationship. No one else may place any reliance upon it, or copy or
>> forward all or any of it in any form (unless otherwise notified). If you
>> receive this email in error, please accept our apologies, we would be
>> obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or
>> email postmas...@gamma.co.uk
>>
>> Gamma Telecom Limited, a company incorporated in England and Wales, with
>> limited liability, with registered number 04340834, and whose registered
>> office is at 5 Fleet Place London EC4M 7RD and whose principal place of
>> business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>>
>>
>>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MC-LAG error on MX-104

[Brijesh Patel]

Hello All,

I am trying to setup MC-LAG between tow MX104 .For the same status of ICCP
is up but interface MC-AE state is "Current State Machine's State: *mcae
config exchange error*"

Below is snap of

manager@MX1# *run show interfaces mc-ae*
 Member Link  : ae1
* Current State Machine's State: mcae config exchange error*
 Local Status : active
 Local State  : down
 Peer Status  : Unknown
 Peer State   : down
 Logical Interface: ae1.0
 Topology Type: bridge
 Local State  : up
 Peer State   : Unknown
 Peer Ip/MCP/State: 10.8.0.2 ae0.0 up

manager@MX1#* run show iccp detail*

Redundancy Group Information for peer 10.8.0.2
  TCP Connection   : Established
  Liveliness Detection : Up
  Redundancy Group ID  Status
1   Up

Client Application: l2ald_iccpd_client
  Redundancy Group IDs Joined: 1

Client Application: lacpd
  Redundancy Group IDs Joined: 1

Any one has idea what could be reason for *mcae config exchange error*
and *peer
status is down.*

Many Thanks,

Brijesh Patel
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MC-LAG error on MX-104

[Marcelio Webster]

Hi!


Send us the configurations
Tks

2015-12-11 10:39 GMT-02:00 Brijesh Patel :

> Hello All,
>
> I am trying to setup MC-LAG between tow MX104 .For the same status of ICCP
> is up but interface MC-AE state is "Current State Machine's State: *mcae
> config exchange error*"
>
> Below is snap of
>
> manager@MX1# *run show interfaces mc-ae*
>  Member Link  : ae1
> * Current State Machine's State: mcae config exchange error*
>  Local Status : active
>  Local State  : down
>  Peer Status  : Unknown
>  Peer State   : down
>  Logical Interface: ae1.0
>  Topology Type: bridge
>  Local State  : up
>  Peer State   : Unknown
>  Peer Ip/MCP/State: 10.8.0.2 ae0.0 up
>
> manager@MX1#* run show iccp detail*
>
> Redundancy Group Information for peer 10.8.0.2
>   TCP Connection   : Established
>   Liveliness Detection : Up
>   Redundancy Group ID  Status
> 1   Up
>
> Client Application: l2ald_iccpd_client
>   Redundancy Group IDs Joined: 1
>
> Client Application: lacpd
>   Redundancy Group IDs Joined: 1
>
> Any one has idea what could be reason for *mcae config exchange error*
> and *peer
> status is down.*
>
> Many Thanks,
>
> Brijesh Patel
> ___
> 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 NMS support of Junos VLAN MIBs

[Chuck Anderson]

On Fri, Dec 11, 2015 at 03:26:24PM +, Phil Mayers wrote:
> On 11/12/15 15:11, Ross Vandegrift wrote:
> 
> >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).
> 
> >On Junos, I got sick of all this and switched to netconf.
> 
> +1 (though Junoscript, in my case)
> 
> ssh admin@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.

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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs

[Ross Vandegrift]

On 12/09/2015 11:31 AM, Chuck Anderson wrote:
> 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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs

[Phil Mayers]

On 11/12/15 15:11, Ross Vandegrift wrote:


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).



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


+1 (though Junoscript, in my case)

ssh admin@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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MPLS admin groups implementation

[tim tiriche]

Hi,

I have an existing MPLS network of 3 regions

ASIA US and EUROPE

I don't want LSP's within US to be established via ASIA or EUROPE and vice
versa.

I want to create an admin group call it: GOLD and apply an exclude on all
US LSP's.

the problem is this will cause LSP to bounce.  since i have my config in
apply groups this change will affect all lsp's.  i want to know is this
traffic impacting if i have link protection in place?

is there a graceful way to do this?

second question, if i have a statement like this:

lsp a-b
admin-group exclude [gold silver]

does that mean, if an interface has either gold OR silver an LSP will not
choose the path or is it an AND?

Sincerely,
-Tim
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MC-LAG error on MX-104

[Alberto Santos]

Hi,

I've seem this before, usually it happens when the active and standby are
config with the same chassis-id 0 or 1 and/or the standby MX is also
configured with active mode.

cheers,


Alberto

On 11 December 2015 at 17:49, Marcelio Webster 
wrote:

> Hi!
>
>
> Send us the configurations
> Tks
>
> 2015-12-11 10:39 GMT-02:00 Brijesh Patel :
>
> > Hello All,
> >
> > I am trying to setup MC-LAG between tow MX104 .For the same status of
> ICCP
> > is up but interface MC-AE state is "Current State Machine's State: *mcae
> > config exchange error*"
> >
> > Below is snap of
> >
> > manager@MX1# *run show interfaces mc-ae*
> >  Member Link  : ae1
> > * Current State Machine's State: mcae config exchange error*
> >  Local Status : active
> >  Local State  : down
> >  Peer Status  : Unknown
> >  Peer State   : down
> >  Logical Interface: ae1.0
> >  Topology Type: bridge
> >  Local State  : up
> >  Peer State   : Unknown
> >  Peer Ip/MCP/State: 10.8.0.2 ae0.0 up
> >
> > manager@MX1#* run show iccp detail*
> >
> > Redundancy Group Information for peer 10.8.0.2
> >   TCP Connection   : Established
> >   Liveliness Detection : Up
> >   Redundancy Group ID  Status
> > 1   Up
> >
> > Client Application: l2ald_iccpd_client
> >   Redundancy Group IDs Joined: 1
> >
> > Client Application: lacpd
> >   Redundancy Group IDs Joined: 1
> >
> > Any one has idea what could be reason for *mcae config exchange error*
> > and *peer
> > status is down.*
> >
> > Many Thanks,
> >
> > Brijesh Patel
> > ___
> > 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Firwall Counter IPv6 : MIB

[david.roy]

Actually it works. My filter was not in interface-specific mode.

David


De : ROY David DTSI/DERS
Envoyé : jeudi 10 décembre 2015 18:45
À : Nitzan Tzelniker
Cc : juniper-nsp@puck.nether.net
Objet : RE : [j-nsp] Firwall Counter IPv6 : MIB

Does anybody has a setup with FWF MIB counters for IPv6 that work in recent 
release?

Appreciate your help.

BR
David

 Message d'origine 
De : ROY David DTSI/DERS
Date :08/12/2015 16:18 (GMT+01:00)
À : Nitzan Tzelniker
Cc : juniper-nsp@puck.nether.net
Objet : RE: [j-nsp] Firwall Counter IPv6 : MIB

Thank you. In 12.3 it doesn't work.

Does your interface is a dual stack interface ?

David


De : Nitzan Tzelniker [mailto:nitzan.tzelni...@gmail.com]
Envoyé : mardi 8 décembre 2015 15:54
À : ROY David DTSI/DERS
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Firwall Counter IPv6 : MIB

Hi David,

It works for me on MX80 running 11.4R8.4

snmpwalk -c X -v2c 1.1.1.1 
.1.3.6.1.4.1.2636.3.5.2.1.5.28.118.54.45.105.110.98.111.117.110.100.45.102.105.108.116.101.114.45.97.101.48.46.49.48.48.48.45.105.23.105.112.118.54.95.116.114.97.102.102.105.99.45.97.101.48.46.49.48.48.48.45.105.2
SNMPv2-SMI::enterprises.2636.3.5.2.1.5.28.118.54.45.105.110.98.111.117.110.100.45.102.105.108.116.101.114.45.97.101.48.46.49.48.48.48.45.105.23.105.112.118.54.95.116.114.97.102.102.105.99.45.97.101.48.46.49.48.48.48.45.105.2
 = Counter64: 73496724892304

snmpwalk -c X -v2c 1.1.1.1 
.1.3.6.1.4.1.2636.3.5.2.1.5.28.118.54.45.105.110.98.111.117.110.100.45.102.105.108.116.101.114.45.97.101.48.46.49.48.48.48.45.105.23.105.112.118.54.95.116.114.97.102.102.105.99.45.97.101.48.46.49.48.48.48.45.105.2
SNMPv2-SMI::enterprises.2636.3.5.2.1.5.28.118.54.45.105.110.98.111.117.110.100.45.102.105.108.116.101.114.45.97.101.48.46.49.48.48.48.45.105.23.105.112.118.54.95.116.114.97.102.102.105.99.45.97.101.48.46.49.48.48.48.45.105.2
 = Counter64: 73496724892304

Thanks

Nitzan


On Tue, Dec 8, 2015 at 9:33 AM, 
> wrote:
Hello All

We tried to retrieve IPv6 Firewall Filter counters within the jnxFirewalls MIB. 
It works well for IPv4 for a long time but we are not able to do the same for 
v6. OID are there but their value are all to 0.

Did anyone experience the same issue ? Is there a workaround - or a specific 
config / MIB ?

Please note that all cli counters work well.

Thanks
David


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs

[Dale Shaw]

Hi Chuck,

On Sat, Dec 12, 2015 at 4:16 AM, Chuck Anderson  wrote:
>
> Here are some commercial NMS products that we've looked at that we
> would like to get working with our Juniper gear:
>
[...]
> 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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp