from:"david.roy"

Re: [j-nsp] SNMP very slow on MX10003

2020-05-25 Thread david.roy

You hit sometimes high response time ( > 14 secs) to collect stats of AE's 
units. Could you correlate this timestamp with significant changes on the 
router of routing events  ? 


-Message d'origine-
De : Leon Kramer [mailto:leonkra...@gmail.com] 
Envoyé : lundi 25 mai 2020 18:42
À : ROY David DTSI/DERS; juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] SNMP very slow on MX10003

> show snmp stats-response-statistics

Average response time statistics:
StatsStatsAverage
Type ResponsesResponse
  Time (ms)
ifd(non ae)  15311162 5.60
ifd(ae)  482105   34.68
ifl(non ae)  5930128  5.96
ifl(ae)  74751690 8.80
firewall 66199433 10.87

Bucket statistics:
Bucket   Stats
Type(ms) Responses
0 - 10   117512092
11 - 50  36891316
51 - 100 3645978
101 - 2001647536
201 - 5001330240
501 - 1000   889495
1001 - 2000  707479
2001 - 5000  40989
More than 5001   9393

Bad responses:
ResponseRequestStats  Key
Time   Type
(ms)(UTC)
14048.002020-04-30 02:26:36ifl(ae)713
13649.322020-05-06 16:50:12ifl(ae)1319
13649.032020-05-06 16:50:12ifl(ae)1320
13648.822020-05-06 16:50:12ifl(ae)1321
13648.592020-05-06 16:50:12ifl(ae)1322
13648.382020-05-06 16:50:12ifl(ae)1323
13647.942020-05-06 16:50:12ifl(ae)1324
13647.722020-05-06 16:50:12ifl(ae)1325
12174.382020-05-19 07:08:22ifl(ae)1517
12145.672020-05-06 16:53:38ifl(ae)3743
12145.422020-05-06 16:53:38ifl(ae)3744
12145.082020-05-06 16:53:38ifl(ae)3745
12144.832020-05-06 16:53:38ifl(ae)3786
12144.522020-05-06 16:53:38ifl(ae)3787
12144.272020-05-06 16:53:38ifl(ae)3788
12144.052020-05-06 16:53:38ifl(ae)3789
12143.772020-05-06 16:53:38ifl(ae)3790
12143.492020-05-06 16:53:38ifl(ae)3791
12143.222020-05-06 16:53:38ifl(ae)3792
12143.002020-05-06 16:53:38ifl(ae)3793

Am Mo., 25. Mai 2020 um 18:32 Uhr schrieb :
>
> Hello
>
> Could you issue this command & share the output : show snmp 
> stats-response-statistics
>
> Otherwise, we use telemetry to collect, among other things, interface stats.
>
> David
>
>
> -Message d'origine-
> De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
> Leon Kramer
> Envoyé : lundi 25 mai 2020 18:26
> À : juniper-nsp@puck.nether.net
> Objet : [j-nsp] SNMP very slow on MX10003
>
> Hello,
>
> we meter approximately 500 logical subinterface counters (e.g. ae0.95,
> ae0.96, etc) of our Juniper MX10003. While this works it is also too
> slow as we fetch the data every 60 seconds.
>
> snmpbulkwalks of IF-MIB::ifHCInOctets and IF-MIB::ifHCOutOctets take
> anything from 1 to 180 seconds.
>
> The time it takes increases noticeably as more subinterfaces are configured.
>
> I know Juniper is not known for fast SNMP queries, but is there
> anything you can do to increase performance? 500 interfaces should
> really not be too much for a fairly new router imho.
> We already have some interface filters in place, but apparently they
> are not sufficient.
>
> If you think that SNMP is too slow, what alternative can you recommend
> for fetching interface counters?
>
> Thank you for your help.
>
>
> Kind Regards
> Leon Kramer
>
>
> > show version
> Model: mx10003
> Junos: 18.4R2-S3
>
>
> > show configuration snmp
> interface [ fxp0.0 ];
> filter-interfaces {
> interfaces {
> "fe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> "xe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> "ge-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> "et-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> }
> all-internal-interfaces;
> }
> filter-duplicates;
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> routing-instance-access;
> ___
> 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 
> con

Re: [j-nsp] SNMP very slow on MX10003

2020-05-25 Thread david.roy

Hello 

Could you issue this command & share the output : show snmp 
stats-response-statistics 

Otherwise, we use telemetry to collect, among other things, interface stats. 

David


-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Leon Kramer
Envoyé : lundi 25 mai 2020 18:26
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] SNMP very slow on MX10003

Hello,

we meter approximately 500 logical subinterface counters (e.g. ae0.95,
ae0.96, etc) of our Juniper MX10003. While this works it is also too
slow as we fetch the data every 60 seconds.

snmpbulkwalks of IF-MIB::ifHCInOctets and IF-MIB::ifHCOutOctets take
anything from 1 to 180 seconds.

The time it takes increases noticeably as more subinterfaces are configured.

I know Juniper is not known for fast SNMP queries, but is there
anything you can do to increase performance? 500 interfaces should
really not be too much for a fairly new router imho.
We already have some interface filters in place, but apparently they
are not sufficient.

If you think that SNMP is too slow, what alternative can you recommend
for fetching interface counters?

Thank you for your help.


Kind Regards
Leon Kramer


> show version
Model: mx10003
Junos: 18.4R2-S3


> show configuration snmp
interface [ fxp0.0 ];
filter-interfaces {
interfaces {
"fe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
"xe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
"ge-[0-9]/[0-9]/[0-9]+\.[0-9]+";
"et-[0-9]/[0-9]/[0-9]+\.[0-9]+";
}
all-internal-interfaces;
}
filter-duplicates;
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
routing-instance-access;
___
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] BGP PIC for inet6

2017-11-21 Thread david.roy

Hello

For ipv6

set routing-options rib inet6.0 protect core

For ipv4 

set routing-options protect core



David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 28 57 66
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)


-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de Jay 
Ford
Envoyé : mardi 21 novembre 2017 22:07
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] BGP PIC for inet6

There is Juniper documentation acknowledging the use case of BGP PIC for inet & 
inet6 unicast, but I can't find a way to enable it for inet6 at Junos 16.2R2.8. 
 Pointers to how to do so would be cool, but confirmation that it isn't 
supported (yet) would also be appreciated.


Jay Ford, Network Engineering, University of Iowa 
___
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] JunOS Telemetry

2017-04-11 Thread david.roy

Actually, not sure your release supports it. Indeed Junos Telemetry Interface 
was introduced in Junos OS Release 15.1F3. not sure R branch supports it


-Message d'origine-
De : Shaffi Khan [mailto:shaf...@interxion.com] 
Envoyé : mardi 11 avril 2017 17:27
À : ROY David DTSI/DERS; juniper-nsp@puck.nether.net
Objet : RE: [j-nsp] JunOS Telemetry

Yes, I did try "restart SDN-Telemetry immediately", but there was no effect.

Unfortunately  I'm not able to try a different version at this point in time.

-Original Message-
From: david@orange.com [mailto:david@orange.com] 
Sent: 11 April 2017 3:41 PM
To: Shaffi Khan ; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] JunOS Telemetry

Strange. It works for me. Maybe a bug or a limitation with your version ? 

Did you try to force SDN-telemetry restart ?

-Message d'origine-
De : Shaffi Khan [mailto:shaf...@interxion.com] Envoyé : mardi 11 avril 2017 
15:57 À : ROY David DTSI/DERS; juniper-nsp@puck.nether.net Objet : RE: [j-nsp] 
JunOS Telemetry

Hmm, I'm not seeing any sensors there

start shell pfe network fpc2


RMPC platform (1200Mhz QorIQ P2020 processor, 3584MB memory, 512KB flash)

NGMPC2(MX-testlab-re0 vty)# show agent sensors
 ID  Name
 --  

Total number of SENSOR = 0


I've just seen this on the documentation page:  "Junos Telemetry Interface was 
introduced in Junos OS Release 15.1F3 on MX Series routers"
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/junos-telemetry-interface-configuring.html

I wonder if it is because I'm running 15.1R4?  It's odd that the telemetry 
commands are available though

-Original Message-
From: david@orange.com [mailto:david@orange.com]
Sent: 11 April 2017 2:37 PM
To: Shaffi Khan ; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] JunOS Telemetry

Ok. 

Could you check at PFE level if sensors are well instanced ? 

start shell pfe network fpcX
show agent sensors

ex. 
show agent sensors

 Jvision ID  Name
 --  
   13222432  sensor-13 5000(300)
   13222433  sensor-12 5000(4902)
   13222434  sensor-11 5000(1348)
   13222439  sensor-14 5000(843)
   13222443  sensor-18 0(0)
   13222464  sensor-23 5000(300)
   13222465  sensor-22 5000(4001)
   13222466  sensor-21 5000(1348)
   13222471  sensor-24 5000(843)
   13222475  sensor-28 0(0)
  129585707  __default_fabric_sensor__  5000(3972)

Total number of jvision SENSORs = 11


-Message d'origine-
De : Shaffi Khan [mailto:shaf...@interxion.com] Envoyé : mardi 11 avril 2017 
15:35 À : ROY David DTSI/DERS; juniper-nsp@puck.nether.net Objet : RE: [j-nsp] 
JunOS Telemetry

Hi David

It seems to be running:

show system processes extensive | match agentd
20980 root1  200   717M  5584K select  0   0:05   0.00% agentd
20997 root1  240   720M  4468K select  3   0:00   0.00% stats-agentd

Polling is a large number because the value is measured in nano seconds:

{master}[edit services analytics sensor test-sensor] testlab@MXtestlab# set 
polling-interval ?
Possible completions:
 Define sensor polling interval in nano secs (nanoseconds)


So I'm polling every 0.1 seconds.

Simarly, reporting-rate under export-profile is measured in milliseconds, so 
I'm reporting every second.

 

-Original Message-
From: david@orange.com [mailto:david@orange.com]
Sent: 11 April 2017 2:24 PM
To: Shaffi Khan ; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] JunOS Telemetry

Hello

Does agent is running ?

show system processes extensive | match agentd
26812 root  3  200   735M 13136K nanslp  1   0:15   0.00% agentd

You could try to restart process :

restart SDN-Telemetry immediately

I see your polling interval is very high David


-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Shaffi Khan Envoyé : mardi 11 avril 2017 15:05 À : juniper-nsp@puck.nether.net 
Objet : [j-nsp] JunOS Telemetry

I've just started investigating using the Juniper telemetry interface for 
analytics on MX routers, but I'm having some problems getting it running.

I'm using the Juniper Open NTI collector, which is up and running (default 
config, no changes made whatsoever), however it never receives any data, as 
confirmed by a tcpdump on the box.

My setup is thus:

testlab@MXtestlab # run show version
Hostname: MXtestlab
Model: mx240
Junos: 15.1R4-S2.1

sensor test-sensor {
server-name open-nti;
export-name test-telemetry;
polling-interval 1;
resource /junos/system/linecard/interface/;
}
streaming-server open-nti {
remote-address 10.100.0.127;
remote-port 5;
}
export-profile test-telemetry {
local-address 10.100.0.96;
local-port 30010;
reporting-rate 1000;
format gpb;
transport

Re: [j-nsp] JunOS Telemetry

2017-04-11 Thread david.roy

Strange. It works for me. Maybe a bug or a limitation with your version ? 

Did you try to force SDN-telemetry restart ?

-Message d'origine-
De : Shaffi Khan [mailto:shaf...@interxion.com] 
Envoyé : mardi 11 avril 2017 15:57
À : ROY David DTSI/DERS; juniper-nsp@puck.nether.net
Objet : RE: [j-nsp] JunOS Telemetry

Hmm, I'm not seeing any sensors there

start shell pfe network fpc2


RMPC platform (1200Mhz QorIQ P2020 processor, 3584MB memory, 512KB flash)

NGMPC2(MX-testlab-re0 vty)# show agent sensors
 ID  Name
 --  

Total number of SENSOR = 0


I've just seen this on the documentation page:  "Junos Telemetry Interface was 
introduced in Junos OS Release 15.1F3 on MX Series routers"
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/junos-telemetry-interface-configuring.html

I wonder if it is because I'm running 15.1R4?  It's odd that the telemetry 
commands are available though

-Original Message-
From: david@orange.com [mailto:david@orange.com] 
Sent: 11 April 2017 2:37 PM
To: Shaffi Khan ; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] JunOS Telemetry

Ok. 

Could you check at PFE level if sensors are well instanced ? 

start shell pfe network fpcX
show agent sensors

ex. 
show agent sensors

 Jvision ID  Name
 --  
   13222432  sensor-13 5000(300)
   13222433  sensor-12 5000(4902)
   13222434  sensor-11 5000(1348)
   13222439  sensor-14 5000(843)
   13222443  sensor-18 0(0)
   13222464  sensor-23 5000(300)
   13222465  sensor-22 5000(4001)
   13222466  sensor-21 5000(1348)
   13222471  sensor-24 5000(843)
   13222475  sensor-28 0(0)
  129585707  __default_fabric_sensor__  5000(3972)

Total number of jvision SENSORs = 11


-Message d'origine-
De : Shaffi Khan [mailto:shaf...@interxion.com] Envoyé : mardi 11 avril 2017 
15:35 À : ROY David DTSI/DERS; juniper-nsp@puck.nether.net Objet : RE: [j-nsp] 
JunOS Telemetry

Hi David

It seems to be running:

show system processes extensive | match agentd
20980 root1  200   717M  5584K select  0   0:05   0.00% agentd
20997 root1  240   720M  4468K select  3   0:00   0.00% stats-agentd

Polling is a large number because the value is measured in nano seconds:

{master}[edit services analytics sensor test-sensor] testlab@MXtestlab# set 
polling-interval ?
Possible completions:
 Define sensor polling interval in nano secs (nanoseconds)


So I'm polling every 0.1 seconds.

Simarly, reporting-rate under export-profile is measured in milliseconds, so 
I'm reporting every second.

 

-Original Message-
From: david@orange.com [mailto:david@orange.com]
Sent: 11 April 2017 2:24 PM
To: Shaffi Khan ; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] JunOS Telemetry

Hello

Does agent is running ?

show system processes extensive | match agentd
26812 root  3  200   735M 13136K nanslp  1   0:15   0.00% agentd

You could try to restart process :

restart SDN-Telemetry immediately

I see your polling interval is very high David


-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Shaffi Khan Envoyé : mardi 11 avril 2017 15:05 À : juniper-nsp@puck.nether.net 
Objet : [j-nsp] JunOS Telemetry

I've just started investigating using the Juniper telemetry interface for 
analytics on MX routers, but I'm having some problems getting it running.

I'm using the Juniper Open NTI collector, which is up and running (default 
config, no changes made whatsoever), however it never receives any data, as 
confirmed by a tcpdump on the box.

My setup is thus:

testlab@MXtestlab # run show version
Hostname: MXtestlab
Model: mx240
Junos: 15.1R4-S2.1

sensor test-sensor {
server-name open-nti;
export-name test-telemetry;
polling-interval 1;
resource /junos/system/linecard/interface/;
}
streaming-server open-nti {
remote-address 10.100.0.127;
remote-port 5;
}
export-profile test-telemetry {
local-address 10.100.0.96;
local-port 30010;
reporting-rate 1000;
format gpb;
transport udp;
}

The problem I see is that "show agent sensors" never reports a sensor:
testlab@MXtestlab# run show agent sensors

{master}[edit services analytics]

I've read over the Juniper docs and can't see anything obvious that I'm 
missing, however I'm sure it is something simple.

If anyone has any idea's I'd love to hear them!

TIA

___
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 privileg

Re: [j-nsp] JunOS Telemetry

2017-04-11 Thread david.roy

I've tried you config on Junos 16.1R4 and it works for me. 

David


-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Shaffi Khan
Envoyé : mardi 11 avril 2017 15:05
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] JunOS Telemetry

I've just started investigating using the Juniper telemetry interface for 
analytics on MX routers, but I'm having some problems getting it running.

I'm using the Juniper Open NTI collector, which is up and running (default 
config, no changes made whatsoever), however it never receives any data, as 
confirmed by a tcpdump on the box.

My setup is thus:

testlab@MXtestlab # run show version
Hostname: MXtestlab
Model: mx240
Junos: 15.1R4-S2.1

sensor test-sensor {
server-name open-nti;
export-name test-telemetry;
polling-interval 1;
resource /junos/system/linecard/interface/;
}
streaming-server open-nti {
remote-address 10.100.0.127;
remote-port 5;
}
export-profile test-telemetry {
local-address 10.100.0.96;
local-port 30010;
reporting-rate 1000;
format gpb;
transport udp;
}

The problem I see is that "show agent sensors" never reports a sensor:
testlab@MXtestlab# run show agent sensors

{master}[edit services analytics]

I've read over the Juniper docs and can't see anything obvious that I'm 
missing, however I'm sure it is something simple.

If anyone has any idea's I'd love to hear them!

TIA

___
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] JunOS Telemetry

2017-04-11 Thread david.roy

Ok. 

Could you check at PFE level if sensors are well instanced ? 

start shell pfe network fpcX
show agent sensors

ex. 
show agent sensors

 Jvision ID  Name
 --  
   13222432  sensor-13 5000(300)
   13222433  sensor-12 5000(4902)
   13222434  sensor-11 5000(1348)
   13222439  sensor-14 5000(843)
   13222443  sensor-18 0(0)
   13222464  sensor-23 5000(300)
   13222465  sensor-22 5000(4001)
   13222466  sensor-21 5000(1348)
   13222471  sensor-24 5000(843)
   13222475  sensor-28 0(0)
  129585707  __default_fabric_sensor__  5000(3972)

Total number of jvision SENSORs = 11


-Message d'origine-
De : Shaffi Khan [mailto:shaf...@interxion.com] 
Envoyé : mardi 11 avril 2017 15:35
À : ROY David DTSI/DERS; juniper-nsp@puck.nether.net
Objet : RE: [j-nsp] JunOS Telemetry

Hi David

It seems to be running:

show system processes extensive | match agentd
20980 root1  200   717M  5584K select  0   0:05   0.00% agentd
20997 root1  240   720M  4468K select  3   0:00   0.00% stats-agentd

Polling is a large number because the value is measured in nano seconds:

{master}[edit services analytics sensor test-sensor] testlab@MXtestlab# set 
polling-interval ?
Possible completions:
 Define sensor polling interval in nano secs (nanoseconds)


So I'm polling every 0.1 seconds.

Simarly, reporting-rate under export-profile is measured in milliseconds, so 
I'm reporting every second.

 

-Original Message-
From: david@orange.com [mailto:david@orange.com]
Sent: 11 April 2017 2:24 PM
To: Shaffi Khan ; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] JunOS Telemetry

Hello

Does agent is running ?

show system processes extensive | match agentd
26812 root  3  200   735M 13136K nanslp  1   0:15   0.00% agentd

You could try to restart process :

restart SDN-Telemetry immediately

I see your polling interval is very high David


-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Shaffi Khan Envoyé : mardi 11 avril 2017 15:05 À : juniper-nsp@puck.nether.net 
Objet : [j-nsp] JunOS Telemetry

I've just started investigating using the Juniper telemetry interface for 
analytics on MX routers, but I'm having some problems getting it running.

I'm using the Juniper Open NTI collector, which is up and running (default 
config, no changes made whatsoever), however it never receives any data, as 
confirmed by a tcpdump on the box.

My setup is thus:

testlab@MXtestlab # run show version
Hostname: MXtestlab
Model: mx240
Junos: 15.1R4-S2.1

sensor test-sensor {
server-name open-nti;
export-name test-telemetry;
polling-interval 1;
resource /junos/system/linecard/interface/;
}
streaming-server open-nti {
remote-address 10.100.0.127;
remote-port 5;
}
export-profile test-telemetry {
local-address 10.100.0.96;
local-port 30010;
reporting-rate 1000;
format gpb;
transport udp;
}

The problem I see is that "show agent sensors" never reports a sensor:
testlab@MXtestlab# run show agent sensors

{master}[edit services analytics]

I've read over the Juniper docs and can't see anything obvious that I'm 
missing, however I'm sure it is something simple.

If anyone has any idea's I'd love to hear them!

TIA

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


_

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

Re: [j-nsp] JunOS Telemetry

2017-04-11 Thread david.roy

Hello

Does agent is running ?

show system processes extensive | match agentd
26812 root  3  200   735M 13136K nanslp  1   0:15   0.00% agentd

You could try to restart process :

restart SDN-Telemetry immediately

I see your polling interval is very high
David


-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Shaffi Khan
Envoyé : mardi 11 avril 2017 15:05
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] JunOS Telemetry

I've just started investigating using the Juniper telemetry interface for 
analytics on MX routers, but I'm having some problems getting it running.

I'm using the Juniper Open NTI collector, which is up and running (default 
config, no changes made whatsoever), however it never receives any data, as 
confirmed by a tcpdump on the box.

My setup is thus:

testlab@MXtestlab # run show version
Hostname: MXtestlab
Model: mx240
Junos: 15.1R4-S2.1

sensor test-sensor {
server-name open-nti;
export-name test-telemetry;
polling-interval 1;
resource /junos/system/linecard/interface/;
}
streaming-server open-nti {
remote-address 10.100.0.127;
remote-port 5;
}
export-profile test-telemetry {
local-address 10.100.0.96;
local-port 30010;
reporting-rate 1000;
format gpb;
transport udp;
}

The problem I see is that "show agent sensors" never reports a sensor:
testlab@MXtestlab# run show agent sensors

{master}[edit services analytics]

I've read over the Juniper docs and can't see anything obvious that I'm 
missing, however I'm sure it is something simple.

If anyone has any idea's I'd love to hear them!

TIA

___
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] FPC Error Debug

2016-11-09 Thread david.roy


Hello
Usually it means either : 

-  transient HW error (Parity error - a reboot can fix it)
- HW failure of LUCHIP memory >> RMA 



David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 28 57 66
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)





-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Brendan Mannella
Envoyé : mercredi 9 novembre 2016 16:39
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] FPC Error Debug

Does anyone have any insight into what these errors mean?

Nov  9 09:34:52  re0.edge2 fpc1 LUCHIP(3) PPE_9 Errors lmem data error
0x0743

Nov  9 09:34:52  re0.edge2 fpc1 PPE PPE HW Fault Trap:  Count 12, PC bf,
  0x00bf:  init_context_lmem

Nov  9 09:34:54  re0.edge2 fpc1 LUCHIP(3) PPE_9 Errors lmem data error
0x0743

Nov  9 09:34:54  re0.edge2 fpc1 PPE PPE HW Fault Trap:  Count 20, PC bf,
  0x00bf:  init_context_lmem

Nov  9 09:34:58  re0.edge2 fpc1 LUCHIP(3) PPE_9 Errors lmem data error
0x0743

Nov  9 09:34:58  re0.edge2 fpc1 PPE PPE HW Fault Trap:  Count 26, PC bf,
  0x00bf:  init_context_lmem

Nov  9 09:35:02  re0.edge2 fpc1 LUCHIP(3) PPE_9 Errors lmem data error
0x0743

Nov  9 09:35:02  re0.edge2 fpc1 PPE PPE HW Fault Trap:  Count 31, PC bf,
  0x00bf:  init_context_lmem

Nov  9 09:35:06  re0.edge2 fpc1 LUCHIP(3) PPE_9 Errors lmem data error
0x0743

Nov  9 09:35:06  re0.edge2 fpc1 PPE PPE HW Fault Trap:  Count 34, PC bf,
  0x00bf:  init_context_lmem

Nov  9 09:35:10  re0.edge2 fpc1 LUCHIP(3) PPE_9 Errors lmem data error
0x0743

Nov  9 09:35:10  re0.edge2 fpc1 PPE PPE HW Fault Trap:  Count 38, PC bf,
  0x00bf:  init_context_lmem

Nov  9 09:35:14  re0.edge2 fpc1 LUCHIP(3) PPE_9 Errors lmem data error
0x0743

Nov  9 09:35:14  re0.edge2 fpc1 PPE PPE HW Fault Trap:  Count 42, PC bf,
  0x00bf:  init_context_lmem

Nov  9 09:35:22  re0.edge2 fpc1 LMEM errors require LUCHIP(3) PPE 9 Zone 14 
disable.

