2.2-ALPHA Snapshots Available
-
any idea if there will be ECMP support?
it could enable loadbalancing when dealing with dynamic routing protocols like ospf, bgp, rip.
might it even help to solve the issue's with loadbalancing certain services like squid? What are the devs thoughts about this?thanks
-
Any planned improvements regarding better AES-NI support and performance?
It's in development but is not likely to make 2.2. More news on that will come later.
-
any idea if there will be ECMP support?
it could enable loadbalancing when dealing with dynamic routing protocols like ospf, bgp, rip.
might it even help to solve the issue's with loadbalancing certain services like squid? What are the devs thoughts about this?It's on our radar but not terribly important for 2.2 (see above, re: narrow scope) but if we stick to the plan then 2.3 won't be far off and it may make it there.
-
THANK YOU for this.
IGB drivers seem to perform flawlessly with minimal tuning and various routing quirks have vanished.
-
Any planned improvements regarding better AES-NI support and performance?
It's in development but is not likely to make 2.2. More news on that will come later.
The issue isn't "AES-NI" support. The issue is that AES-GCM isn't implemented in FreeBSD.
We're fixing that, but as jimp said, it's unlikely to make 2.2.
-
Any planned improvements regarding better AES-NI support and performance?
"Support for AES-NI instruction and intrinsics has been added to gcc. The aesni module has been improved to use pipelining when possible. This results in a significant speed up for AES-XTS and AES-CBC decrypt. " according to: https://wiki.freebsd.org/WhatsNew/FreeBSD10#Kernel.2C_hardware_support_.26_other_low_level_improvements
-
@ermal:
strongswan instead of ipsec-tools.
Does that mean we'll get IKE v2? I'm getting a bit tired of connecting to ASAs and having their admins make comments about having to "downgrade" their equipment.
@gonzopancho:
The "not many other changes" was intentional. By limiting the scope we stayed out of the mess that bogged down the 2.1 release.
The method used: Set an achievable goal; Meet it. Repeat.
Rapid, iterative development. That's the way to go. Glad to hear this.
-
"Support for AES-NI instruction and intrinsics has been added to gcc. The aesni module has been improved to use pipelining when possible. This results in a significant speed up for AES-XTS and AES-CBC decrypt. " according to: https://wiki.freebsd.org/WhatsNew/FreeBSD10#Kernel.2C_hardware_support_.26_other_low_level_improvements
I assume that 2.2 is built with LLVM and not gcc. LLVM has had AESNI for a few years now.
-
I saw one of the first posts mentions that you wanted CARP tested.
I can install this on my home setup secondary router and enable CARP again, should you be able to sync between 2.2 and 2.1-RELEASE (i386)?
-
@ermal:
php-fpm instead of php in general.
This is a fairly big improvement for memory usage.
On a 256mb system (ie ALix2d3), it should be safe enough to turn opcode caching back on which provides a nice performance win.
-
Gitsync master? Or other??
:)
-
Gitsync master? Or other??
:)
Master, until it gets branched. Gitsync is only marginally useful these days though.
-
Thanks! 8)
Just trying to break things until someone goes over and kicks the snapshot server. ;D
-
unable to install package SQUID 2.7 and squidguard
ERROR: No digital signature! If you are SURE you trust this PBI, re-install with –no-checksig option.
-
Hi
Are 64bit snapshots stopped?
Thanks
-
We have been focused on getting 2.1.2 out to fix Heartbleed. 2.2 snaps will be back around soon.
-
@ermal:
strongswan instead of ipsec-tools.
Will settings be automatically migrated for ipsec tunnels, or does the move mean setting up the tunnels from scratch?
Having a very peculiar problem with my connection that started showing up since i started using the 2.1.1 betas, and that has been sticking around since then, so testing a different ipsec stack sound tempting…
-
Greetings All,
My first question can be ignored. I realize this is not possible as packets can only hold the next hop. I was working with someone and we basically assumed that it could work because some other devices let you create these route statement, but it turns out the only reason it was allowed was for documentation purposes and it shows that as usual pfSense is doing it correctly.
[IGNORE]
- Will pfSense ever allow for route creation with a remote gateway. e.g. If my default gateway is 1.1.1.1 and through it I can reach 2.2.2.2 and I want to create a route to 3.3.3.0/24, I can set most other business class routers and firewalls like Cisco ASAs so that 3.3.3.0/24 can be reached via 2.2.2.2 without having an IP in the same subnet as 2.2.2.2.
Is this a FreeBSD limitation? Is the fix a simple kernel flag or can the kernel be compiled to allow for this?
Additionally, I get that this can be an issue for multi-wan, but I would guess there is a way to deal with that as BSD is the basis for many high-end routers out there that support multi-wan.
Would the solution would be to have a rule that pushes traffic to 3.3.3.0/24 through the correct interface, using the default routing table. This is no big deal with the current setup as with multi-wan currently you have to create rules for all traffic that needs to use the default routing table.
The real technical challenge is when 2.2.2.2 can be reached via multiple WAN interfaces something has to be created to push this traffic through the active WAN with the highest priority.
[/IGNORE]- A More simple multi-WAN setup. Currently you have to create rules to use multi-WAN setups which means that you have to create separate rules for internal traffic. The idea is that the admin could specify multiple WANs as default with the LB and Failover metrics and all traffic to default would be sent down the appropriate WAN without special rules. Maybe other systems allow for this by creating their own IP stack with a routing table system that allows for this, so maybe it's not possible with stock BSD.
I believe that FreeBSD supports multiple routing tables. Could route-to be used with fibs or is there something that could replace route-to for use with fibs?
e.g. If a user has two wans pfSense could create two fibs. Each fib has all the same routes, I understand this would require code, except the default route for fib0 is the first WAN and the default route for fib1 is the second WAN. Then something like a gateway group could be created for the fibs. This would eliminate the need to create separate rules for local traffic which is required when using gateway groups.
Thanks,
Rhongomiant
-
"Support for AES-NI instruction and intrinsics has been added to gcc. The aesni module has been improved to use pipelining when possible. This results in a significant speed up for AES-XTS and AES-CBC decrypt. " according to: https://wiki.freebsd.org/WhatsNew/FreeBSD10#Kernel.2C_hardware_support_.26_other_low_level_improvements
I assume that 2.2 is built with LLVM and not gcc. LLVM has had AESNI for a few years now.
Support in LLVM / gcc only helps get the code compiled. Neither compiler will "recognize" the various modes of AES being compiled and magically emit the correct instruction sequence.
AES-XTS / AES-CBC are useful for storage. For IPSEC, typically AES-CTR mode is used (with SHA256 as a MAC).
Since IPSEC wants both crypto and MAC, you don't get a lot of speedup running AES-CTR mode. Thus the coming implementation of AES-GCM, which allows one to do the crypt and MAC parts in one flow, rather than two passes.
Early results say that we should be able to come close to filling a 10Gbps pipe. Certainly IPSEC at 1Gbps becomes possible, assuming hardware able to support same is used.
-
@gonzopancho:
"Support for AES-NI instruction and intrinsics has been added to gcc. The aesni module has been improved to use pipelining when possible. This results in a significant speed up for AES-XTS and AES-CBC decrypt. " according to: https://wiki.freebsd.org/WhatsNew/FreeBSD10#Kernel.2C_hardware_support_.26_other_low_level_improvements
I assume that 2.2 is built with LLVM and not gcc. LLVM has had AESNI for a few years now.
Support in LLVM / gcc only helps get the code compiled. Neither compiler will "recognize" the various modes of AES being compiled and magically emit the correct instruction sequence.
AES-XTS / AES-CBC are useful for storage. For IPSEC, typically AES-CTR mode is used (with SHA256 as a MAC).
Since IPSEC wants both crypto and MAC, you don't get a lot of speedup running AES-CTR mode. Thus the coming implementation of AES-GCM, which allows one to do the crypt and MAC parts in one flow, rather than two passes.
Early results say that we should be able to come close to filling a 10Gbps pipe. Certainly IPSEC at 1Gbps becomes possible, assuming hardware able to support same is used.
What about OpenVPN ? Will it see the same performance improvements as IPSEC?
