Are you using switch stacks? I’ve worked a few cases like this over the years and the first one was nasty to track down so kudos for getting as far as you did, though I expect with 30s as your timer you probably hit it much more frequently than the default 2min value does. In my case the keepalives for primary and backup UCMs had to align perfectly (they are on separate 120s timers) AND the switch had to get busy before the problem would trigger.
I believe the answer is that your switch does port security stuff in the CPU so when they get busy (made worse with stacks of switches) the TCP session times out before the mac gets allowed to transmit. Since TCP retransmit timers are based on RTT that timeout can be just a few seconds. Long story short, don’t make your port security aging time equal to or less than your signaling keepalive. I’m afraid I don’t have much to add about why you see it show up in the data vlan first. Maybe the first packet in that case is a CDP packet? That won’t be tagged so may result in a mac address-table entry for the native vlan (just a guess). -Ryan On Mar 26, 2015, at 9:55 AM, Pawlowski, Adam <[email protected]> wrote: Good morning all, I have a question that I'm sure someone's run into before, so I'm pretty hopeful this time for an answer. Years ago our data group devised a standardized edge port configuration. They implemented port security with an aging time of 1 minute. Today, we're rolling out Cisco 7800/8800 SIP phones as replacements as our 7900s fall apart. I've noticed that this doesn't jive well with our port-security. The phones themselves don't operate on 30 second keepalives like the SCCP phones, but instead default to 120 seconds between attempting to prod the UCMs via SIP REGISTER messages. What I'm seeing is that the phones drop out of the MAC address table on the switch in 60 seconds if they are idle as they don't do anything. Then, when they send the register, the first packet is lost and is retransmitted because of port-sec. That's not great but isn't breaking anything. However, what I've noted under load is that the phones are re-registering. Captures show that they have to send a varying number of re-transmissions before communications are successful, and depending on what the situation is on the phone regarding timers, it will close connection to the UCM and re-register to another. Apparently the UCM doesn't support dual-registration in that it can hand-off to the standby UCM without dying off and re-registering, but that's a different thing. What I'm seeing is illustrated below. The Voice VLAN is 960, the data VLAN is 10, and my phone's MAC is the 001b.2a20.5172 (7961G SIP in this case, but I am reproducing this with an 8851 on the table here too). sw-cc1-122(config)#do sh mac addr int g2/0/38 Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- 10 848f.69f8.d3c8 STATIC Gi2/0/38 960 001b.2a20.5172 STATIC Gi2/0/38 Total Mac Addresses for this criterion: 2 sw-cc1-122(config)#do sh mac addr int g2/0/38 Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- 10 848f.69f8.d3c8 STATIC Gi2/0/38 Total Mac Addresses for this criterion: 1 sw-cc1-122(config)#do sh mac addr int g2/0/38 Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- 10 001b.2a20.5172 STATIC Gi2/0/38 10 848f.69f8.d3c8 STATIC Gi2/0/38 Total Mac Addresses for this criterion: 2 sw-cc1-122(config)#do sh mac addr int g2/0/38 Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- 10 848f.69f8.d3c8 STATIC Gi2/0/38 960 001b.2a20.5172 STATIC Gi2/0/38 Total Mac Addresses for this criterion: 2 So what I'm wondering is why does it join the data VLAN again before ending up on the voice VLAN? Why does it take longer when things are "busier" on the switch or in the data network for this to begin working? Is there a recommended setting either for the port-security aging, or say the SIP "keepalive" interval that should be changed here? On the phone side we have some ability to change things easily, obviously reconfiguring switch ports is not as easy. As always, comments appreciated. Regards, Adam Pawlowski SUNYAB NCS _______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