Nov  9 09:35:32  re0.edge2 fpc1 LUCHIP(3):LMEM errors require LUCHIP(3) PPE
9 Zone 14 disable.

Nov  9 09:35:32  re0.edge2 fpc1 TNPC CM received unknown trigger (type Queue, 
id 1)

Nov  9 09:35:32  re0.edge2 alarmd[3048]: Alarm set: FPC color=RED, 
class=CHASSIS, reason=FPC 1 Major Errors

Nov  9 09:35:32  re0.edge2 craftd[1632]:  Major alarm set, FPC 1 Major Errors 
___
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] force-64bit

2016-06-01 Thread david.roy

Hello

We use it since  Junos 14.2. No bug encountered related to this feature.

It depends on your sizing. As Tim said check the RPD memory - Just never reach 
the 80%.

David

 Tim Hoffman via juniper-nsp a écrit 

64bit RPD is newer, and by nature will have more bugs - so don't run this
unless you need it. Check this with "show task memory" - this will show
what you have used of the RPD accessible memory. As Phil notes, you'd need
significant RIB scale (which does exist in larger networks) to require
this...

Enabling this will cause RPD to restart as you kill one process and start
another.

Tim

On Wed, Jun 1, 2016 at 9:22 AM, Phil Rosenthal  wrote:

> I’ll ask the obvious question — do you actually have a ‘need’ for this?
>
> Even on systems with many peers, 5+ full tables, and a full IGP mesh, I
> haven’t seen rpd much over 1GB of ram in use.  64bit rpd would only be
> beneficial if you have a need for a rpd process using more than 4GB of ram.
>
> Is this a theoretical use case, or is there an actual need?
>
> Best Regards,
> -Phil Rosenthal
> > On Jun 1, 2016, at 3:58 AM, Theo Voss  wrote:
> >
> > Hi,
> >
> > has anybody enabled „system processes force-64bit“ on 64bit Junos? Have
> you done this during daily ops or during a maintenance window? According to
> Juniper documentation [1] rpd must not be restarted to enable 64-bit mode:
> „You need not restart the routing protocol process (rpd) to use the 64-bit
> mode.“...
> >
> > Thanks in advance for your comments! ;-)
> >
> >
> https://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/routing-edit-system-processes.html
> >
> >
> > Cheers,
> > Theo Voss
> > ___
> > 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
>

--
Tim Hoffman | Twitter, Inc.
1355 Market St. | San Francisco, CA | 94103
___
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] what’s the story behind MPC5E

2016-05-20 Thread david.roy

This is the same design for MPC6e PFE and I didn't see any issue with this 
design. I also didn't see any specific issue due to this design in POC where we 
stressed the PFE. XL ressources are just shared. For Inter XM forwarding, the 
shared XL is not used but the fabric links is used. 


-Message d'origine-
De : Adam Vitkovsky [mailto:adam.vitkov...@gamma.co.uk] 
Envoyé : vendredi 20 mai 2016 17:00
À : ROY David DTSI/DERS; juniper-nsp@puck.nether.net
Objet : RE: what’s the story behind MPC5E

> Of david@orange.com
> Sent: Friday, May 20, 2016 3:24 PM
>
> MPC5e has one PFE (260Gpbs) made of 2 XM chip, 1 XL and 1 XQ (only for 
> Q
> mode)
>
OMG, now that's bummer like it has two PFEs but they share a common XL :) Now 
that's got to be the stupidest TRIO design I've seen so far.
I'd love to see how arbitration as well as backpressure is done in this case 
since now two independent arbiters(since arbiter is in XM) are going to fight 
over XL resources.


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.



_

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] what’s the story behind MPC5E

2016-05-20 Thread david.roy

Erratum: it's a 240 Gbps PFE 

-Message d'origine-
De : ROY David DTSI/DERS 
Envoyé : vendredi 20 mai 2016 16:24
À : 'Adam Vitkovsky'; juniper-nsp@puck.nether.net
Objet : RE: what’s the story behind MPC5E

MPC5e has one PFE (260Gpbs) made of 2 XM chip, 1 XL and 1 XQ (only for Q mode) 

-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Adam Vitkovsky Envoyé : vendredi 20 mai 2016 16:20 À : 
juniper-nsp@puck.nether.net Objet : [j-nsp] what’s the story behind MPC5E

Hi folks,

Would anyone know what’s the story behind MPC5E (which I think uses one PFE) 
with Gen 2 TRIO (XM, XL)?
Forwarding capability of up to 130 Gbps per Packet Forwarding Engine.
Up to 240 Gbps of full-duplex traffic.

- Since 240 is not 2x130 it begs the question what components are the 
bottleneck then?


And to add to the confusion the MPC4E which uses two PFEs with Gen 1.5 TRIO 
(XM, 2xLU) is rated Up to 260 Gbps of full-duplex traffic.

- Would have thought that Gen 2 TRIO would have better performance or better 
connectivity to fabric ?


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

_

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] what’s the story behind MPC5E

2016-05-20 Thread david.roy

MPC5e has one PFE (260Gpbs) made of 2 XM chip, 1 XL and 1 XQ (only for Q mode) 

-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Adam Vitkovsky
Envoyé : vendredi 20 mai 2016 16:20
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] what’s the story behind MPC5E

Hi folks,

Would anyone know what’s the story behind MPC5E (which I think uses one PFE) 
with Gen 2 TRIO (XM, XL)?
Forwarding capability of up to 130 Gbps per Packet Forwarding Engine.
Up to 240 Gbps of full-duplex traffic.

- Since 240 is not 2x130 it begs the question what components are the 
bottleneck then?


And to add to the confusion the MPC4E which uses two PFEs with Gen 1.5 TRIO 
(XM, 2xLU) is rated Up to 260 Gbps of full-duplex traffic.

- Would have thought that Gen 2 TRIO would have better performance or better 
connectivity to fabric ?


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

_

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] Segment Routing ( SPRING )

2016-03-04 Thread david.roy

Yes this exactly the same thing. Just naming. Cisco uses more SR and Juniper 
SPRING :) 

But IETF says SPRING 

-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Aaron
Envoyé : vendredi 4 mars 2016 16:17
À : 'Timur Maryin'; 'Jackson, William'
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Segment Routing ( SPRING )

These topics are new to me...

I understand that SR is Segment Routing and SPRING is Source Packet Routing in 
Networking... so I want to know is "SR" and "SPRING" the exact same thing ?  or 
are there some differences in SR and SPRING ?

Aaron

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Timur Maryin
Sent: Friday, March 4, 2016 5:55 AM
To: Jackson, William 
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Segment Routing ( SPRING )

Hi Jackson,

It appears in 15.1F5:

http://www.juniper.net/techpubs/en_US/junos15.1/information-products/topic-c
ollections/release-notes/15.1F5/topic-104251.html#jd0e2762

On 15-Jan-16 13:33, Jackson, William wrote:
> Hi
>
>
>
> have been reading cisco documentation on this topic.
>
> I was wondering if anyone knew the JUNOS status for this was?
>
>
>
> Cant find much on the website etc etc.

___
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

_

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] Segment Routing ( SPRING )

2016-03-04 Thread david.roy

Yes it's me :) 

-Message d'origine-
De : Aaron [mailto:aar...@gvtc.com] 
Envoyé : vendredi 4 mars 2016 16:23
À : ROY David DTSI/DERS; 'Timur Maryin'; 'Jackson, William'
Cc : juniper-nsp@puck.nether.net
Objet : RE: [j-nsp] Segment Routing ( SPRING )

Thanks David, I should've read this email before asking my previous question.

I just got this book yesterday.  Page 92 says SPRING is aka SR.  Thanks

Also I see in preface page xxii that one of the four key contributors to
this book was a guy named David Royis this you?   :)

Aaron

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
david@orange.com
Sent: Friday, March 4, 2016 7:41 AM
To: Timur Maryin ; Jackson, William 

Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Segment Routing ( SPRING )

FYI : The MPLS in the SDN Era book covers SPRING implementation for both Cisco 
and Juniper routers. 

David

-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Timur Maryin Envoyé : vendredi 4 mars 2016 12:55 À : Jackson, William Cc :
juniper-nsp@puck.nether.net Objet : Re: [j-nsp] Segment Routing ( SPRING )

Hi Jackson,

It appears in 15.1F5:

http://www.juniper.net/techpubs/en_US/junos15.1/information-products/topic-c
ollections/release-notes/15.1F5/topic-104251.html#jd0e2762

On 15-Jan-16 13:33, Jackson, William wrote:
> Hi
>
>
>
> have been reading cisco documentation on this topic.
>
> I was wondering if anyone knew the JUNOS status for this was?
>
>
>
> Cant find much on the website etc etc.

___
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

_

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] Segment Routing ( SPRING )

2016-03-04 Thread david.roy

FYI : The MPLS in the SDN Era book covers SPRING implementation for both Cisco 
and Juniper routers. 

David

-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Timur Maryin
Envoyé : vendredi 4 mars 2016 12:55
À : Jackson, William
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Segment Routing ( SPRING )

Hi Jackson,

It appears in 15.1F5:

http://www.juniper.net/techpubs/en_US/junos15.1/information-products/topic-collections/release-notes/15.1F5/topic-104251.html#jd0e2762

On 15-Jan-16 13:33, Jackson, William wrote:
> Hi
>
>
>
> have been reading cisco documentation on this topic.
>
> I was wondering if anyone knew the JUNOS status for this was?
>
>
>
> Cant find much on the website etc etc.

___
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] Firwall Counter IPv6 : MIB

2015-12-11 Thread 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

Thanks

Nitzan

On Tue, Dec 8, 2015 at 9:33 AM,
mailto:david@orange.com>> 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

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

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

2015-12-10 Thread david.roy

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

Hi David,

It works for me on MX80 running 11.4R8.4

Thanks

Nitzan

On Tue, Dec 8, 2015 at 9:33 AM,
mailto:david@orange.com>> wrote:
Hello All

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

___
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,
France Telecom - 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 authorization.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this
message was 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] Firwall Counter IPv6 : MIB

2015-12-08 Thread david.roy

Thank you. In 12.3 it doesn’t work.

Does your interface is a dual stack interface ?

David

Hi David,

It works for me on MX80 running 11.4R8.4

Thanks

Nitzan

On Tue, Dec 8, 2015 at 9:33 AM,
mailto:david@orange.com>> wrote:
Hello All

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

___
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] Firwall Counter IPv6 : MIB

2015-12-07 Thread david.roy

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

Re: [j-nsp] exception traffic types for Juniper routers

2015-09-29 Thread david.roy

Hello

Check show pfe statistics exceptions

David




 Message d'origine 
De : Martin T
Date :29/09/2015 21:40 (GMT+01:00)
À : juniper-nsp
Objet : [j-nsp] exception traffic types for Juniper routers

Hi,

as I understand, there are several different exception traffic types:

1) unicast traffic addressed to router itselt. For example telnet, SSH
or SNMP traffic. I guess it is technically correct to say that
"incoming frames which have one of the router interfaces MAC addresses
as a destination MAC address are exception traffic"?

2) IPv4 packets with options set. IPv6 packets with extension headers?

3) Packets requiring the generation of an ICMP error message. For
example if IPv4/IPv6 packet comes in with TTL/hop-limit 1, then router
has to send ICMP error message to destination.


Are there any other exception traffic types? When is broadcast and
multicast traffic handled as exception traffic?


thanks,
Martin
___
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] L2VPN between Juniper MX and SmartEdge

2015-07-10 Thread david.roy

Here the config part of SE :



l2vpn profile L2PROFILE 
  peer X.X.X.X
log-pw-up-down
remote-encap ethernet

 l2vpn

 xc-group collect
   xc lg GEC3  vlan-id  1668 vc-id 1668 profile L2PROFILE



David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 28 57 66
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)


-Original Message-
From: Olivier Benghozi [mailto:olivier.bengh...@wifirst.fr] 
Sent: jeudi 9 juillet 2015 23:26
To: ROY David DTSI/DERS
Cc: redback-...@puck.nether.net; juniper-nsp
Subject: Re: [j-nsp] L2VPN between Juniper MX and SmartEdge

Hi David,

any suggestions about the SE config part ?
I tried both in dot1q and dot1q tunnel, on the port.


Olivier

> Le 9 juil. 2015 à 23:19, david@orange.com a écrit :
> 
> Hello
> 
> Here my config on MX which works with SE routers:
> 
> 
> xe-19/0/2 {
>   vlan-tagging;
>mtu 4488;
>encapsulation flexible-ethernet-services;
>   unit 1668 {
>encapsulation vlan-ccc;
>vlan-id 1668;
>input-vlan-map pop;
>output-vlan-map push;
>}
> l2circuit {
>neighbor X.X.X.X {
>interface xe-19/0/2. 1668{
>virtual-circuit-id 1668;
>encapsulation-type ethernet;
>}
>   }
> }
> 
> David Roy
> IP/MPLS NOC engineer - Orange France
> Ph. : +33 2 99 28 57 66
> Mob. : +33 6 85 52 22 13
> SkypeID : davidroy.35
> david@orange.com
>  
> JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)
> 
> 
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On 
> Behalf Of Olivier Benghozi
> Sent: jeudi 9 juillet 2015 22:07
> To: redback-...@puck.nether.net; juniper-nsp
> Subject: [j-nsp] L2VPN between Juniper MX and SmartEdge
> 
> Hi guys,
> 
> any clue about interoperability issue between Juniper (some MX in JunOS 
> 13.3R5, MPC cards) and Redback (SE600, SEOS 12.1.1.9, PPA3 20x1GE card) about 
> L2VPN pseudowire, Martini style (using LDP signaling and LDP LSP) ?
> 
> I'm trying to use such feature to forward a vlan between some equipments 
> plugged to those two routers; the tunnel is up, packets flow from the Redback 
> dot1q pvc to the stuff plugged behind the MX vlan-tagged unit (in family 
> vlan-ccc), but in the other direction, the SmartEdge keeps saying "packets 
> sent: 0" on the physical port...
> 
> 
> Thanks.
> Olivier
> 
> ___
> 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.
> 


_

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] L2VPN between Juniper MX and SmartEdge

2015-07-09 Thread david.roy

I don't remember... i will find back tomorrow and send you the config of SE part

 Message d'origine 
De : Olivier Benghozi
Date :09/07/2015 23:26 (GMT+01:00)
À : ROY David DTSI/DERS
Cc : redback-...@puck.nether.net, juniper-nsp
Objet : Re: [j-nsp] L2VPN between Juniper MX and SmartEdge

Hi David,

any suggestions about the SE config part ?
I tried both in dot1q and dot1q tunnel, on the port.


Olivier

> Le 9 juil. 2015 à 23:19, david@orange.com a écrit :
>
> Hello
>
> Here my config on MX which works with SE routers:
>
>
> xe-19/0/2 {
>   vlan-tagging;
>mtu 4488;
>encapsulation flexible-ethernet-services;
>unit 1668 {
>encapsulation vlan-ccc;
>vlan-id 1668;
>input-vlan-map pop;
>output-vlan-map push;
>}
> l2circuit {
>neighbor X.X.X.X {
>interface xe-19/0/2. 1668{
>virtual-circuit-id 1668;
>encapsulation-type ethernet;
>}
>}
> }
>
> David Roy
> IP/MPLS NOC engineer - Orange France
> Ph. : +33 2 99 28 57 66
> Mob. : +33 6 85 52 22 13
> SkypeID : davidroy.35
> david@orange.com
>
> JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)
>
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
> Olivier Benghozi
> Sent: jeudi 9 juillet 2015 22:07
> To: redback-...@puck.nether.net; juniper-nsp
> Subject: [j-nsp] L2VPN between Juniper MX and SmartEdge
>
> Hi guys,
>
> any clue about interoperability issue between Juniper (some MX in JunOS 
> 13.3R5, MPC cards) and Redback (SE600, SEOS 12.1.1.9, PPA3 20x1GE card) about 
> L2VPN pseudowire, Martini style (using LDP signaling and LDP LSP) ?
>
> I'm trying to use such feature to forward a vlan between some equipments 
> plugged to those two routers; the tunnel is up, packets flow from the Redback 
> dot1q pvc to the stuff plugged behind the MX vlan-tagged unit (in family 
> vlan-ccc), but in the other direction, the SmartEdge keeps saying "packets 
> sent: 0" on the physical port...
>
>
> Thanks.
> Olivier
>
> ___
> 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.
>


_

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] L2VPN between Juniper MX and SmartEdge

2015-07-09 Thread david.roy

Hello

Here my config on MX which works with SE routers:


xe-19/0/2 {
   vlan-tagging;
mtu 4488;
encapsulation flexible-ethernet-services;
unit 1668 {
encapsulation vlan-ccc;
vlan-id 1668;
input-vlan-map pop;
output-vlan-map push;
}
l2circuit {
neighbor X.X.X.X {
interface xe-19/0/2. 1668{
virtual-circuit-id 1668;
encapsulation-type ethernet;
}
}
}

David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 28 57 66
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Olivier Benghozi
Sent: jeudi 9 juillet 2015 22:07
To: redback-...@puck.nether.net; juniper-nsp
Subject: [j-nsp] L2VPN between Juniper MX and SmartEdge

Hi guys,

any clue about interoperability issue between Juniper (some MX in JunOS 13.3R5, 
MPC cards) and Redback (SE600, SEOS 12.1.1.9, PPA3 20x1GE card) about L2VPN 
pseudowire, Martini style (using LDP signaling and LDP LSP) ?

I'm trying to use such feature to forward a vlan between some equipments 
plugged to those two routers; the tunnel is up, packets flow from the Redback 
dot1q pvc to the stuff plugged behind the MX vlan-tagged unit (in family 
vlan-ccc), but in the other direction, the SmartEdge keeps saying "packets 
sent: 0" on the physical port...


Thanks.
Olivier

___
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] IP-FRR (LFA) -restrict the computation

2015-06-16 Thread david.roy

Hello

Did you have a look at this: 
http://www.juniper.net/documentation/en_US/junos14.1/topics/topic-map/example-configuring-backup-selection-path-for-is-is-protocol.html

BR
David



David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 28 57 66
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Adam Vitkovsky
Sent: mardi 16 juin 2015 16:03
To: juniper-nsp
Subject: [j-nsp] IP-FRR (LFA) -restrict the computation

Hi Folks,

Is there a way to dictate which prefixes should ISIS compute an LFA backup for 
please?
I can limit the installation of computed backup paths via the route policy.
And the LFA is computed only for prefixes with /32 mask.
But is there a way to actually choose which prefixes I want the LFA to be 
computed for?

Thanks.

adam
___
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] Multi Core on JUNOS?

2015-05-08 Thread david.roy

Alu uses 10 cores.

Br

 Message d'origine 
De : Colton Conor
Date :08/05/2015 20:09 (GMT+01:00)
À : Mark Tinka
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Multi Core on JUNOS?

So are the other vendors, Brocade, Cisco and ALU all single core in
software as well, or is this just a Juniper thing? Whats the point of
having all these cores on the RE's if you unable to use be one of them?

On Fri, May 8, 2015 at 1:05 PM, Mark Tinka  wrote:

>
>
> On 8/May/15 16:12, Colton Conor wrote:
> > Has juniper implemented the use of multicore processors in their software
> > yet? From what I read I heard it was coming, but I am not sure in what
> > release. I can't seem to find any information about it on Juniper's
> > website? What is the current status of multi core threads in Junos?
> >
> > For example, the MX80 has two cores. Are both of them in use?
>
> The code is starting to get optimized in the later years of Junos 14,
> but much of this will begin to surface in Junos 15 and 16.
>
> Knowing how things go, it's likely going to take some time before the
> whole thing is structured properly. So expect real improvements to
> happen gradually.
>
> This is quite painful because it means constant upgrades if you want the
> support, and all the hassle that comes with that.
>
> Mark.
>
___
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] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

2014-08-22 Thread david.roy

I've planned to test this precious enhancement in the 14.2 beta program :) 

David


 
David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)



-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Darren O'Connor
Sent: vendredi 22 août 2014 17:27
To: Scott Granados; Euan Galloway
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding 
convergence

I've been hearing for years that quicker convergence is coming 'in a later 
release' 

Thanks
Darren
http://www.mellowd.co.uk/ccie



> From: sc...@granados-llc.net
> To: euang+juniper-...@lists.eusahues.co.uk
> Date: Fri, 22 Aug 2014 10:40:29 -0400
> CC: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers,   slow
> forwarding convergence
> 
> I can confirm with inline flow sampling enabled and even with the code to fix 
> the PR convergence is still slower.  I hear there's a better fix being 
> released in later code 14.2 if memory serves but I'm not sure.
> 
> On Aug 22, 2014, at 5:13 AM, Euan Galloway 
>  wrote:
> 
> > On Thu, Aug 21, 2014 at 03:38:32PM -0400, Clarke Morledge wrote:
> > 
> >> I did upgrade to 13.3R3 to try to resolve PR963060, but I am still 
> >> seeing enough traffic loss that it makes me skeptical as to whether 
> >> I have really hit this PR, if the issue has not really been resolved, or 
> >> if something
> >> else is going on.   I still think Junos should converge faster.
> > 
> > Did you try disabling inline jflow (and sampling if used), which 
> > would answer the is it/isn't it on that PR (and someone/something to shout 
> > at).
> > 
> > --
> > Euan Galloway
> > ___
> > 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

_

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] Verifying Juniper ECMP

2014-04-15 Thread david.roy

Hello

Since 13.2 Jsim is now available also for MPC (at PFE level) but it is more 
complex and quite different as Jsim for DPC. I have to write a new blog about 
that... :) 

David


 
David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Olivier Benghozi
Sent: mardi 15 avril 2014 11:51
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Verifying Juniper ECMP

Hi John,

as usual with Juniper it's ridiculously overcomplicated, David Roy wrote a fine 
article about that, at least for MX with DPC:
http://www.junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html


Olivier

Le 15 avr. 2014 à 04:01, John Neiberger  a écrit :
> I know that ECMP is, by default, based on a hash of source and 
> destination IP address, and I know that we can see the available paths 
> by doing "show route forwarding-table destination ", but is 
> there a way to determine which path a particular flow is using?
> 
> For those of you familiar with Cisco, I'm looking for an equivalent to 
> "show cef exact-route".

___
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] MX ping - ToS overrided

2014-01-22 Thread david.roy

I meant host-outbound-traffic ;) 

 
David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #143)



-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
david@orange.com
Envoyé : mercredi 22 janvier 2014 15:39
À : 'Arash Alizadeh'; juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] MX ping - ToS overrided

Not the case with 12.3R4 for me :

ping 8.8.8.8 tos 96 

15:37:03.950763 Out IP (tos 0x60, ttl  64, id 64980, offset 0, flags [none], 
proto: ICMP (1), length: 84) X.X.X.X > 8.8.8.8: ICMP echo request, id 34658, 
seq 3, length 64

Do you have host-inbound-traffic knob or Output FWF on lo0 that rewrites 
control plane ? 


 
David Roy
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #143)



-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Arash Alizadeh Envoyé : mercredi 22 janvier 2014 15:22 À : 
juniper-nsp@puck.nether.net Objet : [j-nsp] MX ping - ToS overrided

Hi,
 
I'm experiencing issues when initating ToS ping from MX devices. The specified 
ToS argument just seems to be overrided to dec 192 when leaving the interface.
 
I verified this with the traffic monitor on the egress interface:
 
user@node> ping 8.8.8.8 tos 96
64 bytes from 8.8.8.8: icmp_seq=0 ttl=246 time=15.675 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=246 time=15.385 ms
 
user@node> monitor traffic interface xe-0/0/0.0 extensive matching icmp PFE 
proto 2 (ipv4): (tos 0xc0, ttl 255, id 16332, offset 0, flags [none], proto: 
ICMP (1), length: 84) x.x.x.x > 8.8.8.8: ICMP echo reply, id 47826, seq 0, 
length 64
14:06:58.721197 Out 
 
I've tried this on 11.4R6.6 and 12.3R4-S2 (ppc and 64-bit) boxes with the same 
result.
 
Did anyone else ran into this issue? 
Any input is appriciated. 
 
Regards,
Arash
  
___
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

_

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] MX ping - ToS overrided

2014-01-22 Thread david.roy

