Filtering a SPAN session from a switch
-
Sigh
-
-
166Mpps. No.
-
so youre saying pfsense CANT handle theoretical throughput of 2gbps?
166 million packets isnt much, even for a firewall on non-asic hardware.
EDIT:
the 'medium business' hardware package being sold on the pfsense webstore can handle that just fine. and assuming its the 2015 cpu id say most pfsense boxes being built in a corporate test lab are going to be that age if not newer. OP is clearly not in a home lab. -
166Mpps at 64-byte packets is enough to saturate about 85 gigabit/sec, bro.
Oh. I get it. You think a packet is a byte. We will have to come to terms so we can communicate effectively. Might I suggest Comer.
-
166Mpps at 64-byte packets is enough to saturate about 85 gigabit/sec, bro.
Oh. I get it. You think a packet is a byte. We will have to come to terms so we can communicate effectively. Might I suggest Comer.
no, a packet isnt a bit. that would be a byte.
2gbps / 8 (bit to byte conversion) = 250MBps (bytes).
MTU of 1500 BYTES (since thats the typical mtu, but can vary.) 250,000,000 / 1500 = 166,666 packets. since most packets arent full, and average 576 bytes, that would be 434,027 packets per second. Since thats the theoretical throughput, you can actually adjust that number depending on actual averages. but if you wanted to run it your way and misinterpret a packet to be a byte, that would be 250Mpps ON A SINGLE LINK. Correlating that with the iperf tests i literally just ran 1gbps at 8% cpu utilization, and im not on top end equipment. So I'd say its fair to say a pfsense install in a corporate lab environment is going to be capable of pushing 166Mpps across its 'backplane'. Since, you know, packets per second are theoretical measurements used to descript the capability of a backplane, and not a sing link, bro.
i do appreciate the snide remarks though. keeps me on my toes :)
-
Dude. The first rule of getting out of a hole is to stop digging.
In no sane networking conversation does packet = byte.
-
Dude. The first rule of getting out of a hole is to stop digging.
In no sane networking conversation does packet = byte.
im failing to see how assuming a packet being a single byte, and link speeds moving at 250 megaBYTES per second, isnt 250Mpps.
ive already explained how pps is measured against a backplane, and not a single link. before you jump to the conclusion i dont know what im talking about you can go educate yourself on this topic with some cisco tech specs and running the numbers yourself.
and in no sane networking conversation is packets per second a single link. thats always across a backplane. measuring links speeds in pps isnt easily understood because of the complexity. links speed being tyically measured in bits per second or bytes per second. Point being, if the PPS on a 2Gbps link is in the hundreds of thousands, the backplane on the hardware being capable to handle in the millions, there isnt a performance issue. Therefore, the hardware can handle it.
-
Because the basic, minimum packet size is 64 BYTES so 250 megabits/sec is 480,000 packets per second, using rudimentary math.
-
Because the basic, minimum packet size is 64 BYTES so 250 megabits/sec is 480,000 packets per second, using rudimentary math.
alright, follow the bouncing ball here.
480,000 pps max on a single link. im saying single link loosely, because its going the be the aggregate of presumably a LAGG interface.
backplane PPS being 166M.
so a link transferring 480Kpps leaves how much left for the rest of the backplane? 165,520,000 packets per second (unconsumed), using rudimentary math.
Therefore:
the hardware can handle it. -
You will never be able to have an intelligent conversation on this subject with anyone until you understand that a byte is not a packet.
-
You will never be able to have an intelligent conversation on this subject with anyone until you understand that a byte is not a packet.
Of course a packet isnt a single byte, bro. which at this time id like to point to where i said:
@isolatedvirus:im failing to see how assuming a packet being a single byte, and link speeds moving at 250 megaBYTES per second, isnt 250Mpps
To which you said the minimum is 64b. Which places a 2gbps link well within the capability of hardware that can handle 166Mpps to filter/route.
I'm really failing to see why youre not understanding 166Mpps is a backplane throughput, and not a 2gbps link throughput.
-
166Mpps is 85 gbit/sec, not 2gbit/sec, dude. Stop saying pps when you mean Bps
-
166Mpps is 85 gbit/sec, not 2gbit/sec, dude. Stop saying pps when you mean Bps
-_- do you even know what a backplane IS??! i mean seriouosly. tell me what a backplane is.
-
Do you even know what a packet is? Tell me what a packet is.
-
Because the basic, minimum packet size is 64 BYTES so 250 megabits/sec is 480,000 packets per second, using rudimentary math.
alright, follow the bouncing ball here.
480,000 pps max on a single link. im saying single link loosely, because its going the be the aggregate of presumably a LAGG interface.
backplane PPS being 166M.
so a link transferring 480Kpps leaves how much left for the rest of the backplane? 165,520,000 packets per second (unconsumed), using rudimentary math.
Therefore:
the hardware can handle it.reread this maybe? im seriously at a loss for words on how else to word this. maybe ignore the numbers for a second? Backplane minus link = leftover resources on the backplane. If the backplane is faster than the link, there is left over resources. Meaning the hardware is capable of handling the throughput.
-
Do you even know what a packet is? Tell me what a packet is.
a packet being layer three encapsulation of a frame, marked typically with tcp/udp as the transport layer protocol but not exclusively.
Standard MTU on a packet being 1500, unless youve changed something.
EDIT:
and by change something i mean mess with the MTU, like enabling jumbo frames to support larger packets. -
maybe this is whats tripping you up since you didnt know pps is a measurement commonly given for a backplane.
so youre saying pfsense CANT handle theoretical throughput of 2gbps?
166 million packets isnt much, even for a firewall on non-asic hardware.
EDIT:
the 'medium business' hardware package being sold on the pfsense webstore can handle that just fine. and assuming its the 2015 cpu id say most pfsense boxes being built in a corporate test lab are going to be that age if not newer. OP is clearly not in a home lab.that 166Mpps is clearly me referencing the backplane. not the individual link speed given i later provided the math for the calculation which came out to 166Kpps. I also clarified packets arent measured in bits but instead are measured in bytes.
166Mpps at 64-byte packets is enough to saturate about 85 gigabit/sec, bro.
Oh. I get it. You think a packet is a byte. We will have to come to terms so we can communicate effectively. Might I suggest Comer.
no, a packet isnt a bit. that would be a byte.
2gbps / 8 (bit to byte conversion) = 250MBps (bytes).
MTU of 1500 BYTES (since thats the typical mtu, but can vary.) 250,000,000 / 1500 = 166,666 packets. since most packets arent full, and average 576 bytes, that would be 434,027 packets per second. Since thats the theoretical throughput, you can actually adjust that number depending on actual averages. but if you wanted to run it your way and misinterpret a packet to be a byte, that would be 250Mpps ON A SINGLE LINK. Correlating that with the iperf tests i literally just ran 1gbps at 8% cpu utilization, and im not on top end equipment. So I'd say its fair to say a pfsense install in a corporate lab environment is going to be capable of pushing 166Mpps across its 'backplane'. Since, you know, packets per second are theoretical measurements used to descript the capability of a backplane, and not a sing link, bro.
i do appreciate the snide remarks though. keeps me on my toes :)
-
id also l ike to point out in my testing i was pushing 166kpps through a 1gbps link and saw a jump from 4% to 8% cpu utilization.
given the cpu utilization, i could push 3.2Mpps (166k * 20) and this would put me at 80% cpu utilization. Again, not on crazy hardware.
-
My apologies, I misunderstood. You can accomplish this by setting some routing rules so the traffic coming in is routed through, and filter the traffic with firewall rules. The setup would have pfsense plugged into your span port, and your analyzing box plugged into pfsense. Assuming the traffic coming in is from the same subnet this should be pretty easy.
This is where the thinsgs gets tricky and why I asked about the transparent firewall thing. The SPAN ports contains traffic that is basically duplicated production traffic, it is not the kind of traffic that flows through a firewall because it is routed to it. Also subnets are different. Ti give you an example in the mirrored VLAN I have 3 servers A,B and C. Hosts are in the 172.30.2.0/24 subnet (maybe in different subnets also but we'll leave this for another moment) and talk to C.
So I see 3-way handshakes and traffic between the machines, in both directions. My goal is ro receive all of this traffic and block any packet for server B (for example), so that the analysis machines only gets A<->C. Traffic will continue to flow between A<->B in the production VLAN, but the analysis machine will not receive it. Being B an high volume machine, removing that will reduce traffic that goes to the analysis machine via the 1 gbit interface.You set pfsense to route it. for example, set the WAN interface to go to span and give it a random ip outside of your private range. set a static route to forward traffic to LAN, and have the route encompass the network range for the equipment being tested (next hop to 172.30.2.0/24 is inside LAN), and have your analysis box on the lan port. Set firewall rules to pass ALL traffic on wan, and above that set filter rules to weed out HOST B. Also disable 'block bogon networks'.
this would essentially turn pfsense mostly into a router. PFsense thinks its forwarding traffic correctly. you could even go firther to give analysis box an ip on 172.16.1.0/30 subnet, and pfsense the other. then set that firewall rule to route traffic MATCHING the any rule to gateway "Analysis" and just define the analysis box as an upstream gateway. this would open up policy based routing for example.
I got your picture and will try. I just don't understand how pfSense will think to route to internal something that is not going to be routed, but I suspect it is in the magic of "trasparent" routing. Don't know how it can behave since all parts of the TCP connection (3w handshake) appear on the wan instead of coming from wan and lan. Worth trying.
Thanks
