Juniper's artificial feature blocking (was legacy /8)
Tore Anderson <tore.anderson@redpill-linpro.com> wrote:
Really? My level of respect for Juniper has just dropped a few notches after reading this NANOG post - I didn't know that they were engaged in such DRM-like feature blocking practices. Where can I find more information about Juniper's stance on such practices (having some feature X present in both HW and SW, but artificially blocked until one buys an unlock key from them) and the exact degree to which they engage in such? The reason I ask is because I've been considering building my own PIM for their J-series, a PIM that would terminate Nokia/Covad's flavor of SDSL/2B1Q at the physical layer and present an ATM interface to JunOS, optionally supporting NxSDSL bonding with MLPPPoA. I have no love for routers that aren't 100% FOSS, but I couldn't find any other existing router platform which could be extended with 3rd-party physical interface modules, and designing and building my own base router chassis is not a viable option if I want to actually have something built before the Sun swells into a red giant and engulfs the Earth. So I thought that even though it isn't 100% FOSS, JunOS ought to be at least tolerable given that it appears to be based on FreeBSD and I've heard that it even allows the user to get direct access to the underlying Unix shell (does it really?) - but hearing about DRM-like artificial feature blocking seems to negate that. I mean, how could their disabled-until-you-pay blocking of "premium features" be effective if a user can get to the underlying Unix OS, shell, file system, processes, etc? Wouldn't such access allow smart users to unblock whatever feature is artificially blocked? Someone please educate me... MS
On Sun, Apr 4, 2010 at 2:33 PM, Michael Sokolov <msokolov@ivan.harhan.org> wrote:
Probably signed binaries, veriexec with a signature list of allowed executables, proprietary system daemons, hardware drivers, and read-only filesystems. Protections may be in hardware, and you do not have source code. You can in JunOS "start shell user root" as much as you like and get a root shell on various platforms, but some functions are limited. Using a 'key' is slightly less of a network operator nightmare than having 100 featuresets, and thousands of mystery meat images for the same software version. At least you don't need to go buy a new software image, and do a full upgrade procedure to gain feature access. Applying a key seems less risky and less likely that downtime is needed, when you decide that you now need this feature.
Even CPU manufacturers are noted for artificially restricting features in software (such as VT or hyper-threading, even artificially disabling cores). Not all buyers of L3 switches need or want to pay for that, and there is more $$$ to be made from those that do. The manufacturer can either segment their market by not offering OSPFv3 on the device, release a new higher-end hardware model for V3 support at 10x the cost, or offer an add-on license, as an incremental upgrade to a larger number of users (including the installed base). -- -J
On 04 Apr 2010 16:07, James Hess wrote:
Indeed. Just as importantly, developing a single image with license-enabled features saves both vendors and customers a lot of time on QA, acceptance testing, etc. Since you're always running the same image, you only need to test it once, with all features enabled, to be sure that everything works; if there are different images for different feature sets, you have to run a full test suite on each image. That's a lot of extra work for no real benefit. Having to switch from one image to another to enable a particular feature also entails additional risk, downtime, etc. that simply loading a license key does not.
Indeed. Vendors face a lot of price pressure, so being able to disable non-mandatory features to meet low-end customers' price demands is a major competitive advantage. However, they still need revenue to support the development that the handful of high-end customers demand for "new" or "optional" features, and charging for licenses to enable those features seems to be the best way that anyone has figured out to do that. Heck, I work with one vendor that requires separate licenses for virtually every checkbox in their GUI; turning up one customer port may involve purchasing dozens of new licenses. The customers of their product don't like it, sure, but suggest that they pay the full cost of enabling all options on all ports and they flip out. Licensed features enable customers to purchase only what they need, not what some marketing puke decides they need (or some one-size-must-fit-all pricing scheme, which rarely works well). S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Sun, Apr 4, 2010 at 4:33 PM, Michael Sokolov <msokolov@ivan.harhan.org> wrote:
(...)
At least for IPv6 features, that feature gap only happens with Juniper EX. All other Juniper gear has, according to them, IPv6 feature parity within all license levels and packages. Rubens
participants (5)
-
James Hess -
msokolov＠ivan.Harhan.ORG -
Owen DeLong -
Rubens Kuhl -
Stephen Sprunk