Suggested Hardware for 1Gbit Throughput / 100% working Hardware-Suggestion
-
The nexcoms usually have a com1 console redirection feature in the bios. I think it should work fine with that. I haven't tested gigabit performance yet so I'm interested in reading results from your tests.
-
Sure, I'll keep you informed when I have managed to get the test-environment up and running…
May I contact you in case I need help with that?Thanks!
Best regards,
Christian
-
Hello again ;)
Well the NexCom was unfortunately a complete flop :'(
It has Marvell Chips on-board and they are not recognized by pfSense at all…
Slowly I really start to think that pfSense HATES me :'( :'(Well for my last try to get this working:
Will pfSense run on this hardware here perfectly:- Intel
3010 (Mukilteo 2) Chipset 1066/800/533MHz FSB - 4xSATA-2 (ICH7R) with RAID 0/1
- 2x GigaBit LAN (Intel 82573V PCI-Express)
- Intel Xeon 3060 S775 2,40GHz 4MB FSB1066
- 2 x 1024MB DDR2 FSB667 unbuffered ECC
- 2x Hitachi 80GB SATA-2 7200U 8MB Cache
- PCI-X 133MHz Risercard for Intel Dual Port NIC Pro/1000 MT
Could anybody give me a definite "Go" for this system or does anybody know of any
component which makes a "No-Go" for pfSense?Does anybody use this Intel Dual Port pro /1000 MT - NIC successfully with pfSense?
(Without those packet-problems we have here?)Or is there any Dell-Server known as 100% functioning with pfSense?
Thanks for your answers :-)
Best regards,
Christian
- Intel
-
Hello again ;)
Well the NexCom was unfortunately a complete flop :'(
It has Marvell Chips on-board and they are not recognized by pfSense at all…
Slowly I really start to think that pfSense HATES me :'( :'(did you test it with one of the latest snapshops of pfsense ???
they use a newer version of freebsd so they suport more hardware
then the 1.0.1 version -
Yes I did… I used the newest Version on the Server :(
But thanks for your hint ;)Does anybody see a "blocking point" with the hardware-config I posted above?
Thanks!
Best regards,
Christian
-
To me the config doesn't seem much different from your blade server. Why don't you try the through put on the blade server with the firewall allowing a stright pass through and see what happens then.
Correct me if I am wrong though I thought that the firewall didn't work on bridge mode unless you changed the settings from the default.
Hello again ;)
Well the NexCom was unfortunately a complete flop :'(
It has Marvell Chips on-board and they are not recognized by pfSense at all…
Slowly I really start to think that pfSense HATES me :'( :'(Well for my last try to get this working:
Will pfSense run on this hardware here perfectly:- Intel 3010 (Mukilteo 2) Chipset 1066/800/533MHz FSB
- 4xSATA-2 (ICH7R) with RAID 0/1
- 2x GigaBit LAN (Intel 82573V PCI-Express)
- Intel Xeon 3060 S775 2,40GHz 4MB FSB1066
- 2 x 1024MB DDR2 FSB667 unbuffered ECC
- 2x Hitachi 80GB SATA-2 7200U 8MB Cache
- PCI-X 133MHz Risercard for Intel Dual Port NIC Pro/1000 MT
Could anybody give me a definite "Go" for this system or does anybody know of any
component which makes a "No-Go" for pfSense?Does anybody use this Intel Dual Port pro /1000 MT - NIC successfully with pfSense?
(Without those packet-problems we have here?)Or is there any Dell-Server known as 100% functioning with pfSense?
Thanks for your answers :-)
Best regards,
Christian
- Intel
-
Firewall works on bridges if you enable it at system>advanced.
-
As we want to support pfSense because we think it is a really great software,
we have just made an arrangement with a company, which is selling powerful
servers to make them run with pfSense.
We'll pay them for the set-up of a 1 HE-Box which will run smoothly with the newest
snapshot.
That will be our first sponsorship for this wonderful project.You can then add them to the verified hardware-list and then have the possibility to
get pfsense into those areas where really huge throughputs are needed (as most of
the currently suggested hardware is not that powerful).I hope that we have invested our money well for this project!
We will keep you updated on the progress….
Best regards,
Christian
-
Yes that is what I ment be it isn't on by default is it???
I would presume by the firewall not being on the processor speed doesn't make a difference for the through put unless it is really slow. (I mean that the proc must meet the rquirements to handle 1GB data traffic)
-
Jonb,
regarding the bridge: You have to activate it manually. Per default it is deactivated!
Regarding the CPU:
Well I think it is a combination of everything. Like when we test the throughput and have around 526 MBit/second with 130kbyte-TCP-Packets, our CPU is at 70% (tested on an old P-III with 1.3 Ghz and 3 GB Ram)
So the new System will have the power of not only handling the throughput but also (if needed later) AV-Scans etc. :)Best regards,
Chris
-
Sorry I should claritfy it better. What I ment is that if you enable the bridge over two connections on PFsense it will not pass the packets through the firewall roules. Like hoba said you can enable it in the advanced section of the setuo. Is this something you have done or are you just trying to get the firewall to act as a hub.
Jonb,
regarding the bridge: You have to activate it manually. Per default it is deactivated!
Regarding the CPU:
Well I think it is a combination of everything. Like when we test the throughput and have around 526 MBit/second with 130kbyte-TCP-Packets, our CPU is at 70% (tested on an old P-III with 1.3 Ghz and 3 GB Ram)
So the new System will have the power of not only handling the throughput but also (if needed later) AV-Scans etc. :)Best regards,
Chris
-
Hey ;-)
I yes of course a bridge uses the firewall rules :)
That's what a bridge is for… It sits transparently in front of your servers and only let's those packets through
which are allowed...Or did I get you wrong again ;D
We are currently using pfSense as a transparent FW (as a bridge) between OPT1 and WAN...
-
system -> advaced then on that page you will see
Enable filtering bridge
This will cause bridged packets to pass through the packet filter in the same way as routed packets do (by default bridged packets are always passed). If you enable this option, you'll have to add filter rules to selectively permit traffic from bridged interfaces.They way I read that firewall will only apply if you put a tick in that box which isn't there by default.
-
Ah NOW I think I get you ;D
I was thinking the other way around all the time ;)
So what you want to say is if I disable that option (and all packets are simply put through pfSense without
checking) I should try and find out what happens? -
Yes if you disable the firewall for the bridge. Then you can see what through put you can achive straight through the nic. If it is still bad than you could maybe say it is more of hardware/software with the actual routing/connection side of PFsense. If it is good then it points to firewall/processor problems.
If anyone of the dev's say I am wrong here please say :)
-
Sure,
but for us the bridged traffic counts… so we'll do all the tests with bridging enabled ;)
So we're now waiting for the new server... :)
Best regards,
Chris
-
Technicaly it should work on the blade server. I would enable the bridge and make sure that the is no firewall active on the bridge and see what you get.
-
I use Dell Poweredge 850 and 860 carp clusters.
They have 6 Ge ports. 2 Broadcom (better not use those too much) and 2 Dual Port Intel E1000 nics.
They should do fine, I use it as a internal VLAN router/firewall.A basic Dell PE 860 with the cheapest processor and 1GB ram and a disk costs between 1000 and 1200 with the Dell account manager.
I have not done any benchmarking but it looks to push atleast a couple hundred megabits and the monitoring system is not complaining.
-
While I haven't messed around with the bridging interface on pfSense much, I do know that the first thing I do with a pfSense box is set the states table to 10-25x the default value, and set the state timeout to conservative. This ensures that all 'not-well-behaved' protocols and apps still work properly. Also, since I always use 1GB of ram minimum, this is completely acceptable.
-
Just a thought, could those massively delayed packets be retransmits caused by the state table in your firewall overflowing? (well technically just filling up and waiting for connections to timeout in the state table).