Not the case with 12.3R4 for me :

ping 8.8.8.8 tos 96 

15:37:03.950763 Out IP (tos 0x60, ttl  64, id 64980, offset 0, flags [none], 
proto: ICMP (1), length: 84) X.X.X.X > 8.8.8.8: ICMP echo request, id 34658, 
seq 3, length 64

Do you have host-inbound-traffic knob or Output FWF on lo0 that rewrites 
control plane ? 


 
David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #143)



-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Arash Alizadeh
Envoyé : mercredi 22 janvier 2014 15:22
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] MX ping - ToS overrided

Hi,
 
I'm experiencing issues when initating ToS ping from MX devices. The specified 
ToS argument just seems to be overrided to dec 192 when leaving the interface.
 
I verified this with the traffic monitor on the egress interface:
 
user@node> ping 8.8.8.8 tos 96
64 bytes from 8.8.8.8: icmp_seq=0 ttl=246 time=15.675 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=246 time=15.385 ms
 
user@node> monitor traffic interface xe-0/0/0.0 extensive matching icmp PFE 
proto 2 (ipv4): (tos 0xc0, ttl 255, id 16332, offset 0, flags [none], proto: 
ICMP (1), length: 84) x.x.x.x > 8.8.8.8: ICMP echo reply, id 47826, seq 0, 
length 64
14:06:58.721197 Out 
 
I've tried this on 11.4R6.6 and 12.3R4-S2 (ppc and 64-bit) boxes with the same 
result.
 
Did anyone else ran into this issue? 
Any input is appriciated. 
 
Regards,
Arash
  
___
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] smartctl for junos

2014-01-08 Thread david.roy

Hi

Smartd tool can be used via the hidden cli command : 

request chassis routing-engine hard-disk-test

regards
David

 
David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
//
JNCIE-SP #703 
JNCIE-ENT #305
JNCIP-SEC

-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
snort bsd
Envoyé : mercredi 8 janvier 2014 00:20
À : juniper-nsp
Objet : [j-nsp] smartctl for junos

hi all:

there is smartd running on junos, but i am not able to find "smartctl" utility 
for smartd.

thanks
___
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] Ex stack of 4 switchs stops routing, switching, ...

2014-01-06 Thread david.roy

Oups ! a little mistake. 

Sorry for the spam. 



-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
david@orange.com
Envoyé : lundi 6 janvier 2014 11:21
À : 'Maarten van der Hoek'; 'Laurent CARON'
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Ex stack of 4 switchs stops routing, switching, ...

Je vais refaire un mail. 
David


 
David Roy
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
//
JNCIE-SP #703
JNCIE-ENT #305
JNCIP-SEC

-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Maarten van der Hoek Envoyé : lundi 6 janvier 2014 10:15 À : 'Laurent CARON'
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Ex stack of 4 switchs stops routing, switching, ...

Hi Laurent,

Had almost exactly the same this morning when I came in the office... 
All network traffic was still flowing, however DHCP packet's didn't (for 
machine's which were not in the office during the weekendlaptop's / pda's  
/ etceverything 'new' to the switch)

Message log showed:

Jan  6 10:16:37  swex2200vc /kernel: rt_pfe_veto: Memory over consumed. Op 2, 
rtsm_id 47, msg type 2 Jan  6 10:16:41  swex2200vc /kernel: kmem type session 
using 58778K, exceeding limit 40960K Jan  6 10:16:42  swex2200vc /kernel: 
rt_pfe_veto: Memory over consumed. Op 1, rtsm_id 47, msg type 2 Jan  6 10:16:57 
 swex2200vc last message repeated 3 times

Stack consists of 2x EX2200-48T running Junos 13.2X50-D15.3

What ls your Junos ?
Found anything yet ?

Brgds,

Maarten


-Oorspronkelijk bericht-
Van: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Namens Laurent 
CARON
Verzonden: zondag 5 januari 2014 17:52
Aan: juniper-nsp@puck.nether.net
Onderwerp: [j-nsp] Ex stack of 4 switchs stops routing, switching, ...

Hi,

Running a chassis composed of 2 EX4200 and 2 EX4500.

One of the RE did reboot (by itself) on Dec 26th.

I managed to collect some logs:

Dec 25 12:21:41  swa eventd: sendto: Cannot allocate memory Dec 25 12:21:44 swa 
/kernel: rt_pfe_veto: Memory over consumed. Op 1, rtsm_id 47, msg type 2 Dec 25 
12:21:59  swa last message repeated 3 times Dec 25 12:22:49  swa last message 
repeated 10 times Dec 25 12:22:54  swa /kernel: rt_pfe_veto: Memory over 
consumed. Op 1, rtsm_id 47, msg type 2 Dec 25 12:22:59  swa /kernel:
rt_pfe_veto: Memory over consumed. Op 1, rtsm_id 47, msg type 2 
Jan  5 12:50:37  swa /kernel: rt_pfe_veto: Memory over consumed. Op 8, rtsm_id 
0, msg type 10 Jan  5 12:50:38  swa rpd[20440]: RPD_KRT_Q_RETRIES:
Route Update: No buffer space available Jan  5 12:50:42  swa /kernel:
rt_pfe_veto: Memory over consumed. Op 8, rtsm_id ...
Jan  5 15:09:17  swa /kernel: rt_pfe_veto: Memory over consumed. Op 8, rtsm_id 
0, msg type 10 Jan  5 15:09:17  swa /kernel: rt_pfe_veto: Possible slowest 
client is pfem2. States processed - 117754359. States to be processed - 27 Jan  
5 15:09:22  swa /kernel: rt_pfe_veto: Memory over consumed. Op 8, rtsm_id 0, 
msg type 10 Jan  5 15:09:22  swa /kernel:
rt_pfe_veto: Possible slowest client is pfem2. States processed - 117754359.
States to be processed - 27 Jan  5 15:09:26  swa rpd[20440]:
RPD_KRT_Q_RETRIES: Route Update: No buffer space available

Today the switch would only continue switching for a while but not route 
packets anymore.

The arp table was empty.

Restarting routing process only rendered the switch unresponsive so I had to 
reboot it via console port.

This switch only handles 3 dozens of LACP aggregates, a few of them are 10Gb, 
the others Gb, a few SVI, a few pure L2 VLANs, 100 firewall rules, no dhcp 
snooping. I use OSPF on ~30 interfaces

The only "fancy" features I use are:
Graceful switchover
RSTP
LLDP
LLDP-Med
NSB
Ethernet storm control

Do any of you have a clue about it ?

Thanks

Laurent

___
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

_

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 autho

Re: [j-nsp] Ex stack of 4 switchs stops routing, switching, ...

2014-01-06 Thread david.roy

Je vais refaire un mail. 
David


 
David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
//
JNCIE-SP #703 
JNCIE-ENT #305
JNCIP-SEC

-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Maarten van der Hoek
Envoyé : lundi 6 janvier 2014 10:15
À : 'Laurent CARON'
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Ex stack of 4 switchs stops routing, switching, ...

Hi Laurent,

Had almost exactly the same this morning when I came in the office... 
All network traffic was still flowing, however DHCP packet's didn't (for
machine's which were not in the office during the weekendlaptop's /
pda's  / etceverything 'new' to the switch)

Message log showed:

Jan  6 10:16:37  swex2200vc /kernel: rt_pfe_veto: Memory over consumed. Op
2, rtsm_id 47, msg type 2
Jan  6 10:16:41  swex2200vc /kernel: kmem type session using 58778K,
exceeding limit 40960K
Jan  6 10:16:42  swex2200vc /kernel: rt_pfe_veto: Memory over consumed. Op
1, rtsm_id 47, msg type 2
Jan  6 10:16:57  swex2200vc last message repeated 3 times

Stack consists of 2x EX2200-48T running Junos 13.2X50-D15.3

What ls your Junos ?
Found anything yet ?

Brgds,

Maarten


-Oorspronkelijk bericht-
Van: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Namens Laurent
CARON
Verzonden: zondag 5 januari 2014 17:52
Aan: juniper-nsp@puck.nether.net
Onderwerp: [j-nsp] Ex stack of 4 switchs stops routing, switching, ...

Hi,

Running a chassis composed of 2 EX4200 and 2 EX4500.

One of the RE did reboot (by itself) on Dec 26th.

I managed to collect some logs:

Dec 25 12:21:41  swa eventd: sendto: Cannot allocate memory Dec 25 12:21:44
swa /kernel: rt_pfe_veto: Memory over consumed. Op 1, rtsm_id 47, msg type 2
Dec 25 12:21:59  swa last message repeated 3 times Dec 25 12:22:49  swa last
message repeated 10 times Dec 25 12:22:54  swa /kernel: rt_pfe_veto: Memory
over consumed. Op 1, rtsm_id 47, msg type 2 Dec 25 12:22:59  swa /kernel:
rt_pfe_veto: Memory over consumed. Op 1, rtsm_id 47, msg type 2 
Jan  5 12:50:37  swa /kernel: rt_pfe_veto: Memory over consumed. Op 8,
rtsm_id 0, msg type 10 Jan  5 12:50:38  swa rpd[20440]: RPD_KRT_Q_RETRIES:
Route Update: No buffer space available Jan  5 12:50:42  swa /kernel:
rt_pfe_veto: Memory over consumed. Op 8, rtsm_id ...
Jan  5 15:09:17  swa /kernel: rt_pfe_veto: Memory over consumed. Op 8,
rtsm_id 0, msg type 10 Jan  5 15:09:17  swa /kernel: rt_pfe_veto: Possible
slowest client is pfem2. States processed - 117754359. States to be
processed - 27 Jan  5 15:09:22  swa /kernel: rt_pfe_veto: Memory over
consumed. Op 8, rtsm_id 0, msg type 10 Jan  5 15:09:22  swa /kernel:
rt_pfe_veto: Possible slowest client is pfem2. States processed - 117754359.
States to be processed - 27 Jan  5 15:09:26  swa rpd[20440]:
RPD_KRT_Q_RETRIES: Route Update: No buffer space available

Today the switch would only continue switching for a while but not route
packets anymore.

The arp table was empty.

Restarting routing process only rendered the switch unresponsive so I had to
reboot it via console port.

This switch only handles 3 dozens of LACP aggregates, a few of them are
10Gb, the others Gb, a few SVI, a few pure L2 VLANs, 100 firewall rules, no
dhcp snooping. I use OSPF on ~30 interfaces

The only "fancy" features I use are:
Graceful switchover
RSTP
LLDP
LLDP-Med
NSB
Ethernet storm control

Do any of you have a clue about it ?

Thanks

Laurent

___
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

_

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

Re: [j-nsp] command monitor

2013-10-08 Thread david.roy


set interfaces x unit 0 family inet sampling input|output 

Regards
David

 
David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
//
JNCIE-SP #703 
JNCIE-ENT #305
JNCIP-SEC


-Message d'origine-
De : Rodrigo Augusto [mailto:rodr...@1telecom.com.br] 
Envoyé : mardi 8 octobre 2013 20:37
À : ROY David DTF/DERX; juniper-nsp@puck.nether.net
Objet : Re: command monitor

that¹s all right we want this! Thanks for all!!! And if I want put this on 
only one interface?! What I have to do ?
Rodrigo Augusto
Gestor de T.I. Grupo Connectoway
http://www.connectoway.com.br  
http://www.1telecom.com.br 
* rodr...@connectoway.com.br
( (81) 3366-7376
( (81) 8184-3646
( INOC-DBA 52965*100





On 08/10/13 15:29, "david@orange.com"  wrote:

>Hi
>
>You can activate soft sampling (netflow) and select file as output. 
>(but no stat will be done) you can just view sampled flows in file
>
>
>EX. 
>
>Config
>
>show configuration forwarding-options
>sampling {
>input {
>rate 4000;
>run-length 0;
>max-packets-per-second 4000;
>}
>family inet {
>output {
>flow-inactive-timeout 15;
>flow-active-timeout 60;
>file filename sampled_v5 files 5 size 1m;
>}
>}
>}
>
>And monitoring : 
>
>file show /var/tmp/sampled_v5
>or monitor start /var/tmp/sampled_v5
>
># Sep 27 18:34:49
>#  Dest Src  Dest   Src Proto  TOS   Pkt  IntfIP
> TCP
>#  addraddr  port  port  len   num  frag
>flags
>  10.1.1..8   10.1.1..94   161 3498517  0x0   205 65543   0x4000   0x0
>  10.1.1..64  10.1.1..218  2816 0 1  0x056   329   0x0   0x0
>  10.1.1..98   10.1.1..94   443 14043 6  0x0   209 65543   0x4000
>0x18
>  10.1.1..64  10.1.1..218  2816 0 1  0x056   329   0x0   0x0
>  10.1.1..64  10.1.1..218  2816 0 1  0x056   329   0x0   0x0
>
> 
>David Roy
>IP/MPLS NOC engineer - Orange France
>Ph. : +33 2 99 87 64 72
>Mob. : +33 6 85 52 22 13
>SkypeID : davidroy.35
>david@orange.com
> 
>//
>JNCIE-SP #703
>JNCIE-ENT #305
>JNCIP-SEC
>
>
>-Message d'origine-
>De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la 
>part de Rodrigo Augusto Envoyé : mardi 8 octobre 2013 19:22 À : 
>juniper-nsp@puck.nether.net Objet : [j-nsp] command monitor
>
>Hi folks!
> 
>Does anyone knows if junos have a command as equal linux iftop ?!
>Thanks!
>Rodrigo Augusto
>Gestor de T.I. Grupo Connectoway
>http://www.connectoway.com.br  
>http://www.1telecom.com.br 
>* rodr...@connectoway.com.br
>( (81) 3366-7376
>( (81) 8184-3646
>( INOC-DBA 52965*100
>
>
>
>
>
>___
>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.
>
>




_

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

Re: [j-nsp] command monitor

2013-10-08 Thread david.roy

Hi

You can activate soft sampling (netflow) and select file as output. (but no 
stat will be done) you can just view sampled flows in file


EX. 

Config 

show configuration forwarding-options
sampling {
input {
rate 4000;
run-length 0;
max-packets-per-second 4000;
}
family inet {
output {
flow-inactive-timeout 15;
flow-active-timeout 60;
file filename sampled_v5 files 5 size 1m;
}
}
}

And monitoring : 

file show /var/tmp/sampled_v5
or monitor start /var/tmp/sampled_v5

# Sep 27 18:34:49
#  Dest Src  Dest   Src Proto  TOS   Pkt  IntfIP   TCP
#  addraddr  port  port  len   num  frag flags
  10.1.1..8   10.1.1..94   161 3498517  0x0   205 65543   0x4000   0x0
  10.1.1..64  10.1.1..218  2816 0 1  0x056   329   0x0   0x0
  10.1.1..98   10.1.1..94   443 14043 6  0x0   209 65543   0x4000   0x18
  10.1.1..64  10.1.1..218  2816 0 1  0x056   329   0x0   0x0
  10.1.1..64  10.1.1..218  2816 0 1  0x056   329   0x0   0x0

 
David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
//
JNCIE-SP #703 
JNCIE-ENT #305
JNCIP-SEC


-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Rodrigo Augusto
Envoyé : mardi 8 octobre 2013 19:22
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] command monitor

Hi folks!
 
Does anyone knows if junos have a command as equal linux iftop ?!
Thanks!
Rodrigo Augusto
Gestor de T.I. Grupo Connectoway
http://www.connectoway.com.br  
http://www.1telecom.com.br 
* rodr...@connectoway.com.br
( (81) 3366-7376
( (81) 8184-3646
( INOC-DBA 52965*100





___
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] Output queue drops and temporal buffers

2013-10-01 Thread david.roy

Hi

We experienced unexpected drops with temporal buffer (which is a static buffer) 
and iCHIP based cards. It was in junos 11.4. Jtac had found an internal PR that 
matched our issue. 

Workaround was the using buffer-size in %. 

Which version and cards do you use? 

David

Envoyé de mon iPad

> Le 1 oct. 2013 à 21:13, "John Neiberger"  a écrit :
> 
> I've been troubleshooting an interesting problem off and on the past couple
> of days. We have a 1-gig link that is consistently running around 10%
> utilization, give or take a couple of percent, but we see periods where the
> egress WRED drops for queue 0 spike. It's bizarre because there is no
> corresponding increase in overall utilization. I don't know much about
> queueing on this platform (MX960), but I've been reading up on it today.
> Here is the config for that queue:
> 
> TRAFFIC-CLASS-1-SCHEDULER {
>transmit-rate percent 20;
>buffer-size temporal 50k;
>priority low;
>drop-profile-map loss-priority low protocol any drop-profile DROP-LOW;
>drop-profile-map loss-priority high protocol any drop-profile DROP-HIGH;
> 
> As I understand it, the formula to determine available buffer space is this:
> 
> bandwidth * transmit-rate percent * temporal buffer size
> 
> On a 1-gig link, I think that means that queue has a total buffer size of
> 1.25 MB. I'm guessing that means that we must be getting large-ish chunks
> of data big enough to come close to filling that queue but intermittent
> enough that the average rate doesn't go up noticeably.
> 
> My question regarding the config is this: if we are already setting the
> transmit rate percentage, why would we also configure a temporal
> allocation? Isn't a percentage of the available bandwidth sufficient? What
> does adding a temporal allocation buy us? Is the transmit rate percent just
> setting how often that queue is serviced, while the buffer-size configures
> the queue depth?
> 
> Thanks,
> John
> ___
> 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] MX960 Install Validation Checklist

2013-09-04 Thread david.roy

Hi 

Our default check list but that's for post upgrade not really for MX install ! 

show version invoke-on all-routing-engines
show system snapshot (on both RE)
show chassis alarms
show chassis routing-engine
show chassis fpc
show chassis hardware 
show chassis environment
show chassis power
show chassis fan
show chassis fabric summary
show chassis fabric summary
show chassis fabric plane
show chassis fabric fpcs
show system storage
show krt state
show task memory
show task memory history
show task jobs
show system processes summary
show route summary
show isis adjacency
show ldp neighbor
show ldp session
show pim neighbor 
show bgp summary 
show vrrp brief 
show interfaces queue | match "Physical|drop"
show interfaces statistics detail | match "Physical interface|drops|errors"
show pfe stat error
show system boot-messages 
show log messages | last 500
show log chassisd  | last 100

David

David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com

//
JNCIE-SP #703 
JNCIE-ENT #305
JNCIP-SEC

-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Mark Tinka
Envoyé : mercredi 4 septembre 2013 17:46
À : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] MX960 Install Validation Checklist

On Wednesday, September 04, 2013 05:32:34 PM Christopher Costa wrote:

> Curious if there's a  document (or feedback from personal
> experiences) on "best-practice" steps/commands to validate an MX960 
> installation.  For example:
> - power supplies functional
> - fta's functional
> - routing-engines up
> - file system
> - modular cards (SCBs/MPC's, etc)
> - pluggable optics recognized
> - etc

(run) show chassis hardware detail

Cheers,

Mark.

_

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] qfx3500

2013-09-03 Thread david.roy

Hello

Yes you can use qfx3500 as a standalone switch.

David

Le 3 sept. 2013 à 21:28, "Robert Hass"  a écrit :

> Hi
> I'm looking for 1U switch with minimum 48x10GE SFP+ and 2x40GE QSFP.
> I see than QFX3500 can do all what I need - can this switch work alone
> without rest elements of Q-Fabric ?
> 
> If someone already is using this switch can write something about stability
> and problems ?
> 
> Rob
> ___
> 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] Wierd problem with RE-based sampling on 12.3

2013-08-02 Thread david.roy

Hello

Did you try only input direction? I guess yes and i guess it works but just to 
be sure. I

Netflow v5 & 12.3 work fine for us on dpc but we use only input sampling.



David



Tom Eichhorn  a écrit :


Dear all,

I have a very curious problem with some box running
JunOS 12.3, DPC-based:

I have one interface towards some upstream provider and want to
generate cflow for in- and outbound direction and have the following
configuriation:

teichhorn@somerouter# show forwarding-options
sampling {
input {
rate 2048;
run-length 0;
max-packets-per-second 4096;
}
family inet {
output {
flow-active-timeout 60;
flow-server a.a.a.a {
port 9000;
autonomous-system-type origin;
source-address (ip lo0);
version 5;
}
}
}
}

teichhorn@somerouter# show interfaces xe-0/3/0
description "TRANSIT - XXX";
unit 0 {
family inet {
sampling {
input;
output;
}
address c.c.c.c;
}
family inet6 {
address a:b:c:d::1/128;
}
}

(It doesn't matter if I use family inet sampling or a firewall filter)

All the flows which are exported only contains the outbound packets,
but no inbound ones.

Has anyone seen that before or has a hint? I would like to open a case
the next days but like to hear your opinion before...

(And no, I can't simply put output sampling on the other interfaces,
since there is MPLS forwarding on them active...)

Thanks,
Tom
___
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] R: RE : multicast issue

2013-07-16 Thread david.roy

If you can't start/stop manually mcast streams you will never have stable 
counters and can't detect packet loss. What you could do is to monitor customer 
mcast rate per (S,G) with the same snmp counters but it requieres you have 
constant bit rate for your (S,G). We have also this kind of script in perl 
which detects rate falling of (S,G) and triggers alarms when a given threshold 
is reach. It works very well for mcast TV channels (But you don't have the 
number of packet loss)

Best regards

Envoyé de mon iPad

Le 16 juil. 2013 à 21:14, "dim0sal" 
mailto:dim0...@hotmail.com>> a écrit :

Hi roy
Good suggestions. Thanks.

Anyway we re not able to start monitoring mcast flows since we get by external 
sources.

We could perform the snmp get on the devices but since is not done in the same 
moment and routers are placed in different locations I expect the forwarded 
pkts will be different and the delta as well...

What do you think?


Inviato da Samsung Mobile



 Messaggio originale 
Da: david@orange.com
Data:
A: R S mailto:dim0...@hotmail.com>>,John Neiberger 
mailto:jneiber...@gmail.com>>
Cc: juniper-nsp@puck.nether.net
Oggetto: RE : [j-nsp] multicast issue


Hello,

We use mcast streams dedicated for multicast monitoring which are flooded to 
the entire network (some specific (S;G) ).  we are able to start / stop 
automatically these streams.
We developed a perl script which does :

While(1)
(

- Stop multicast "monitoring" streams
- Get via SNMP GET the forwarded packets for each (S;G) on every routers of the 
network (Multicast MIB gives per S;G forwarded packets
- Restart the streams
- Wait 1 hour
- Stop again streams
- Get again via SNMP GET the per (S;G) forwarded packets per routers
- compute the delta forwarded packet per node
- detect packet loss and alert via snmp trap / mail which nodes loss some 
packets
- Start the stream for 1 hour

)

Best reagrd

De : juniper-nsp 
[juniper-nsp-boun...@puck.nether.net]
 de la part de R S [dim0...@hotmail.com]
Date d'envoi : mardi 16 juillet 2013 18:55
À : John Neiberger
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] multicast issue

Hi John
it's not a problem of how/why the packet lose, my concern is how can we monitor 
the multicast traffic hence our NOC is able to see the problem before the 
customer...
It's multicast coming from financial markets.

Tks

From: jneiber...@gmail.com
Date: Tue, 16 Jul 2013 10:42:18 -0600
Subject: Re: [j-nsp] multicast issue
To: dim0...@hotmail.com
CC: juniper-nsp@puck.nether.net

What sort of multicast traffic is it? Is it a constant stream like voice or 
video or is it an intermittent feed like some sort of multicast messaging? If 
this is very low-rate traffic and intermittent, Juniper routers often drop the 
first packet because the multicast route has timed out of the forwarding table 
and it gets punted to the RE. If that is what is happening, there is a 
workaround. If you're losing traffic mid-stream, that's a different issue 
entirely.


John

On Tue, Jul 16, 2013 at 10:14 AM, R S 
mailto:dim0...@hotmail.com>> wrote:






Hi all



Just a

brainstorming and your possible help.



I manage a

network where multicast is the most important traffic and sometimes I get issue

by customer where they state that some packets are lost…





Does

anybody have an idea or can help me in understanding a possible solution in

monitoring traffic in real time manner, maybe with the use of some software or 
appliance or whatelse.



In my idea

I could monitor traffic on the source and on the destination, then with  a sort 
of parsing understand if it’s my

network loosing the packets or not…







Any idea ?

suggestion ?



tks





___

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

_

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

Re: [j-nsp] multicast issue

2013-07-16 Thread david.roy

Hello,

We use mcast streams dedicated for multicast monitoring which are flooded to 
the entire network (some specific (S;G) ).  we are able to start / stop 
automatically these streams. 
We developed a perl script which does :

While(1) 
(

- Stop multicast "monitoring" streams
- Get via SNMP GET the forwarded packets for each (S;G) on every routers of the 
network (Multicast MIB gives per S;G forwarded packets
- Restart the streams
- Wait 1 hour 
- Stop again streams
- Get again via SNMP GET the per (S;G) forwarded packets per routers
- compute the delta forwarded packet per node 
- detect packet loss and alert via snmp trap / mail which nodes loss some 
packets
- Start the stream for 1 hour

)

Best reagrd

De : juniper-nsp [juniper-nsp-boun...@puck.nether.net] de la part de R S 
[dim0...@hotmail.com]
Date d'envoi : mardi 16 juillet 2013 18:55
À : John Neiberger
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] multicast issue

Hi John
it's not a problem of how/why the packet lose, my concern is how can we monitor 
the multicast traffic hence our NOC is able to see the problem before the 
customer...
It's multicast coming from financial markets.

Tks

From: jneiber...@gmail.com
Date: Tue, 16 Jul 2013 10:42:18 -0600
Subject: Re: [j-nsp] multicast issue
To: dim0...@hotmail.com
CC: juniper-nsp@puck.nether.net

What sort of multicast traffic is it? Is it a constant stream like voice or 
video or is it an intermittent feed like some sort of multicast messaging? If 
this is very low-rate traffic and intermittent, Juniper routers often drop the 
first packet because the multicast route has timed out of the forwarding table 
and it gets punted to the RE. If that is what is happening, there is a 
workaround. If you're losing traffic mid-stream, that's a different issue 
entirely.


John

On Tue, Jul 16, 2013 at 10:14 AM, R S  wrote:






Hi all



Just a

brainstorming and your possible help.



I manage a

network where multicast is the most important traffic and sometimes I get issue

by customer where they state that some packets are lost…





Does

anybody have an idea or can help me in understanding a possible solution in

monitoring traffic in real time manner, maybe with the use of some software or 
appliance or whatelse.



In my idea

I could monitor traffic on the source and on the destination, then with  a sort 
of parsing understand if it’s my

network loosing the packets or not…







Any idea ?

suggestion ?



tks





___

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

_

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] Inline jflow AS Lookup Failures

2013-07-05 Thread david.roy

I tested RPKI on a beta 12.2 and found a major bug but now fixed. 12.3 works 
fine for us since 2 months. But, of course without nsr ;-)

David

Envoyé depuis mon Samsung Galaxy Ace d'Orange

Mark Tinka  a écrit :

On Monday, July 01, 2013 05:02:33 PM Mark Tinka wrote:

> The only reason I'd venture into 12.3 or 13 is if the
> hardware requires it.

On second thought, we want RPKI support, and that is 12.2
minimum.

Mark.

_

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] Inline jflow AS Lookup Failures

2013-07-01 Thread david.roy

Hi

12.3 runs on several mx960 with mpc4e cards since several months without any 
issue.

Note. We don't use NSR and we use a service release that includes some fix of 
bugs found during our qualification tests in lab.

For me 12.3 is a good release, but in our config.

Envoyé depuis mon Samsung Galaxy Ace d'Orange

Gabriel Blanchard  a écrit :

Just an FYI though, we run 12.3 on MX80s and that's been fine. Anything with 
dual RE seems to be the problem.

On 2013-07-01, at 10:24 AM, Drew Weaver 
mailto:drew.wea...@thenap.com>>
 wrote:

Has anyone else been brave enough to try 12.3 yet to see what the damage is? =)

From: Richard Hesse [mailto:richard.he...@weebly.com]
Sent: Friday, June 28, 2013 5:52 PM
To: Gabriel Blanchard
Cc: Drew Weaver; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Inline jflow AS Lookup Failures

Did you report the crash to Juniper? What was it related to?

-richard

On Fri, Jun 28, 2013 at 7:02 PM, Gabriel Blanchard 
mailto:g...@teksavvy.ca>> wrote:
I tried 12.3. Crashed within 24h

On 2013-06-28, at 2:59 PM, Drew Weaver 
mailto:drew.wea...@thenap.com>>
 wrote:

> How much of a disaster (vs 11.4) are we guessing that 12.3R3 is going to be?
>
> From: Richard Hesse 
> [mailto:richard.he...@weebly.com]
> Sent: Friday, June 28, 2013 2:58 PM
> To: Drew Weaver
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Inline jflow AS Lookup Failures
>
> It's fixed in JunOS 12.3R3 and 13.2R1. It's in PR#820988, but that isn't 
> ready for the public yet.
>
> -richard
>
> On Fri, Jun 28, 2013 at 5:08 PM, Richard Hesse 
> mailto:richard.he...@weebly.com>>>
>  wrote:
> It's totally useless right now. I have a support case open with Juniper on 
> this. I'll post back to the list if we make any headway.
>
> -richard
>
> On Fri, Jun 28, 2013 at 9:51 AM, Drew Weaver 
> mailto:drew.wea...@thenap.com>>>
>  wrote:
> Howdy,
>
> I am wondering if anyone has figured out any way to get inline jflow to send 
> proper dstas/srcas on routers with full tables?
>
> I'm seeing a lot of these incrementing (snipped output):
>
> show services accounting errors inline-jflow
>Route Record Lookup Failures: 5415, AS Lookup Failures: 15775477
> show services accounting errors inline-jflow
>Route Record Lookup Failures: 5415, AS Lookup Failures: 15776293
> What this ends up doing in practice is sending ff ff ff ff (or 4294967295) 
> for the ASN..
>
> Which ends up looking like:
>
> [root@d6 etc]# /usr/local/bin/nfdump -r /var/netflow/nc/nfcapd.current -s 
> dstas/bytes 'router ip 192.168.25.7 and out if 555' -qN
> 2013-06-27 22:23:02.827 52026.907 any  4294967295  996(20.3) 
> 2201(14.9)   420620(17.1)0   64   191
>
> In other words, totally useless.
>
> Any tips?
> ___
> 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

_

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] Alarm

