[c-nsp] Catalyst switches and %C4K_EBM-4-HOSTFLAPPING

Peter Rathlev peter at rathlev.dk
Mon Oct 17 05:38:54 EDT 2011


On Mon, 2011-10-17 at 10:59 +0200, Henry-Nicolas Tourneur wrote:
> The topology looks like this:
> 
> [CUSTOMER DEVICE] ---> [RADIO CPE] ---> [RADIO BASE STATION PmP]
>                                            ||
> 							 ||
> 							Ethernet Trunk
> 							 ||
> 							 ||
>      [Cisco Router]----Ethernet trunk---[Catalyst switch]
> 
> We provide IP services to the customer, it's done as you see in the
> above diagram.
> If the customer device starts announcing the same MAC Address than the
> Cisco router, it'll make the Catalyst switch flap inside that VLAN
> (which indeed creates very high CPU usage, 99%).

The flapping itself might not be the only thing driving the CPU usage
up. You might have a genuine loop and see all the side effects of this.

> So, isn't there anything we can do to prevent this? 
> Any switchport security to disable all the traffic of a VLAN when it
> flaps too much?

You could use port-security with "switchport port-security violation
shutdown vlan", which disables a specific VLAN when a violation occurs.
Beware of the "stickyness" of MAC addresses when using port-security.

If the customer is using a router so you only expect to see one (maybe
the same) MAC address per VLAN you might have luck using a MAC
access-list on your switch and disable learning for these VLANs. This
might be too complex if the VLAN is used for more than one customer. And
it would prevent the customer from changing his MAC address(es) and thus
swap out his router.

AFAIK there isn't much else you can do. What is the customer device? A
router or a switch? Would you expect to see many different MAC addresses
coming in from the customer or just one (per VLAN)? When things go wrong
do you see more than the expected number of MAC addresses from the
customer side, other than the MAC address of you router that you
mentioned? Are you using STP towards the customer, and does your
spanning-tree include them?

-- 
Peter




More information about the cisco-nsp mailing list