This presentation is the continuation of the presentation that I shared in March 2013 about Broadcast and Multicast Storm control in IX.
Hopefully this presentation finalises the BUM storm control in Internet Exchange.
Feel free to discuss and share!!
Thanks,
Jimmy
2. ž This is the continuation of the Broadcast
and Multicast Storm Control in Internet
Exchange topic that I shared in March
2013
ž This presentation hopefully finalizes the
BUM (Broadcast, Unkown Unicast, and
Multicast) storm protection in Internet
Exchange
ž This is for discussion and sharing
purposes
3. ž Unicast packets with unknown
destination MAC addresses
ž The packets will travel to all members in
the same VLAN
ž Creates security concern in Internet
Exchange platform since all members
are sharing the same VLAN
4. ž Causes 99% high CPU in the Line Card
where the attack comes from
ž VPLS CPU protection in Brocade is not
protecting
ž The unknown unicast limit threshold in
Brocade is not protecting
ž The 99% CPU causes packet losses to/
from the participants that reside in same
Line Card with the attacker
5. ž Drops the unknown unicast packets in
hardware
ž Tested successfully can reduce the 99%
CPU down to 1%!!
ž Record down any packets that are denied
by incoming L2 access list to syslog
ž This will fasten the troubleshooting
during BUM attack
6.
7. ž Helps to identify the source of BUM attack
ž Shows the source attack port and the related
source and destination MAC address
ž The logging can be very noisy
• Cisco devices send the periodic L2 related packets
to the specified destination MAC address
• These packets are categorized as unknown unicast
since the destination MAC address is not owned by
any participants in the same VPLS VLAN
8.
9.
10. ž We still able to drop unknown unicast
packets in hardware without enabling
logging to syslog
ž We just need to remove the deny any any
statement at the end of the access-list
ž We need to use other monitoring tools
like MRTG, INMON, or others to identify
the source of BUM attacks