[j-nsp] Process swi3: ipopt ip6opt on the MX80

2014-09-10 Thread Yury Vladarchyk
Hi to all!
I have question
Is responsible for what this process?

 PID USERNAME  THR PRI NICE   SIZERES STATETIME   WCPU COMMAND
   38 root1 -36 -155 0K16K WAIT   279:04 31.25% swi3: ipopt
ip6opt

Without specific reasons for increased load average and cpu, will clarify
at what increased only inerrupt value

 run show chassis routing-engine
Routing Engine status:
Temperature 45 degrees C / 113 degrees F
CPU temperature 57 degrees C / 134 degrees F
DRAM  2048 MB (2048 MB installed)
Memory utilization  91 percent
CPU utilization:
  User   9 percent
  Background 0 percent
  Kernel 9 percent
   *   Interrupt 55 percent*
  Idle  28 percent
Model  RE-MX80-T
Start time 2014-08-21 21:36:17 EEST
Uptime 19 days, 12 hours, 5 minutes, 7 seconds
Last reboot reason Router rebooted after a normal shutdown.
Load averages: 1 minute   5 minute  15 minute
   3.37   3.90   3.52

Best Regards,
Yury Vladarchyk,
Network Engineer,
ITBiz

Phone: +38 (044) 597 10 90
Mobile: +38 (050) 301 16 13
Skype: yury.vladarchyk
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


[j-nsp] Sybex JNCIE-M Study Guide case study configuration files

2014-09-10 Thread Huan Pham
Dear group,

Does anyone has the files from the CD that comes with this text book
(JNCIE-M Study Guide published by Sybex)? I recently bought the book from
Amazon, but the CD is not included. This book was released few years ago,
and I can no longer buy brand new copy anymore. I do not think there is any
licensing issue with sharing the config files, as you can get the soft copy
of the book for free from Juniper website.

Thanks for sharing in advance.

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


Re: [j-nsp] BGP Peer formatting

2014-09-10 Thread Scott Harvanek

Awesome, thank you very much :-)

Both work great!

Scott H.

On 9/9/14, 9:32 PM, Ben Dale wrote:

On 10 Sep 2014, at 7:54 am, Scott Harvanek scott.harva...@login.com wrote:


This is a silly/OCD question;

I've faced this before and I can't recall how it was prettied up...

If I recall there is a way to pretty up the formatting of show bgp summary;

Peer AS  InPkt OutPktOutQ   Flaps Last Up/Dwn 
State|#Active/Received/Accepted/Damped...
XXX.XXX.XXX.XXX   X4463666 120866   0   0 5w3d 9:31:20 
Establ
  inet.0: 272410/510233/510233/0

To remove the line break / fix the table formatting.  I've tried adjusting 
screen-width with no joy.

Halp?

There's a few ways to neaten it, but it's a case of which information you can 
live without:

show bgp summary | except inet
show bgp group summary | match l:

Failing that, I just hacked up an op script to only show a summarised version 
from each peer - output here:

https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.md

Code here:

https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.slax

The script *should* sum all the prefixes from each RIB into a single summarised 
number per peer, but I haven't had a chance to test it too thoroughly yet.  
Feedback/Pull Requests welcome.

Cheers,

Ben




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


Re: [j-nsp] Sybex JNCIE-M Study Guide case study configuration files

2014-09-10 Thread Harry Reynolds
I have placed copies of the configs files for case studies and the chapter on 
google drive:

https://drive.google.com/folderview?id=0ByOb4tf4FcWGd2VlNHRoNDNyVmMusp=sharing


HTHs.



-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Huan Pham
Sent: Tuesday, September 09, 2014 11:45 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Sybex JNCIE-M Study Guide case study configuration files

Dear group,

Does anyone has the files from the CD that comes with this text book (JNCIE-M 
Study Guide published by Sybex)? I recently bought the book from Amazon, but 
the CD is not included. This book was released few years ago, and I can no 
longer buy brand new copy anymore. I do not think there is any licensing issue 
with sharing the config files, as you can get the soft copy of the book for 
free from Juniper website.

