Broadcast storm
-
Best practice would be correct size ;) That allow for room for growth.. and its good idea if possible to leave adjacent networks open so that you could expand even more or bring up a new subnet in the same logical block, for lots of reasons one of which is the ability to summary route, etc..
If you have 500 servers then a /23 would be most likely enough.. But doesn't leave a lot of room.. Do you really have all your servers on same subnet now?? These servers all do the same thing for the same people? Quite often servers would be broken up into their own subnets based upon location/function/dept etc. etc.. 500 on the same broadcast domain seems high to me to be honest..
You sure wouldn't put servers that serve public or other parts of the network on same subnet as say your database servers or print servers or AD servers, etc.. So that can firewall traffic.. Sure I could see if small location with a handful of servers, and nothing to the public might be easier to just put everything on one network..
But a location that has 500 servers, unless your talking 500 of the same thing I don't see those being on the same network anyway..
-
Best practice would be correct size ;) That allow for room for growth.. and its good idea if possible to leave adjacent networks open so that you could expand even more or bring up a new subnet in the same logical block, for lots of reasons one of which is the ability to summary route, etc..
If you have 500 servers then a /23 would be most likely enough.. But doesn't leave a lot of room.. Do you really have all your servers on same subnet now?? These servers all do the same thing for the same people? Quite often servers would be broken up into their own subnets based upon location/function/dept etc. etc.. 500 on the same broadcast domain seems high to me to be honest..
You sure wouldn't put servers that serve public or other parts of the network on same subnet as say your database servers or print servers or AD servers, etc.. So that can firewall traffic.. Sure I could see if small location with a handful of servers, and nothing to the public might be easier to just put everything on one network..
But a location that has 500 servers, unless your talking 500 of the same thing I don't see those being on the same network anyway..
Yes, 500 servers in one broadcast domain. That's why im going to split it up now before it's to late haha . It's very easy to split it up because there are a lot of different servers.
-
Ok, I did some more research. I found out that the storm is a L3 storm, a netbios storm.
I did a wireshark capture, and this is the line that keeps coming back:
source 172.16.1.1 destination 172.16.255.255 protocol NBNS info name query NB ISATAP<00>This is an example, but the info part changes according to other names.
I found this post that looks like a similar issue:
https://forum.pfsense.org/index.php?topic=95379.0Is it normal behavior to forward netbios request between interfaces? If so, what's the use of it?
Edit:
The equivelant of cisco is "no ip directed-broadcast" is this possible with pfsense? And so not, isn't pfsense vulnerable for a smurf attack? -
And the weird thing, if I turn of the gateway in the default lan to * rule this is not happening.
-
I am not aware of pfsense forwarding directed broadcast or broadcast traffic.. But maybe since you say that ANYTHING send it to this gateway… But if you didn't have those 2 different layer 3 on the same layer 2, then you wouldn't have an issue would you??
-
I am not aware of pfsense forwarding directed broadcast or broadcast traffic.. But maybe since you say that ANYTHING send it to this gateway… But if you didn't have those 2 different layer 3 on the same layer 2, then you wouldn't have an issue would you??
Yes, that's right. Going to seperate it in vlan's anwyay. But maybe it's an idea to include an option in the interfaces like cisco's "no ip directed-broadcast".
-
When I get a chance I will test, but AFAIK it should not forward direct broadcast or broadcast anywhere. I have never it seen it do such a thing.. It shouldn't could test by creating a gateway and then creating a rule to send everything down that gateway and see what it does..
-
route-to (rules specifying a gateway) doesn't necessarily follow the rules of routing traffic that normal routing of the OS will. If passing broadcast traffic with a rule with a gateway, it will forward that traffic as instructed. Where your architecture is poor and you have HA, that can result in a routing loop that's akin to a broadcast storm.
Block broadcast traffic before matching pass rules specifying a gateway in that case.