Filtering a SPAN session from a switch
-
Maybe this Paint masterpiece helps
-
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.
-
What paint masterpiece?
I don't know how you think a layer 3 CPU will do better at filtering than a layer 2 switch.
If nothing else you should try filtering though another switch. Maybe something up to the task-at-hand.
-
What paint masterpiece?
I don't know how you think a layer 3 CPU will do better at filtering than a layer 2 switch.
If nothing else you should try filtering though another switch. Maybe something up to the task-at-hand.
he already said it wasnt in budget, hence abandoning my argument of replacing the cisco switch with a newer/more powerful model.
-
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