Thanks for sharing in advance.

Huan
___
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] T4000 power architecture

2014-09-10 Thread Sam Silvester
Hi Aqeel - thanks for the reply.

Agree 100% - the problem is, we only seem to be getting power to FPC0 from
one PEM... have a look below (and also note that FPC1 is fine, as are the
rest of the FPCs).

The question is - are we looking at a PEM fault here, or a midplane fault?
As per previous discussion, the FPC itself seems fine, as moving it to
another slot resolves the issue. Putting another card into slot 0 yields
the same result as below.

PEM 0 status:
  State  Online
  Temperature32 degrees C / 89 degrees F
  DC Input:  OK
  Voltage(V)  Current(A)  Power(W)  Load(%)
  INPUT 0   54.750   4.312  2369
  INPUT 1   54.500   6.000  327   13
  INPUT 2   54.625  11.750  641   26
  INPUT 3   54.750   6.125  335   13
  INPUT 4   54.250  10.500  569   23
  INPUT 5   54.500   6.062  330   13
  DC Output   Voltage(V)  Current(A)  Power(W)  Load(%)
  FPC 0 55.062   8.625  474   31
  FPC 1 55.250   4.062  224   14

...snip...

PEM 1 status:
  State  Online
  Temperature30 degrees C / 86 degrees F
  DC Input:  OK
  Voltage(V)  Current(A)  Power(W)  Load(%)
  INPUT 0   54.500   3.250  1777
  INPUT 1   54.625   3.375  1847
  INPUT 2   54.500  12.437  677   28
  INPUT 3   54.500   5.125  279   11
  INPUT 4   54.625  12.062  658   27
  INPUT 5   54.375   2.750  1496
  DC Output   Voltage(V)  Current(A)  Power(W)  Load(%)
  FPC 0  0.000   0.00000
  FPC 1 55.125   4.500  248   16

...snip...



On Wed, Sep 10, 2014 at 8:48 PM, aqeel ahmed aqee...@yahoo.com wrote:

 Hi

 Though aimed for redundancy If system has both power supplies installed
 then it will automatically load balance and in case one power supply goes
 down then whole system will be on single power supply left working.

 For further details you can refer to following juniper document.


 http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/topic-collections/hardware/t-series/t4000/hwguide/t4000-hwguide.pdf

 Regards



   On Wednesday, September 10, 2014 5:16 AM, Sam Silvester 
 sam.silves...@gmail.com wrote:


 Howdy,

 Can anybody shed any light on how the PEMs on a T4000 actually distribute
 power to each FPC slot?

 Have the case of a single FPC slot that is showing power being received
 from only one of the PEMs, whilst all the other FPC slots are load sharing
 as expected.

 Replacing the FPC shows the same issue, so we're pretty happy that it's
 slot specific.

 What I'm curious about is if the midplane has individual 'traces' (for lack
 of a better term) for supplying power to each FPC from the two PEMs, or if
 there is a common bus shared between all the FPCs from each PEM. The reason
 I ask is if the PEM only has a single connection to the midplane, replacing
 it seems pointless and instead it looks like we're better off replacing the
 midplane. If the PEM has individual outputs to each slot, then replacing
 the PEM seems like a reasonable approach.

 I've been pointed at the following document (

 http://www.juniper.net/documentation/en_US/release-independent/junos/topics/concept/power-supply-t4000-description.html
 )
 which is very light-on in terms of detail. Does anybody know if there is a
 more detailed document available (or even internally?) that we can ask
 about?

 Thanks!
 ___
 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] T4000 power architecture

2014-09-10 Thread Sam Silvester
Pins 'seem' ok from a visual inspection.

Our support vendor is involved, however because of reasons I'm getting the
feeling we're now playing whack-a-mole with randomly replacing components,
as opposed to actually using the results from previous tests such as moving
the FPC to guide us towards a most likely culprit.

The reason I'd like to know if the PEM has 'individual' outputs / feeds to
each FPC vs. a bus arrangement vai the midplane is that will hopefully
prevent needlessly changing out the PEM if it's more likely the midplane,
or vice-versa.

