[27212] in resnet
Re: Ethernet ports "burning out"
daemon@ATHENA.MIT.EDU (Charlie Teater)
Thu Jan 26 10:58:30 2012
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=f46d043c08d874ec3104b7705dab
Message-ID: <CAGnT4c7zLMd95SBkWb6BR4pX=vwsbwKNeAKFMRAyy-da+mY3UA@mail.gmail.com>
Date: Thu, 26 Jan 2012 08:52:18 -0700
Reply-To: Resnet Forum <RESNET-L@listserv.nd.edu>
From: Charlie Teater <cteater@boisestate.edu>
To: RESNET-L@listserv.nd.edu
In-Reply-To: <4F20B575.3020908@tcnj.edu>
--f46d043c08d874ec3104b7705dab
Content-Type: text/plain; charset=ISO-8859-1
We used to have similar issues of switch ports being deactivated. It was
caused by residents with Hubs that were causing too many collisions so the
switch deactivated the port. We would reactivate the port and it would
work fine for a while, then kick off again. Since hubs are not used much
any more it has not been a problem in some time. I would start by trying
to reset the ports on the switch.
Charlie Teater
IT Systems Coordinator
University Housing
Boise State University
On Wed, Jan 25, 2012 at 7:07 PM, Brad Coburn <coburn@tcnj.edu> 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.
>
> 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
>
>
> 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<http://LISTSERV.ND.EDU/archives/resnet-l.html>
> ______________________________**_____________________
>
___________________________________________________
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
___________________________________________________
--f46d043c08d874ec3104b7705dab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
We used to have similar issues of switch ports being deactivated.=A0 It was=
caused by residents with Hubs that were causing too many collisions so the=
switch deactivated the port.=A0 We would reactivate the port and it would =
work fine for a while, then kick off again.=A0 Since hubs are not used much=
any more it has not been a problem in some time.=A0 I would start by tryin=
g to reset the ports on the switch.<br>
=A0<br clear=3D"all">Charlie Teater<br>IT Systems Coordinator<br>University=
Housing<br>Boise State University<br>
<br><br><div class=3D"gmail_quote">On Wed, Jan 25, 2012 at 7:07 PM, Brad Co=
burn <span dir=3D"ltr"><<a href=3D"mailto:coburn@tcnj.edu">coburn@tcnj.e=
du</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all.<br>
<br>
I have a curious situation that perhaps the community might be able to offe=
r some insight on. I apologize for the length of my post; I hope the detail=
will serve to spark some insight.<br>
<br>
Some background:<br>
Two, 10-story residence halls. One Ethernet port per student (so 2-person r=
ooms have two Ethernet ports). Three equipment rooms per hall, serving appr=
oximately 1/3 of each building. 15, 48-port 10/100 switches total in each b=
uilding.<br>
<br>
The situation:<br>
Suddenly this Fall I have a recurring issue with a single student room.<br>
<br>
The initial report is that they cannot establish connection with their lapt=
ops. One is a PC, one is a MAC; neither looks terribly old (I'm on the =
network side, not the desktop side).<br>
<br>
First time, troubleshooting turns up "bad" Ethernet ports on that=
switch for these two connections. Not an uncommon occurrence across reside=
nce halls. If it's important, the two patch cords are adjacent (jacks w=
ere patched in, in-order).<br>
<br>
Moved patch cords to two spare ports (happen to be adjacent) on that switch=
; service restored (confirmed with my tester and customer machines).<br>
<br>
Two weeks later (second time), call comes back. No link. Troubleshooting sh=
ows two "bad" Ethernet ports again. There are only three of us wh=
o work on switches in the field, and nothing's been touched (so the pat=
ch cables are where they were). Moved both patch cords to another switch, a=
djacent ports, same model.<br>
<br>
Some days later (third time), call comes back. It's "bad" por=
ts 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 teste=
r to try advanced functions like TDR, as well as resistance and voltage mea=
surements pair-to-pair and pair-to-ground, with computers connected and wit=
hout computers connected. Nothing comes up.<br>
<br>
By now I'm out of sufficient spare ports, so I place these two connecti=
ons on a little desktop Netgear switch and patch that into the stack. This =
is just before Thanksgiving break. Student connections again confirmed work=
ing with tester and customer computers.<br>
<br>
Shortly thereafter we replace the two switches with "bad" ports (=
there had been other port failures over the years) with two new switches fr=
om spare stock. One switch is the same model. One switch is the newest mode=
l of the 10/100 class - a model I'm placing in other buildings that won=
't support or can't afford GigE.<br>
<br>
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.<br>
<br>
Everything worked fine from approximately post-Thanksgiving Break until las=
t Thursday, January 19. Most students returned from Winter Break on Tuesday=
January 24.<br>
<br>
Call is back (fourth time). Ports are "bad" again, on this brand-=
new switch. This model supports extended diagnostics, which sometimes repor=
t bad ports. Nothing comes up this time (this is not atypical).<br>
<br>
Tech and I followed the cable in the ceiling all the way to the IDF (only o=
ne floor down). This room is roughly in the middle of the cable runs, and t=
he 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.<br>
<br>
So tomorrow I have Facilities scheduled to go up and run new cable for this=
room. The parents are irate at this point.<br>
<br>
I'm more than sure that this is a customer equipment issue, but I can&#=
39;t figure out what could be happening. We've not seen anything like t=
his before. A single-port occurrence would be more likely rather than a sim=
ultaneous 2-port event.<br>
<br>
It may be important to know that when the campus was originally cabled some=
one took advantage of the "economy" offered by 10Mbps Ethernet=
9;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 fo=
r retro-fits some time ago).<br>
<br>
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 custome=
r equipment damages the first connection, the customer tries the second con=
nection immediately and blows that too.<br>
<br>
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.<br>
<br>
I have not tried:<br>
- Swapping horizontal cables with the neighbor. If the problem follows, the=
n 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 phy=
sical damage.<br>
- Separating the two patch cords for the room between switches. It just has=
n't happened.<br>
- Installing a surge suppressor on the line (I have pricing).<br>
<br>
I really would like to know what I can do to damage an Ethernet port. By th=
e 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" co=
ndition. Oh, and it's a Fluke LinkRunnerPRO.<br>
<br>
Any thoughts?<br>
<br>
Thanks.<br>
<br>
-Brad Coburn<br>
Associate Director, Communications Technologies<br>
Information Technology<br>
The College of New Jersey<br>
<br>
<br>
15 switches<br>
48 ports each<br>
<br>
______________________________<u></u>_____________________<br>
You are subscribed to the ResNet-L mailing list.<br>
<br>
To subscribe, unsubscribe or search the archives,<br>
go to <a href=3D"http://LISTSERV.ND.EDU/archives/resnet-l.html" target=3D"_=
blank">http://LISTSERV.ND.EDU/<u></u>archives/resnet-l.html</a><br>
______________________________<u></u>_____________________<br>
</blockquote></div><br>
___________________________________________________
You are subscribed to the ResNet-L mailing list.
<p>
To subscribe, unsubscribe or search the archives,
go to http://LISTSERV.ND.EDU/archives/resnet-l.html
___________________________________________________
--f46d043c08d874ec3104b7705dab--
