[j-nsp] Cost of vMX

Mark Tinka mark.tinka at seacom.mu
Sun Apr 22 06:03:16 EDT 2018


I posit that a number of cloud environments are either DIY (meaning
unlikely to forward serious traffic), or were installed by a vendor
(meaning they were pricey, and as such, went in with limited forwarding
capacity).

To do stuff in CPU and memory should not be an issue - but I doubt that
many cloud environments have been setup to replicate what a
router/switch forwarding 100Gbps or more can do.

Of course, I could be wrong.

In our case, we are looking at small scale, i.e., 5Gbps - 10Gbps of
traffic at peak per chassis. Mostly for value-added bits, and not part
of our core networking infrastructure. The numbers stop making sense for
our use-case once we start to go beyond that capacity on x86 boxes.

Mark.

On 21/Apr/18 21:59, Aaron Gould wrote:
> But I guess in a situation where you already have a data center or virtual environment like what is being talked about, and you simply add in vMX for vRR or vCGNat, then perhaps that makes it more bearable 
>
> Btw, can you actually emulate the MS-MIC-16G/MS-MPC-128G hardware cgnat functions on vMX ?!
>
> - Aaron
>
>
> -----Original Message-----
> From: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka
> Sent: Saturday, April 21, 2018 6:36 AM
> To: Saku Ytti; Mike
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Cost of vMX
>
>
>
> On 21/Apr/18 02:19, Saku Ytti wrote:
>
>> >From BOM POV if you have to pay for the XEONs it probably isn't very
>> good value proposal per Mpps. However if you have poor pricing for MX,
>> good pricing on your XEON and modest pps need, maybe it makes sense.
> This...
>
> Looking at virtual routers - even from other vendors - what quickly
> stands out for me is that if your traffic volumes are typically low, but
> you get value in things such as being able to host a ton of customers on
> the same chassis/VM, hold millions of routes for several years without
> worrying about hardware resources (in the case of RR's), need to crunch
> numbers very quickly in CPU (in the case of a virtualized Netflow
> collector such as Arbor), then it makes very good sense.
>
> If you're trying to forward 10's of Gbps through a virtual router on
> general-purpose x86 hardware at any meaningful scale, you're quickly
> going to see all your money go into:
>
>     - The server hardware
>     - The hypervisor license
>     - The VM license
>
> Doesn't make for a good prospect, if I'm honest, with today's
> state-of-the-art.
>
> While you could build a virtual router capable of forwarding 100Gbps
> aggregate, it's going to be cheaper for you to work with a purpose-built
> router/switch.
>
> Mark.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> .
>



More information about the juniper-nsp mailing list