If Discovery didn't regulate Shazzam's rate, it would spew packets so quickly that it might not work correctly, and might even cause some issues on your network. Out-of-the-box, Shazzam is set to transmit no more than 3,000 packets per second — which is actually a fairly conservative figure (most modern networks should be able to easily handle far higher rates). We set Shazzam's regulator to this rate so that it would operate safely on nearly all networks. But what if you've got a need for speed? Or what if you've got a MID server sitting in an office running on an old-fashioned 10 mbps hub, and you need to slow it down even further? Can you do this?
Well, of course you can! And you don't even need to write any JavaScript to do it. Here's how:
The first thing you'll need to do is to figure out where the "weakest link" in your network is, for those network segments where a MID server is located. You may want to consult with your network organization to do this. Typically this will be a segment with older, slower hardware, or with a slow WAN link to CIs (hardware devices) being scanned. In some cases, all your MID servers will be located on modern switched networks, 100 mbps (or faster). In any case, locate that weakest link — and then figure out how much network traffic the MID server could safely inject on that segment. Estimate this in bits per second. For example, on a modern 100 mpbs switched network, you might decide that injecting 20 mbps was perfectly safe. On the other hand, if you're going to scan an office connected to the MID server via a T1 (1.5 mpbs), you might want to limit your injected traffic to no more than 0.3 mpbs. I'll use these two numbers (20 mbps and 0.3 mbps) for my examples here.
These parameters work together to control the rate at which Shazzam will transmit packets — no more than regulator_max_packets will be transmitted per regulator_period_ms. In the example at right, the settings are for no more than 1 packet per 5 milliseconds, or no more than 200 packets per second (since 5 milliseconds is 1/200th of a second). If you figure that the average packet transmitted has about 1,000 bits (in reality the packet sizes vary, but 1,000 bits per packet is a good estimate), then this setting results in a maximum injected traffic rate of 200 kbps, or 0.2 mbps.
Now lets take our examples above — 20 mbps and 0.3 mbps — and figure out the Shazzam regulator settings we need to achieve those limits. 20 mbps is about 20,000 packets per second (figuring the same 1,000 bits per packet). By setting regulator_max_packets to 20 and regulator_period_ms to 1, that's what we'll get. 0.3 mbps is about 300 packets per second, or 3 packets every 1/100th of a second. By setting regulator_max_packets to 3 and regulator_period_ms to 10, we'll throttle Shazzam down to that slow rate.
That's all there is to it!
A couple of notes:
Sharp-eyed networking types out there might howl that all I've accounted for here is outbound traffic (that is, packets transmitted from Shazzam). Inbound traffic I've completely ignored. What kind of idiot would do that!?! Well, here's the deal: on most networks, the IP address ranges are rather sparsely populated, and therefore most of the packets Shazzam transmits will not get any answers. In such a case, the inbound traffic only comes from those relatively few IP addresses that actually have devices on them, and that incoming traffic will be negligible when compared with the outbound traffic. However, if your IP ranges are densely populated (that is, most IP addresses DO have a device on them), you might want to adjust my math a bit. A simple way to do this is to multiply the estimated bits per packet times an adjustment factor that's based on your IP range density. For example, if your IP ranges are, on average, 35% populated, then multiply 1,000 bits per packet times 1.35 (to get 1,350) and then use that for the rest of the math above. This will give you a slightly better result.
One other reason you might want to throttle Shazzam down is if your network is monitored by an IDS (Intrusion Detection System) or similar device that gets upset when it detects port scanning activity. Often these devices are triggered by the rate of port scanning, so if you sluggify Shazzam (quelle horreur!) it will not cause alarms to go off. However, a better solution to the IDS issue is to have your network team configure "exemptions" for your MID servers. Every IDS I've ever seen has such a capability, though your network team may not want to admit it...
