When UP and UP is false!

Unknown

Just wanted to share with CCNA candidates a fun scenario I had. In a new site buildout they had a new network printer installed which they could not find on the network. I knew they had new ethernet cables installed so I am always a little leery that its a cable issue. I check the network port on the printer and it is lit green. Which usually indicates the port is online and cable is fine. So I ruled that out. The printer was set to receive a dhcp ip address but was not getting an ip. To check connectivity I added a static IP just to see if I can ping it.

No Ping...I reset the printer, shut off, turn on and add the static ip address again. Still No Ping.. I log into the switch that it is connected to and check the status of the port and it is UP and UP. Ok..I disconnect the ethernet cable shut off the printer and reconnect the ethernet and power it back on.

Try to ping again..No ping. I disconnected an ethernet cable from a nearby cisco ip phone and I was able to ping the printer. Ok it was a cable issue and I was not about to run another 100 ft cable across a 75ft ceiling through tubing to the printer.

If it was a bad cable why was the network port on the printer lit green? Why was the switchport that the printer was connected to showing a status of UP and UP.

I figured why don't I check the mac-address table in the switch to see if I am getting a mac address on that port.


I ran the command:
sh mac address-table

There was no mac-address entry on that port. I shot up out of my chair and looked at the pins on the ethernet cable connected into the printer and did a side to side comparison with the one from the ip phone. One of the pins on the cable going to the printer was crossed, gotcha!. My logic was since the rest of pins lined up it gave a false positive on the network port and switchport. I quickly cut that end off and terminated the connector. Voila connectivity!

Let me walk this through the OSI model from bottom to top

Physical: Check cable, Network light from printer green, appeared to functioning normally
Data Link: Port was online up and up
Network layer: Ping printer, no response

(Possible bad network port in printer) Tried another cable

Physical:Network light from printer green, appeared to functioning normally
Data Link: Port was online up and up
Network layer: Ping printer, response

(All ports are functioning normal) Reinserted original cable

Physical: Network light from printer green, appeared to functioning normally
Data Link: Checked Mac address-table-No entry

(Frames from printer are not being sent to switch) Recheck cable

Physical: Check pins in cable (1 pin was crossed)

(Removed ethernet head and terminated a new one)

Physical:Network light from printer green, appeared to functioning normally
Data Link: Port was online up and up, Mac address is in the mac address table
Network layer: Ping printer, response

*Always keep the OSI model in the back of your head

Hondabuff

Wow, were are your tools?

First thing I used to do when I worked desk top support was grab my Fluke toner and wire mapper and punch down tool. Test the run and if you have all 8 lights then you move on from layer 1 issues. We move cubes around like there is no tomorrow and the punch downs in the wall plates come off all the time from stress pulls. I have seen Cisco IP phones power up and keep searching for an IP. Pull the wall plate and there is a flyer on the back of the punch down.

http://www.flukenetworks.com/datacom-cabling/copper-testing/IntelliTone-Pro-Toner-and-Probe
http://www.amazon.com/TRENDnet-Network-Cable-Tester-TC-NT2/dp/B0000AZK08
http://www.amazon.com/Fluke-Networks-10055501-EverSharp-Screwdriver/dp/B000FJCRBG/ref=sr_1_cc_1?s=aps&ie=UTF8&qid=1412340586&sr=1-1-catcorr&keywords=fluke+punch+down+tool

Go shopping!!

Legacy User

I rarely ever deal with cables so I do not have any wire testers at work but that is something to consider. Thanks for your input but the purpose of this post was to be informative by describing a real world problem for ccna candidates and that sometimes relying on a switchport status of UP and UP can bite you in the butt which can easily waste a good 5 minutes of a busy day.

Hondabuff

Step 1) Printer set to DHCP *FAIL*
Step 2) Assigning an IP address and failing to ping the Printer from the switch which would of told your its not a layer 3 problem and its a layer 2 or 1, Failing to check arp table on switch to see the ip and mac exsisted. Rules out L3/L2 Problem
"Who looks up the mac address anyway"
Step 3) Not having any tools to trouble shoot Layer 1 or 2 Problems
Step 4) Not bringing any extra network cords with you to rule out a layer 1 issue.

Not busting your chops but it probably took longer to type this post then it would of taken to fix the problem.

Jon_Cisco

Nice post dmarcisco. It's always good to see so real life examples as the certifications teach you about lots of things but they don't always explain how to make use of the information.

Legacy User

Hondabuff wrote: »

Step 1) Printer set to DHCP *FAIL*
Step 2) Assigning an IP address and failing to ping the Printer from the switch which would of told your its not a layer 3 problem and its a layer 2 or 1, Failing to check arp table on switch to see the ip and mac exsisted. Rules out L3/L2 Problem
"Who looks up the mac address anyway"
Step 3) Not having any tools to trouble shoot Layer 1 or 2 Problems
Step 4) Not bringing any extra network cords with you to rule out a layer 1 issue.

Not busting your chops but it probably took longer to type this post then it would of taken to fix the problem.

Step 1) Printer set to DHCP *FAIL*
I agree I was not the one to set up the printers. I recommended setting the printers to static.
Step 2) Assigning an IP address and failing to ping the Printer from the switch which would of told your its not a layer 3 problem and its a layer 2 or 1, Failing to check arp table on switch to see the ip and mac exsisted. Rules out L3/L2 Problem
"Who looks up the mac address anyway"