2013-04-17 Thread david.roy

s/reload/reboot/g 

Sorry :-/ 

 
David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com
 
JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC

-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
david@orange.com
Envoyé : mercredi 17 avril 2013 14:32
À : 'Mohammad Khalil'; juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Alarm

Hi,

Try this 


start shell
su
Password: Enter root pwd 


Then :


> sysctl -a | grep bootdevs

I guess disk should be not present in the list. Then, 

> sysctl -w machdep.bootdevs="usb,compact-flash,disk,lan"


Then exit the shell mode and restart the RE

>  request system reload 


If you lose again the HD, I believe you should replace the RE. 

David



 
David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com
 
JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC
-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Mohammad Khalil
Envoyé : mercredi 17 avril 2013 13:00
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] Alarm

Hi
I am facing the below alarm
CR04> show system alarms
1 alarms currently active
Alarm time   Class  Description
2013-04-17 05:03:42 EEST Major  Host 0 hard-disk missing in Boot List

safezone@CR04> show version
Hostname: CR04
Model: mx240
JUNOS Base OS boot [10.0R3.10]
JUNOS Base OS Software Suite [10.0R3.10] JUNOS Kernel Software Suite 
[10.0R3.10] JUNOS Crypto Software Suite [10.0R3.10] JUNOS Packet Forwarding 
Engine Support (M/T Common) [10.0R3.10] JUNOS Packet Forwarding Engine Support 
(MX Common) [10.0R3.10] JUNOS Online Documentation [10.0R3.10] JUNOS Voice 
Services Container package [10.0R3.10] JUNOS Border Gateway Function package 
[10.0R3.10] JUNOS Services AACL Container package [10.0R3.10] JUNOS Services 
LL-PDF Container package [10.0R3.10] JUNOS Services Stateful Firewall 
[10.0R3.10] JUNOS AppId Services [10.0R3.10] JUNOS IDP Services [10.0R3.10] 
JUNOS Routing Software Suite [10.0R3.10]

Can this be solved ?

Thanks

BR,
___
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,
France Telecom - 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, France Telecom - 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,
France Telecom - 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, France Telecom - 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] Alarm

2013-04-17 Thread david.roy

Hi,

Try this 


start shell
su
Password: Enter root pwd 


Then :


> sysctl -a | grep bootdevs

I guess disk should be not present in the list. Then, 

> sysctl -w machdep.bootdevs="usb,compact-flash,disk,lan"


Then exit the shell mode and restart the RE

>  request system reload 


If you lose again the HD, I believe you should replace the RE. 

David



 
David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com
 
JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC
-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Mohammad Khalil
Envoyé : mercredi 17 avril 2013 13:00
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] Alarm

Hi
I am facing the below alarm
CR04> show system alarms
1 alarms currently active
Alarm time   Class  Description
2013-04-17 05:03:42 EEST Major  Host 0 hard-disk missing in Boot List

safezone@CR04> show version
Hostname: CR04
Model: mx240
JUNOS Base OS boot [10.0R3.10]
JUNOS Base OS Software Suite [10.0R3.10] JUNOS Kernel Software Suite 
[10.0R3.10] JUNOS Crypto Software Suite [10.0R3.10] JUNOS Packet Forwarding 
Engine Support (M/T Common) [10.0R3.10] JUNOS Packet Forwarding Engine Support 
(MX Common) [10.0R3.10] JUNOS Online Documentation [10.0R3.10] JUNOS Voice 
Services Container package [10.0R3.10] JUNOS Border Gateway Function package 
[10.0R3.10] JUNOS Services AACL Container package [10.0R3.10] JUNOS Services 
LL-PDF Container package [10.0R3.10] JUNOS Services Stateful Firewall 
[10.0R3.10] JUNOS AppId Services [10.0R3.10] JUNOS IDP Services [10.0R3.10] 
JUNOS Routing Software Suite [10.0R3.10]

Can this be solved ?

Thanks

BR,
___
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,
France Telecom - 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, France Telecom - 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] ability to turn USB port on/off for MX routing engine?

2013-03-19 Thread david.roy

You can at least remove it from the boot list via sysctl cmd

Envoyé de mon iPad

Le 19 mars 2013 à 19:53, "Morgan McLean"  a écrit :

> I can see turning off USB from a security stand point, like disabling
> console toobut then again in the event of needing to restore the device
> that could be a big problem.
> 
> AND, if they have physical access, the war is already lost.
> 
> ...Also, I don't think you should really be powering devices with your
> routers? Just an opinion. Not exactly what its designed for.
> 
> Morgan
> 
> 
> On Tue, Mar 19, 2013 at 11:28 AM, Clarke Morledge  wrote:
> 
>> To answer my own question, I found out from JTAC that the ability to turn
>> off the power to the USB port on an MX routing engine is not possible
>> because it is "not supported".
>> 
>> I thought Junos was built on FreeBSD.   Aren't you supposed to be able to
>> do just about anything you want with FreeBSD?
>> 
>> 
>> Clarke Morledge
>> College of William and Mary
>> Information Technology - Network Engineering
>> Jones Hall (Room 18)
>> Williamsburg VA 23187
>> __**_
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/**mailman/listinfo/juniper-nsp
>> 
> 
> 
> 
> -- 
> Thanks,
> Morgan
> ___
> 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,
France Telecom - 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, France Telecom - 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] JNCIE-SP LAB Exam

2013-03-11 Thread david.roy

I recommend the inetzero workbook :

https://www.inetzero.com/workbooks-jncie-sp/

 
David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com
 
JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC
-Message d'origine-
De : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de Farhat Abbasse
Envoyé : lundi 11 mars 2013 09:30
À : juniper juniper
Objet : Re: [j-nsp] JNCIE-SP LAB Exam



 Thanks to all of you, for your priceless recommendation, I will dive right now 
on JUNOSPHERE. Could please recommend me any study materials for this Exam.  
Thanks a lot.BR/   From: bruno.juni...@gmail.com
To: juniper-nsp@puck.nether.net; ab_ferha...@hotmail.co.uk
Subject: Re:JNCIE-SP LAB Exam
Date: Mon, 11 Mar 2013 09:51:24 +0800

Hi Farhat,
I have pass JNCIE-SP last year. U can purchase rack from juniper . they have 
junosphere can emulate juniper mx. can do practice everything on it .
--Best Regards,
Bruno

-- Original --From:  
"juniper-nsp-request";Date:  Mon, Mar 11, 
2013 00:00 AMTo:  "juniper-nsp"; Subject:  
juniper-nsp Digest, Vol 124, Issue 14 Send juniper-nsp mailing list submissions 
to
juniper-nsp@puck.nether.net

To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/juniper-nsp
or, via email, send a message with subject or body 'help' to
juniper-nsp-requ...@puck.nether.net

You can reach the person managing the list at
juniper-nsp-ow...@puck.nether.net

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of juniper-nsp digest..."


Today's Topics:

   1. JNCIE-SP LAB Exam (Farhat Abbasse)


--

Message: 1
Date: Sun, 10 Mar 2013 10:03:06 +0100
From: Farhat Abbasse 
To: juniper juniper 
Subject: [j-nsp] JNCIE-SP LAB Exam
Message-ID: 
Content-Type: text/plain; charset="iso-8859-1"







 

Hi nice
Community,

 

 I would
like to expose my concern regarding the JNCIE-SP, and I hope you could help me .

Actually I do
want to take the JNCIE-SP LAB exam, but my problem is that since the LAB is 
based on MX series it becomes a little bit problematic, 

as I do not
have any MX boxes where I can have hands on it.

 So, could
you please recommend me, any study materials in order to  prepare for the 
JNCIE-SP LAB. 

 
your pieces
of advice are warmly welcome.

 

BR/

Farhat.

  

--

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

End of juniper-nsp Digest, Vol 124, Issue 14

  
___
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,
France Telecom - 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, France Telecom - 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

[j-nsp] RE : JNCIE-SP LAB Exam

2013-03-10 Thread david.roy

Hello

Junosphere is a good choice.  

David

De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
de la part de Farhat Abbasse [ab_ferha...@hotmail.co.uk]
Date d'envoi : dimanche 10 mars 2013 10:03
À : juniper juniper
Objet : [j-nsp] JNCIE-SP LAB Exam

Hi nice
Community,



 I would
like to expose my concern regarding the JNCIE-SP, and I hope you could help me .

Actually I do
want to take the JNCIE-SP LAB exam, but my problem is that since the LAB is
based on MX series it becomes a little bit problematic,

as I do not
have any MX boxes where I can have hands on it.

 So, could
you please recommend me, any study materials in order to  prepare for the 
JNCIE-SP LAB.


your pieces
of advice are warmly welcome.



BR/

Farhat.


___
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,
France Telecom - 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, France Telecom - 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] 11.4R6-S2 feedback ?

2013-02-28 Thread david.roy

Thank you for this feedback. 

Regards
David


 
David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com
 
JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC

-Message d'origine-
De : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de Sebastian Wiesinger
Envoyé : jeudi 28 février 2013 15:13
À : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] 11.4R6-S2 feedback ?

* david@orange.com  [2013-02-27 17:36]:
> Hi all
> 
> Does anybody use this version in production ? if yes, did you experience some 
> SW issues with it?

We're having -S1 in production and no major problems. We see a strange problem 
with RE firewall filters where packets are sporadically discarded even if they 
should be accepted by a term. This is currently investigated by JTAC.

Regards

Sebastian

--
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE) 'Are 
you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant 
___
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,
France Telecom - 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, France Telecom - 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

[j-nsp] 11.4R6-S2 feedback ?

2013-02-27 Thread david.roy

Hi all

Does anybody use this version in production ? if yes, did you experience some 
SW issues with it?

Many thanks for your feedback
David



David Roy
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com

JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC

_

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,
France Telecom - 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, France Telecom - 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] MTU problems over VPLS

2013-02-13 Thread david.roy

We hit this PR but should be fixed in your release. Double check with JTAC if 
there is no regression or corner case?

David

Problem Report
Number  PR568550
Title   With default settings,4 bytes lesser ip payload can be sent when MX-80 
is acting as P router compared to M7i
Release Note

MPLS MTU was reserving 3 labels length apart from the MPLS labels that come in 
the packet. So due to this the packets were getting dropped in P router when 
ping packet size was 1456B for physical MTU of 1514B(excludes CRC).



SeverityMajor
Status  Closed
Last Modified   2012-09-11 23:47:31 PDT
Resolved In 10.4R5 11.1R3 11.2R1 11.3R1
Operating SystemJunos
Product MX-series
Functional Area software
Feature Group   Platform and Infrastructure
Workaround

Set higher MTU i.e.(X+12Bytes) in order to allow X bytes.



Triggers* Trio platform * sending packet more than 1455B

Envoyé de mon iPad

Le 12 févr. 2013 à 22:25, "Luca Salvatore" 
mailto:l...@ninefold.com>> a écrit :

11.2R5.4 on all MX involved - this was the recommended release up to a few days 
ago.
Any ideas on the PR number?

Luca


-Original Message-
From: david@orange.com 
[mailto:david@orange.com]
Sent: Wednesday, 13 February 2013 8:24 AM
To: Luca Salvatore
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MTU problems over VPLS

Which release do you use ? Experienced some mpls mtu issue on trio platform. 
Known PR...

Envoyé de mon iPad

Le 12 févr. 2013 à 22:17, "Luca Salvatore" 
mailto:l...@ninefold.com>> a écrit :

I have a few sites connected via a VPLS core.  The core devices are all MX 10 
routers connected via 10Gb fibre.
I'm having problems doing file copies (SCP between two Centos VMs).

The issue is that the file copy never gets anywhere, on the Centos CLI it sits 
at 0% then says 'stalled'
To fix this issue I have just set the MTU on the Centos machines to be 1400 - 
when this is in place the copy works and I get nice speeds.

I don't believe I should have to modify the MTU though, shouldn't path MTU 
discovery take care of this?

For example - I have done some TCPdumps, I can see the sender is sending 
traffic with the DF bit set, however I don't see any 'ICMP fragmentation 
needed' coming back from the MX saying the MTU is too big, I assume this should 
be the case.

I haven't modified any of the MTU's on the MX, everything is just the default.

I also have normal layer 3 running over the fibre between the routers and when 
I use that I don't see any issues, so it must be something to do with VPLS.

Any thoughts would be greatly appreciated.

Thanks
Luca.

___
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, France Telecom - 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, France Telecom - Orange is not liable for messages 
that have been modified, changed or falsified.
Thank you.


_

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,
France Telecom - 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, France Telecom - Orange is not liable for messages 
that have been modified, changed or falsified.
Thank you.

___
juniper-nsp mailing li

Re: [j-nsp] MTU problems over VPLS

2013-02-13 Thread david.roy

Which release do you use ? Experienced some mpls mtu issue on trio platform. 
Known PR... 

Envoyé de mon iPad

Le 12 févr. 2013 à 22:17, "Luca Salvatore"  a écrit :

> I have a few sites connected via a VPLS core.  The core devices are all MX 10 
> routers connected via 10Gb fibre.
> I'm having problems doing file copies (SCP between two Centos VMs).
> 
> The issue is that the file copy never gets anywhere, on the Centos CLI it 
> sits at 0% then says 'stalled'
> To fix this issue I have just set the MTU on the Centos machines to be 1400 - 
> when this is in place the copy works and I get nice speeds.
> 
> I don't believe I should have to modify the MTU though, shouldn't path MTU 
> discovery take care of this?
> 
> For example - I have done some TCPdumps, I can see the sender is sending 
> traffic with the DF bit set, however I don't see any 'ICMP fragmentation 
> needed' coming back from the MX saying the MTU is too big, I assume this 
> should be the case.
> 
> I haven't modified any of the MTU's on the MX, everything is just the default.
> 
> I also have normal layer 3 running over the fibre between the routers and 
> when I use that I don't see any issues, so it must be something to do with 
> VPLS.
> 
> Any thoughts would be greatly appreciated.
> 
> Thanks
> Luca.
> 
> ___
> 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,
France Telecom - 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, France Telecom - 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] 6PE + mpls no-propagate-ttl

2013-01-23 Thread david.roy

Sorry 

I sent a mail too fast. Actually it works, my test was wrong.

FYI : We used LDP for transport labels

Thank you for the tip with RSVP. 

Best regards
David

David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com

JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC

-Message d'origine-
De : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de Saku Ytti
Envoyé : mercredi 23 janvier 2013 16:39
À : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] 6PE + mpls no-propagate-ttl

On (2013-01-23 16:07 +0100), david@orange.com wrote:

> Did somebody have got trouble with no-propagate-ttl on 6PE environment 
> ? It seems that it doesn't work for me in 11.4

Running mostly 11.4R3, R5, R6 here and it works for me.

I.e. when I traceroute I see ingress PE, egress PE.

Can you elaborate how it does not work? You see whole path? You're missing 
ingress/egress PE?

IIRC no-propagate-ttl only takes affect after LSPs are recreated in JunOS, so 
enabling it runtime and you won't see it being on.

--
  ++ytti
___
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,
France Telecom - 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, France Telecom - 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

[j-nsp] 6PE + mpls no-propagate-ttl

2013-01-23 Thread david.roy

Hello

Did somebody have got trouble with no-propagate-ttl on 6PE environment ? It 
seems that it doesn't work for me in 11.4

Many thanks
David


David Roy
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com

JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC

_

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,
France Telecom - 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, France Telecom - 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] Multicast flow with "Wrong incoming interface notifications" counter incrementing

2013-01-15 Thread david.roy

Could you send us the traces of "show multicast stat" 2 times separated with 10 
sec. 

Thank you 
 


 
David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com
 
JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC

-Message d'origine-
De : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de Riccardo S
Envoyé : mardi 15 janvier 2013 09:14
À : nkham...@juniper.net
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Multicast flow with "Wrong incoming interface 
notifications" counter incrementing


Having also a look to Juniper documentation says:

Wrong incoming interface notifications = Number of times that the upstream 
interface was not available

It doesn't sound as an RPF fail counter, isn't it ?

Tks

> From: nkham...@juniper.net
> To: dim0...@hotmail.com
> CC: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Multicast flow with "Wrong incoming interface 
> notifications" counter incrementing
> Date: Mon, 14 Jan 2013 17:14:42 +
> 
> Iif mismatch means the multicast traffic received for this (S,G) has a 
> different incoming interface than the one we programmed in the PFE (based on 
> RPF check). 
> 
> Traffic would get discarded in this case and not forwarded. However, a 
> notification is sent to RPD/PIM on the RE to check if the we need to 
> change the iif on this (S,G) to a new iif (for e.g. if this leads to 
> RPT to SPT cutover or if there is a change in the iif due to RPF 
> interface change)
> 
> If the counter increase consistently, then most likely you are not forwarding 
> on that (S,G) if 100% of the incoming traffic on this (S,G) get discarded 
> with iif mismatch. Alternately, you might be getting same (S,G) traffic on 2 
> different iifs and in this case one coming over correct iif gets forwarded 
> and one over wrong iif gets discarded with iif mismatch counted against that 
> (S,G).
> 
> Thanks,
> Nilesh. 
> 
> 
> Sent from my mobile device
> 
> On Jan 14, 2013, at 8:14 AM, "Riccardo S"  wrote:
> 
> > 
> > 
> > 
> > Hi
> > 
> > What does means incrementing counter "Wrong incoming interface 
> > notifications" in the following command ?
> > 
> > Is the following flow forwarded, as expected, towards the receiver ?
> > 
> > 
> > 
> > 
> > 
> > # run show multicast route group
> > 224.12.22.1 extensive
> > 
> > Instance: master Family: INET
> > 
> > 
> > 
> > Group: 224.12.22.1
> > 
> > 
> > Source: 1.1.1.1/32
> > 
> > 
> > Upstream interface: vlan.1
> > 
> > 
> > Downstream interface list: 
> > 
> >vlan.100
> > 
> > 
> > Session description: Unknown
> > 
> > 
> > Statistics: 3 kBps, 30 pps, 43340 packets
> > 
> > 
> > Next-hop ID: 131071
> > 
> > 
> > Upstream protocol: PIM
> > 
> > 
> > Route state: Active
> > 
> > 
> > Forwarding state: Forwarding
> > 
> > 
> > Cache lifetime/timeout: 360 seconds
> > 
> > 
> > Wrong incoming interface notifications: 6960
> > 
> > 
> > Uptime: 00:36:36
> > 
> > 
> > 
> > After 10 seconds:
> > 
> > 
> > 
> > # run show multicast route group
> > 224.12.22.1 extensive
> > 
> > Instance: master Family: INET
> > 
> > 
> > 
> > Group: 224.12.22.1
> > 
> > 
> > Source: 1.1.1.1/32
> > 
> > 
> > Upstream interface: vlan.1
> > 
> > 
> > Downstream interface list: 
> > 
> >vlan.100
> > 
> > 
> > Session description: Unknown
> > 
> > 
> > Statistics: 2 kBps, 30 pps, 43491 packets
> > 
> > 
> > Next-hop ID: 131071
> > 
> > 
> > Upstream protocol: PIM
> > 
> > 
> > Route state: Active
> > 
> > 
> > Forwarding state: Forwarding
> > 
> > 
> > Cache lifetime/timeout: 360 seconds
> > 
> > 
> > Wrong incoming interface notifications: 6974
> > 
> > 
> > Uptime: 00:36:41
> > Tks
> > 
> > 
> > 
> > ___
> > 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

_

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,
France Telecom - 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 notif

Re: [j-nsp] EX switches and bpdu-block-on-edge

2013-01-14 Thread david.roy

Should be work but I experienced one time a bug with interface all not for mstp 
but for ISIS on MX platform : ldp-sync on interface all, didn't work as 
expected. But if it works in lab for your feature, I think it will be good. 
Beware, when you need upgrade, check before in lab if there is no regression :) 

David
 


 
David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com
 
JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC

-Message d'origine-
De : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de Pierre-Yves Maunier
Envoyé : lundi 14 janvier 2013 12:04
À : Juniper-Nsp List
Objet : [j-nsp] EX switches and bpdu-block-on-edge

Hi,

I have a quick question about the bpdu-block-on-edge feature on EX switches.

I think I have the good configuration for what I want to achieve but I'd like 
some feedback before I put that info production.

I have top of rack EX switches : all ports except the uplink one should not 
receive bpdus and should be blocked if they received some.

I've made the following sample configuration, which given my lab tests, works 
great :

ge-0/0/24 is the uplink

My question is : I have a more-specific config on ge-0/0/24 that over-ride the 
edge statement in "interface all". But as it's not a interface all "mode" edge 
but directly interface all edge, I'd like to be sure the 'edge'
statement will never be applied to ge-0/0/24 resulting in a really bad 
behaviour in a production environment (shutdown the switch uplink).

protocols {
mstp {
bridge-priority 60k;
interface ge-0/0/24.0 {
mode point-to-point;
}
interface all {
edge;
}
bpdu-block-on-edge;
}
}
ethernet-switching-options {
bpdu-block {
disable-timeout 300;
}
}

Regards,

Pierre-Yves Maunier
___
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,
France Telecom - 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, France Telecom - 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] LACP support on forwarding plane on M10i?

2012-10-30 Thread david.roy

Hello,

Not supported. You can see LACP packets punted to the RE if you use "monitor 
trafic interface xxx" or if you check ppm "remote" adjacencies there is no LACP 
adj up at PFE level  : show ppm adjacencies remote (hidden cmd) 

For exemple on MX you have LACP distributed at PFE : 

mymx@mx> show ppm adjacencies remote
Protocol   Hold time (msec)
LACP   3000
LACP   3000
LACP   3000
LACP   3000
LACP   3000
LACP   3000
LACP   3000
LFM300


David

 
David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com
 
JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC

-Message d'origine-
De : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de Martin T
Envoyé : mardi 30 octobre 2012 16:16
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] LACP support on forwarding plane on M10i?

Is LACP supported on forwarding plane on M10i? According to "Disabling 
Distributed Periodic Packet Management on the Packet Forwarding
Engine"(http://goo.gl/uDwYm) document LACP is supported on packet forwarding 
engine only on MX series.


On the other hand, "show pfe statistics traffic" displays LACP under "Packet 
Forwarding Engine local protocol statistics":

root@M10i> show pfe statistics traffic
Packet Forwarding Engine traffic statistics:
Input  packets:   15819824321 pps
Output packets:   13308609440 pps
Packet Forwarding Engine local traffic statistics:
Local packets input : 13846116
Local packets output:  5817751
Software input control plane drops  :0
Software input high drops   :0
Software input medium drops :  6108913
Software input low drops:0
Software output drops   : 2049
Hardware input drops:201244886
Packet Forwarding Engine local protocol statistics:
HDLC keepalives:0
ATM OAM:0
Frame Relay LMI:0
PPP LCP/NCP:0
OSPF hello :0
OSPF3 hello:0
RSVP hello :0
LDP hello  :  217
BFD:  3502848
IS-IS IIH  :   140750
LACP   :   564573
ARP:40358
ETHER OAM  :0
Unknown:0
Packet Forwarding Engine hardware discard statistics:
Timeout:0
Truncated key  :0
Bits to test   :0
Data error :0
Stack underflow:0
Stack overflow :0
Normal discard : 15337489
Extended discard   :0
Invalid interface  :0
Info cell drops:0
Fabric drops   :0
Packet Forwarding Engine Input IPv4 Header Checksum Error and Output MTU Error 
statistics:
Input Checksum :  707
Output MTU :0

root@M10i>


regards,
martin
___
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,
France Telecom - 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, France Telecom - Orange is not liable for messages 
that have been modified, changed or falsified.
Thank you.


___
juniper-nsp m

[j-nsp] RE : Re: RE : Re: MX80 no more hash-key option in 12.2?

2012-10-23 Thread david.roy

Sorry i forgot that it was a mx80 i play too much with mx960. Yes sounds good. 
You can see that trio based card like mx80 adds by default layer 4 in the key 
buffer.  Unlike ichip based card.

I written a post regarding this on my blog. Http://www.junosandme.net

Regards
David

Envoyé depuis mon Samsung Galaxy Ace d'Orange

Paul Vlaar  a écrit :

On 23/10/12 10:23 AM, david@orange.com wrote:
> Yes and you can check current hash config with the pfe cmd
>
> request pfe execute command "show jnh lb" target fpcX X=slot

First time I hear of this (hidden?) command. Doesn't work quite how you say:

mx80> request pfe execute command "show jnh lb" target fpc0
error: command is not valid on the mx80-48t

mx80> request pfe execute command "show jnh lb" target ?
Possible completions:
  tfeb0Connect to Forwarding Engine Board

mx80> request pfe execute command "show jnh lb" target tfeb0
SENT: Ukern command: show jnh lb
GOT:
GOT: Unilist Seed Configured 0x8bce4c39 System Mac address 00:00:00:00:00:00
GOT: Hash Key Configuration: 0x00e0 0x
GOT:IIF-V4: No
GOT:  SPORT-V4: Yes
GOT:  DPORT-V4: Yes
GOT:   TOS: No
GOT:
GOT:IIF-V6: No
GOT:  SPORT-V6: Yes
GOT:  DPORT-V6: Yes
GOT: TRAFFIC_CLASS: No
GOT:
GOT:  IIF-MPLS: No
GOT:  MPLS_PAYLOAD: Yes
GOT:  MPLS_EXP: No
GOT:
GOT:   IIF-BRIDGED: No
GOT: MAC ADDRESSES: Yes
GOT: ETHER_PAYLOAD: Yes
GOT:  802.1P OUTER: No
GOT:
GOT: Services Hash Key Configuration:
GOT:  SADDR-V4: No
GOT:  DADDR-V4: No
GOT:IIF-V4: No
GOT:
GOT:  SADDR-V6: No
GOT:  DADDR-V6: No
GOT:IIF-V6: No
GOT:
LOCAL: End of file

Looks good, I suppose?

~paul

_

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,
France Telecom - 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, France Telecom - 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

[j-nsp] RE : Re: MX80 no more hash-key option in 12.2?

2012-10-23 Thread david.roy

Yes and you can check current hash config with the pfe cmd

request pfe execute command "show jnh lb" target fpcX X=slot

David

Envoyé depuis mon Samsung Galaxy Ace d'Orange

Doug Hanks  a écrit :

Pretty much. enhanced-hash-hey does a lot by default. Harry can elaborate.

On 10/23/12 2:38 AM, "Paul Vlaar"  wrote:

>On 23/10/12 12:59 AM, Doug Hanks wrote:
>> hash-key = DPC (should never been been on or used on the MX80 - doesn't
>> even do anything when configured)
>>
>>
>> enhanced-hash-key = MPC (which works on the MX80 as it's based on Trio)
>
>mx80# set family inet ?
>Possible completions:
>+ apply-groups Groups from which to inherit configuration data
>+ apply-groups-except  Don't inherit configuration data from these groups
>  incoming-interface-index  Include incoming interface index in the hash
>key
>  no-destination-port  Omit IP destination port in the hash key
>  no-source-port   Omit IP source port in the hash key
>  type-of-service  Include TOS byte in the hash key
>[edit forwarding-options enhanced-hash-key]
>
>I can only negate layer-4 information in the settings for that, does
>this imply that hashing on source / destination port is now the default
>even when I leave this setting out completely?
>
>So if I leave out any enhanced-hash-key setting, I can assume that
>traffic is hashed based on IP address, source and destination port?
>
>And does this mean ...
>
>services-loadbalancing {
>family inet layer-3-services {
>incoming-interface-index;
>source-address;
>}
>}
>
>... that only IPv4 based ECMP hashing is supported across the different
>PICs?
>
>Thanks,
>
>~paul
>

___
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,
France Telecom - 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, France Telecom - 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

[j-nsp] IPv6 Packet too big !

2012-10-19 Thread david.roy

Hi all,

Does anybody know which source IPv6 address is used by a Juniper router to send 
back an ICMPv6 Packet too Big. If I configure the default address selection 
feature and have an IPv6 address on my loopback ? Does it use this address or 
still use the IPv6 interface address ?

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,
France Telecom - 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, France Telecom - 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] Assigning Forwarding Class and DSCP Value for Routing Engine-Generated Traffic

2012-10-10 Thread david.roy

Hi 

I do Not use that. Why you do not using host-outbound-traffic feature ? 
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-cos/changing-fc-dscp.html#changing-fc-dscp
 

David   


 
David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com
 
JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC

-Message d'origine-
De : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de Huan Pham
Envoyé : mercredi 10 octobre 2012 14:18
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] Assigning Forwarding Class and DSCP Value for Routing 
Engine-Generated Traffic

Hi all,


There seems to be a bug with this feature.

http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-cos/cos-assigning-fc-dscp-to-re-pkts.html

Once I apply the Firewall Filter with QoS term on loopback interface, it does 
not seem to change the default behaviour.

I tried  host-outbound-traffic  feature, which assign a forwarding class, and I 
can set DSCP for all traffic generated by RE, which works as it says, but I 
want a finer control.


Here's the config I have:




[edit firewall family inet]

lab@MX5# show

filter RE-Protection-And-CoS {

term OSPF {

from {

protocol ospf;

}

then {

forwarding-class Network-Control;

dscp cs7;

}

}

term TELNET {

from {

protocol tcp;

port telnet;

}

/* Demonstration purpose - Put on another queue */

