port-security issues with printers

[thomsmith]

I am experiencing intermittant issues with printers simply dropping off the network. Every couple of days, the print queue will die and the printer stops responding to ping. Ping from another another PC on the same subnet and then it appears to "wake up." I can then ping from other subnets and print queue becomes active.

General observations: router can not ping printer, printer IP address appears in router arp cache with correct MAC, printer MAC does not appear in switch mac address table, ping printer IP from switch, printer MAC appears in switch mac address table, router can ping printer, queue becomes active and printer is now reachable from remote subnets.

The switch port configuration is included below...

interface FastEthernet0/8

description *** PRINTER ***

power inline never

switchport access vlan 600

switchport trunk encapsulation dot1q

switchport trunk native vlan 600

switchport trunk allowed vlan none

switchport mode access

switchport nonegotiate

switchport block multicast

switchport block unicast

switchport port-security

service-policy input SEFCUmarkTraffic

macro description unused | printer

no cdp enable

spanning-tree portfast

spanning-tree bpduguard enable

spanning-tree guard root

I am convinced this is a port-security issue, but I have no idea what it is. To prove it's the problem, I disabled port-security on all printer ports at one of three sites experiencing the problem. I'll monitor and provide updates. Any assistance is appreciated!

[m-haddad]

I am just wondering why do you have the port configured as trunk? All you need is an access port!

Regards,

[thomsmith]

The port isn't configured as a trunk. The config is based upon a secure configuration guide from nsa.gov (see http://www.nsa.gov/snac/os/switch-guide-version1_01.pdf ) and a very security conscious financial environment. The config is intended to prevent ports from coming up as trunks and malicious vlan hopping.

After further troubleshooting, I am inclined to switch paths away from my initial port-security suggestion. I found another url that very closely matches my situation. http://www.ciscotaccc.com/lanswitching/showcase?case=K43408304 . Now what to do?

[m-haddad]

Hello,

I suggest to check if there is an IP address conflict. Also, try to upgrade the switch IOS. I had similar problem and it was solved after upgrading the switch IOS.

Regards,

[Mikhail.Galiulin]

Hi,

Could it be that you have static ARP record for the printer on your router? (I just trying to understand how router can have correct MAC in ARP table while the switch has no MAC adress in forwarding table.

I think that the "switchport block unicast" could be the cause of problem. The scenario is following: printers mac-address dissapears from forwarding database on the switch after a period of inactivity. At the same time router beleives that it can forward trafic direct to printer becase it knows its MAC-address (remember, I assume that router has static ARP record for the printer). When the forwarded packet comes to the switch the switch doesn't know where to forward the packet because the printers MAC-address missing in forwarding database. Normally, it will flood the packet but in your case the switch can not do this because of "switchport block unicast". So packet never comes to printer. When you ping the printer from any other address in the same subnet the standard ARP procedure is launching first (becase other hosts doesn't know printer's MAC-address). So the broadcast packet goes through the switchport to the printer, "wakes it up", printer answers and the switch places printers MAC-address in its forwarding database. Now you can communicate with the printer till it will "sleep" again.

Another recomendation is to check ethernet frame type on the printer (a while ago I had a communication problem quite similar to yours between 72XX router and IBM iSeries machine due to ethernet type mismatch).

//Mikhail Galiulin

[thomsmith]

Confirmed, as expected, this morning that port-security isn't the source of the problem. Had to ping and force ARP from another PC in order for switch to learn the L2 address.

There are no static ARP entries in the router. Nor are there any IP address conflicts. The router has, by default, a 4-hour ARP timeout vs a 5 minute L2 timeout on the switch. So the IP appears in the router ARP long after the MAC has aged out of the switch forwarding table. And as you suggested, the unicast isn't being flooded because of the switchport block unicast.

Would changing the mac-address-table aging-time to match the router ARP timeout also resolve this issue? Or will I continue to experience problems until I re-enable unknown unicast flooding on these ports?

[Edison Ortiz]

"Would changing the mac-address-table aging-time to match the router ARP timeout also resolve this issue?"

Even if it doesn't solve the problem, that's the ideal design. All devices must have a similar ARP timeout, else you will run into problems.

[Mikhail.Galiulin]

OK. So the problem seems to be that sometimes router still has printers MAC-address in its ARP cache while switch aged the address out from its forwarding database.

I don't think that it is good idea to increase MAC-address-table aging time. Why is the ARP aging time is so long? Is there any special reasons to this?

As a simple workaround which doesn't affect parameters on both router and switch I can recommend to set up IP SLA agent on the router which will simply automatically ping the printer each 3,4,5 minutes, so switch will always have "fresh" MAC-address in its forwarding database.

//Mikhail Galiulin

[thomsmith]

I may have mis-spoke previously. Because I thought I was simply stating default timeouts; 14400 sec for ARP and 300 sec for L2 MAC, at least I thought. I should say neither the arp timeout nor the mac-address-table aging-time has been changed from the default.

[Mikhail.Galiulin]

Right...

I forgot that default ARP timeout is 14400...

One more solution could be to define printers MAC address statically on the port

(switchport port-security mac-address ...).

//Mikhail Galiulin

[thomsmith]

I don't want to be in the business of policing printer mac addresses. I'm going to try changing the switch mac-address-table aging-time to 14400 sec to match the ARP timeout. If that doesn't work, I'll change the mac-address-table aging-time back to default again and remove the switchport block unicast. I'll keep you posted.

[Mikhail.Galiulin]

Well, in my opinion the problem is that when you change mac-address-table aging time it will affect all ports on the switch (or all ports in VLAN). This can cause some problems similar to the problem you are solving now in the future. That's why I recommend to define static MAC-address for the printer on the switch. This solution is addressed only to currently affected equipment and because the printer is more or less "static" device (it is unlikelly that the connection will be moved to another switchport often) it will not create significant administrative overhead.

//Mikhail Galiulin