[27207] in resnet
Re: Ethernet ports "burning out"
daemon@ATHENA.MIT.EDU (Willis Marti)
Wed Jan 25 22:46:19 2012
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <4F20C9E5.5040101@tamu.edu>
Date: Wed, 25 Jan 2012 21:35:01 -0600
Reply-To: wmarti@tamu.edu
From: Willis Marti <wmarti@tamu.edu>
To: RESNET-L@listserv.nd.edu
In-Reply-To: <4F20B575.3020908@tcnj.edu>
Bad grounding between IDF, room, computers?
On 01/25/2012 08:07 PM, Brad Coburn wrote:
> Hi all.
>
> I have a curious situation that perhaps the community might be able to
> offer some insight on. I apologize for the length of my post; I hope
> the detail will serve to spark some insight.
>
> Some background:
> Two, 10-story residence halls. One Ethernet port per student (so
> 2-person rooms have two Ethernet ports). Three equipment rooms per
> hall, serving approximately 1/3 of each building. 15, 48-port 10/100
> switches total in each building.
>
> The situation:
> Suddenly this Fall I have a recurring issue with a single student room.
>
> The initial report is that they cannot establish connection with their
> laptops. One is a PC, one is a MAC; neither looks terribly old (I'm on
> the network side, not the desktop side).
>
> First time, troubleshooting turns up "bad" Ethernet ports on that
> switch for these two connections. Not an uncommon occurrence across
> residence halls. If it's important, the two patch cords are adjacent
> (jacks were patched in, in-order).
>
> Moved patch cords to two spare ports (happen to be adjacent) on that
> switch; service restored (confirmed with my tester and customer
> machines).
>
> Two weeks later (second time), call comes back. No link.
> Troubleshooting shows two "bad" Ethernet ports again. There are only
> three of us who work on switches in the field, and nothing's been
> touched (so the patch cables are where they were). Moved both patch
> cords to another switch, adjacent ports, same model.
>
> Some days later (third time), call comes back. It's "bad" ports again.
> So I and my tech go out there. Standard tests come back fine.
> Re-terminated the jack "just in case". I brought my cable pair tester
> to try advanced functions like TDR, as well as resistance and voltage
> measurements pair-to-pair and pair-to-ground, with computers connected
> and without computers connected. Nothing comes up.
>
> By now I'm out of sufficient spare ports, so I place these two
> connections on a little desktop Netgear switch and patch that into the
> stack. This is just before Thanksgiving break. Student connections
> again confirmed working with tester and customer computers.
>
> Shortly thereafter we replace the two switches with "bad" ports (there
> had been other port failures over the years) with two new switches
> from spare stock. One switch is the same model. One switch is the
> newest model of the 10/100 class - a model I'm placing in other
> buildings that won't support or can't afford GigE.
>
> The Netgear setup worked the whole time, but it's a non-standard setup
> and will only come back to haunt us later. So we pulled the Netgear
> out and placed the room patch cords back in their usual spot, which is
> now also on the new replacement switch.
>>
>>
>>
>> 15 switches
>> 48 ports each
>>
>> ___________________________________________________
>> You are subscribed to the ResNet-L mailing list.
>>
>> To subscribe, unsubscribe or search the archives,
>> go to http://LISTSERV.ND.EDU/archives/resnet-l.html
>> ___________________________________________________
>
> Everything worked fine from approximately post-Thanksgiving Break
> until last Thursday, January 19. Most students returned from Winter
> Break on Tuesday January 24.
>
> Call is back (fourth time). Ports are "bad" again, on this brand-new
> switch. This model supports extended diagnostics, which sometimes
> report bad ports. Nothing comes up this time (this is not atypical).
>
> Tech and I followed the cable in the ceiling all the way to the IDF
> (only one floor down). This room is roughly in the middle of the cable
> runs, and the room next door shares a common route from the hallway.
> Inspection turned up nothing in the way of obvious damage. Moved the
> customer patch cords to two spare ports on the new switch.
>
> So tomorrow I have Facilities scheduled to go up and run new cable for
> this room. The parents are irate at this point.
>
> I'm more than sure that this is a customer equipment issue, but I
> can't figure out what could be happening. We've not seen anything like
> this before. A single-port occurrence would be more likely rather than
> a simultaneous 2-port event.
>
> It may be important to know that when the campus was originally cabled
> someone took advantage of the "economy" offered by 10Mbps Ethernet's
> operation over 2-pair. So we split the cable at the faceplate and then
> again back in the IDF. That's how it was done back then, and we're
> still operating successfully at 100Mbps now (but we stopped the
> practice for retro-fits some time ago).
>
> Given our "split" architecture in this case, I suppose there's a
> remote possibility that a damaging event on one half of the cable
> could transfer to the entire cable. It's also just as likely that if
> customer equipment damages the first connection, the customer tries
> the second connection immediately and blows that too.
>
> I certainly understand what this looks like for the customer, but I
> don't know what else to say. Of course the customers aren't doing
> anything out of the ordinary, and neither is anyone else they might
> invite into the room.
>
> I have not tried:
> - Swapping horizontal cables with the neighbor. If the problem
> follows, then it's ours. It's too late now though; Facilities will
> replace this cable and we will pull the old one down to more
> thoroughly inspect for physical damage.
> - Separating the two patch cords for the room between switches. It
> just hasn't happened.
> - Installing a surge suppressor on the line (I have pricing).
>
> I really would like to know what I can do to damage an Ethernet port.
> By the way, my tester "sees" the bad ports as a switch connected, but
> powered off. Which should mean that it sees the transformer at the
> front of the interface. In no case has the tester reported any "error"
> condition. Oh, and it's a Fluke LinkRunnerPRO.
>
> Any thoughts?
>
> Thanks.
>
> -Brad Coburn
> Associate Director, Communications Technologies
> Information Technology
> The College of New Jersey
--
Willis Marti
Director
Networking and Information Security
CISO, Texas A&M University
___________________________________________________
You are subscribed to the ResNet-L mailing list.
To subscribe, unsubscribe or search the archives,
go to http://LISTSERV.ND.EDU/archives/resnet-l.html
___________________________________________________