I actually was on site in the middle of upgrading an ISR G1 to ISR G2 and the cable guy left who I assume never checked the cables. They asked me to take a look at it so I quickly looked at it. Yes you are right the ping did tell me it was not a layer 3 problem thats why I quickly looked at the mac-address in the table. The reason I did not check arp on the switch because I wanted to see if anything was coming in on the switchport the printer was connected to. Checking the mac address table showed all connected hosts. All arp showed was the interface vlan which was not helpful in this situation.

Step 3) Not having any tools to trouble shoot Layer 1 or 2 Problems

I was not there to diagnose those problems was there for an upgrade but you are right I should have those tools handy. I happened to have a wire crimper in my bag.

Step 4) Not bringing any extra network cords with you to rule out a layer 1 issue.
There was plenty of ethernet cables around I ruled it out with a known working cable.

Not busting your chops but it probably took longer to type this post then it would of taken to fix the problem
Lol, your right it did take me longer to write the post then resolve the issue it took me about 5 minutes to fix it but about 20 minutes to type and edit the post for clarity purposes.

I don't understand what your issue is? I laid out a real world example and had many people already messaging me thanking me for the informative post. That is the intention of this post not for someone else to be berating it because your are going through personal issues.

MTciscoguy

I thought the original post was a good one, that explains a real life situation that does happen. I did learn a long time ago, that when dealing with networks, if you have a problem some how, make sure and check your cables, I always check my cabling first then go from there, it is amazing even in this day and age how many problems cabling can cause.

Hondabuff

dmarcisco wrote: »

Step 1) Printer set to DHCP *FAIL*
I agree I was not the one to set up the printers. I recommended setting the printers to static.
Step 2) Assigning an IP address and failing to ping the Printer from the switch which would of told your its not a layer 3 problem and its a layer 2 or 1, Failing to check arp table on switch to see the ip and mac exsisted. Rules out L3/L2 Problem
"Who looks up the mac address anyway"

I actually was on site in the middle of upgrading an ISR G1 to ISR G2 and the cable guy left who I assume never checked the cables. They asked me to take a look at it so I quickly looked at it. Yes you are right the ping did tell me it was not a layer 3 problem thats why I quickly looked at the mac-address in the table. The reason I did not check arp on the switch because I wanted to see if anything was coming in on the switchport the printer was connected to. Checking the mac address table showed all connected hosts. All arp showed was the interface vlan which was not helpful in this situation.

Step 3) Not having any tools to trouble shoot Layer 1 or 2 Problems

I was not there to diagnose those problems was there for an upgrade but you are right I should have those tools handy. I happened to have a wire crimper in my bag.

Step 4) Not bringing any extra network cords with you to rule out a layer 1 issue.
There was plenty of ethernet cables around I ruled it out with a known working cable.

Not busting your chops but it probably took longer to type this post then it would of taken to fix the problem
Lol, your right it did take me longer to write the post then resolve the issue it took me about 5 minutes to fix it but about 20 minutes to type and edit the post for clarity purposes.

I don't understand what your issue is? I laid out a real world example and had many people already messaging me thanking me for the informative post. That is the intention of this post not for someone else to be berating it because your are going through personal issues.

No issue, Slow day at work today and nothing better to do . No hard feelings!

Hondabuff

I'm going to reply to the PM's. First thanks for the Neg rep. The OP has a scenario of he is troubleshooting a network issue and didn't follow the steps outlined in any Comptia or Cisco trouble shooting methodology. If he clearly followed the "steps" you learn by getting certified, he could of cut out extra steps of trouble shooting. If you are going to direct it towards new potential CCNA's which NET+ is a prerequisite then this skill would of been learned. I'm not here to tear down the OP for the post but it could of been better. Maybe he could of went a bit deeper by saying " I did a show interfaces status" and it showed my that the speed on interface fa x/x was showing 100mb of speed. Knowing that a gigabit wire requires 4 pair to work and the switch is showing 100Mb that can be determined that its a L2/L1 problem and only using 2 pair. Since the link lights were on but it wasn't showing an IP address or mac in the CAM leaves no other fault then a cable issue or failed NIC in the printer. Up/Up is Layer1/Layer2, its on but not communicating correctly. Show arp will tell you that. Show Interfaces status will tell you about how L2 is communicating. I was not even going to reply to the post until I saw the 1 pin crossed comment. Maybe he cut off a 568C end and installed a 568B.

Magic Johnson

The bane of my life is badly terminated structured cabling. A lot of buildings are done by lazy sparkies or cowboy IT companies. My LAN tester notifies of straight/cross and also if any of the wires are damaged. This can be hugely problematic if there are limited wall jacks and the cable is damaged somewhere in the middle. I always carry a small unmanaged switch and ethernet splitters just in case.

techiie

Hondabuff wrote: »

Step 2) Assigning an IP address and failing to ping the Printer from the switch which would of told your its not a layer 3 problem and its a layer 2 or 1, Failing to check arp table on switch to see the ip and mac exsisted. Rules out L3/L2 Problem
"Who looks up the mac address anyway"
.

Sorry really really slow day today. But I had to comment on the "who looks up the mac address anyway. Well looking up the mac address is extremely useful when trying to locate the exact location of the host on the switch. We use show mac address-table address <mac address> quite often to find hosts/printers/servers to narrow down locations so because you don't doesnt mean it applies to everyone.

#Sh arp
will show the vlan that the host is associated to not the exact port.

volfkhat

You would also check the switch CAM table when chasing down DUPLICATE ip addresses on your subnet.
So... still a relevant command.

Hondabuff wrote: »

Not busting your chops but it probably took longer to type this post then it would of taken to fix the problem.

lol
Calm down dude; we can't all be as fast as the Honda :]

I appreciated the OP's share; was not aware of the UP/UP False-positive.
I learned something new!