How could one mitigate SYN FLOOD DOS on Catalyst 3750/3560 as it has no control plane protection?
Cisco Catalyst 3750/3560 SYN FLOOD protection
ciscocisco-catalyst
Related Solutions
CRC errors are often cabling problems. Here are the things I would check next before swapping out hardware:
- Are the servers connected directly to the switch or do they connect through some sort of infrastructure cabling? If so, get the infrastructure cables re-certified.
- If you have a real cable tester (not a simple continuity tester), I would test the cables.
- If the cables are hand made, I would replace with factory made cables. Often run into these types of issues with hand made cables.
- Check to see if there is any source of EM near where the cables run. Re-path the cables if you can even temporarily to make sure they are kept separate from power or other sources of EM.
Beyond that, I would start at the NICs as you already indicated. Could be you got some from a bad run.
The client switchport or the server switchport can be monitored. A third switchport can be configured as a mirror port. This means that this mirror port will receive copies of all packets on the corresponding original port, while the original traffic won't be affected.
For example, on the Catalyst 3560:
Enter configuration mode:
conf tDefine the source and set the session number:
monitor session 1 source interface fa 0/24Here, the session number can be from 1 to 66, you could also specify a VLAN or an ethernet channel. Also, interface ranges such as
fa 0/25 - 26are possible, and interface list, such asfa 0/24,fa 0/26, if you would like to monitor several clients at the same time. Also by repeating the command you can add ports, or remove usingno. Mixing ports and VLANs is not possible in the same session, another restriction is that you cannot use a destination port as a source port.Define the destination port:
monitor session 1 destination interface gi 0/1You can use a normal port, but not a VLAN. Similarly to above, a destination port cannot be a source port: a port used here can either be a source or a destination port, and only of one session. Again, you can specify multiple ports like above.
You may want to
exitconfigiration mode and save the config.You may have a look at your defined session - here multiple ports, tried like above:
#show monitor session 1 Session 1 --------- Type : Local Session Source Ports : Both : Fa0/24,Fa0/25-26 Destination Ports : Fa0/48,Gi0/1 Encapsulation : Native Ingress : DisabledYou can see an encapsulation here - optionally you can set it to
replicatefor replicating the source interface encapsulation method, such as by addingencapsulation replicateafter the source interface. Furthermore, you can specify a direction (tx,rx,both), filter VLANs and more. TheIngress: Disabledline means that the switch will not accept any frames presented to it by your capture device on a destination port. For such finer details and for further restrictions and default settings have a look at the command reference of the IOS version of your switch.
Once you configured source and destination port, you can capture the traffic using your laptop connected to the destination port, for example with Wireshark.
The number of source sessions can be limited, for example the 3560 supports a maximum of 2.
After the capturing, don't forget to remove this session configuration.
Best Answer
3750 does have some internally priority on what it prefers to punt when congested, but it's not configurable.
So you should rely on common best practices, that is on all your network edges you should have iACL (infrastructure ACL). In iACL you'd allow UDP highports, ICMP to infrastructure network addresses and drop rest. This way ping and traceroute work, but infrastructure cannot be attacked.
iACL should be complemented by policing the allowed traffic to small acceptable rates.
This way when external party is attacking addresses on your 3750, it'll be dropped by network border in the edge.
iACL usually is 100% static so it's low maintenance, as it'll only include infrastructure addresses (loopback, core links).
This will still leave wide open cases where your router is facing customer LAN directly, like when LAN is 192.0.2.0/24 and 3750 has 192.0.2.1 then usually 192.0.2.1 would not be covered by iACL and can be attacked.
Solution for those devices is either to invest on device with proper CoPP capabilities or maintain dynamic iACL always adding the router's customer facing address there.
If you only face customers via link-networks (/30 or /31) solution is much cleaner, you just omit advertising the link-network and add static /32 route for the CPE side, this way external to this router parties cannot attack the router, as they won't have route.
Alternative solution to same issue is to use non-continuous ACL entry in iACL, if your CPE link-network is 198.51.100.0/24 in iACL you could do 'deny ip any 198.51.100.0 0.0.0.254' then all the even addresses would be allowed and odd addresses denied, so if CPE is even and 3750 is odd, all current and future links are protected without updating iACL.