Filtering a SPAN session from a switch
-
Maybe this Paint masterpiece helps
i dont have a fancy picture but youre going to do something like this with the topology:
hosts A/B/C in vlan XYZ get SPAN to 2gbps port -> pfsense wan (or opt interface, doesnt matter) set with static routes -> PFSense LAN connected to anaylisis box.
-
He doesn't need to replace the 6500. Just get something that can trim the traffic he needs trimmed. I mean if a $35 3750 off ebay can't do it, he's going to spend a helluva lot more on Xeons to get pfSense to do it.
-
He doesn't need to replace the 6500. Just get something that can trim the traffic he needs trimmed. I mean if a $35 3750 off ebay can't do it, he's going to spend a helluva lot more on Xeons to get pfSense to do it.
depends on what he has available. he expects his current pfsense hardware can handle it, so why not try it? My current setup is handling 10gbps throughput just fine, and im not sure an old 65k from cisco would be up to the task given the filterin requirements i have. thats besides the point though, point being that its possible he already has hardware able to do it except the said hardware isnt a switch.
EDIT:
wouldnt 166Mpps be well within most pfsense boxes anyway? thats the maximum throughput hes talking about filtering… -
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.