then {

forwarding-class Gold;

dscp cs3;

}

}

/* Keep default behaviour */

term OTHERS {

then accept;

}

}



[edit interfaces lo0]

lab@MX5# show

unit 0 {

family inet {

filter {

output RE-Protection-And-CoS;

}

}

}



/* Forwarding class definition, etc are not shown */



lab@MX5# commit



*This does not seem to do anything. CoS marking is the same as the default
behaviour.*



lab@MX5> monitor traffic interface ge-1/0/0 no-resolve detail



*OSPF*


11:18:53.217416  In IP (*tos 0xc0*, ttl   1, id 55089, offset 0, flags
[none], proto: OSPF (89), length: 80) 10.1.1.2 > 224.0.0.5: OSPFv2, Hello, 
length 60 [len 48]

Router-ID 10.1.1.2, Backbone Area, Authentication Type: none (0)

Options [External, LLS]

  Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 128

  Designated Router 10.1.1.1, Backup Designated Router 10.1.1.2

  Neighbor List:

10.1.1.1

  LLS: checksum: 0xfff6, length: 3

Extended Options (1), length: 4

  Options: 0x0001 [LSDB resync]

11:18:53.968184 Out IP (*tos 0xc0*, ttl   1, id 55102, offset 0, flags
[none], proto: OSPF (89), length: 80) 10.1.1.1 > 224.0.0.5: OSPFv2, Hello, 
length 60 [len 48]

Router-ID 10.1.1.1, Backbone Area, Authentication Type: none (0)

Options [External, LLS]

  Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 128

  Designated Router 10.1.1.1, Backup Designated Router 10.1.1.2

  Neighbor List:

10.1.1.2

  LLS: checksum: 0xfff6, length: 3

Extended Options (1), length: 4

  Options: 0x0001 [LSDB resync]



*PING*


11:21:39.110220 Out IP (*tos 0x0*, ttl  64, id 57119, offset 0, flags [none], 
proto: ICMP (1), length: 84) 10.1.1.1 > 10.1.1.2: ICMP echo request, id 19937, 
seq 0, length 64

11:21:39.110684  In IP (*tos 0x0*, ttl  64, id 57122, offset 0, flags [none], 
proto: ICMP (1), length: 84) 10.1.1.2 > 10.1.1.1: ICMP echo reply, id 19937, 
seq 0, length 64



*TELNET*



11:41:10.988010  In IP (tos 0x10, ttl  64, id 8376, offset 0, flags [DF],
proto: TCP (6), length: 54) 10.1.1.2.61468 > 10.1.1.1.telnet: P
3181355086:3181355088(2) ack 436609309 win 33304 

11:41:10.988944 Out IP (tos 0x10, ttl  64, id 8379, offset 0, flags [DF],
proto: TCP (6), length: 56) 10.1.1.1.telnet > 10.1.1.2.61468: P 1:5(4) ack
2 win 33304 

11:41:11.067600  In IP (tos 0x10, ttl  64, id 8383, offset 0, flags [DF],
proto: TCP (6), length: 54) 10.1.1.2.61468 > 10.1.1.1.telnet: P 2:4(2) ack
5 win 33304 

11:41:11.067635 Out IP (tos 0x10, ttl  64, id 8386, offset 0, flags [DF],
proto: TCP (6), length: 63) 10.1.1.1.telnet > 10.1.1.2.61468: P 5:16(11) ack 4 
win 33303 




*This behaviour is not what I expected. Does anyone experience the same issue, 
please?* ___
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

Re: [j-nsp] Trigger Trap when interface is overloaded

2012-10-02 Thread david.roy

Thanks 

Yes I saw that but I'm not sure that this config is scalable and sometimes 
ifindex are not persistant after reboot. 

Best regards
David



 
David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com
 
JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC

-Message d'origine-
De : Per Granath [mailto:per.gran...@gcc.com.cy] 
Envoyé : mardi 2 octobre 2012 16:30
À : ROY David DTF/DERX; juniper-nsp@puck.nether.net
Objet : RE: Trigger Trap when interface is overloaded

Have a look at RMON.


> Is-there an easy way (without accounting-profile / event-script) to 
> generate a trap or a syslog when interface reach 95% of load (for 
> example) ? Platform MX / release 11.4


_

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,
France Telecom - 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, France Telecom - 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

[j-nsp] Trigger Trap when interface is overloaded

2012-10-02 Thread david.roy

Hi all,

Is-there an easy way (without accounting-profile / event-script) to generate a 
trap or a syslog when interface reach 95% of load (for example) ? Platform MX / 
release 11.4

Many thanks
Best regards
David





David Roy
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com

JNCIE-M&T/SP #703 - JNCIE-ENT #305 - JNCIP-SEC


_

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,
France Telecom - 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, France Telecom - 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

[j-nsp] RE : route BGP stall bug

2012-07-18 Thread david.roy

Hi

How many groups do you have?  

David Roy
NOC Engineer at Orange France
JNCIE-SP #703 ; JNCIE-ENT #305 

De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
de la part de Richard A Steenbergen [r...@e-gerbil.net]
Date d'envoi : mercredi 18 juillet 2012 20:15
À : Tim Vollebregt
Cc : Juniper-NSP
Objet : Re: [j-nsp] route BGP stall bug

On Wed, Jul 18, 2012 at 12:03:39AM +0200, Tim Vollebregt wrote:
> Hi All,
>
> This morning during a maintenance I experienced the route stall bug
> Richard mentioned a few times already on j-nsp.
>
> Hardware kit:
> -MX480 with SCB (non-e)
> -2 x RE-S-1800x4
> -4 x MPC 3D 16x 10GE
> Software version: 10.4R8.5
> During this maintenance I was placing 2 new routing engines into the
> router, replacing the 'old' RE-S-2000. This router is pushing a lot of
> traffic and receiving 14 x full BGP tables from eBGP peers/1 RR
> session to it's 'mate'/several iBGP peers with partial tables

Rest assured this issue is still alive and well in every piece of code
I've ever looked at. I've basically just given up and accepted that
Juniper can't actually handle a large number of routes, and nobody seems
capable of fixing it. EX's are especially bad, I can't get a full fib
installed from a reboot in anything less than an hour, even if I turn
off most of the BGP sessions so it converges faster. Either stop
carrying so many routes (14x full tables = you're screwed), or go buy a
Cisco. :(

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

_

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,
France Telecom - 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, France Telecom - 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

[j-nsp] RE : Woot. Updated MX software recommendation

2012-04-11 Thread david.roy

Hi all,

I do not encounter SNMP issue anymore since the upgrade in 11.4R2.14. Same test 
like in 11.4R1 

Strange ?

Best regards
David

De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
de la part de Alexandre Snarskii [s...@snar.spb.ru]
Date d'envoi : mercredi 11 avril 2012 18:09
À : OBrien, Will
Cc : juniper-nsp
Objet : Re: [j-nsp] Woot. Updated MX software recommendation

On Wed, Apr 11, 2012 at 02:05:52PM +, OBrien, Will wrote:
> I got on TAC about the fact that they were recommending 10.4 code
> for the MX when it doesn't support the Enhanced SCB at all.
> I don't know if it was my case or just enough people giving them a
> hard time, but they notified me that they've updated KB21476.
>
> There is now an entry for the MX series and the MX series with the
> Enhanced SCB. (11.2R5.4 at this time.)

11.4R2.14 this article says to me :)

PS: to whom it may concern: SNMP counters in 11.4R2 broken even worse
than in 11.4R1. Looks like the same PR/731833,
http://puck.nether.net/pipermail/juniper-nsp/2012-February/022369.html

--
In theory, there is no difference between theory and practice.
But, in practice, there is.

___
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,
France Telecom - 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, France Telecom - 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] SCB-E

2012-02-08 Thread david.roy

Hi,

Same results on my side... 

Just a precision to be sure that there is no mis-understanding : it's not 
triggered by SCB-E, it is a software issue... But currently we only have this 
release to play with SCB-E :-) 

Regards
David

David Roy 
IP/MPLS Support engineer - Orange France
Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13
david@orange.com

JNCIE-M&T/SP #703
JNCIP-ENT

-Message d'origine-
De : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de Daniel Roesen
Envoyé : mercredi 8 février 2012 07:44
À : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] SCB-E

On Wed, Feb 08, 2012 at 01:23:11AM +, OBrien, Will wrote:
> Anyone running the SCB-E? I've got a stack of them with a set of fresh 
> MX480s ready to roll out. I'm curious what code your running.

Given that there is only one public JUNOS release which supports SCB-E, there 
aren't many options: 11.4R1 - and that one has unusable SNMP due to new PFE 
statistics request delays introduced (feature, not bug of
course!):

foo@lab-MX960> show snmp mib walk ifHCOutOctets | count
Count: 413 lines

$ time snmpbulkwalk -v2c -c removed x.x.x.x ifHCInOctets > /dev/null
Timeout: No Response from x.x.x.x

real0m26.380s
user0m1.647s
sys 0m0.133s

PR/731833 - fix supposed to come in 11.4R3 slated for May.

So as far as things stand, SCB-E not deployable before mid 2012 earliest if 
(and that's a big "if" when looking at 10.4 experience) 11.4R3 is going to be 
usable.

Ah, and 11.4R1 floods your log with messages like:

mcsn[91713]: %DAEMON-6: krt_decode_nexthop: Try freeing: nh-handle: 0x0
nh-index: 1049083 fwdtype: 3

No idea wether that's service affecting - we haven't observed any impact due to 
that yet.

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 
___
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,
France Telecom - 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 authorization.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this 
message was modified, changed or falsified.
Thank you.

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

[j-nsp] RE : Re: BGP routes processing

2011-11-20 Thread david.roy

Hi

20 mins is not normal. During the outage, did you experience some kernel queues 
stuck ? Show krt queue

did you check the logs to see if there are some info to help you for 
troubleshooting.

Enable bgp traceoption to see more info...

what is the bgp peer of the mx?

Regards
David Roy
Sent from my mobile...
-Message d'origine-
De : biwa net
Envoyé :  20/11/2011, 22:31
À : OBrien, Will
CC : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] BGP routes processing

Hi Will

The 20 min is from the box itself,

Basically I have a client directly connected the MX960 and I basically try
to ping /traceroute  BGP prefixes on the internet through the the transit
provider.

As it is new device coming into the network, we are just doing testing (no
production traffic yet) , The configuration is not overly complicated,
currently it only has simple config such as ISIS , BGP routes, NO
RIB-groups, we have some LDP mpls configuration , but really it's no much

Maybe my way of checking is not good, but what I am doing , is
ping/traceroute to prefixes on the Internet (our transit from whome we
receive the full table being our EBGP nexthop )

when doing ping/traceroute, I always get next hop not reachable , as if the
PFE does not know how to reach the destination (ie does not have the route).

After 15-20 min ,the same ping/traceroute is then working fine which make
me believe that somehow the full BGP table route receive from the provider
(RIB-In) is taking 15-20min to go through the Rib Loc and Rib out and
installed in the PFE.

Currently it is not an issue since we usually do test before bringing the
box in production , but as we will go ahead other box will come in
production and cant afford to wait 15-20 min to have the PFE getting the
full table

anyway you can advise on how I can check how long it takes from the Rib-in
to Rib out /PFE (cmds etcc..)?

On 20 November 2011 19:40, OBrien, Will  wrote:

> 20 mins is not normal.
> Is that from the box or from a downstream client. What are you doing with
> rib groups and how are you advertising internal routes?
>
> Will O'Brien
>
> On Nov 20, 2011, at 1:30 PM, "biwa net"  wrote:
>
> > hi
> >
> > we added in our network a new mx960, with EBGP peering on it
> >
> > We receive full routing table ,
> >
> > when I do "show route receive-protocol bgp x.x.x.x> it took around 2-3
> min
> > for the 380k to be downloaded, which is ok .
> >
> > But It seems that it took around 20min to be able to reach any bgp
> > destination from that BGP full routing table I received, although when I
> do
> > "show rould see the BGP routete ..."I cou .
> >
> > MY thinking is that it took 2-3 min for the full routing to be installed
> in
> > the RIB-IN, however 20min to be process through the RIB-Loc and then the
> > RIB-out to be installed in the PFE.
> >
> > I don't think it is normal for a  device like a MX960 to take that long
> to
> > process and install the routes in the Forwarding Engine
> >
> > Can anyone advise, how I can see (what commands, output, ...) how long it
> > takes for the MX960 to process the BGP routes from the RIB-IN to Rib-LOC,
> > and how long it takes from the RIB-LOc to the RIB-OUT ie:PFE ?
> > ___
> > 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

_

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, France Telecom - 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 authorization. If you have received this email in error, 
please notify the sender and delete this message and its attachments. As emails 
may be altered, France Telecom - Orange shall not be liable if this message was 
modified, changed or falsified. Thank you.

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

[j-nsp] LAG + ECMP MX MPC

2011-11-03 Thread david.roy

Hi all,

