[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,

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
>
> Hello all,
>
>
> I've got kinda of a weird situation, and if you could give me your take
> it'd really give me some peace of mind. Suddenly last night all of the
> hosts attached to the 1-24ish ports of a FI48E (JetCore) blade in our
> FI800 started experiencing massive packet loss (20-100%).
> Before we figured out it was that blade, we tried failing the active
> management module (FxGMR4) over to the passive just in case it was the
> problem. That didn't help. Actually moving the the affected hosts from
> one FI48E blade to another seems to have corrected the issue. When we
> ping hosts on the "bad" blade we get stuff like this:
>
> wrong data byte #28 should be 0x1c but was 0x7e
> #8      8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 7e 1f 1e
> 1f 20 21 22 23 24 25 26 27
> #40     28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
>
> A show backplane and a show module, doesn't show any errors or issues on
> the "bad" blade.
>
> My real concern right now is that we might have a chassis backplane
> going bad (which would take out everything). Is that possible/likely?
>
> Any help in eliminating the backplane as a possibility would really be
> appreciated. Also, I have some IronCore 24-port blades from our old
> FastIron II. Could I put those into my two empty slots on the FI800 to
> take over for the "bad" blade until I can get it replaced? If so, does
> it require a chassis reboot to do that (should the chassis be off)?
>
> Lastly, as an update, some of the hosts connected to the "good" FI48E
> are starting to exhibit long pings (no packet loss yet). I'm very
> concerned something's going to take the whole chassis down. We're
> running on 3 power supplies, instead of 4. Could power be an issue?
>
> Again any help is greatly appreciated!
>
> Best Regards,
> Jason
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>