syslog messages.

[pynoc]

No service impact but my syslog looks very ugly and cannot find any PR information with following log messages.

Model: m320

JUNOS: [8.2R2.4]

Nov 29 18:47:31.712  dca-rp01 fpc7 JBUS: FPGA irq handler called, no outstanding interrupts, status=0x00000000, enable=0x0000f800
Nov 29 18:48:08.674  dca-rp01 fpc7 JBUS: FPGA irq handler called, no outstanding interrupts, status=0x00000000, enable=0x0000f800
Nov 30 04:25:20.818  dca-rp01 fpc7 JBUS: FPGA irq handler called, no outstanding interrupts, status=0x00000000, enable=0x0000f800

Also, is it possible to turn off " ------high alarm set/cleared" messages or I have to talk to my Telco Vendor?

1           GIGE 1000SX       FINISAR CORP.      FTRJ-8519-7D-JUN

Nov 29 20:11:30.504  dca-rp01 fpc0 XGE(0/1): transceiver temperature high alarm cleared
Nov 30 04:15:40.745  dca-rp01 fpc0 XGE(0/1): transceiver temperature high alarm set
Nov 30 04:15:50.745  dca-rp01 fpc0 XGE(0/1): transceiver temperature high alarm cleared
Nov 30 06:00:30.798  dca-rp01 fpc0 XGE(0/1): receive optical power high alarm set
Nov 30 06:00:40.798  dca-rp01 fpc0 XGE(0/1): receive optical power high alarm cleared

Thanks,

[JJ]

Hi!

I would open a JTAC case for both of these issues. 

The first syslog message (JBUS: FPGA irq handler called) looks like internal "Greek" that a developer would need to look at to verify if it means some hardware issue or software.  However, it seems to be extra diagnostic information that would not affect traffic.

The second issue looks familiar.  I don't have any reference numbers available, but I don't expect any way to turn off those messages in 8.2R2.4 either.  I'm assuming that when the transceiver message is logged, no one has pulled the cable or turned off the remote transmit?  It is normal to get "receive optical power" alarms when the transceiver is not receiving light, but if you can verify that the light is within spec when you get these logs, then you are running into another issue.

[pynoc]

Nope, we didn't touch fiber.

I understand alert with Intel xenpak (PR 233011) b/c I have alert with intel xenpak too.

But PR98428 is closed and still seeing same alert and I ma not seeing any errors or alerts with that link.

L3 incompletes delta value should be change if it's right alert?

thanks

peter

[JJ]

Hi Peter,

The fix for PR 98428 is not checked into JUNOS until after 8.2R2.4.  It should be in 8.2R4, according to the PR headers.  I see from your screenshots you are running 8.2R2.4, so if this is a lab environment, you may try 8.2R4 since it was recently released.  I don't see anything about "L3 incompletes" in the two PRs you mentioned, only the syslog messages.

Hope that helps.

-JJ

[pynoc]

From alert fpc/pic with sh mon int

L3 incompletes:                 3545421                              [30]

 L3 incompletes:                 3546011                             [620]

and

 Statistics last cleared: 2007-11-30 14:24:11 EST (00:00:19 ago)
Input errors:
    Errors: 136, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 incompletes: 136

Maybe fpc has issues?

[gdavies]

Hi Pynoc,

What level have you set your syslog to? I suspect, as JJ said, that this may be internal messages that show that things are 'working as normal'.

If you've changed your syslog settings, then you might want to change them back ;-) The general advice I've had when talking to colleagues in JTAC is "don't change the settings for syslog". They're perfectly adequate for all day-to-day monitoring of the box. Only crank up the level if you have a particular problem to solve and only on the advice of JTAC.

Rgds,

Guy

[pynoc]

Hi,

syslog set is default b/c I didn't change at all.

Also daemon  info | match "(!( receive optical power high warning set) | ! (receive optical power high warning cleared))" should be work?

Looks like my only solution is use 8.2R4..

Thanks for the tip,

peter

[gdavies]

Hi Peter,

Yes, that filter should work to prevent the lines that you're trying to block. It's a good solution for one or two lines that appear excessively but probably won't scale too well ;-)

Rgds,

Guy