Does anybody have experienced ECMP LAGs. I mean, MX MPC only support 16 links 
per LAG until the 12.2, so we need to split more than 16 links in 2 LAGs, and 
each LAG will have the same cost. For exemple 2 LAGs with 10 links per LAG ?

Any experience, bug, limitation ???

Thanks
Regards
David



David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange.com
Skype : davidroy.35
JNCIE-SP #703

Guest Haiku :
IS-IS screams,
BGP peers are flapping:
I want my mommy!




IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.



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

Re: [j-nsp] LSP Refresh ISIS

2011-09-07 Thread david.roy

Thks. That could be the reason... 

David

David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
Skype : davidroy.35
JNCIE-M/T #703(SP #1168)

-Message d'origine-
De : Vladimir Blazhkun [mailto:v.blazh...@gmail.com] 
Envoyé : mardi 6 septembre 2011 16:30
À : ROY David DTF/DERX
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] LSP Refresh ISIS

Hi, David,

I guess it is 317 because the number is a prime one (decreases a possibility of 
the self-synchronization). Also 317 looks cool :)

P.S. As was told, 300 is "a reasonable value", the standard says, not a 
recommended one, to be precise.

With best regards,
Vladimir Blazhkun.

On Tue, Sep 6, 2011 at 10:41,   wrote:

> Hi all,
>
> Just for my understanding.
> Does anybody know why juniper uses LSP Lifetime-317 secs for its 
> max-LSP-origination-interval ? The ISO recommends LSP Lifetime - 300. Why 317 
> secs ?

IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.

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

[j-nsp] LSP Refresh ISIS

2011-09-05 Thread david.roy

Hi all,

Just for my understanding.
Does anybody know why juniper uses LSP Lifetime-317 secs for its 
max-LSP-origination-interval ? The ISO recommends LSP Lifetime - 300. Why 317 
secs ?

Thanks
David



David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
Skype : davidroy.35
JNCIE-M/T #703 & SP #1168



IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.


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

[j-nsp] RE : ECMP vs LAG and OAM vs BFD

2011-08-16 Thread david.roy

De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
de la part de Rafael Rodriguez [packetjoc...@gmail.com]
Date d'envoi : vendredi 29 juillet 2011 22:08
À : Daniel Verlouw
Cc : Juniper Puck
Objet : Re: [j-nsp] ECMP vs LAG and OAM vs BFD

FYI list,

OAM LFM (802.3ah) appears to be supported in Junos 11.1 for Trio/MPC (I've
yet to test this).

http://www.juniper.net/techpubs/en_US/junos11.1/information-products/topic-collections/release-notes/11.1/index.html?topic-53312.html#jd0e1736

On Sat, Jul 23, 2011 at 7:22 AM, Daniel Verlouw  wrote:

> On Fri, Jul 22, 2011 at 22:14, Stefan Fouant
>  wrote:
> > Regarding BFD's capabilities to determine member state of individual
> member
> > links, this is not currently supported by BFD.  Take a look at IETF Draft
> > 'Bidirectional Forwarding Detection (BFD) for Interface' which was just
> > released a few weeks ago. It is designed to meet these requirements -
> > http://tools.ietf.org/html/draft-chen-bfd-interface-00
>
> IOS XR (at least on the ASR9k) supports BFD over individual member
> links. Saw it in the lab, seemed to work fine. Not sure if it's
> implementation is based on this draft though, or if it's a proprietary
> one.
>
>  --Daniel.
>
> ___
> 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

IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.

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

[j-nsp] PSN-2011-07-298 - More info

2011-07-15 Thread david.roy

Hi all,

Does anybody have more info regarding this new Tech Bulletin ? I tried to 
reproduce the issue in lab on my T640 FPC type 3 without success.

Thanks
Best Regards



David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
Skype : davidroy.35
JNCIE-M/T  #703 ; JNCIS-ENT



IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.


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

[j-nsp] RE : Perempt hold-down time on vrrp

2011-07-06 Thread david.roy

Hi 

Hold-time on Junos is only available when Vrrpd restart (It is usually used 
when VRRP crash or RE reboot or RE switchover without NSR)

Regards
David


De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
de la part de MSusiva [ssiva1...@gmail.com]
Date d'envoi : mercredi 6 juillet 2011 20:44
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] Perempt hold-down time on vrrp

Hi experts,

I have been testing prempt hold time on vrrp & it did not work as expected
or may be my understanding is wrong.

I have set prempt hold-down time as 60sec. In the case of master router is
going down, the backup router takes master state immediately. When the
previous master comes up, it has to wait 60sec before taking the master
state.

Can some please explain?

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


IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.



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

[j-nsp] RE : Matching communities in 'show route receive-protocol bgp' command

2011-07-06 Thread david.roy

Hi

>From the Junos Guide :

The output displays the selected routes and the attributes with which they were 
received, but does not show the effects of import policy on the routing 
attributes

REgards
David

De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
de la part de Alexander Shikoff [minot...@crete.org.ua]
Date d'envoi : mercredi 6 juillet 2011 18:33
À : Stacy W. Smith
Cc : Juniper List
Objet : Re: [j-nsp] Matching communities in 'show route receive-protocol
bgp' command

On Wed, Jul 06, 2011 at 10:28:07AM -0600, Stacy W. Smith wrote:
> OK. Thanks for the additional details. That allows me to replicate the 
> behavior you are seeing.
>
> It seems the 'community' argument to 'show route' always evaluates post 
> import policy even when 'receive-protocol' is specified.
[...]
> I suspect this is because each argument to 'show route' is evaluated 
> independently. I'm not aware of a way to change this behavior.
Hmmm... Now I'm wondering is that a bug or feature? :)

> Would it be acceptable to change your import policies to use 'community add' 
> rather than 'community set'? That would be a potential workaround.
Yes, of course. I guess I'll use that workaround.
Thanks a lot for quick help!

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

IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.

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

Re: [j-nsp] RE : ALS on Juniper

2011-06-29 Thread david.roy

Hi Alex,

I thought to use it, but in my case I can't use source-filtering because my 
interface is within an AE. And I don't want to source-filter on the entire AE 
but on a specific interface of the AE.

David

David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
Skype : davidroy.35
JNCIE-M/T  #703 ; JNCIS-ENT

-Message d'origine-
De : Alex [mailto:alex.arsen...@gmail.com] 
Envoyé : mardi 28 juin 2011 18:59
À : ROY David DTF/DERX
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] RE : ALS on Juniper

You can simulate it with source MAC filtering: allow fake MAC in and deny 
everything else.
HTH
Rgds
Alex

- Original Message -
From: 
To: "Ben Dale" 
Cc: 
Sent: Tuesday, June 28, 2011 5:39 PM
Subject: [j-nsp] RE : ALS on Juniper

Hi

thank you.

What I try to do is to simulate an unidirectionnal link failure (for OAM LFM 
tests). So I'm not sure that there is a way to disable ALS.

Regards
David

De : Ben Dale [bd...@comlinx.com.au]
Date d'envoi : mardi 28 juin 2011 12:46
À : ROY David DTF/DERX
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] ALS on Juniper

On 28/06/2011, at 7:24 PM,  
 wrote:
> Do you know if Junos provides ALS (Automatic Laser Shutdown) configuration 
> ? Like Cisco 
> (http://www.cisco.com/en/US/docs/routers/7600/install_config/ES40_config_guide/es40_chap11.pdf)

I can only vouch for the EX platform, but in some testing I did a while back 
it would appear that yanking a single core from an SFP takes the transmitter 
down on both sides.  A log message is also generated that lets you know that 
RX has fallen below a certain threshold and the transmitter is being shut 
down.  No configuration is required to make this happen.

I suspect this would be reliant on you using Juniper "certified" optics 
though as you'd need digital diagnostics.

Ben

IMPORTANT.Les informations contenues dans ce message electronique y compris 
les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans 
ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment 
s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout 
virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential 
and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named 
recipient(s), please immediately notify the sender and delete this e-mail 
message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.

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

IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be rel

[j-nsp] RE : ALS on Juniper

2011-06-28 Thread david.roy

thank you.

What I try to do is to simulate an unidirectionnal link failure (for OAM LFM
tests). So I'm not sure that there is a way to disable ALS.

Regards
David

De : Ben Dale [bd...@comlinx.com.au]
Date d'envoi : mardi 28 juin 2011 12:46
À : ROY David DTF/DERX
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] ALS on Juniper

On 28/06/2011, at 7:24 PM,
wrote:
> Do you know if Junos provides ALS (Automatic Laser Shutdown) configuration ?
> Like Cisco
> (http://www.cisco.com/en/US/docs/routers/7600/install_config/ES40_config_guide/es40_chap11.pdf)

I can only vouch for the EX platform, but in some testing I did a while back it
would appear that yanking a single core from an SFP takes the transmitter down
on both sides. A log message is also generated that lets you know that RX has
fallen below a certain threshold and the transmitter is being shut down. No
configuration is required to make this happen.

I suspect this would be reliant on you using Juniper "certified" optics though
as you'd need digital diagnostics.

Ben

IMPORTANT.Les informations contenues dans ce message electronique y compris les
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s)
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine,
veuillez immediatement le signaler a l expediteur et effacer ce message
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s),
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.

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

[j-nsp] ALS on Juniper

2011-06-28 Thread david.roy

Hi all,

Do you know if Junos provides ALS (Automatic Laser Shutdown) configuration ?
Like Cisco
(http://www.cisco.com/en/US/docs/routers/7600/install_config/ES40_config_guide/es40_chap11.pdf)

Thks
Regards
David

David Roy
Orange - IP Domestic Backbone - TAC
Tel. +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
Skype : davidroy.35
JNCIE-M/T #703 ; JNCIS-ENT

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

[j-nsp] RE : RE : RE : Bad time and date on firewall log.

2011-06-08 Thread david.roy

oups I forgot : set interface lo0 unit 0 family inet address 127.0.0.1 


De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
de la part de david@orange-ftgroup.com [david@orange-ftgroup.com]
Date d'envoi : mercredi 8 juin 2011 23:01
À : David Lockuan
Cc : juniper-nsp@puck.nether.net
Objet : [j-nsp] RE : RE :  Bad time and date on firewall log.

yep ! So I guess you don't use NTP.

Try this :

edit ex
 set system ntp boot-server 127.0.0.1
 set system ntp server 127.0.0.1
commit sync and-quit

And check RE system uptime and sntp at PFE level

I believe it works but I don't know if it's supported by Juniper ;-)

Regards,
David



De : David Lockuan [dlock...@gmail.com]
Date d'envoi : mercredi 8 juin 2011 22:26
À : ROY David DTF/DERX
Cc : juniper-nsp@puck.nether.net
Objet : Re: RE : [j-nsp] Bad time and date on firewall log.

Hi David,

Here the output of the command "request pfe execute..."

*
{master}
test@MX960-LAB-RE0> request pfe execute command "show sntp" target fpc7
SENT: Ukern command: show sntp
GOT:
GOT: SNTP status:
GOT:  current time:  Jan  1 02:54:24.583
GOT:  last SNTP update time: (null)
GOT:  seconds since last update: 10464
GOT:  last update interval:  64.000 seconds
GOT:
GOT:  last time offset:  0us
GOT:  last frequency offset: 0.000 PPM
GOT:  last RTT delay:0us
GOT:  Good SNTP updates: 0
GOT:  Bad SNTP updates:  0
GOT:  Number of overflows:   0
LOCAL: End of file

{master}
test@MX960-LAB-RE0> request pfe execute command "show sntp" target fpc0
SENT: Ukern command: show sntp
GOT:
GOT: SNTP status:
GOT:  current time:  Jan  1 02:54:41.158
GOT:  last SNTP update time: (null)
GOT:  seconds since last update: 10481
GOT:  last update interval:  64.000 seconds
GOT:
GOT:  last time offset:  0us
GOT:  last frequency offset: 0.000 PPM
GOT:  last RTT delay:0us
GOT:  Good SNTP updates: 0
GOT:  Bad SNTP updates:  0
GOT:  Number of overflows:   0
LOCAL: End of file

{master}
test@MX960-LAB-RE0>
*

I note that the date is different from the system uptime. Do you know how we 
can change the date and time of the PFE?

thanks for all,

BR,

---
David

On Wed, Jun 8, 2011 at 2:19 PM, 
mailto:david@orange-ftgroup.com>> wrote:
Hi,

Did you try to check the time at PFE level :

request pfe execute command "show sntp" target fpc

Regards,
David

De : 
juniper-nsp-boun...@puck.nether.net 
[juniper-nsp-boun...@puck.nether.net]
 de la part de David Lockuan [dlock...@gmail.com]
Date d'envoi : mercredi 8 juin 2011 19:52
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] Bad time and date on firewall log.

Hi guys,

I was testing the firewall filter over a MX960 with release 10.4R1.9 and I
noted that time and date of the firewall logs was wrong. I am doing an
upgrade to release 10.4R4.5 and the issue continue.

*
{master}
test@MX960-LAB-RE0> show version
Hostname: MX960-LAB-RE0
Model: mx960
JUNOS Base OS boot [10.4R4.5]
JUNOS Base OS Software Suite [10.4R4.5]
JUNOS Kernel Software Suite [10.4R4.5]
JUNOS Crypto Software Suite [10.4R4.5]
JUNOS Packet Forwarding Engine Support (M/T Common) [10.4R4.5]
JUNOS Packet Forwarding Engine Support (MX Common) [10.4R4.5]
JUNOS Online Documentation [10.4R4.5]
JUNOS Voice Services Container package [10.4R4.5]
JUNOS Border Gateway Function package [10.4R4.5]
JUNOS Services AACL Container package [10.4R4.5]
JUNOS Services LL-PDF Container package [10.4R4.5]
JUNOS Services PTSP Container package [10.4R4.5]
JUNOS Services Stateful Firewall [10.4R4.5]
JUNOS Services NAT [10.4R4.5]
JUNOS Services Application Level Gateways [10.4R4.5]
JUNOS Services Captive Portal and Content Delivery Container package
[10.4R4.5]
JUNOS Services RPM [10.4R4.5]
JUNOS AppId Services [10.4R4.5]
JUNOS IDP Services [10.4R4.5]
JUNOS Runtime Software Suite [10.4R4.5]
JUNOS Routing Software Suite [10.4R4.5]

{master}
nsn@MX960-LAB-RE0> show firewall log detail
Time of Log: 1969-12-31 19:19:47 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2040
Name of protocol: RSVP, Packet Length: 140, Source address: 10.113.0.18,
Destination address: 10.113.0.17
Time of Log: 1969-12-31 19:19:46 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2000
Name of protocol: RSVP, Packet Length: 52, Source address: 10.113.0.2,
Destination address: 10.113.0.1
Time of Log: 1969-12-31 19:19:46 PET, Filter: pfe, Filter action: accep

[j-nsp] RE : RE : Bad time and date on firewall log.

2011-06-08 Thread david.roy

yep ! So I guess you don't use NTP. 

Try this : 

edit ex
 set system ntp boot-server 127.0.0.1
 set system ntp server 127.0.0.1
commit sync and-quit

And check RE system uptime and sntp at PFE level

I believe it works but I don't know if it's supported by Juniper ;-)

Regards,
David



De : David Lockuan [dlock...@gmail.com]
Date d'envoi : mercredi 8 juin 2011 22:26
À : ROY David DTF/DERX
Cc : juniper-nsp@puck.nether.net
Objet : Re: RE : [j-nsp] Bad time and date on firewall log.

Hi David,

Here the output of the command "request pfe execute..."

*
{master}
test@MX960-LAB-RE0> request pfe execute command "show sntp" target fpc7
SENT: Ukern command: show sntp
GOT:
GOT: SNTP status:
GOT:  current time:  Jan  1 02:54:24.583
GOT:  last SNTP update time: (null)
GOT:  seconds since last update: 10464
GOT:  last update interval:  64.000 seconds
GOT:
GOT:  last time offset:  0us
GOT:  last frequency offset: 0.000 PPM
GOT:  last RTT delay:0us
GOT:  Good SNTP updates: 0
GOT:  Bad SNTP updates:  0
GOT:  Number of overflows:   0
LOCAL: End of file

{master}
test@MX960-LAB-RE0> request pfe execute command "show sntp" target fpc0
SENT: Ukern command: show sntp
GOT:
GOT: SNTP status:
GOT:  current time:  Jan  1 02:54:41.158
GOT:  last SNTP update time: (null)
GOT:  seconds since last update: 10481
GOT:  last update interval:  64.000 seconds
GOT:
GOT:  last time offset:  0us
GOT:  last frequency offset: 0.000 PPM
GOT:  last RTT delay:0us
GOT:  Good SNTP updates: 0
GOT:  Bad SNTP updates:  0
GOT:  Number of overflows:   0
LOCAL: End of file

{master}
test@MX960-LAB-RE0>
*

I note that the date is different from the system uptime. Do you know how we 
can change the date and time of the PFE?

thanks for all,

BR,

---
David

On Wed, Jun 8, 2011 at 2:19 PM, 
mailto:david@orange-ftgroup.com>> wrote:
Hi,

Did you try to check the time at PFE level :

request pfe execute command "show sntp" target fpc

Regards,
David

De : 
juniper-nsp-boun...@puck.nether.net 
[juniper-nsp-boun...@puck.nether.net]
 de la part de David Lockuan [dlock...@gmail.com]
Date d'envoi : mercredi 8 juin 2011 19:52
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] Bad time and date on firewall log.

Hi guys,

I was testing the firewall filter over a MX960 with release 10.4R1.9 and I
noted that time and date of the firewall logs was wrong. I am doing an
upgrade to release 10.4R4.5 and the issue continue.

*
{master}
test@MX960-LAB-RE0> show version
Hostname: MX960-LAB-RE0
Model: mx960
JUNOS Base OS boot [10.4R4.5]
JUNOS Base OS Software Suite [10.4R4.5]
JUNOS Kernel Software Suite [10.4R4.5]
JUNOS Crypto Software Suite [10.4R4.5]
JUNOS Packet Forwarding Engine Support (M/T Common) [10.4R4.5]
JUNOS Packet Forwarding Engine Support (MX Common) [10.4R4.5]
JUNOS Online Documentation [10.4R4.5]
JUNOS Voice Services Container package [10.4R4.5]
JUNOS Border Gateway Function package [10.4R4.5]
JUNOS Services AACL Container package [10.4R4.5]
JUNOS Services LL-PDF Container package [10.4R4.5]
JUNOS Services PTSP Container package [10.4R4.5]
JUNOS Services Stateful Firewall [10.4R4.5]
JUNOS Services NAT [10.4R4.5]
JUNOS Services Application Level Gateways [10.4R4.5]
JUNOS Services Captive Portal and Content Delivery Container package
[10.4R4.5]
JUNOS Services RPM [10.4R4.5]
JUNOS AppId Services [10.4R4.5]
JUNOS IDP Services [10.4R4.5]
JUNOS Runtime Software Suite [10.4R4.5]
JUNOS Routing Software Suite [10.4R4.5]

{master}
nsn@MX960-LAB-RE0> show firewall log detail
Time of Log: 1969-12-31 19:19:47 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2040
Name of protocol: RSVP, Packet Length: 140, Source address: 10.113.0.18,
Destination address: 10.113.0.17
Time of Log: 1969-12-31 19:19:46 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2000
Name of protocol: RSVP, Packet Length: 52, Source address: 10.113.0.2,
Destination address: 10.113.0.1
Time of Log: 1969-12-31 19:19:46 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2040
Name of protocol: RSVP, Packet Length: 52, Source address: 10.113.0.18,
Destination address: 10.113.0.17
Time of Log: 1969-12-31 19:19:42 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2000
Name of protocol: RSVP, Packet Length: 148, Source address: 10.113.0.2,
Destination address: 10.113.0.1
Time of Log: 1969-12-31 19:19:37 PET, Filter: pfe, Filter action: acce

[j-nsp] RE : Bad time and date on firewall log.

2011-06-08 Thread david.roy

Hi,

Did you try to check the time at PFE level :

request pfe execute command "show sntp" target fpc

Regards,
David 

De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
de la part de David Lockuan [dlock...@gmail.com]
Date d'envoi : mercredi 8 juin 2011 19:52
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] Bad time and date on firewall log.

Hi guys,

I was testing the firewall filter over a MX960 with release 10.4R1.9 and I
noted that time and date of the firewall logs was wrong. I am doing an
upgrade to release 10.4R4.5 and the issue continue.

*
{master}
test@MX960-LAB-RE0> show version
Hostname: MX960-LAB-RE0
Model: mx960
JUNOS Base OS boot [10.4R4.5]
JUNOS Base OS Software Suite [10.4R4.5]
JUNOS Kernel Software Suite [10.4R4.5]
JUNOS Crypto Software Suite [10.4R4.5]
JUNOS Packet Forwarding Engine Support (M/T Common) [10.4R4.5]
JUNOS Packet Forwarding Engine Support (MX Common) [10.4R4.5]
JUNOS Online Documentation [10.4R4.5]
JUNOS Voice Services Container package [10.4R4.5]
JUNOS Border Gateway Function package [10.4R4.5]
JUNOS Services AACL Container package [10.4R4.5]
JUNOS Services LL-PDF Container package [10.4R4.5]
JUNOS Services PTSP Container package [10.4R4.5]
JUNOS Services Stateful Firewall [10.4R4.5]
JUNOS Services NAT [10.4R4.5]
JUNOS Services Application Level Gateways [10.4R4.5]
JUNOS Services Captive Portal and Content Delivery Container package
[10.4R4.5]
JUNOS Services RPM [10.4R4.5]
JUNOS AppId Services [10.4R4.5]
JUNOS IDP Services [10.4R4.5]
JUNOS Runtime Software Suite [10.4R4.5]
JUNOS Routing Software Suite [10.4R4.5]

{master}
nsn@MX960-LAB-RE0> show firewall log detail
Time of Log: 1969-12-31 19:19:47 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2040
Name of protocol: RSVP, Packet Length: 140, Source address: 10.113.0.18,
Destination address: 10.113.0.17
Time of Log: 1969-12-31 19:19:46 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2000
Name of protocol: RSVP, Packet Length: 52, Source address: 10.113.0.2,
Destination address: 10.113.0.1
Time of Log: 1969-12-31 19:19:46 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2040
Name of protocol: RSVP, Packet Length: 52, Source address: 10.113.0.18,
Destination address: 10.113.0.17
Time of Log: 1969-12-31 19:19:42 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2000
Name of protocol: RSVP, Packet Length: 148, Source address: 10.113.0.2,
Destination address: 10.113.0.1
Time of Log: 1969-12-31 19:19:37 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2000
Name of protocol: RSVP, Packet Length: 52, Source address: 10.113.0.2,
Destination address: 10.113.0.1
Time of Log: 1969-12-31 19:19:37 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2040
Name of protocol: RSVP, Packet Length: 52, Source address: 10.113.0.18,
Destination address: 10.113.0.17
Time of Log: 1969-12-31 19:19:28 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2000
Name of protocol: RSVP, Packet Length: 52, Source address: 10.113.0.2,
Destination address: 10.113.0.1
Time of Log: 1969-12-31 19:19:28 PET, Filter: pfe, Filter action: accept,
Name of interface: ge-7/0/4.2040
Name of protocol: RSVP, Packet Length: 52, Source address: 10.113.0.18,
Destination address: 10.113.0.17

{master}
test@MX960-LAB-RE0> show configuration logical-systems was firewall
filter test_arfc {
term 1 {
then {
log;
accept;
}
}
}

{master}
test@MX960-LAB-RE0> show system uptime
Current time: 2011-06-08 12:50:53 PET
System booted: 2011-06-08 12:25:55 PET (00:24:58 ago)
Protocols started: 2011-06-08 12:26:56 PET (00:23:57 ago)
Last configured: 2011-06-08 12:18:26 PET (00:32:27 ago) by root
12:50PM  up 25 mins, 1 user, load averages: 0.02, 0.02, 0.05

*

Someone had the similar problem.

Thanks in advance,

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


IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message ele

Re: [j-nsp] ISIS between ERX 1440 and MX960

2011-05-30 Thread david.roy

Hi All,

Some news : I tried without auth. and the Adj. is still down. I've opened a 
case. Maybe, an hardware issue.

Regards,
David

David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
Skype : davidroy.35
JNCIE-M/T  #703 ; JNCIS-ENT

