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 
>

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;

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

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

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

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] 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] 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 mark.ti...@seacom.mu 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 
 euang+juniper-...@lists.eusahues.co.uk 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 jneiber...@gmail.com 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 prefix, 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

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

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

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

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.connectoway.com.br/ 
http://www.1telecom.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 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.connectoway.com.br/ 
http://www.1telecom.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 for messages that have been 
modified, changed or falsified.
Thank you.

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 jneiber...@gmail.com 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] 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 robh...@gmail.com 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 t...@wirkbetrieb.net 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] 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 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 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 
dim0...@hotmail.commailto: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.commailto:david@orange.com
Data:
A: R S dim0...@hotmail.commailto:dim0...@hotmail.com,John Neiberger 
jneiber...@gmail.commailto:jneiber...@gmail.com
Cc: juniper-nsp@puck.nether.netmailto: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.netmailto:juniper-nsp-boun...@puck.nether.net]
 de la part de R S [dim0...@hotmail.commailto:dim0...@hotmail.com]
Date d'envoi : mardi 16 juillet 2013 18:55
À : John Neiberger
Cc : juniper-nsp@puck.nether.netmailto: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.commailto:jneiber...@gmail.com
Date: Tue, 16 Jul 2013 10:42:18 -0600
Subject: Re: [j-nsp] multicast issue
To: dim0...@hotmail.commailto:dim0...@hotmail.com
CC: juniper-nsp@puck.nether.netmailto: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 
dim0...@hotmail.commailto: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.netmailto:juniper-nsp@puck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp



___
juniper-nsp mailing list 
juniper-nsp@puck.nether.netmailto: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,

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 mark.ti...@seacom.mu 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 g...@teksavvy.ca 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 
drew.wea...@thenap.commailto: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.comhttp://weebly.com]
Sent: Friday, June 28, 2013 5:52 PM
To: Gabriel Blanchard
Cc: Drew Weaver; juniper-nsp@puck.nether.netmailto: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 
g...@teksavvy.camailto:g...@teksavvy.ca wrote:
I tried 12.3. Crashed within 24h

On 2013-06-28, at 2:59 PM, Drew Weaver 
drew.wea...@thenap.commailto: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.commailto:richard.he...@weebly.com]
 Sent: Friday, June 28, 2013 2:58 PM
 To: Drew Weaver
 Cc: juniper-nsp@puck.nether.netmailto: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 
 richard.he...@weebly.commailto:richard.he...@weebly.commailto:richard.he...@weebly.commailto: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 
 drew.wea...@thenap.commailto:drew.wea...@thenap.commailto:drew.wea...@thenap.commailto: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.netmailto:juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


 ___
 juniper-nsp mailing list 
 juniper-nsp@puck.nether.netmailto: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

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-MT/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] 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-MT/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-MT/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] 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 wrx...@gmail.com 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 chm...@wm.edu 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-nsphttps://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-MT/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-requestjuniper-nsp-requ...@puck.nether.net;Date:  Mon, Mar 11, 
2013 00:00 AMTo:  juniper-nspjuniper-nsp@puck.nether.net; 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 ab_ferha...@hotmail.co.uk
To: juniper juniper juniper-nsp@puck.nether.net
Subject: [j-nsp] JNCIE-SP LAB Exam
Message-ID: dub115-w137c2d617a8f2c27cbd340aca...@phx.gbl
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-MT/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 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.commailto:david@orange.com

JNCIE-MT/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

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


___
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 
l...@ninefold.commailto: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.commailto:david@orange.com 
[mailto:david@orange.com]
Sent: Wednesday, 13 February 2013 8:24 AM
To: Luca Salvatore
Cc: juniper-nsp@puck.nether.netmailto: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 
l...@ninefold.commailto: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.netmailto: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.

___

[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.commailto:david@orange.com

JNCIE-MT/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] 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-MT/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

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-MT/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-MT/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 mailing list