Requests so far for a more detailed power architecture have been met with
being sent that same (basic) document over and over; you'd think somebody,
somewhere would have some more detailed insight into the power architecture
of these beasts.

Sam



On Thu, Sep 11, 2014 at 8:34 AM, Tom Storey t...@snnap.net wrote:

 Can you see any physical damage to any of the pins on the midplane? I
 and my colleagues have come across a number of damaged sockets, bent
 pins etc.

 May not be easy to do, but perhaps power cycle all of the inputs to
 that PEM, and perhaps unseat and inspect for damage on the pins for it
 as well.

 If not, JTAC and see what they say. I'd like to hear the outcome
 though, as I work a lot with Juniper routers, this could be a useful
 bit of knowledge!

 On 10 September 2014 23:36, Sam Silvester sam.silves...@gmail.com wrote:
  Hi Aqeel - thanks for the reply.
 
  Agree 100% - the problem is, we only seem to be getting power to FPC0
 from
  one PEM... have a look below (and also note that FPC1 is fine, as are the
  rest of the FPCs).
 
  The question is - are we looking at a PEM fault here, or a midplane
 fault?
  As per previous discussion, the FPC itself seems fine, as moving it to
  another slot resolves the issue. Putting another card into slot 0 yields
  the same result as below.
 
  PEM 0 status:
State  Online
Temperature32 degrees C / 89 degrees F
DC Input:  OK
Voltage(V)  Current(A)  Power(W)  Load(%)
INPUT 0   54.750   4.312  2369
INPUT 1   54.500   6.000  327   13
INPUT 2   54.625  11.750  641   26
INPUT 3   54.750   6.125  335   13
INPUT 4   54.250  10.500  569   23
INPUT 5   54.500   6.062  330   13
DC Output   Voltage(V)  Current(A)  Power(W)  Load(%)
FPC 0 55.062   8.625  474   31
FPC 1 55.250   4.062  224   14
 
  ...snip...
 
  PEM 1 status:
State  Online
Temperature30 degrees C / 86 degrees F
DC Input:  OK
Voltage(V)  Current(A)  Power(W)  Load(%)
INPUT 0   54.500   3.250  1777
INPUT 1   54.625   3.375  1847
INPUT 2   54.500  12.437  677   28
INPUT 3   54.500   5.125  279   11
INPUT 4   54.625  12.062  658   27
INPUT 5   54.375   2.750  1496
DC Output   Voltage(V)  Current(A)  Power(W)  Load(%)
FPC 0  0.000   0.00000
FPC 1 55.125   4.500  248   16
 
  ...snip...
 
 
 
  On Wed, Sep 10, 2014 at 8:48 PM, aqeel ahmed aqee...@yahoo.com wrote:
 
  Hi
 
  Though aimed for redundancy If system has both power supplies installed
  then it will automatically load balance and in case one power supply
 goes
  down then whole system will be on single power supply left working.
 
  For further details you can refer to following juniper document.
 
 
 
 http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/topic-collections/hardware/t-series/t4000/hwguide/t4000-hwguide.pdf
 
  Regards
 
 
 
On Wednesday, September 10, 2014 5:16 AM, Sam Silvester 
  sam.silves...@gmail.com wrote:
 
 
  Howdy,
 
  Can anybody shed any light on how the PEMs on a T4000 actually
 distribute
  power to each FPC slot?
 
  Have the case of a single FPC slot that is showing power being received
  from only one of the PEMs, whilst all the other FPC slots are load
 sharing
  as expected.
 
  Replacing the FPC shows the same issue, so we're pretty happy that it's
  slot specific.
 
  What I'm curious about is if the midplane has individual 'traces' (for
 lack
  of a better term) for supplying power to each FPC from the two PEMs, or
 if
  there is a common bus shared between all the FPCs from each PEM. The
 reason
  I ask is if the PEM only has a single connection to the midplane,
 replacing
  it seems pointless and instead it looks like we're better off replacing
 the
  midplane. If the PEM has individual outputs to each slot, then replacing
  the PEM seems like a