Broadcast storm control – a network saviour for loopingJuli 8, 2009 pukul 10:40 am | Ditulis dalam Tutorial Jaringan | 2 Komentar
Tag: broadcast, broadcast storm control, managed switch, prevent loop, storm control
How big… or how small is your network ? The bigger network you have, or the more switches you have in your network, you really must understand that a Layer 2 network is very easily attacked by looping the network.
Please take note the terminology “LAYER 2″… it means no router, no routing, no VLAN routing. So it’s just plain switching. Looping will not happen if you use a layer 3 technology.
How to loop the network ? It is very easy thing to do. Just use a UTP cable, plug it in one of the port, and plug the other end in the other port, of course in the same switch. Thanks to auto-MDI/X feature, so these ports are connected. And voila… you loop the network.
Of course, you will not do that in your LAN. But who knows ? If you are just running a LAN, it might be OK. But how if the L2 is spanned in the entire building, and some users from other department are just buying their own switches because they don’t want to be managed by the IT ? This kind of looping classic problem will always exists everywhere in every LAN.
How to overcome this situation ?
Well, one of the old technique was to disable ports those are not used in the switches. This might greatly help, but of course we never knew if someone is using the ‘already ON’ port and make the loop, right ?
Another popular technique in Layer 2 to prevent this loop is RSTP/STP(Spanning Tree Protocol). But as what I have experienced, implementing RSTP creates another headache such as, we must define where are the edge-ports so that the ports will automatically forwarding the packets. Another headache is we have to make sure the root switch is the ‘real’ root switch, which must be protected by BPDU guard, etc. It is not always bulletproof as well. Let’s say you have one switch A with RSTP activated, connecting to a switch B without RSTP activated, and you do the loop in the switch B, both switches will be down in few seconds.. AFTER there is packet broadcasting ( something like pinging to unknown IP address will create ARP broadcast, and a very good tool to create the loop ).
Luckily, there is one interesting feature that can be found in most of the advanced managed switches these days. The terminology “broadcast/multicast storm control” feature is a thing that I really like. What does this feature do ? Well, if we loop a network, it means where there is a broadcast packet generated by a computer, it will be broadcasted in these looped ports, and it will keep broadcasted until the whole switch is down. By utilising this broadcast storm control feature, we can limit all ‘suspicious’ ports, or could be the whole ports inside a switch (it’s up to you :D), with a specific number.
Some switches are using Kilobits/sec parameter, other model might use Packet/second, some I found also use percentage level (such as 50%). In some models, broadcast storm control are applied per VLAN, but majority right now this feature is implemented port by port levels.
What is the right number to fill in the parameter ? This is a difficult thing to answer. The best way to ‘predict’ this is by making a baseline of broadcast packet in your network. For example, you can use MRTG (or other similar product that can do snmp get for broadcast packet parameter), and observe what is the broadcast packet per second in a normal/peak time. After you get a number, let’s say you get broadcast packet for 100Kbps, then you can assume the maximum is twice of 100kbps, which is 200Kbps. This 100kbps number is just assumption. In one of my client, I just fill in something like 10Mbps, which is very unlikely to happen there is a broadcast with that amount.
Please take more attention when you are doing wireless LAN inside your network, and it is in the same VLAN(subnet) . Although 5Mbps of broadcast is relatively small for 100Mbps network, this 5mbps of broadcast will hammer your wireless easily. So, it might be safer if you can move your wireless implementation in other subnet (other broadcast domains). If you can’t move it, other way to do this is by implementing Quality of Service on the ports going to the wireless. For example, putting broadcast maximum to 1Mbps specifically to those ports.
How to test ? Of course… by looping it… If you are configuring it correctly, the loop might be there, but the ports might be disabled/locked, or perhaps some switches can be set to send SNMP trap to NMS, etc.
I know some switches don’t provide such feature. In this case, the only thing we can do is to do the broadcast storm control in the uplink side. But of course, looping might happen and kill that switch. It is still OK as long as it doesn’t impact on your uplink where you have bigger network, don’t you think ?