[f-nsp] [SPAM tagged by PCNET] Failing Backplane or Interface Module on a FastIron 800...help is greatly appreciated.

[Jason J. W. Williams]

Hi Todd,

Yeah, apparently they are different at least for us. I can't find any
speed/duplex mismatches on the ports. I'm being told it could be a bad
CAM chip. Need to reboot the chassis and watch the self-test
diagnostics.

How do you like the MLX? Does that have the redundant switch fabric?

-J

On 3/14/07, Todd Christell <tchristell at springnet.net> wrote:
>  Jason,
>
> Did you mean to indicate that the speed/duplex mismatch CAM trashing was
> different than the CAM trashing problems with the J-F48E modules?  If
> so, we have seen the speed/duplex mismatch with the J-F48E-A also.
>
> We take fiber to the customer so almost all of our FE connections are
> through media converters so we control the electrical interface on the
> 10/100 side and are able to control the mismatch problem (as long as the
> media converts behave).
>
> Just received 4 MLXs so having some fun with those; going to the Foundry
> MPLS class in April.
>
> Todd
>
> -----Original Message-----
> From: Jason J. W. Williams [mailto:jasonjwwilliams at gmail.com]
> Sent: Monday, March 12, 2007 12:39 PM
> To: Todd Christell
> Cc: foundry-nsp at puck.nether.net
> Subject: Re: [SPAM tagged by PCNET] [f-nsp] Failing Backplane or
> Interface Module on a FastIron 800...help is greatly appreciated.
> Importance: Low
>
> Hi Todd,
>
> Thank you again. I finally got a straight story out of a Foundry SE.
> You're absolutely correct that speed/duplex mismatches can cause CAM
> trashing. Also, CAM trashing can occur on J-F48E modules in a select
> manufacturing window. Apparently it was a problem with their memory
> supplier. They fixed the issue with the J-F48E-A. Again thank you.
>
> Best Regards,
> Jason
>
> On 3/9/07, Todd Christell <tchristell at springnet.net> wrote:
> >  Jason,
> >
> > The old 24 por 10/100 blades won't work with the JetCore module  .
> >
> > We saw some similar behavior on a BI8000 with JetCore that ended up
> > being a speed/duplex mismatch.  All of our internal ports are set for
> > Auto but one of our media converters went to hard coded 100 meg full
> > dux.  Didn't seem to bother anything until the traffic on that port
> > ramped up to 50 or 60 meg and then the 10/100 blade started wigging
> out.
> > Dropped traffic, arp tables corrupted and finally the port just died.
> > Not knowing about the media converter we swapped out the card which
> > appeared to fix the problem until the traffic on that port ramped up
> > again and killed the port on the new card.  We replaced the media
> > converter and tested both cards and no problems.
> >
> > Foundry said that the configuration of hard code device to a Foundry
> > port configured for auto-negotiation was an "unsupported
> configuration."
> >
> > Todd
> >
> > Todd Christell
> > SpringNet Network Manager
> >
> > -----Original Message-----
> > From: foundry-nsp-bounces at puck.nether.net
> > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Jason J. W.
> > Williams
> > Sent: Friday, March 09, 2007 2:46 PM
> > To: foundry-nsp at puck.nether.net
> > Subject: [SPAM tagged by PCNET] [f-nsp] Failing Backplane or Interface
>
> > Module on a FastIron 800...help is greatly appreciated.
> > Importance: Low
> >
>