Interesting One

Unanswered Question
Jun 9th, 2008

This is a good one. We had two network connected devices, a printer and a sort of scanning pedestal. The printer seemed to work fine, however the pedestal, although pulling a DHCP address successfully, had no network connectivity, ipconfig /renew didnt't work either, so it would pick up an IP address at boot time but never thereafter. It couldn't ping its default gateway or anything. One of the available structured cable runs had a bad pair and that only added to the general pain and feelings of despair.

Another symptom was that if you plugged the printer cable into the pedestal it worked, and if you plugged the pedestal cable into the printer it stopped working. Obvious right ?

If you did a show mac-address table interface gig 3/0/28 it was empty, even though you could see that the network connection was sending packets in the network applet of XP. You could also see that no packets were being recieved by XP.

We fiddled around with different cables and structured cabling and generally tried everything , enabling and disabling port security, upping the max allowed addresses, clearing port security, eventually siting the pedestal next to the switch and removing the structured cabling from the equation.

It was during this time with the pedestal physically next to the switch that I made one change to the config of the port that the pedestal was plugged into and it was this that led to the solution.

At some point unknown we had plugged the pedestal into the printers good cable back to the switchport. This port had a port security max of 4. Now then, the switch therefore had the mac-address of the pedestal pointing at port 3/0/44, or at least as far as SECURITY was concerned

that was where it should be. That and the printer mac, which explains why the printer didn't work on the pedestal cable when swapped over.

I had also, at some point unknown, disabled port security on the pedestal port. The moment I enabled port security on the port it started reporting security violations on port 3/0/28 due to the mac address appearing there.... and of course it was, unknown to me, sticky on 3/0/44. The moment I removed the sticky learnt config line from the printer port 3/0/44 it jumped into life.

Conclusions :-

1. Port Security reports a problem on the port where it sees a packet, not the port where the,

mac address has been sticky learnt. So while it was merrilly doing its security thing and

blocking the traffic it didn't tell us. I had port security off so thought it was off.

2. Port Security actually changes the behaviour of the mac address database, it didn't note that

the pedestal mac was appearing on 3/0/28. Now we know it wasn't supposed to be there but

it added to the confusion and raised suspicions about the PC.

3. It's probably a good idea to keep port security down to 1 mac per port if you have to use it.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Farrukh Haroon Mon, 06/09/2008 - 18:31

What you are seeing is normal port-security behavior. If one MAC is already learned on any port, it will not let any other port use that address unless you clear the stick address using

clear port-sec sticky interface x/y

Regards

Farrukh

Actions

This Discussion