Edge Router X

[kvic]

Not related to OP's question but anyone interested in ER-X might want to hear this news. The main guy behind EdgeOS decides to leave Ubnt for a new endeavour. Have to see how the firmware will evolve going forward.

http://community.ubnt.com/t5/EdgeMAX/Introduction/m-p/1649678#M123751

 

[Nullity]

Not related to OP's question but anyone interested in ER-X might want to hear this news. The main guy behind EdgeOS decides to leave Ubnt for a new endeavour. Have to see how the firmware will evolve going forward.

http://community.ubnt.com/t5/EdgeMAX/Introduction/m-p/1649678#M123751

Another interesting note is that the pfSense co-founder Chris Buechler recently left pfSense for Ubiquiti.

https://forum.pfsense.org/index.php?topic=115948

 

[Trip]

Interesting on the ubnt-pfsense talent swap. As for An-Cheng's departure, hopefully UBNT has systematized their job positions well enough to slot in the required replacement(s) and keep the machine humming. Guess we'll see how that goes the rest of this year and into next. *fingers crossed*

 

[mtganzer]

Not really...

HW Accel is a patch - a proper router doesn't need it...

LOL I'm guessing you never lived in the big-iron Internet core router world...most of the routers that pass data between your remote content and you still have a lot of specialized silicon in them.

If you use AES-NI in your Intel CPU for AES acceleration in your VPN, you are using hardware acceleration. Now CPU's have gotten faster and cheaper, so you can do a LOT more in just CPU, hardware acceleration is NOT a problem as long as you understand the limitations.

 

[mtganzer]

One thing is conceptual - those ethernet ports on ER's, just like some other devices, are not switched ports by default, they're interfaces...

Quite a few folks have been surprised that things work a bit different compared to consumer Router/AP all-in-one devices where one has a WAN port, and 4-8 switched LAN ports...

While true for the ER-Lite and similar products, my understanding is the ER-X can do line-rate switching between all 5 ports. You just have to tell it which ports you want in the switch group, and which ports are a routed interface.

 

[sfx2000]

LOL I'm guessing you never lived in the big-iron Internet core router world...most of the routers that pass data between your remote content and you still have a lot of specialized silicon in them.

If you use AES-NI in your Intel CPU for AES acceleration in your VPN, you are using hardware acceleration. Now CPU's have gotten faster and cheaper, so you can do a LOT more in just CPU, hardware acceleration is NOT a problem as long as you understand the limitations.

Yes, I work with the big-iron - and yes, there is specialized silicon inside - but it's a bit different when folks in the 'consumer' space - HW Accel there is basically turning a router into what Cisco would refer to as a multiple layer switch that functions not just on layer 2, but layers 3 thru 7 - ctf.ko in the broadcom SDK does this... and MLS, while somewhat limited by specific rules, can perform very well.

AES-NI, is not HW accel in a routing context, e.g. it doesn't forward packets any faster, but it does allow faster processing for auth, encryption, and some hashing. But, again, it works quite nicely with AES-128-cbc for example, but doesn't do anything for blowfish...

 

[System Error Message]

AES-NI and other sorts of acceleration isnt hardware acceleration in networking sense. It is hardware acceleration in the computing sense just like how SSE is used to accelerate calculations involving larger datasets. However the way that NAT acceleration is done is very different from hardware encryption because AES units, SSE and all that stuff is a unit part of the CPU core. Just like how each modern GPU core has a bunch of shaders and units each CPU core consists of a bunch of units that execute specific instructions. AES-NI is basically a logical unit part of the core just like the integer unit, floating point unit and so on.

However like any hardware acceleration there is a drawback. small hardware FPUs have a limited accuracy compared to software float, hardware AES only limit is that the frequency scales with the data size so if it was made to handle 128bit data it will do so every cycle but give it 256 bit AES and it will take multiple cycles for each data. Hardware NAT cannot do complicated QoS or firewall.

 

[sfx2000]

However like any hardware acceleration there is a drawback. small hardware FPUs have a limited accuracy compared to software float

Sorry - I do have to make a quick comment here - an FPU is IEEE compliant with 754 for the most part - if it wants to be considered an FPU - whether HW or SW driven - if I drive a calculation requirement floating point math, it better give a consistent and correct result.

Remember the Pentium fdiv bug?

Doesn't matter whether it's HW or SW - HW does it faster, but SW gives the same answer - and it better be the same answer whether it's MIPS/ARM/PPC/Sparc/x86 or SW...

hardware AES only limit is that the frequency scales with the data size so if it was made to handle 128bit data it will do so every cycle but give it 256 bit AES and it will take multiple cycles for each data.

AES-NI, at least on intel, actually runs in same path as SSE and AVX - it's just optimized instructions... don't confuse this with QuickSyncVideo or QuickAssistTech - those are functional blocks, AES-NI is not.

There are dedicated crypto blocks out there - ViA has one for their x86 chips (yes, they still make them) called Padlock, and the various ARM and MIPS processors can include crypto as well (and some are very, very, very fast... I have a friend that is working on one for an ARM scale out processor that is silly fast)

Hardware NAT cannot do complicated QoS or firewall.

