Howdy list, I experienced a problem today with an Adaptive Services PIC running Link Services on a Juniper M10i. The PIC is being used to support MLPPP bundled T1 links. The M10i is currently configured with 2 adaptive services cards for redundancy.
The setup had been working well for quite a while, but without warning the AS PIC's started failing over back and forth between the primary and secondary lsq for several hours today, several times per minute. This caused all MLPPP bundled links to bounce every time a card failed over. Troubleshooting included removing and reseated both PIC's, removing one PIC at a time and replacing the PIC's with a third AS PIC. Even with a single AS PIC in the chassis the lsq interface would stay up for no more than a minute and then spontaneously change to a down or unknown state, at which point the PIC would not revive without shutting it down and bringing it back into service. The problem eventually cleared up after removing redundancy options, re-adding them and running a commit. Looking back at the logs, this string of messages was repeated over and over durning the issue: 3/11/2009 11:34 AM rw1 Notice cfeb Transient flow-control asserted by MAC0 on sp-1/2 for 1 seconds 3/11/2009 11:34 AM rw1 Notice cfeb Transient flow-control asserted by MAC0 on sp-1/2 for 2 seconds 3/11/2009 11:34 AM rw1 Warning cfeb Prolonged flow-control asserted by MAC0 on sp-1/2, bringing interface down 3/11/2009 11:34 AM rw1 Notice /kernel: ML Bundle DOWN: rlsq0.0:Reason: hard down 3/11/2009 11:34 AM rw1 Notice cfeb MAC flow-control cleared on sp-1/2 Looking at older logs, this message was discovered to be ocurring about once every 3 days, but it never persisted and repeated as it did today. The pertinent configuration options look like this: chassis { fpc 0 { pic 2 { adaptive-services { service-package layer-2; } } } fpc 1 { pic 2 { adaptive-services { service-package layer-2; } } } } rlsq0 { per-unit-scheduler; redundancy-options { primary lsq-0/2/0; secondary lsq-1/2/0; warm-standby; Can anyone shed some light on this issue or the meaning of these log entries? Much appreciation to the list, Ambrose _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp