No affordable MX appliance for gigabit

[IT_Magician]

I know for years people have requested an affordable gigabit MX, so this is just another poke at Meraki. Gigabit is becoming a standard and we are seeing new fiber only ISPs offering symmetrical fiber gigabit internet for $250 a month.

I am sure you have your reasons, but for your partners who 100% standardize on Meraki it forces us to bring on a different firewall to deliver affordable gigabit speeds to our clients. That brings more complexity into our business, cause now we have to train our technicians how to work two different firewall platforms, setup external monitoring to the non MX networks, and have different troubleshooting guides.

Just something to think about, I know this topic comes up a lot but here we are getting another non MX firewall to stay within the budget of a customer while using Meraki switches and WAPs behind it.

[DHAnderson]

I agree.  Cellular companies have jumped into the ISP business causing a spurt of competition.  We are seeing reasonable non symmetric near gigabyte speeds from some cable companies, and affordable symmetric speeds from companies in with fiber.

[PhilipDAth]

I suspect now that 16.x is in beta, that it will enable the release of newer faster hardware.

[NolanHerring]

---

@PhilipDAth wrote:

I suspect now that 16.x is in beta, that it will enable the release of newer faster hardware.

---

I am aware that Meraki has heard our complaints, is fully aware, and is supposedly taking action on this very thing. The when? Not sure, hoping sooner than later.

[DHAnderson]

Forgive my ignorance, but how does 16.x enable the release of newer faster hardware?  Or is that proprietary?

[PhilipDAth]

>Forgive my ignorance, but how does 16.x enable the release of newer faster hardware?  Or is that proprietary?

This is wild speculation by me.

More than likely, the lower end MXs are using 32 bit ARM architecture (pure guess, I don't know).  I'm guessing the higher end MXs are using 64 bit Intel.

ARM has had solid 64-bit support for a while now.  So you could say let's switch to 64 bit ARM for the low end and re-write our code to support it.

Or you might say, we have all this existing Intel 64 bit code for the higher end platforms and the VMX already.  Works great.  Let's not re-develop the existing ARM code.  Let's dump it, and change the low-end platforms over to Intel 64 bit CPUs (low-end ones, of course).  Now we have one code platform to support for all MXs, physical and virtual.

This would then leave you free to release a new low-end platform using Intel which much higher performance.

[Owen]

The last MX64 that I pulled apart used a Broadcom SoC 50586 or something along those lines. Dual core ARMv7. Serial console on the motherboard. Nothing secret as it was all easily available.

U-Boot 2012.10-00099-g7c856f3 (Mar 19 2015 - 12:00:01)Meraki MX64 Boot Kernel Loader
[ 0.000000] Booting Linux on physical CPU 0
[ 0.000000] Linux version 3.4.109+ (meraki@buildbot106.meraki.com) (gcc version 4.8.3 (GCC) ) #3 SMP Wed Jun 15 15:00:28 PDT 2016
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[ 0.080000] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.160000] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
[ 0.180000] CPU1: Booted secondary processor
[ 0.340000] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.340000] Brought up 2 CPUs
[ 0.340000] SMP: Total of 2 processors activated (4780.85 BogoMIPS).

An faulty MX84 we had was on a C2000 series Intel dual core from memory. Again no rocket science here.

[Owen]

Keep in mind though that even if an MX has certain hardware inside Meraki artificially add policers to limit throughput so the models line up nicely in the sizing guide. Remember the times when Z1 was not limited until a certain software version introduced the policer?

[DHAnderson]

I would think that it would be time to develop a pipeline processor for in going and out going inspection.  A FPGA could be developed and tested before committing to a die.  That would give you great inspection speed.  We did that at another company I worked at and raised image inspection from 300 parts per minute to 14,000 per minute.  Each stage of the pipeline could perform a simple inspection. We used a ARM processor to setup the pipeline, and to further refine the results from the pipeline.

[Owen]

FPGA isn't needed. Dedicated security processors like Cavium exist for this. Some Juniper SRX and Paloalto firewalls are based on Cavium for forwarding because of the offloading from a general purpose CPU.

Using a dedicated processor like Cavium doesn't line up with the "Meraki way" of using OpenWRT for everything with extras added on top though.

[DHAnderson]

I don't know much about OpenWRT, but I presume drivers could be be written to support a security co-processor.

[DHAnderson]

Has anyone taken a look at the Meraki.com page today?

https://meraki.cisco.com/product-category/security-sd-wan/

[Dinger · Accepted solution]

Agree 100% with this.  What we need is a mx64/67 replacement that can take the gigabit speeds which are now price positive.  I don't think I can wait forever for something to show up.  A little "press" could go a long way before the hard decisions of continuing to use a different firewall need to be made for upcoming projects.  C'mon Meraki, late to the game, but you don't have to be late for somewhat of an announcement.