Telnet Flooding Without CoPP
To demonstrate what can happen when a Catalyst 6500 is attacked without CoPP enabled, a flooding attack against TCP port 23 (Telnet) was started using the hping31 utility. Running on an average PC platform using SuSe Linux, the hping3 utility generated about 110,000 pps, which would not be a problem for the 6500 in normal situations.
However, because Telnet packets are destined to the management plane, they are forwarded directly to the central CPU where they are processed. In this case, the CPU responds to the flood of arriving TCP SYN packets, which gives it little time to perform other tasks.
After a short time, the CPU load increases from its average 1 percent load to maximum load:
c6500#sh proc cpu
CPU utilization for five seconds: 98%/41%; one minute: 94%; five minutes: 60%
At the same time, the OSPF process starts to lose contact with its OSPF neighbors because no CPU cycles are available to process the incoming keepalives from the neighbors:
3w1d: %OSPF-5-ADJCHG: Process 64, Nbr 194.19.92.130 on Vlan254 from FULL to DOWN,
Neighbor Down: Dead timer expired 3w1d: %OSPF-5-ADJCHG: Process 64, Nbr 192.168.10.10 on Vlan10 from FULL to DOWN,
Neighbor Down: Dead timer expired 3w1d: %OSPF-5-ADJCHG: Process 64, Nbr 192.168.10.10 on Vlan10 from LOADING to FULL, Loading Done
Because this switch is the main routing platform in the lab, all connectivity goes down for about 30 seconds, which results in the disruption of all network services.
In a real production environment, this attack could have caused disastrous consequences as with instabilities in routing protocols—all IP traffic stops. However, a good design would contain redundant 6500s, which would result in minimal impact if one switch goes down.
But if the attacker is able to attack one switch, would it be such a big problem to also attack the other switch?
Continue reading here: Telnet Flooding with CoPP
Was this article helpful?