-Message d'origine-
De : Mark Tinka [mailto:mti...@globaltransit.net] 
Envoyé : vendredi 27 mai 2011 15:40
À : juniper-nsp@puck.nether.net
Cc : David Lockuan; ROY David DTF/DERX
Objet : Re: [j-nsp] ISIS between ERX 1440 and MX960

On Saturday, May 21, 2011 02:03:09 AM David Lockuan wrote:

> Could you try to put the authentication with md5? I say this because 
> when I was doing interoperability between JunOS and IOS, I noted that 
> the simple authentication don't work correctly. Maybe the hash-key is 
> not compatible when you use the simple authentication.

This problem is even more obvious in IOS XR when running
HMAC-MD5 authentication for RSVP between the Cisco and Junos.

Cheers,

Mark.

IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.

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

[j-nsp] MC LAG experience ?

2011-05-29 Thread david.roy

Hi All,

Somebody has experience regarding MX LAG on Juniper MX in 10.2 ?

MC LAG in stanby-active for VPLS mode with LACP and ICCP configured ? Does-it 
work ? Are-there any HW or SW requierements ? Some sample config are welcome, 
too.
I tried to configure it with DPC combo card (20x1GE - 2x20GE). All the 
configuration has commited but my LAG is still down.

Thanks for your help.
Regards
David

Hereafter my configuration :

On MX 1 :

 ae0 {
encapsulation ethernet-vpls;
aggregated-ether-options {
link-speed 1g;
lacp {
active;
system-priority 1;
system-id 00:00:00:00:00:01;
admin-key 12345;
}
mc-ae {
mc-ae-id 1;
redundancy-group 1;
chassis-id 0;
mode active-standby;
status-control standby;
}
}
unit 0;
}
   ge-0/0/3 {
speed 1g;
link-mode full-duplex;
gigether-options {
802.3ad ae0;
}
}
  iccp {
local-ip-addr 1.1.1.1;
peer 2.2.2.2 {
redundancy-group-id-list 1;
liveness-detection {
minimum-interval 1000;
}
}
}

On MX 2


 ae0 {
encapsulation ethernet-vpls;
aggregated-ether-options {
link-speed 1g;
lacp {
active;
system-priority 1;
system-id 00:00:00:00:00:01;
admin-key 12345;
}
mc-ae {
mc-ae-id 1;
redundancy-group 1;
chassis-id 0;
mode active-standby;
status-control active; 
}
}
unit 0;
}
   ge-0/0/5 {
speed 1g;
link-mode full-duplex;
gigether-options {
802.3ad ae0;
}
}
  iccp {
local-ip-addr 2.2.2.2;
peer1.1.1.1 {
redundancy-group-id-list 1;
liveness-detection {
minimum-interval 1000;
}
}
}


IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.



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

[j-nsp] RE : Missing interface ID in RE based sflow export from M7i

2011-05-21 Thread david.roy

Hi,

Maybe you hit this recent PR  :

JUNOS Problem Report Information
NUMBER  598135
SEVERITYmajor
CATEGORYsw
STATE   open
SYNOPSISCFLOW records have interface index as 0 for any interfaces with 
index greater than 8192
RELEASE NOTEMaximum number of service IFL's supported on M320 platform are 
8192
RESOLVED IN -
ARRIVAL DATE2011-04-05 18:53:47
LAST MODIFIED   2011-04-19 04:06:36
CLOSE DATE  - 

Regards,
David



De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
de la part de Samit [janasa...@wlink.com.np]
Date d'envoi : samedi 21 mai 2011 14:07
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] Missing interface ID in RE based sflow export from M7i

Hi,

I  am testing the RE based flow export from my Juniper M7i running
9.2R2.15 , for some reason my flow analyzer wrapped up all the flows in
instance 0 interface for all the flows exported, at the same time all
the export from all the Cisco is working and showing up perfectly.

Upon investigating the sflow packets through wireshark, it is found that
all the captured sflow frames from M7i has  Input interface and Output
interface information id is "0"  thus Interface ID is not exported. Is
this the know issue or are there any configuration miss? any workaround
or fix?

###

Wireshark output:

> pdu 1/29
  SrcAddr: 202.xx.xx.xx (202.xx.xx.xx)
  DstAddr: 195.xx.xx.xx (195.xx.xx.xx)
  NextHop: 125.xx.xx.xx (125.xx.xx.xx)
  InputInt: 0  <-- here...
  OutputInt: 0 <-- here...
  Packets: 1
  Octets: 48
> [Duration:0.0 seconds]
  SrcPort: 48129
  DstPort: 28158
  padding
  TCP Flags: 0x00
  Protocol: 17
 IP Tos: 0x00



interfaces {
ge-1/3/0 {
unit 0 {
   family inet {
  filter {
 input all;
 output all;
  }
  address 202.xx.xx.xx/26;
  address 202.xx.xx.xx/27;
   }
}
}
}

firewall {
filter all {
term all {
   then {
  sample;
  accept;
   }
}
}
}

forwarding-options {
sampling {
input {
   family inet {
  rate 100;
   }
}
output {
   cflowd  202.xxx.xxx.xxx{
  port 2055;
  version 5;
   }
   flow-inactive-timeout 15;
   flow-active-timeout 60;
}
}
}

###

Chassis   M7i
Midplane  REV 05   M7i Midplane
Power Supply 0   Rev 05AC Power Supply
Routing EngineREV 01  RE-850
CFEB  REV 08   Internet Processor II
FPC 0 E-FPC
  PIC 0 REV 09   1x G/E, 1000 BASE-SX
FPC 1 E-FPC
  PIC 2 BUILTIN 1x Tunnel
  PIC 3REV 08   1x G/E, 1000 BASE
Xcvr 0 SFP-SX
Fan Tray Rear Fan Tray

###

--
Regards
Samit


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


IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.



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

[j-nsp] RE : ISIS between ERX 1440 and MX960

2011-05-20 Thread david.roy

Thanks.

I tried too, but I ve the same behavior ! IIH discarded at the ERX side.  

Moreover when i configure my interface in point-to-point the ERX stops sending 
IIH ! So strange. The MX has already ISIS adjacencies with ALU 7750, other 
Juniper T and M series and Cisco boxes as well. I don't understand why I can't 
do it with ERX ! Maybe a bug ! ERX is in 10.2.1

David


De : David Lockuan [dlock...@gmail.com]
Date d'envoi : vendredi 20 mai 2011 20:03
À : ROY David DTF/DERX
Cc : sth...@nethelp.no; juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] ISIS between ERX 1440 and MX960

Hi David,

Could you try to put the authentication with md5? I say this because when I was 
doing interoperability between JunOS and IOS, I noted that the simple 
authentication don't work correctly. Maybe the hash-key is not compatible when 
you use the simple authentication.

Now we are using md5 as authentication-type and point-to-point configuration 
between equipments ERX, T1600, GSR and CRS.

BR,

---
David


On Fri, May 20, 2011 at 10:47 AM, Payam Chychi 
mailto:pchy...@gmail.com>> wrote:
correction:
point-to-point is configured under the interface on the erx

" interface blah/0

isis network point-to-point "


-Payam


Payam Chychi wrote:
Hey,

Have you tried setting each side up as a. Point-to-point network? Its
done under protocol isis

Try that and see if it works. If so, ur dst mac on one side is getting
filtered (by the device itself or perhaps your  provider)


On 5/20/11, david@orange-ftgroup.com 
mailto:david@orange-ftgroup.com>> wrote:

Hi,

I don't know how to go on with the ERX. I tried many things without success.
More traces below. Thanks for your help : May be a bug ?!?

Regards,
David


ERX :
###

interface loopback 50
 ip address x.x.x.x 255.255.255.255
 no ip redirects
!
interface gigabitEthernet 12/0
 mtu 4488
 ip address y.y.y.1 255.255.255.252
 no ip redirects
 ip router isis 31337
 isis circuit-type level-2-only
 isis authentication-key level-2 foo123
!
router isis 31337
 is-type level-2-only
 passive-interface loopback50
 net 49.0001....00
 domain-authentication psnp
 domain-authentication csnp
 domain-message-digest-key 1 hmac-md5 foo123
 metric-style wide
!


MX :
###

ge-2/2/2 {
   mtu 4484;
   unit 0 {
   family inet {
   address y.y.y.2/30;
   }
   family iso;
   }
}

isis {
   level 2 {
   authentication-key ""; ## SECRET-DATA = foo123
   authentication-type md5;
   wide-metrics-only;
   }
   interface ge-2/2/2.0 {
 level 1 disable;
 level 2 {
 hello-authentication-key "$9$fQ39yrv8xdBIs4aJDjCtpBhS"; ##
SECRET-DATA = foo123
 hello-authentication-type simple;
 }
  }
}


Trace on MX :
##

show interfaces ge-2/2/2
Physical interface: ge-2/2/2, Enabled, Physical link is Up
 Interface index: 251, SNMP ifIndex: 556
 Description: Connection To LNS
 Link-level type: Ethernet, MTU: 4484, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled,
 Source filtering: Disabled, Flow control: Enabled, Auto-negotiation:
Enabled, Remote fault: Online
 Device flags   : Present Running
 Interface flags: SNMP-Traps Internal: 0x4000
 Link flags : None
 CoS queues : 8 supported, 8 maximum usable queues
 Schedulers : 0
 Current address: 84:18:88:e8:c9:9e, Hardware address: 84:18:88:e8:c9:9e
 Last flapped   : 2011-05-20 11:54:46 EEST (01:08:11 ago)
 Input rate : 6144 bps (8 pps)
 Output rate: 0 bps (0 pps)
 Active alarms  : None
 Active defects : None

 Logical interface ge-2/2/2.0 (Index 75) (SNMP ifIndex 656)
   Flags: SNMP-Traps 0x400 Encapsulation: ENET2
   Input packets : 27981
   Output packets: 600
   Protocol inet, MTU: 4470
 Flags: Sendbcast-pkt-to-re
 Addresses, Flags: Is-Preferred Is-Primary
   Destination: x.x.x.x/30, Local: x.x.x.x, Broadcast: x.x.x.x
   Protocol iso, MTU: 4467
<< or  for full protocol
decode
Address resolution is OFF.
Listening on ge-2/2/2.0, capture size 4488 bytes

TO ERX :

13:04:34.156857 Out 84:18:88:e8:c9:9e > 1:80:c2:0:0:15, 802.3, length 1509:
LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI
NLPID IS-IS (0x83): L2 Lan IIH, src-id 2131.3905.5002, lan-id
2131.3905.5002.00, prio 64, length 1492  <<< PDU length including hello
padding of the MX

FROM ERX :

13:04:35.450255  In 0:90:1a:41:fa:f5 > 1:80:c2:0:0:15, 802.3, length 1514:
LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI
NLPID IS-IS (0x83): L2 Lan IIH, src-id 1921.6801.6029, lan-id
1921.6801.6029.01, prio 64, length 1497  <<< PDU length including hello
padding of the ERX



Trace on ERX :
##



sho int gi 12/0
GigabitEthernet12/0 is Up, Administrative status is Up
 Hardware is PMC 3386, address is 0090.1a41.faf5
 Primary MAU is 1000BASE-LX 10km, secondary MAU is 1000BASE-LX 10km
 MTU: O

Re: [j-nsp] ISIS between ERX 1440 and MX960

2011-05-20 Thread david.roy

Hi, 

I don't know how to go on with the ERX. I tried many things without success. 
More traces below. Thanks for your help : May be a bug ?!?

Regards,
David


ERX :
###

interface loopback 50
 ip address x.x.x.x 255.255.255.255
 no ip redirects
! 
interface gigabitEthernet 12/0
 mtu 4488
 ip address y.y.y.1 255.255.255.252
 no ip redirects
 ip router isis 31337
 isis circuit-type level-2-only
 isis authentication-key level-2 foo123
!
router isis 31337
 is-type level-2-only
 passive-interface loopback50
 net 49.0001....00
 domain-authentication psnp
 domain-authentication csnp
 domain-message-digest-key 1 hmac-md5 foo123 
 metric-style wide
! 


MX : 
###

ge-2/2/2 {
mtu 4484;
unit 0 {
family inet {
address y.y.y.2/30;
}
family iso;
}
}

isis {
level 2 {
authentication-key ""; ## SECRET-DATA = foo123
authentication-type md5;
wide-metrics-only;
}
interface ge-2/2/2.0 {
  level 1 disable;
  level 2 {
  hello-authentication-key "$9$fQ39yrv8xdBIs4aJDjCtpBhS"; ## 
SECRET-DATA = foo123
  hello-authentication-type simple;
  }
   }
}


Trace on MX : 
##

show interfaces ge-2/2/2  
Physical interface: ge-2/2/2, Enabled, Physical link is Up
  Interface index: 251, SNMP ifIndex: 556
  Description: Connection To LNS
  Link-level type: Ethernet, MTU: 4484, Speed: 1000mbps, BPDU Error: None, 
MAC-REWRITE Error: None, Loopback: Disabled,
  Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, 
Remote fault: Online
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x4000
  Link flags : None
  CoS queues : 8 supported, 8 maximum usable queues
  Schedulers : 0
  Current address: 84:18:88:e8:c9:9e, Hardware address: 84:18:88:e8:c9:9e
  Last flapped   : 2011-05-20 11:54:46 EEST (01:08:11 ago)
  Input rate : 6144 bps (8 pps)
  Output rate: 0 bps (0 pps)
  Active alarms  : None
  Active defects : None

  Logical interface ge-2/2/2.0 (Index 75) (SNMP ifIndex 656) 
Flags: SNMP-Traps 0x400 Encapsulation: ENET2
Input packets : 27981 
Output packets: 600
Protocol inet, MTU: 4470
  Flags: Sendbcast-pkt-to-re
  Addresses, Flags: Is-Preferred Is-Primary
Destination: x.x.x.x/30, Local: x.x.x.x, Broadcast: x.x.x.x
Protocol iso, MTU: 4467  << or  for full protocol decode
Address resolution is OFF.
Listening on ge-2/2/2.0, capture size 4488 bytes

TO ERX : 

13:04:34.156857 Out 84:18:88:e8:c9:9e > 1:80:c2:0:0:15, 802.3, length 1509: 
LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID 
IS-IS (0x83): L2 Lan IIH, src-id 2131.3905.5002, lan-id 2131.3905.5002.00, prio 
64, length 1492  <<< PDU length including hello padding of the MX

FROM ERX : 

13:04:35.450255  In 0:90:1a:41:fa:f5 > 1:80:c2:0:0:15, 802.3, length 1514: LLC, 
dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS 
(0x83): L2 Lan IIH, src-id 1921.6801.6029, lan-id 1921.6801.6029.01, prio 64, 
length 1497  <<< PDU length including hello padding of the ERX



Trace on ERX :
##



sho int gi 12/0
GigabitEthernet12/0 is Up, Administrative status is Up
  Hardware is PMC 3386, address is 0090.1a41.faf5
  Primary MAU is 1000BASE-LX 10km, secondary MAU is 1000BASE-LX 10km
  MTU: Operational 4488, Administrative 4488 
<<< MTU seems good
  Duplex Mode: Operational Full Duplex, Administrative Auto Negotiate
  Speed: Operational 1000 Mbps, Administrative Auto Negotiate
  Debounce: State is Disabled 
  Link: Operational Primary Link Selected,
Administrative Link Selected Automatically
  Link Failover Timeout: Operational 727 ms, Administrative default
  Primary link selected 258 times, Secondary link selected 252 times
  Primary link signal detected, Secondary link signal not detected

  No baseline has been set
  5 minute input rate 1024 bits/sec, 0 packets/sec 
  5 minute output rate 19456 bits/sec, 12 packets/sec 

  In: Bytes 789821048435, Unicast 476720
   Multicast 2224876, Broadcast 2088
   Errors 0, Discards 36549, Mac Errors 0, Alignment 0  < IIH 
coming from MX are discarded
   CRC 0, Too Longs 0, Symbol Errors 0
  Out: Bytes 6824490336601, Unicast 6292729944
   Multicast 4577411, Broadcast 103
   Errors 0, Discards 0, Mac Errors 0, Deferred 0, No Carrier 0
   Collisions: Single 0, Multiple 0, Late 0, Excessive 0
Policed Statistics:
  In: 0, Out: 0
ARP Statistics:
  In: ARP requests 211, ARP responses 8
   Errors 0, Discards 6
  Out: ARP requests 103, ARP responses 204
   Errors 0, Discards 7

Administrative qos-shaping-mode: none
Operational qos-shaping-mode: frame
queue 0: traffic class best-effort, bound to ethernet GigabitEthernet12/0
  Queue length 0 bytes 
  Forwarded packets 0, bytes 0
  Dropped committed packets 0, bytes 0
  Dropped conformed

Re: [j-nsp] ISIS between ERX 1440 and MX960

2011-05-19 Thread david.roy

Hi 

Thanks

1. yes

2. I tried but without success. I believe that the ISO MTU is less than the 
padded hello of the MX. I will try to set mtu of the gi 12/0 of the ERX to 1518 
: I will update you if it works

Regards
David
 


 
David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
JNCIE-M/T  #703 ; JNCIS-ENT

-Message d'origine-
De : Kaliraj [mailto:kalir...@gmail.com] 
Envoyé : jeudi 19 mai 2011 20:37
À : ROY David DTF/DERX
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] ISIS between ERX 1440 and MX960

hi david,

1. is the erx interface configured with an ip-address?

http://www.juniper.net/techpubs/software/erx/junose72/swconfig-ip-ipv6-igp/html/isis-config6.html#89040
says erx should have atleast one ip-addres/router-id configured.

2. if yes, then pls try if adjusting hello-padding attributes on both ends. it 
does look like mtu and padding issue. perhaps try adaptive/strict padding on 
junos side to see if there are mtu issues.

kaliraj

On Thu, May 19, 2011 at 10:24 AM,   wrote:
> Hi all,
>
> I'm trying to establish an ISIS L2 adjacency between an ERX (Junose is 
> new for me) and 1 MX without success :  I double checked the mtu, 
> subnet, Area (not checked for L2), authentication key (I tried simple 
> and MD5 types)
>
> The problem seems to be at the ERX side. Indeed, the MX receives well the IIH 
> of the ERX and put its state to Init, then it sends an IIH to the ERX. At the 
> ERX level, IIH is discarded (at the Interface level : Input Discard counter). 
> I don't understand why. I guess there is a MTU issue with the hello padding 
> process but I'm not sure.
>
> Config at the MX side
> ---
>
> ge-2/2/2.0
> {
> family iso;
> faimly inet address 10.1.1.1/30
> }
>
> lo0
> {
> family iso address 49.0001.xxx
> }
>
> protocol isis
> {
> level 2 {
>    authentication-key sdjskdjskd;
>    authentication-type md5;
> }
> interface ge-2/2/2.0 {
> level 1 disable;
> level 2 {
>  hello-authetication-key FOO;
>  hello-authetication-type md5;
> }
> }
>
>
> Config at the ERX side :
>
> router isis 1234
> is-type level-2-only
> net 49.0001.xxx
> domain-message-digest-key 1 hmac-md5 FOO passive-interface loopback50
>
>
> int gi 12/0
> ip router isis 1234
> isis circuit-type level-2-only
> isis message-digest-key 1 hmac-md5 FOO level-2
>
>
> I tried to monitor ISIS packet at the MX side. I noticed that the PDU length 
> of the MX IIH is equal to 1492 and the ERX one is equal to 1497. Moreover, 
> the protocol capabilities of the MX are IPv4 and IPv6 and for the ERX that 
> are CLNP and IPv4.
>
> Any help would be most welcome.
>
> thanks
> Regards,
> David
>
>
>
> 
> IMPORTANT.Les informations contenues dans ce message electronique y compris 
> les fichiers attaches sont strictement confidentielles
> et peuvent etre protegees par la loi.
> Ce message electronique est destine exclusivement au(x) destinataire(s) 
> mentionne(s) ci-dessus.
> Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
> veuillez immediatement le signaler  a l expediteur et effacer ce message
> et tous les fichiers eventuellement attaches.
> Toute lecture, exploitation ou transmission des informations contenues dans 
> ce message est interdite.
> Tout message electronique est susceptible d alteration.
> A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
> il a ete altere, deforme ou falsifie.
> De meme, il appartient au destinataire de s assurer de l absence de tout 
> virus.
>
> IMPORTANT.This e-mail message and any attachments are strictly confidential 
> and may be protected by law. This message is
> intended only for the named recipient(s) above.
> If you have received this message in error, or are not the named 
> recipient(s), please immediately notify the sender and delete this e-mail 
> message.
> Any unauthorized view, usage or disclosure ofthis message is prohibited.
> Since e-mail messages may not be reliable, France Telecom Group shall not be 
> liable for any message if modified, changed or falsified.
> Additionally the recipient should ensure they are actually virus free.
> 
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et e

Re: [j-nsp] ISIS between ERX 1440 and MX960

2011-05-19 Thread david.roy

Hi Payam,

I'm trying with ERX not EX. 

Thanks
David


-Message d'origine-
De : Payam Chychi [mailto:pchy...@gmail.com] 
Envoyé : jeudi 19 mai 2011 19:46
À : ROY David DTF/DERX
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] ISIS between ERX 1440 and MX960

Hey David,


by default on the ex's igmp snooping is active.
disable this on the vlan being used for carry the isis traffic and it will 
build nei adj

cheers
Payam




david@orange-ftgroup.com wrote:
> Hi all,
>
> I'm trying to establish an ISIS L2 adjacency between an ERX (Junose is 
> new for me) and 1 MX without success :  I double checked the mtu, 
> subnet, Area (not checked for L2), authentication key (I tried simple 
> and MD5 types)
>
> The problem seems to be at the ERX side. Indeed, the MX receives well the IIH 
> of the ERX and put its state to Init, then it sends an IIH to the ERX. At the 
> ERX level, IIH is discarded (at the Interface level : Input Discard counter). 
> I don't understand why. I guess there is a MTU issue with the hello padding 
> process but I'm not sure.
>
> Config at the MX side
> ---
>
> ge-2/2/2.0
> {
> family iso;
> faimly inet address 10.1.1.1/30
> }
>
> lo0
> {
> family iso address 49.0001.xxx
> }
>
> protocol isis
> {
> level 2 {
> authentication-key sdjskdjskd;
> authentication-type md5;
> }
> interface ge-2/2/2.0 {
> level 1 disable;
> level 2 {
>  hello-authetication-key FOO;
>  hello-authetication-type md5;
> }
> }
>
>
> Config at the ERX side :
>
> router isis 1234
> is-type level-2-only
> net 49.0001.xxx
> domain-message-digest-key 1 hmac-md5 FOO passive-interface loopback50
>
>
> int gi 12/0
> ip router isis 1234
> isis circuit-type level-2-only
> isis message-digest-key 1 hmac-md5 FOO level-2
>
>
> I tried to monitor ISIS packet at the MX side. I noticed that the PDU length 
> of the MX IIH is equal to 1492 and the ERX one is equal to 1497. Moreover, 
> the protocol capabilities of the MX are IPv4 and IPv6 and for the ERX that 
> are CLNP and IPv4. 
>
> Any help would be most welcome.
>
> thanks
> Regards,
> David
>  
>
>
> 
> IMPORTANT.Les informations contenues dans ce message electronique y compris 
> les fichiers attaches sont strictement confidentielles
> et peuvent etre protegees par la loi.
> Ce message electronique est destine exclusivement au(x) destinataire(s) 
> mentionne(s) ci-dessus.
> Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
> veuillez immediatement le signaler  a l expediteur et effacer ce message 
> et tous les fichiers eventuellement attaches.
> Toute lecture, exploitation ou transmission des informations contenues dans 
> ce message est interdite.
> Tout message electronique est susceptible d alteration.
> A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
> il a ete altere, deforme ou falsifie.
> De meme, il appartient au destinataire de s assurer de l absence de tout 
> virus.
>
> IMPORTANT.This e-mail message and any attachments are strictly confidential 
> and may be protected by law. This message is
> intended only for the named recipient(s) above.
> If you have received this message in error, or are not the named 
> recipient(s), please immediately notify the sender and delete this e-mail 
> message.
> Any unauthorized view, usage or disclosure ofthis message is prohibited.
> Since e-mail messages may not be reliable, France Telecom Group shall not be 
> liable for any message if modified, changed or falsified.
> Additionally the recipient should ensure they are actually virus free.
> 
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>   



IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have r

[j-nsp] ISIS between ERX 1440 and MX960

2011-05-19 Thread david.roy

Hi all,

I'm trying to establish an ISIS L2 adjacency between an ERX (Junose is new for 
me) and 1 MX without success :  I double checked the mtu, subnet, Area (not 
checked for L2), authentication key (I tried simple and MD5 types)