Goes back to my comment about multi-layer switching, which is what BRCM is doing with ctf.ko, it is programming the ethernet fabric inside the SoC with very specific rules... it can do NAT at L3, which is a firewall onto itself in some context, but it's not a stateful implementation like Netfilter or pf, and I agree, QoS can be a challenge with an MLS, whereas a Router that is focused on L3 can do a lot more....

Which goes back to my original statement - HW Accel is a patch/crutch - if one is properly sized for traffic, then one doesn't need HW accel at all...

 

[sfx2000]

While true for the ER-Lite and similar products, my understanding is the ER-X can do line-rate switching between all 5 ports. You just have to tell it which ports you want in the switch group, and which ports are a routed interface.

ERX talks to the onboard switch directly - it configures the switch fabric initially as interfaces, not switched ports - there was a bug in the bootloader some time back (since fixed) where it would lose the configuration of the switch, and this would cause no end of pain/confusion when someone rebooted...

It's a decent design, and capable of very good performance...

 

[System Error Message]

Sorry - I do have to make a quick comment here - an FPU is IEEE compliant with 754 for the most part - if it wants to be considered an FPU - whether HW or SW driven - if I drive a calculation requirement floating point math, it better give a consistent and correct result.

Remember the Pentium fdiv bug?

Doesn't matter whether it's HW or SW - HW does it faster, but SW gives the same answer - and it better be the same answer whether it's MIPS/ARM/PPC/Sparc/x86 or SW...



AES-NI, at least on intel, actually runs in same path as SSE and AVX - it's just optimized instructions... don't confuse this with QuickSyncVideo or QuickAssistTech - those are functional blocks, AES-NI is not.

There are dedicated crypto blocks out there - ViA has one for their x86 chips (yes, they still make them) called Padlock, and the various ARM and MIPS processors can include crypto as well (and some are very, very, very fast... I have a friend that is working on one for an ARM scale out processor that is silly fast)

...

What i mean is that a FPU is fixed in that you cannot change its accuracy or use a 32 bit FPU to perform 64 bits fast without having to spend many many cycles.

I meantion AES-NI as being a part of the CPU as in crypto acceleration is part of the cpu core itself rather than something seperate like NAT acceleration for example which makes use of something outside the CPU.

Hardware acceleration for NAT has been used for quite a while now on many consumer routers even vpn based routers even ubiquiti edgerouters too. While i agree that you shouldnt need hardware acceleration for NAT many ubiquiti edgerouter users will throw stones at you for saying it as it shows how slow the edgerouter really is. At least the non rackmount edgerouters are much cheaper than broadcom prosumer routers whos users wouldnt have a clue about the hardware NAT limits and how it affects them.

If you've used openCL and get errors its usually because what a GPU calls float isnt what a CPU calls float. so FPUs arent consistent among processors. They are on x86 though. Its easy to get different values between GPUs and x86 CPUs on the matter of floats. A GPU outputting graphics doesnt have to be accurate compared to CPU because whats a pixel gone wrong in a single frame that the eye wont see?

 

[sfx2000]

While i agree that you shouldnt need hardware acceleration for NAT many ubiquiti edgerouter users will throw stones at you for saying it as it shows how slow the edgerouter really is

People can throw stones at me - that's ok, most of them have not designed routers - I have...

 

[sfx2000]

What i mean is that a FPU is fixed in that you cannot change its accuracy or use a 32 bit FPU to perform 64 bits fast without having to spend many many cycles.

We get into a funny place with bit-precision - FP32 is great for GPU's tossing out math for triangles and what not for graphics, but it's not precise enough for OpenCL applications - heck, even FP64 introduces errors that a regular FPU wouldn't generate (16 bit means a lot when we go to FP80, which is the minimum expected by most languages on a functional basis, and by languages, I'm saying C, R, Pascal, Python, etc...)

 

[System Error Message]

We get into a funny place with bit-precision - FP32 is great for GPU's tossing out math for triangles and what not for graphics, but it's not precise enough for OpenCL applications - heck, even FP64 introduces errors that a regular FPU wouldn't generate (16 bit means a lot when we go to FP80, which is the minimum expected by most languages on a functional basis, and by languages, I'm saying C, R, Pascal, Python, etc...)

GPUs actually have 64 bit units for performing doubles or FP64 but on many consumer GPUs these are usually restricted. Its why the last GPU i bought was an AMD HD 7970 as it didnt restrict double performance. Even nvidia titans have drivers artificially restricting their 64 bit performance. Every newer AMD GPU restricts their double FP performance.

 

[sfx2000]

GPUs actually have 64 bit units for performing doubles or FP64 but on many consumer GPUs these are usually restricted. Its why the last GPU i bought was an AMD HD 7970 as it didnt restrict double performance. Even nvidia titans have drivers artificially restricting their 64 bit performance. Every newer AMD GPU restricts their double FP performance.

Yep - might bite them in the you know what... Xeon Phi fixes all that - and your interest in highly parallel computation...

We might want to break this sub-topic out, it's interesting stuff, but way off topic

 

[hawkeye62]

Just a follow up. I have the ER-X installed and working on my network. Easier than I thought to configure and get working. I had three devices that I had to power down/up to get connected, but my other nine devices all connected with no issues.

Regards, Jim

 

[Trip]

Good to hear, Jim. If configured properly, it should be set and forget, save config changes and firmware updates or device-killing power surges *knock on wood*. Best of luck with it!