[FQuest Alert] Network Instability

[Terra]

As part of the ongoing network upgrades and STP work, a VLAN tagging misconfiguration in one of our core switches caused it to go into severe packet loss... This matter will be taken up with Foundry engineers to determine why it looped onto itself...

This issue has been resolved, and the network has now stabilized...

The network event lasted between 3:51am to 4:18am ET...

Our sincerest apologies for any inconvenience this network glitch had caused...

--
Terra
sysAdmin
FutureQuest

[Bradley]

Thanks for the update Terra, least I can give a big sigh of relief that it wasn't me this time :rasberry:
What all Foundry models you have in place now days?

[Nyxie]

Thanks for the usual prompt information. I'm glad it ws just a temporary thing.

[Terra]

We have two FastIron 4802 and one FastIron Workgroup switch... The FI4802 are hardcore switches that are still top performers...

Our original switch was the Cisco Catalyst 2924 XL...

The newest switches are HP ProCurve gear, and so far I haven't looked back as I've been happiest overall with them in ease of management and simply fitting the best into our network... Also, I believe they are the best concentrator choice for our Gigabit core network...

The work I'm doing now isn't going as well as planned, as I'm reworking the network topology to make it more resilient and faster to failover to the backup uplinks... The issue tonight is I was trying to provision some new VLANs between OZ and THOR, and when I invoked the setting, it caused OZ to loop in on itself _which should *not* have happened_... Even the precaution of disabling the Gigabit uplink between OZ and THOR, and rerouting OZ through TOTO (which worked flawlessly) so that I could work on the OZ to THOR link ended up having unexpected results when I tagged the OZ uplink to THOR... In theory, everything I did was correct, but for some unknown reason, OZ had other ideas and pitched a fit...

--
Terra
sysAdmin
FutureQuest