2

Could someone shed some light on measures I could take to ensure a few clients (ports) doesn't flood traffic (perhaps UDP?) and congest the switch for everyone? I've always been a little behind on Ethernet flow control outside of TCP scaling, which in the end of things, could be ignored by a malicious client.

2
  • 1
    What kind of switch do you have? Different manufacturers have different methods.
    – Ron Trunk
    Nov 25 '14 at 14:01
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 10 '17 at 23:22
2

There are a few ways of setting a limit on single user bandwidth consumption. It isn’t very common for an individual to seriously affect your entire network unless they genuinely have malicious intent. Along with technical suggestions, it is also worth adding in administrative ones, too.

  • Access Control: Limit who has access to your machines and what gets done on them. This isn’t a technical step, and not even viable in every scenario (like a downstream customer), but your initial question leads me to believe you’re concerned with nefarious users on your network. A good step would be to not let them on to begin with or stopping them from getting toolsets that allow them to do what your trying to prevent.

    You’ll almost always find that once a lower layer is penetrated, the higher ones start to follow. It isn’t always common to find a machine vulnerable to some 0-day you found off exploitdb, but it is common (and easy) to find an open port, send out bogus ARP replies, and then spoof websites. 802.1X is getting heavy push in most organizations for a reason: port-security just isn’t cutting it anymore.

  • Solid Device Baseline: Get a good, secure baseline that all of your devices are working off of. Even if you restrict someone to a 128k connection, that won’t stop any amplification attack and will render the entire initiative useless. Good device baselines can be found on the NSA's site, along with solid explinations.

  • Policing: This is effectively setting a hard cap on any port you choose. Anything beyond the pre allocated bandwidth is just chopped off and sent to the bit bucket. If you’re looking to limit a single port to a specific amount of bandwidth, this is the easiest way of achieving it.

    This does have a critical drawback, it isn’t intelligent in any way; once an interface reaches that threshold, it’s gone. What does this mean when no one’s using the network? Well, those policed aren’t going to, either. You can look at that as wasting usable bandwidth.

  • Shaping: There isn’t a good way of performing this within the boundary of your LAN, but it does an excellent job of sharing bandwidth at the edge (probably your POP or your customers POP). If you police a port, that port can never exceed the amount you’ve provisioned. When you shape, you can set group bandwidth percentages and different drop characteristics that allow priority ports all the bandwidth they can eat, when they actually need it.

    This, too, has a pretty big drawback; it’s kind of difficult to get going. You will need to figure out a marking/queuing discipline that gives you exactly what you want. Plus, you’ll need to get all of the devices on your network talking the same language (configuration-wise) before you get real benefit from it.

8
  • 1
    The Port Speed and Hardware Limit sections are wrong. While I appreciate the reference to my duplex mismatch answer, you cannot have a speed mismatch. If you have two devices configured for different speeds, they will not link up because they can't speak the "same language." Even if only one side is configured to negotiate, prenegotiation will allow it to choose the correct speed. As for the hardware limit section, 100M also only uses only two pairs. Starting at Gigabit is where all four pairs are used.
    – YLearn
    Nov 25 '14 at 23:41
  • You're totally right on the Hardware Limit section, rookie mistake. As for the Port Speed, I was referencing manual speed/duplex settings on one side, and auto speed/duplex settings on the other. Devices will link up and talk with different speeds/duplexes in that instance; one side will auto down to a-10/half, with the other operating at whatever port settings it was configured with (100|1000/full). I did remove it for clarity, though, as it isn't a good way of doing business.
    – Ryan Foley
    Nov 26 '14 at 12:21
  • You can have a duplex mismatch, but never a speed mismatch. If both sides are using a fixed speed configuration that doesn't match, you will get no link. If they match, no problem. If at least one side is configured for auto-negotiation, then it will either match the configured speed (if the device can support it) or fail to link up at all (if the device doesn't support it, such as a 10/100 device connecting to an interface configured for Gigabit). In any situation, there will never be a speed mismatch because a speed mismatch will result in no link.
    – YLearn
    Nov 26 '14 at 18:44
  • I'm afraid that simply isn't accurate; I'm struggling to fix a network right now where workstations are set to 100/full but auto-negotiation on the switch end is pushing it down to a-10/half.
    – Ryan Foley
    Nov 26 '14 at 19:27
  • Not knowing your situation, I would have to say there is something else at play there. Either there is an intermediary device, or there is some other sort of failure or bug in play. You simply can't have a 100baseTX to 10baseT link...it doesn't work that way.
    – YLearn
    Nov 26 '14 at 20:19
2

There are many ways of addressing this and which one you choose can be dependent on the situation. Let me go over some of the more common ones.

  1. Quality of Service (aka QoS) - this could include rate limits, policing, marking traffic, etc. Depending on the capabilities of the device in use, this can take on a number of forms.
  2. Storm Control - depending on you device, this can provide hard limits and/or scaled limits on the amount of traffic that is received from a host. This will typically at least include broadcast traffic, but may also include multicast and/or unicast traffic as well.
  3. 802.1X/RADIUS - not only does this provide limitations requiring devices to authenticate to the network, you can configure policies that the host will be limited by, such as the amount of traffic allowed over a given period of time.
  4. IDS/IPS/SEIM - this would be a security based solution that would be looking for various types of events or abnormal behaviors. It can generally be configured to alert and/or take action when certain types of events occur.
0

One way would be to use ACLs/firewall filters (depending on the vendor) to rate limit traffic on those ports. It depends on what type of features are supported on your box.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.