[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 dha...@juniper.net a écrit :


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


On 10/23/12 2:38 AM, Paul Vlaar p...@vlaar.net 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] 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 p...@vlaar.net 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] 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-MT/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 nop,nop,timestamp
976623188 976594278

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 nop,nop,timestamp 976623190 976623188

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 nop,nop,timestamp 976623268 976623190

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 nop,nop,timestamp 976623268 976623268




*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

[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.commailto:david@orange.com

JNCIE-MT/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] 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-MT/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] 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 Steenbergen r...@e-gerbil.net   http://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-MT/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 obri...@missouri.edu 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 biwa...@gmail.com 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.commailto: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,  david@orange-ftgroup.com 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-06 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.commailto: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 dan...@shunoshu.net wrote:

On Fri, Jul 22, 2011 at 22:14, Stefan Fouant
sfou...@shortestpathfirst.net 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

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.commailto: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 : 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

[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

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: david@orange-ftgroup.com
To: Ben Dale bd...@comlinx.com.au
Cc: juniper-nsp@puck.nether.net
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, david@orange-ftgroup.com 
david@orange-ftgroup.com 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

[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.commailto: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 : 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, david@orange-ftgroup.com
david@orange-ftgroup.com 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

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

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

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

[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, 
david@orange-ftgroup.commailto:david@orange-ftgroup.com wrote:
Hi,

Did you try to check the time at PFE level :

request pfe execute command show sntp target fpcX

Regards,
David

De : 
juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net 
[juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net]
 de la part de David Lockuan [dlock...@gmail.commailto:dlock...@gmail.com]
Date d'envoi : mercredi 8 juin 2011 19:52
À : juniper-nsp@puck.nether.netmailto: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

[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, 
david@orange-ftgroup.commailto:david@orange-ftgroup.com wrote:
Hi,

Did you try to check the time at PFE level :

request pfe execute command show sntp target fpcX

Regards,
David

De : 
juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net 
[juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net]
 de la part de David Lockuan [dlock...@gmail.commailto:dlock...@gmail.com]
Date d'envoi : mercredi 8 juin 2011 19:52
À : juniper-nsp@puck.nether.netmailto: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

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

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 received this message in error, or are not the named recipient(s), 
please immediately notify the sender

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

2011-05-19 Thread david.roy

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

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

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 keegan.hol...@sungard.comwrote:

 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üş 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 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
 diogo.montag...@gmail.comwrote:

  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üş ggu...@gmail.com
 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 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

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.commailto: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 david@orange-ftgroup.commailto: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)299876472tel:%2B33%280%29299876472
Mob. +33(0)685522213tel:%2B33%280%29685522213
Email. david@orange-ftgroup.commailto:david@orange-ftgroup.com
JNCIE-M/T  #703 ; JNCIS-ENT

-Message d'origine-
De : 
juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.netmailto: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.netmailto: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 
keegan.hol...@sungard.commailto:keegan.hol...@sungard.comwrote:

 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üş 
 ggu...@gmail.commailto: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 dha...@juniper.netmailto: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.netmailto:juniper-nsp-boun...@puck.nether.net
  [mailto:
 juniper-nsp-boun...@puck.nether.netmailto: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.netmailto: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
 diogo.montag...@gmail.commailto:diogo.montag...@gmail.comwrote:

  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üş 
  ggu...@gmail.commailto:ggu...@gmail.com
 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

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

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 mcontrol_check_backup_active+364:   0x3d200201

On Tue, Mar 1, 2011 at 7:29 AM, meryem Z merye...@hotmail.com wrote:

  You mean kgdb i guess. this tool is available on

[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

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 
david@orange-ftgroup.com wrote:

 From: david@orange-ftgroup.com david@orange-ftgroup.com
 Subject: [j-nsp] JNCIS-ENT - Software to prepare for exam
 To: juniper-nsp@puck.nether.net 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] 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.commailto: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

Re: [j-nsp] Disable ICMP Time Exceeded

2010-04-30 Thread david.roy

Hi,

Yes ICMP is handled by the CPU of the PFE. We can check ICMP throttled at this 
level.  
As you said, a firewall filter at the interface level works. Thank you

Regards,
David



 
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 : Richard A Steenbergen [mailto:r...@e-gerbil.net] 
Envoyé : vendredi 30 avril 2010 00:23
À : ROY David DTF/DERX
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Disable ICMP Time Exceeded

On Thu, Apr 29, 2010 at 05:04:20PM +0200, david@orange-ftgroup.com wrote:
 Hi all,
 
 Is-there a way to disable or rate-limit (in junos) the sending of ICMP 
 Time Exceeded when the box receives datagrams with a TTL expired.

Not directly afaik. You could firewall packets that are about to TTL expire, so 
they never get processed in the first place. The ICMP generation is handled by 
the PFE CPU, so I'm not sure if a lo0 filter would affect that, but a physical 
interface filter should work.

Usually the issue is the opposite from the hard coded ICMP generation rate 
limit which you can't tweak, i.e. as soon as some customer points a default 
route back at you and creates a small routing loop your router starts looking 
shitty in traceroute and even idiot on the Internet with mtr and/or visual 
traceroute descends upon your noc email/phone like a swarm of locusts. You 
haven't lived until you've received a complaint in the form of a windows 
desktop screenshot of a tracert.exe window embedded in a word document, zipped, 
with porn windows open in the background.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

*
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] Disable ICMP Time Exceeded

2010-04-29 Thread david.roy

Hi all,

Is-there a way to disable or rate-limit (in junos) the sending of ICMP Time 
Exceeded when the box receives datagrams with a TTL expired.

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

Re: [j-nsp] BGP tcp-mss

2010-03-22 Thread david.roy

Hi,

Just for info. A new PR 514196 has been opened to track this issue.

Regards,
David
 


 
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 : Harry Reynolds [mailto:ha...@juniper.net] 
Envoyé : mercredi 3 février 2010 17:10
À : ROY David DTF/DERX; juniper-nsp@puck.nether.net
Objet : RE: BGP tcp-mss

I believe so. I only scanned, but did not seem platform or pmtu related.

Regards

 

-Original Message-
From: david@orange-ftgroup.com [mailto:david@orange-ftgroup.com]
Sent: Wednesday, February 03, 2010 2:39 AM
To: Harry Reynolds; juniper-nsp@puck.nether.net
Subject: RE: BGP tcp-mss

 
Hi,

Path MTU Discovery is disabled and I have the problem with MX, T640 and T1600 
platforms. 
Do you think that the PR might include my case as well ? 

Regards,
David


 
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 : Harry Reynolds [mailto:ha...@juniper.net] Envoyé : mercredi 3 février 2010 
02:22 À : ROY David DTF/DERX; juniper-nsp@puck.nether.net Objet : RE: BGP 
tcp-mss

Sounds like case 2009-0127-0051, which seems to have been fixed via pr 390993 
around 9.4.

Hths

Harry






-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
david@orange-ftgroup.com
Sent: Tuesday, February 02, 2010 6:55 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] BGP tcp-mss

Hi all,

Do you why, when I set the tcp-mss to 4096 between to BGP neighbors, this one 
is well exchange between the TCP Connection Establishment but when I check the 
mss via the command show system connection extensive I see that the mss used 
is 2048 (the half).

R1 config - lo0 172.20.223.6 :

  neighbor 172.20.223.5 {
tcp-mss 4096;
}
R2 config - lo0 172.20.223.5

  neighbor 172.20.223.6 {
tcp-mss 4096;
}

One Link between R1 and R2 with MTU set to 4484.

TCPDUMP output on R2 - we see that 4096 is well exchanged :

15:49:29.681732 Out IP 172.20.223.5.55025  172.20.223.6.179: S 
2338565447:2338565447(0) win 16384 mss 4096,nop,wscale 0,nop,nop,timestamp 
2417320394 0,sackOK,eol
15:49:29.682439  In IP 172.20.223.6.179  172.20.223.5.55025: S 
1139135010:1139135010(0) ack 2338565448 win 16384 mss 4096,nop,wscale 
0,nop,nop,timestamp 455578404 2417320394,sackOK,eol
15:49:29.682455 Out IP 172.20.223.5.55025  172.20.223.6.179: . ack 1 win 16384 
nop,nop,timestamp 2417320394 455578404


On R2 : show system connection extensive | find 172.20.223.6

tcp4   0  0  172.20.223.5.55025
172.20.223.6.179  ESTABLISHED
   sndsbcc:  0 sndsbmbcnt:  0  sndsbmbmax: 131072
sndsblowat:   2048 sndsbhiwat:  16384
   rcvsbcc:  0 rcvsbmbcnt:  0  rcvsbmbmax: 131072
rcvsblowat:  1 rcvsbhiwat:  16384
   proc id:   1131  proc name:rpd
   iss: 2338565447  sndup: 2338567245
snduna: 2338567245 sndnxt: 2338567245  sndwnd:  16384
sndmax: 2338567245sndcwnd:   4096 sndssthresh: 1073725440
   irs: 1139135010  rcvup: 1139136242
rcvnxt: 1139136261 rcvadv: 1139152645  rcvwnd:  16384
   rtt:  0   srtt:   2230rttv:574
rxtcur:   1200   rxtshift:  0   rtseq: 2338567226
rttmin:   1000  mss:   2048


N.B: Release 9.3

Thank you
Regards,
David


David Roy
Orange France - RBCI IP Technical Assistance Center
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.commailto: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

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



*
This message and any attachments (the message) are

Re: [j-nsp] Verify loss priority for a forwarding class

2010-03-10 Thread david.roy

Hi,

You can view drops at the fabric level via the command :
 
 show class-of-service fabric statistics

David



 
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 : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de meryem Z
Envoyé : mercredi 10 mars 2010 13:17
Cc : juniper-nsp@puck.nether.net
Objet : [j-nsp] Verify loss priority for a forwarding class


hello Community,

I configured a forwarding class with high priority loss. Now I need to verify 
that the traffic sent under this forwarding class ( using a traffic generator) 
has a high priority loss. The show interface queue  doesn't show this 
information. is there any other way to do it ?

Thank you.


  
_
Votre messagerie et bien plus où que vous soyez. Passez à Windows Live Hotmail, 
c'est gratuit !
https://signup.live.com/signup.aspx?id=60969
___
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] RE : Strange IS-IS Problem

2010-03-07 Thread david.roy

Hi 

Did you try to check via Tcpdump on your MX, the size of the MX ISIS Hello 
packet (with the hello padding) ? 

Regards,
 David


De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
de la part de Derick Winkworth [dwinkwo...@att.net]
Date d'envoi : dimanche 7 mars 2010 07:25
À : Eric Van Tol; Juniper-Nsp
Objet : Re: [j-nsp] Strange IS-IS Problem

If its JUNOS, then just configure the MTU normally in the interface config on 
the switch.




From: Eric Van Tol e...@atlantech.net
To: Juniper-Nsp juniper-nsp@puck.nether.net
Sent: Sat, March 6, 2010 3:07:23 PM
Subject: Re: [j-nsp] Strange IS-IS Problem

Answers to several questions from various sources below:

 - If you have an aggregate between switches, routers... make sure they
 are correctly configured from both sides?

The EX2500s are connected together via two 10G ports, aggregated into a 
portchannel.  No errors on that or the interfaces on the EX2500s.

 - Also Try to check duplex.

Duplex is not a problem.

 - Is there is possibility to connect the routers directly? This will
 isolate the problem.

There is, but I am not physically in front of the routers at the moment.  My 
next test on Monday was to connect the J2320 up to ge-1/0/0 on the MX960.

 What happens when you reduce the physical MTUs on the MX and the
 J-Series to something smaller?  Same behavior?

Unfortunately, yes, I get the same behavior.

 Are the EX2500's configured for jumbos?

I thought of this earlier and checked the documentation, but while it does 
state that the EX2500 supports jumbo frames, there is absolutley nothing in the 
docs that says how to configure this feature.  A search for 'jumbo' yields two 
hits and a search for 'mtu' yields nothing.  I *can* ping from one router to 
the other with 1472-byte packets with the df-bit set, so I know that my 
1500-byte packet can get through no problem.

 Try adding the point-to-point command under protocols Isis xxx
 interface.

This does nothing, unfortunately.  Besides, the original setup was supposed to 
be that xe-1/2/0.1 be in a bridge-group with interface irb.1 as its routing 
interface, so point-to-point wouldn't meet my end goal.  When that didn't work, 
I simplified it for troubleshooting to just be a plain vlan trunk routed 
interface.

 Can you try configuring family iso mtu 1500?

I've tried 1497 and 1500 to no avail. :-(

My feeling is that there is something happening inside the EX2500s of which I 
am not aware.  These are brand new switches that I've no experience 
configuring, but I would think that if I can ping through them after 
configuring trunk and portchannel interfaces, that there'd really be no other 
config necessary in this very simple topology (besides MSTP).

Thanks to all for your suggestions thus far.

-evt

 -Original Message-
 From: Walaa Abdel razzak [mailto:wala...@bmc.com.sa]
 Sent: Saturday, March 06, 2010 8:24 AM
 To: Eric Van Tol; Juniper-Nsp
 Subject: RE: [j-nsp] Strange IS-IS Problem

 Hi

 - If you have an aggregate between switches, routers... make sure they
 are correctly configured from both sides?
 - Also Try to check duplex.
 - Is there is possibility to connect the routers directly? This will
 isolate the problem.

 Best Regards,
 Walaa Abdel Razzak

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net
 [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Eric Van Tol
 Sent: Saturday, March 06, 2010 3:54 PM
 To: Juniper-Nsp
 Subject: [j-nsp] Strange IS-IS Problem

 Hi all,
 I've got a strange ISIS problem and I'm hoping another set of eyes can
 help me identify what is wrong here.  I've got an MX960 logically
 connected to a J2320 through two EX2500 switches:

 MX960 == EX2500 == EX2500 == J2320

 I'm simply trying to get ISIS working between the two routers and it's
 not coming up.  Traceoptions don't show anything out of the ordinary.

 MX960:
 xe-1/2/0 {
 vlan-tagging;
 mtu 9192;
 unit 1 {
 vlan-id 1;
 family inet {
 mtu 1500;
 address x.x.x.99/28;
 }
 family iso;
 }
 }
 lo0 {
 unit 0 {
 family inet {
 address 127.0.0.1/32;
 address x.x.x.74/32;
 }
 family iso {
 address 47.0001....00;
 }
 }
 }
 ...
 protocols {
 isis {
 interface xe-1/2/0.1;
 interface lo0.0 {
 passive;
 }
 }
 }


 J2320:
 ge-0/0/0 {
 vlan-tagging;
 mtu 9192;
 unit 1 {
 vlan-id 1;
 family inet {
 mtu 1500;
 address x.x.x.100/28;
 }
 family iso;
 }
 }
 lo0 {
 unit 0 {
 family inet {
 address 127.0.0.1/32;
 address x.x.x.75/32;
 }
 family iso {
 address 47.0001....00;
 }
 }
 }
 ...
 protocols {
 isis {
 interface

[j-nsp] BGP tcp-mss

2010-02-02 Thread david.roy

Hi all,

Do you why, when I set the tcp-mss to 4096 between to BGP neighbors, this one 
is well exchange between the TCP Connection Establishment but when I check the 
mss via the command show system connection extensive I see that the mss used 
is 2048 (the half).

R1 config - lo0 172.20.223.6 :

  neighbor 172.20.223.5 {
tcp-mss 4096;
}
R2 config - lo0 172.20.223.5

  neighbor 172.20.223.6 {
tcp-mss 4096;
}

One Link between R1 and R2 with MTU set to 4484.

TCPDUMP output on R2 - we see that 4096 is well exchanged :

15:49:29.681732 Out IP 172.20.223.5.55025  172.20.223.6.179: S 
2338565447:2338565447(0) win 16384 mss 4096,nop,wscale 0,nop,nop,timestamp 
2417320394 0,sackOK,eol
15:49:29.682439  In IP 172.20.223.6.179  172.20.223.5.55025: S 
1139135010:1139135010(0) ack 2338565448 win 16384 mss 4096,nop,wscale 
0,nop,nop,timestamp 455578404 2417320394,sackOK,eol
15:49:29.682455 Out IP 172.20.223.5.55025  172.20.223.6.179: . ack 1 win 16384 
nop,nop,timestamp 2417320394 455578404


On R2 : show system connection extensive | find 172.20.223.6

tcp4   0  0  172.20.223.5.55025
172.20.223.6.179  ESTABLISHED
   sndsbcc:  0 sndsbmbcnt:  0  sndsbmbmax: 131072
sndsblowat:   2048 sndsbhiwat:  16384
   rcvsbcc:  0 rcvsbmbcnt:  0  rcvsbmbmax: 131072
rcvsblowat:  1 rcvsbhiwat:  16384
   proc id:   1131  proc name:rpd
   iss: 2338565447  sndup: 2338567245
snduna: 2338567245 sndnxt: 2338567245  sndwnd:  16384
sndmax: 2338567245sndcwnd:   4096 sndssthresh: 1073725440
   irs: 1139135010  rcvup: 1139136242
rcvnxt: 1139136261 rcvadv: 1139152645  rcvwnd:  16384
   rtt:  0   srtt:   2230rttv:574
rxtcur:   1200   rxtshift:  0   rtseq: 2338567226
rttmin:   1000  mss:   2048


N.B: Release 9.3

Thank you
Regards,
David


David Roy
Orange France - RBCI IP Technical Assistance Center
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david@orange-ftgroup.commailto: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

Re: [j-nsp] Very urgent: Point to multipoint lsp

2009-12-08 Thread david.roy

Hi,

Hereafter a simple example of static P2PM with 2 branch

Enable mpls and RSVP on your routers.

On the head router : 

protocols {
mpls {
label-switched-path R1toR2 {
from x.x.x.x
to y.y.y.y;
p2mp MyP2MP;
primary path1;
}
label-switched-path R1toR3 {
from x.x.x.x
to z.z.z.z;
p2mp MyP2MP;
primary path2;
}
path path1 {
A.B.C.D strict;
}
path path2 {
A.B.C.E strict;
}

}
}

To inject multicast trafic into p2mp 

set routing-options static route 232.x.x.x/X p2mp-lsp-next-hop MyP2MP 

Regards,
David
 
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 : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de chandrasekaran iyer
Envoyé : mardi 8 décembre 2009 14:42
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] Very urgent: Point to multipoint lsp

Hi,

  Anyone can provide me working config. of point to multipoint lsp.

--
Thanks with regards

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

Re: [j-nsp] RE : VRRP packets neither counted nor logged

2009-11-12 Thread david.roy

Did you try to replace from protocol vrrp by from destination-address 
224.0.1.18 ?

David
 


 
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 : juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] De la part de Bit Gossip
Envoyé : mercredi 11 novembre 2009 22:11
À : Juniper List
Objet : Re: [j-nsp] RE : VRRP packets neither counted nor logged

Well this is getting interesting: I have enabled md5 and this is what I get 
(jr4=Junos9.5 CoPP=IOS12.4):
~
$ sudo tcpdump -i eth0 dst host 224.0.0.18

21:57:17.670215 IP jr4  VRRP.MCAST.NET: AH(spi=0xabababab,seq=0x18b):
VRRPv2, Advertisement, vrid 126, prio 100, authtype ah, intvl 1s, length 20

21:57:17.878430 IP copp  VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 126, prio 
100, authtype #254, intvl 1s, length 50 
~
So Junos uses AH and Cisco doesn't - and of course VRRP is broken :-(

With regards to the fw issue of my original post, the term VRRP does match VRRP 
packets, at least without authentication, but it just doesn't count them!
This is proven by the fact that if I change the term action from accept to 
reject, VRRP is broken.

Thanks,
Bit.



On Wed, 2009-11-11 at 20:59 +0100, david@orange-ftgroup.com wrote:
 Does your vrrp use MD5 authentication. If Yes VRRP uses AH hearder.
 So ,The IP protocol field is 51. You need to filter to the vrrp 
 multicast destination address : 224.0.1.18 and not to the protocol 
 vrrp
  
 Regards,
 David
 David Roy
 Orange France - RBCI IP Technical Assistance Center
 +33(0)299876472
 +33(0)685522213
 david@orange-ftgroup.com
 
 
 __
 De: juniper-nsp-boun...@puck.nether.net de la part de Bit Gossip
 Date: mer. 11/11/2009 18:55
 À: Juniper List
 Objet : [j-nsp] VRRP packets neither counted nor logged
 
 
 Experts, any idea why?
 
 The firewall term VRRP matches packets because if I change the action 
 to reject the vrrp status changes to master because vrrp from the 
 other router are not heard anymore.
 
 Nevertheless matched packet are neither counted nor logged :-(
 
 
 
 l...@jr4 show configuration firewall filter LUCA
 
 term VRRP {
 
 from {
 
 protocol vrrp;
 
 }
 
 then {
 
 count RT-VRRP;
 
 log;
 
 accept;
 
 }
 
 }
 
 term FXP0-ACCEPT {
 
 from {
 
 interface fxp0.0;
 
 }
 
 then {
 
 count FXP0-ACCEPT;
 
 accept;
 
 }
 
 }
 
 
 
 l...@jr4 show firewall log
 
 
 
 l...@jr4 show firewall filter LUCA
 
 
 
 Filter: LUCA
 
 Counters:
 
 NameBytes
 Packets
 
 RT-VRRP 0
 0
 
 FXP0-ACCEPT 43570
 802
 
 
 
 l...@jr4 show vrrp detail
 
 Physical interface: ge-1/3/0, Unit: 1, Vlan-id: 1, Address:
 10.15.4.74/26
 
   Index: 71, SNMP ifIndex: 135, VRRP-Traps: disabled
 
   Interface state: up, Group: 126, State: backup
 
   Priority: 100, Advertisement interval: 1, Authentication type: none
 
   Delay threshold: 100, Computed send rate: 0
 
   Preempt: yes, Accept-data mode: yes, VIP count: 1, VIP: 10.15.4.126
 
   Dead timer: 2.833s, Master priority: 100, Master router: 10.15.4.75
 
   Virtual router uptime: 00:47:44
 
   Tracking: disabled
 
 
 
 l...@jr4 monitor traffic interface ge-1/3/0 no-resolve matching dst 
 host 224.0.0.18 detail count 1
 
 Address resolution is OFF.
 
 Listening on ge-1/3/0, capture size 1514 bytes
 
 
 
 14:47:32.936935  In IP (tos 0xc0, ttl 255, id 0, offset 0, flags 
 [none],
 proto: VRRP (112), length: 40) 10.15.4.75  224.0.0.18:
 VRRPv2-advertisement 20: vrid=126 prio=100 authtype=none intvl=1
 addrs:
 10.15.4.126
 
 
 
 l...@jr4 show configuration interfaces lo0
 
 unit 0 {
 
 family inet {
 
 filter {
 
 input LUCA;
 
 }
 
 address 127.0.0.1/32;
 
 address 1.1.1.1/32 {
 
 primary;
 
 preferred;
 
 }
 
 }
 
 family iso {
 
 address 49......0001.00;
 
 }
 
 }
 
 
 
 l...@jr4 show configuration interfaces ge-1/3/0
 
 vlan-tagging;
 
 link-mode full-duplex;
 
 gigether-options {
 
 no-flow-control;
 
 }
 
 unit 1 {
 
 vlan-id 1;
 
 family inet {
 
 no-redirects;
 
 policer {
 
 arp ARP-POLICER;
 
 }
 
 address 10.15.4.74/26 {
 
 vrrp-group 126 {
 
 virtual-address 10.15.4.126;
 
 advertise-interval 1;
 
 accept-data;
 
 }
 
 }
 
 }
 
 family iso;
 
 family mpls;
 
 }
 
 
 
 ___
 juniper-nsp

[j-nsp] RE : VRRP packets neither counted nor logged

2009-11-11 Thread david.roy

Does your vrrp use MD5 authentication. If Yes VRRP uses AH hearder. So ,The IP 
protocol field is 51. You need to filter to the vrrp multicast destination 
address : 224.0.1.18 and not to the protocol vrrp 
 
Regards,
David

David Roy
Orange France - RBCI IP Technical Assistance Center
+33(0)299876472
+33(0)685522213
david@orange-ftgroup.com



De: juniper-nsp-boun...@puck.nether.net de la part de Bit Gossip
Date: mer. 11/11/2009 18:55
À: Juniper List
Objet : [j-nsp] VRRP packets neither counted nor logged



Experts, any idea why?

The firewall term VRRP matches packets because if I change the action to
reject the vrrp status changes to master because vrrp from the other
router are not heard anymore.

Nevertheless matched packet are neither counted nor logged :-(



l...@jr4 show configuration firewall filter LUCA

term VRRP {

from {

protocol vrrp;

}

then {

count RT-VRRP;

log;

accept;

}

}

term FXP0-ACCEPT {

from {

interface fxp0.0;

}

then {

count FXP0-ACCEPT;

accept;

}

}



l...@jr4 show firewall log



l...@jr4 show firewall filter LUCA



Filter: LUCA

Counters:

NameBytes
Packets

RT-VRRP 0
0

FXP0-ACCEPT 43570
802



l...@jr4 show vrrp detail

Physical interface: ge-1/3/0, Unit: 1, Vlan-id: 1, Address:
10.15.4.74/26

  Index: 71, SNMP ifIndex: 135, VRRP-Traps: disabled

  Interface state: up, Group: 126, State: backup

  Priority: 100, Advertisement interval: 1, Authentication type: none

  Delay threshold: 100, Computed send rate: 0

  Preempt: yes, Accept-data mode: yes, VIP count: 1, VIP: 10.15.4.126

  Dead timer: 2.833s, Master priority: 100, Master router: 10.15.4.75

  Virtual router uptime: 00:47:44

  Tracking: disabled



l...@jr4 monitor traffic interface ge-1/3/0 no-resolve matching dst
host 224.0.0.18 detail count 1

Address resolution is OFF.

Listening on ge-1/3/0, capture size 1514 bytes



14:47:32.936935  In IP (tos 0xc0, ttl 255, id 0, offset 0, flags [none],
proto: VRRP (112), length: 40) 10.15.4.75  224.0.0.18:
VRRPv2-advertisement 20: vrid=126 prio=100 authtype=none intvl=1 addrs:
10.15.4.126



l...@jr4 show configuration interfaces lo0

unit 0 {

family inet {

filter {

input LUCA;

}

address 127.0.0.1/32;

address 1.1.1.1/32 {

primary;

preferred;

}

}

family iso {

address 49......0001.00;

}

}



l...@jr4 show configuration interfaces ge-1/3/0

vlan-tagging;

link-mode full-duplex;

gigether-options {

no-flow-control;

}

unit 1 {

vlan-id 1;

family inet {

no-redirects;

policer {

arp ARP-POLICER;

}

address 10.15.4.74/26 {

vrrp-group 126 {

virtual-address 10.15.4.126;

advertise-interval 1;

accept-data;

}

}

}

family iso;

family mpls;

}



___
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

Re: [j-nsp] RE : Strange LOGIN_FAILED message

2009-07-22 Thread david.roy


I've only a modem connected to the consol port. 
 
Regards,
David




De : Brandon Bennett [mailto:benn...@gmail.com] 
Envoyé : mardi 21 juillet 2009 23:30
À : ROY David DTF/DERX
Cc : Manu Chao; juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] RE : Strange LOGIN_FAILED message




On Tue, Jul 21, 2009 at 10:35 AM, david@orange-ftgroup.com wrote:



I think so but I can't see any input TCP sessions by using 
tcpdump on the box. I will try to put a specific term in my loopback firewall 
filter to catch the source addresses (if there are) !



 
Do you have a terminal server pluged in the console port possibly 
displaying a login prompt back at the at the router that is interpreted as a 
failed login?

-Brandon 




*
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 135 matches

Mail list logo