The problem seems to be at the ERX side. Indeed, the MX receives well the IIH 
of the ERX and put its state to Init, then it sends an IIH to the ERX. At the 
ERX level, IIH is discarded (at the Interface level : Input Discard counter). I 
don't understand why. I guess there is a MTU issue with the hello padding 
process but I'm not sure.

Config at the MX side
---

ge-2/2/2.0
{
family iso;
faimly inet address 10.1.1.1/30
}

lo0
{
family iso address 49.0001.xxx
}

protocol isis
{
level 2 {
authentication-key sdjskdjskd;
authentication-type md5;
}
interface ge-2/2/2.0 {
level 1 disable;
level 2 {
 hello-authetication-key FOO;
 hello-authetication-type md5;
} 
}


Config at the ERX side :

router isis 1234
is-type level-2-only
net 49.0001.xxx
domain-message-digest-key 1 hmac-md5 FOO
passive-interface loopback50


int gi 12/0
ip router isis 1234
isis circuit-type level-2-only
isis message-digest-key 1 hmac-md5 FOO level-2


I tried to monitor ISIS packet at the MX side. I noticed that the PDU length of 
the MX IIH is equal to 1492 and the ERX one is equal to 1497. Moreover, the 
protocol capabilities of the MX are IPv4 and IPv6 and for the ERX that are CLNP 
and IPv4. 

Any help would be most welcome.

thanks
Regards,
David
 



IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.



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

[j-nsp] 802.3ah OAM LFM

2011-05-16 Thread david.roy

Hi all,

I would appreciate to have any feedback regarding 802.3ah OAM Link-Fault 
Management on MX (DPC and MPC) and T series (FPC3 T640 and FPC4 for T1600).
Does it work well ? Did you experience some issues ?

Thanks a lot
Regards
David




IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.


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

Re: [j-nsp] SFP+ ZR module

2011-04-13 Thread david.roy

Hi,

In which MPC ? 16x10GE ? 

What is the manufactor of the SFP+ ?

Thks
David



 
David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
JNCIE-M/T  #703 ; JNCIS-ENT

-Message d'origine-
De : bas [mailto:kilo...@gmail.com] 
Envoyé : mercredi 13 avril 2011 13:37
À : ROY David DTF/DERX; juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] SFP+ ZR module

On Wed, Apr 13, 2011 at 12:11 PM,   wrote:
> Does anybody know if Juniper's MPC cards support SFP+ ZR (80km) modules ?

They work.
It's just junos doesn't recognise them (yet)

--
show interfaces diagnostics optics xe-5/3/1 Physical interface: xe-5/3/1
Laser bias current:  62.206 mA
Laser output power:  1.7770 mW / 2.50 dBm
Receiver signal average optical power :  0.0352 mW / -19.53 dBm
Laser bias current high alarm :  Off
Laser bias current low alarm  :  Off
Laser bias current high warning   :  Off
Laser bias current low warning:  Off
Laser output power high alarm :  Off
Laser output power low alarm  :  Off
Laser output power high warning   :  Off
Laser output power low warning:  Off
Module temperature high alarm :  Off
Module temperature low alarm  :  Off
Module temperature high warning   :  Off
Module temperature low warning:  Off
Module voltage high alarm :  Off
Module voltage low alarm  :  Off
Module voltage high warning   :  Off
Module voltage low warning:  Off
Laser rx power high alarm :  Off
Laser rx power low alarm  :  Off
Laser rx power high warning   :  Off
Laser rx power low warning:  Off
Laser bias current high alarm threshold   :  85.000 mA
Laser bias current low alarm threshold:  10.000 mA
Laser bias current high warning threshold :  80.000 mA
Laser bias current low warning threshold  :  12.000 mA
Laser output power high alarm threshold   :  5.0110 mW / 7.00 dBm
Laser output power low alarm threshold:  0.5010 mW / -3.00 dBm
Laser output power high warning threshold :  3.9810 mW / 6.00 dBm
Laser output power low warning threshold  :  0.6310 mW / -2.00 dBm
Module temperature high alarm threshold   :  85 degrees C / 185 degrees F
Module temperature low alarm threshold:  -10 degrees C / 14 degrees F
Module temperature high warning threshold :  80 degrees C / 176 degrees F
Module temperature low warning threshold  :  -5 degrees C / 23 degrees F
Module voltage high alarm threshold   :  3.700 V
Module voltage low alarm threshold:  2.900 V
Module voltage high warning threshold :  3.599 V
Module voltage low warning threshold  :  3.000 V
Laser rx power high alarm threshold   :  0.2512 mW / -6.00 dBm
Laser rx power low alarm threshold:  0.0020 mW / -26.99 dBm
Laser rx power high warning threshold :  0.1995 mW / -7.00 dBm
Laser rx power low warning threshold  :  0.0025 mW / -26.02 dBm



---
show chassis hardware
Hardware inventory:
Item Version  Part number  Serial number Description
  PIC 3   BUILTIN  BUILTIN   4x 10GE(LAN) SFP+
Xcvr 1   REV 01   740-011613   H36TR015  UNKNOWN
---


IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally

[j-nsp] SFP+ ZR module

2011-04-13 Thread david.roy

Sorry : Duplicated mail - but the previous one had the bad object :-) 

 
Hi all,

Does anybody know if Juniper's MPC cards support SFP+ ZR (80km) modules ? 

Thanks
Regards
David


 
David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
JNCIE-M/T  #703 ; JNCIS-ENT

IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles et peuvent etre protegees 
par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message et 
tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is intended only for the named 
recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.



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


IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.



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

Re: [j-nsp] MX80 - restricted bundles and disabled 10G ports.

2011-04-13 Thread david.roy

 
Hi all,

Does anybody know if Juniper's MPC cards support SFP+ ZR (80km) modules ? 

Thanks
Regards
David


 
David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
JNCIE-M/T  #703 ; JNCIS-ENT

IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.



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

Re: [j-nsp] Too much packet loss during switchover on MPLS network

2011-03-14 Thread david.roy

Sorry,

Which release ?

Your secondary path is well in Standby mode ?

Could you enable traffic stat for LSP with a short interval ? And check during 
the blackholing where the LSP is broken on the path (by checking LSP stat on 
nodes before and after the failure ) ?



thks
regards
David


David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
JNCIE-M/T  #703 ; JNCIS-ENT



De : Gökhan Gümüş [mailto:ggu...@gmail.com]
Envoyé : lundi 14 mars 2011 21:11
À : ROY David DTF/DERX
Cc : Keegan Holley; juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Too much packet loss during switchover on MPLS network

Actually i am using MX960 routers.

Did you monitor forwarding database on each PE to check if there is any change 
(MAC address refresh) after your 41 sec of outage ?

- I need to re-test it. Currently i can not say it.

Did you experience the same issue when your primary LSP comes up (and after the 
revert timout) ?

No there is no packet loss during transition from secondary to primary.

Thanks and regards,
Gokhan


2011/3/14 mailto:david@orange-ftgroup.com>>
Hi,

Which version and HW do you use ?

Did you monitor forwarding database on each PE to check if there is any change 
(MAC address refresh) after your 41 sec of outage ?

Did you experience the same issue when your primary LSP comes up (and after the 
revert timout) ?

Regards
David


David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
JNCIE-M/T  #703 ; JNCIS-ENT

-Message d'origine-
De : 
juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net]
 De la part de Gökhan Gümüs
Envoyé : lundi 14 mars 2011 20:52
À : Keegan Holley
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Too much packet loss during switchover on MPLS network

Hi,

Actually customer BGP session is always up. I requested them to ping from 
different servers to the same destination when i shut the interface down.All of 
them had no reachability to the remote destinations.
Could it be possible to fix it with BFD?

Thanks,
Gokhan

On Mon, Mar 14, 2011 at 8:46 PM, Keegan Holley 
mailto:keegan.hol...@sungard.com>>wrote:

> Another to way to check would be to figure out when you start seeing
> mac-addresses from the customer in the vpls tables.  That will mean
> the network has failed over properly.  Do you know what the customer
> topology looks like?  They could be waiting for BGP to fail over or
> something else that inherently slow.  I doubt this is a problem with
> your mpls config, especially if you see your lsp switch.  It's hard to
> guess without knowing your's or the customer's topology though.
>
>
> On Mon, Mar 14, 2011 at 3:42 PM, Gökhan Gümüş 
> mailto:ggu...@gmail.com>> wrote:
>
>> No, they are not using rapid ping, i can confirm it.
>>
>> I do not agree with Spanning tree issue.
>> Just for note, i am just de-activating one circuit via CLI to trigger
>> transition from primary to secondary.
>>
>> Gokhan
>>
>>
>>
>> 2011/3/14 Doug Hanks mailto:dha...@juniper.net>>
>>
>>> I'm sure they were using a rapid ping, so it didn't take anywhere
>>> near 45 seconds.  If they were using a regular ping, however, it maybe a 
>>> STP issue.
>>>
>>> Also are you using pre-signaled LSPs?
>>>
>>> -Original Message-
>>> From: 
>>> juniper-nsp-boun...@puck.nether.net
>>>  [mailto:
>>> juniper-nsp-boun...@puck.nether.net]
>>>  On Behalf Of Keegan Holley
>>> Sent: Monday, March 14, 2011 11:15 AM
>>> To: Diogo Montagner
>>> Cc: juniper-nsp@puck.nether.net; Gökhan 
>>> Gümüş
>>> Subject: Re: [j-nsp] Too much packet loss during switchover on MPLS
>>> network
>>>
>>> On Mon, Mar 14, 2011 at 1:25 PM, Diogo Montagner
>>> mailto:diogo.montag...@gmail.com>>wrote:
>>>
>>> > Do you have FRR enabled on the LSPs ?
>>> >
>>>
>>> Node protection and link-protection is the same thing as fast re-route.
>>>
>>> Is it configured correctly though?  You have to configure a
>>> secondary path under protocols mpls and then enable it for FRR/node
>>> protection.  You can't just enable it and have it work.
>>> Also, what does the topology look like?  Could you just be waiting
>>> for customer routing/spanning tree?  Even without FRR your lsp's
>>> failover at the speed of your IGP when a link is shut down.  None of
>>> them take 41 seconds.
>>>
>>> >
>>> >
>>> > On Tue, Mar 15, 2011 at 12:46 AM, Gökhan Gümüş 
>>> > mailto:ggu...@gmail.com>>
>>> wrote:
>>> > > Dear all,
>>> > >
>>> > > I have a problem with one of our customer.
>>> > >
>>> > > Customer has been deployed with VPLS. We are

Re: [j-nsp] Too much packet loss during switchover on MPLS network

2011-03-14 Thread david.roy

Hi,

Which version and HW do you use ? 

Did you monitor forwarding database on each PE to check if there is any change 
(MAC address refresh) after your 41 sec of outage ?

Did you experience the same issue when your primary LSP comes up (and after the 
revert timout) ? 

Regards
David

 
David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
JNCIE-M/T  #703 ; JNCIS-ENT

-Message d'origine-
De : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de Gökhan Gümüs
Envoyé : lundi 14 mars 2011 20:52
À : Keegan Holley
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Too much packet loss during switchover on MPLS network

Hi,

Actually customer BGP session is always up. I requested them to ping from 
different servers to the same destination when i shut the interface down.All of 
them had no reachability to the remote destinations.
Could it be possible to fix it with BFD?

Thanks,
Gokhan

On Mon, Mar 14, 2011 at 8:46 PM, Keegan Holley wrote:

> Another to way to check would be to figure out when you start seeing 
> mac-addresses from the customer in the vpls tables.  That will mean 
> the network has failed over properly.  Do you know what the customer 
> topology looks like?  They could be waiting for BGP to fail over or 
> something else that inherently slow.  I doubt this is a problem with 
> your mpls config, especially if you see your lsp switch.  It's hard to 
> guess without knowing your's or the customer's topology though.
>
>
> On Mon, Mar 14, 2011 at 3:42 PM, Gökhan Gümüş  wrote:
>
>> No, they are not using rapid ping, i can confirm it.
>>
>> I do not agree with Spanning tree issue.
>> Just for note, i am just de-activating one circuit via CLI to trigger 
>> transition from primary to secondary.
>>
>> Gokhan
>>
>>
>>
>> 2011/3/14 Doug Hanks 
>>
>>> I'm sure they were using a rapid ping, so it didn't take anywhere 
>>> near 45 seconds.  If they were using a regular ping, however, it maybe a 
>>> STP issue.
>>>
>>> Also are you using pre-signaled LSPs?
>>>
>>> -Original Message-
>>> From: juniper-nsp-boun...@puck.nether.net [mailto:
>>> juniper-nsp-boun...@puck.nether.net] On Behalf Of Keegan Holley
>>> Sent: Monday, March 14, 2011 11:15 AM
>>> To: Diogo Montagner
>>> Cc: juniper-nsp@puck.nether.net; Gökhan Gümüş
>>> Subject: Re: [j-nsp] Too much packet loss during switchover on MPLS 
>>> network
>>>
>>> On Mon, Mar 14, 2011 at 1:25 PM, Diogo Montagner
>>> wrote:
>>>
>>> > Do you have FRR enabled on the LSPs ?
>>> >
>>>
>>> Node protection and link-protection is the same thing as fast re-route.
>>>
>>> Is it configured correctly though?  You have to configure a 
>>> secondary path under protocols mpls and then enable it for FRR/node 
>>> protection.  You can't just enable it and have it work.
>>> Also, what does the topology look like?  Could you just be waiting 
>>> for customer routing/spanning tree?  Even without FRR your lsp's 
>>> failover at the speed of your IGP when a link is shut down.  None of 
>>> them take 41 seconds.
>>>
>>> >
>>> >
>>> > On Tue, Mar 15, 2011 at 12:46 AM, Gökhan Gümüş 
>>> wrote:
>>> > > Dear all,
>>> > >
>>> > > I have a problem with one of our customer.
>>> > >
>>> > > Customer has been deployed with VPLS. We are using primary path 
>>> > > and secondary path ( standby ) to handle VPLS traffic between sites.
>>> > >
>>> > > Within a maintenance window, we made a failover test. Customer 
>>> > > was
>>> > pinging
>>> > > remote site continuosly and we would like to test how many 
>>> > > packets
>>> are
>>> > being
>>> > > lost during switchover. When i triggered transition from primary 
>>> > > to secondary, customer lost 41 packets during ping test. Then i
>>> implemented
>>> > > node-link-protection and link protection in case they help but
>>> customer
>>> > > experienced same amount of packet loss during transition.
>>> > >
>>> > > My question, is it a normal behaviour? From my perspective it is 
>>> > > not
>>> a
>>> > > normal behaviour.
>>> > >
>>> > > Has anybody such an experince?
>>> > >
>>> > > Thanks and regards,
>>> > >
>>> > > Gokhan
>>> > > ___
>>> > > 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
>>>
>>
>>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp

IMPORTANT.Les informati

Re: [j-nsp] SFTP on junos 9.0 routers

2011-03-02 Thread david.roy

Hi,

You can use scp. 

Regards,
David
 


 
David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
JNCIE-M/T  #703 ; JNCIS-ENT

-Message d'origine-
De : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de meryem Z
Envoyé : mercredi 2 mars 2011 13:41
Cc : juniper-nsp@puck.nether.net
Objet : [j-nsp] SFTP on junos 9.0 routers


Hello community,

Is secure ftp supported on juniper m-series routers running junos OS 9.0 ? what 
are alternatives to secure ftp tranfers ?


Thank you.




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


IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.



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

Re: [j-nsp] Debug vmcore files

2011-03-01 Thread david.roy

Hi,

You can also use the cli command : show system core-dumps core-file-info detail 

Regards,
David

David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com
JNCIE-M/T  #703 ; JNCIS-ENT

-Message d'origine-
De : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de Scott T. Cameron
Envoyé : mardi 1 mars 2011 15:02
À : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Debug vmcore files

Here's an example below.  You'll either need to use gdb on the box itself, or 
get/xcompile a powerpc-freebsd gdb.

Again, without source, you're not going to get far.

% tar zvxf /var/tmp/chassisd.core-tarball.4.tgz
chassisd.core.4.gz
juniper.conf.gz
messages
chassisd.info.4
juniper.conf.1.gz
% gzip -d chassisd.core.4.gz
% gdb /usr/sbin/chassisd chassisd.core.4 GNU gdb 6.5 [juniper_2006a_411] 
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are 
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-specifix.com-freebsd"...(no debugging 
symbols found)

Reading symbols from /usr/lib/libddl-access.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libddl-access.so.1 Reading symbols from 
/usr/lib/libjipc.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libjipc.so.1 Reading symbols from 
/usr/lib/libberkeley-db.so.4...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libberkeley-db.so.4 Reading symbols from 
/usr/lib/libthr.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libthr.so.2
Reading symbols from /usr/lib/libisc.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libisc.so.2
Reading symbols from /usr/lib/libkvm.so.3...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkvm.so.3
Reading symbols from /usr/lib/libfasic.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libfasic.so.1 Reading symbols from 
/usr/lib/libhsl2.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libhsl2.so.1 Reading symbols from 
/usr/lib/libcmb.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libcmb.so.1
Reading symbols from /usr/lib/libcnh.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libcnh.so.1
Reading symbols from /usr/lib/libjpci.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libjpci.so.1 Reading symbols from 
/usr/lib/libm.so.4...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libm.so.4
Reading symbols from /usr/lib/libfabric2.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libfabric2.so.1 Reading symbols from 
/usr/lib/libfabric1.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libfabric1.so.1 Reading symbols from 
/usr/lib/libprovider.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libprovider.so.1 Reading symbols from 
/usr/lib/libiic.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libiic.so.1
Reading symbols from /usr/lib/libcam.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libcam.so.3
Reading symbols from /usr/lib/libsbuf.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsbuf.so.3 Reading symbols from 
/usr/lib/libutil.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libutil.so.5 Reading symbols from 
/usr/lib/libgcc.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgcc.so.1
Reading symbols from /usr/lib/libc.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libc.so.6
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/libexec/ld-elf.so.1 Core was generated by `chassisd'.
Program terminated with signal 6, Aborted.
#0  0x42683428 in kill () from /usr/lib/libc.so.6 [New Thread 0x2057000 (LWP 
100110)]
(gdb) bt
#0  0x42683428 in kill () from /usr/lib/libc.so.6
#1  0x421d8a30 in raise () from /usr/lib/libthr.so.2
#2  0x42681e88 in abort () from /usr/lib/libc.so.6
#3  0x01c00c64 in vlogging_event ()
#4  0x01c00af4 in vlogging ()
#5  0x01c00ce4 in logging ()
#6  0x01ab9670 in pic_clean_init ()
#7  0x01a16308 in mcontrol_check_backup_active ()
#8  0x01a16e20 in msm_exec ()
#9  0x01a17b2c in mcontrol_init ()
#10 0x019365e4 in ch_init ()
#11 0x01938640 in ch_a2_fru_map_set_context ()
#12 0x01ab3620 in allocadupx ()
#13 0x01ab44bc in main ()
(gdb) x 0x01a16308
0x1a16308 :   0x3d200201

On Tue, Mar 1, 2011 at 7:29 AM, meryem Z  wrote:

>  You mean kgdb i guess. this tool is available on juniper routers on 
> /var/bin.
> I'm wondering if anyone has te

[j-nsp] RE : SNMP if-mib stops responding

2011-02-15 Thread david.roy

Hi 

We encountered this issue in 10.2R3 (fixed in 10.2S6.3). Mib2d and PFED become 
stuck due to a bug (PR). You need to restart the pfed process (it manages PFE 
stats : no issue if you  restart it). 

Kill, via the shell, the PFEd process (there is no restart via cli). it will 
restart then. 

Regards,
David

De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
de la part de Pekka Savola [pek...@netcore.fi]
Date d'envoi : mardi 15 février 2011 18:50
À : Ido Szargel
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] SNMP if-mib stops responding

On Tue, 15 Feb 2011, Ido Szargel wrote:
> We have tried to restart both the mib-process and the snmp.
> Even with local snmpwalk we don't see any interfaces:

In many cases like these, we've had to restart chassisd
(chassis-control).  This is service-impacting.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

IMPORTANT. 
Les informations contenues dans ce message électronique y compris les fichiers 
attachés sont strictement confidentielles et peuvent être protégées par la loi.
Ce message électronique est destiné exclusivement au(x) destinataire(s) 
mentionné(s) ci-dessus. 
Si vous avez reçu ce message par erreur ou s'il ne vous est pas destiné, 
veuillez immédiatement le signaler à l'expéditeur et effacer ce message et tous 
les fichiers éventuellement attachés.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite. 
Tout message électronique est susceptible d'altération.
A ce titre, le Groupe France Télécom décline toute responsabilité notamment 
s'il a été altéré, déformé ou falsifié.
De même, il appartient au destinataire de s'assurer de l'absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is intended only for the named 
recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure of this message is prohibited. 
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.

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

Re: [j-nsp] JNCIS-ENT - Software to prepare for exam

2010-12-22 Thread david.roy

Thank you. 

David Roy
Orange France - RBCI IP Technical Assistance Center
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com

-Message d'origine-
De : Jared Gull [mailto:jmg...@yahoo.com] 
Envoyé : mercredi 22 décembre 2010 15:53
À : juniper-nsp@puck.nether.net; ROY David DTF/DERX
Objet : Re: [j-nsp] JNCIS-ENT - Software to prepare for exam

Hi David,

I'm not aware of any Boson or boson-like tests out there but the fast track 
portal does offer free routing and switching study guides and assessment tests. 
These study guides and assessment tests are great resources for this test. If 
you don't have it, the URL for the fast track is below:

http://www.juniper.net/us/en/training/fasttrack/

Jared

--- On Wed, 12/22/10, david@orange-ftgroup.com 
 wrote:

> From: david@orange-ftgroup.com 
> Subject: [j-nsp] JNCIS-ENT - Software to prepare for exam
> To: "juniper-nsp@puck.nether.net" 
> Date: Wednesday, December 22, 2010, 3:24 AM Hi all,
> 
> Is there a tool, like Boson software, to prepare for the new JNCIS-ENT 
> exam ?
> 
> thks,
> regards,
> David
> 
> 
> 
> 
> 
> 
> *
> This message and any attachments (the "message") are confidential and 
> intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration. 
> France Telecom Group shall not be liable for the message if altered, 
> changed or falsified.
> If you are not the intended addressee of this message, please cancel 
> it immediately and inform the sender.
> 
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 

*
This message and any attachments (the "message") are confidential and intended 
solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or 
falsified.
If you are not the intended addressee of this message, please cancel it 
immediately and inform the sender.

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

[j-nsp] JNCIS-ENT - Software to prepare for exam

2010-12-22 Thread david.roy

Hi all,

Is there a tool, like Boson software, to prepare for the new JNCIS-ENT exam ?

thks,
regards,
David






*
This message and any attachments (the "message") are confidential and intended 
solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or 
falsified.
If you are not the intended addressee of this message, please cancel it 
immediately and inform the sender.


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

[j-nsp] "Total packets" OID

2010-08-31 Thread david.roy

Hi all,

Is-there a specific OID to get the "total input packets" of a specific 
interface (that we show with the cli commands show interface xe-x/x/x ext).
I saw the if-mib and the jnx-if-extension mibs but we've only separate counter 
for unicast, broadcast and mcast in the if-mib and nothing in the jnx mib (only 
pps).

thanks,
regards



David Roy
Orange France - RBCI IP Technical Assistance Center
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.com



*
This message and any attachments (the "message") are confidential and intended 
solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or 
falsified.
If you are not the intended addressee of this message, please cancel it 
immediately and inform the sender.


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

1 2 >

1 - 100 of 157 matches

Mail list logo