Re: [j-nsp] MPC4D-32*GE Major Alarms

2016-02-14 Thread Diogo Montagner
That should give you some indication of which subsystem is having problem. Also, check if there are no core-dumps generated fornthe FPC. Without additional information will be very hard to pinpoint where to look. On Sunday, 14 February 2016, Alex K. wrote: > Hello Diogo, > > I'm currently not

Re: [j-nsp] MPC4D-32*GE Major Alarms

2016-02-14 Thread Alex K.
Hello Masood, This problem probably isn't transient, since the output rate from that linecard is cut in half (and restored after MPC get restarted). I was thinking in the direction you mentioned but CRC errors at the fabric should be indeed, transient in nature but they're "seem to persist" till

Re: [j-nsp] MPC4D-32*GE Major Alarms

2016-02-14 Thread Alex K.
Hello Diogo, I'm currently not on site, so I'll definitely try it when I'll get there. Now I'm considering a plan of actions. What should I look for in that command? Thank you. On 14 Feb 2016 10:00, "Diogo Montagner" wrote: > Alex, > > What do you see in the show nvram at the FPC shell ? > > Do

Re: [j-nsp] MPC4D-32*GE Major Alarms

2016-02-14 Thread Masood Ahmad Shah
Some of the alarms are transient (should generate Syslog trap though), and they generate a Chassis alarm upon occurrence (i.e. PFE<>Fabric plane took a hit of CRC errors and then got recovered through fabric healing). Sometimes Chassis does not clear alarm when the transient state gets cleared and

Re: [j-nsp] MPC4D-32*GE Major Alarms

2016-02-14 Thread Diogo Montagner
Alex, What do you see in the show nvram at the FPC shell ? Do you have a case open with JTAC ? Thanks On Sunday, 14 February 2016, Alex K. wrote: > Hello everyone, > > For some time now, one of my customers are getting "major alarms" from the > MPC mentioned above on one of their MX960s. > >