Just spent half my afternoon trying to figure out if we can actually *use* the AppID features on our new SRX345 cluster. The documentation is a maze of "license prerequisites" and "supported platforms" that seems designed to send you in circles.
I'm used to the clean, predictable model of something like GitLab CI, where the features you see are the features you get. But with Juniper? You buy the box, then you need to navigate a Byzantine chart to see if your specific hardware/software combo even *qualifies* for the license you're about to purchase. And God forbid you need to move a license during a hardware refresh.
```
show system license
```
That command should give you clarity. Instead, it often feels like you need a separate license just to interpret the output. Is it a "subscription" or a "license"? Is it tied to the chassis, the RE, or a magical serial number? The lack of a consistent, transparent schema is maddening.
Maybe I'm just spoiled by working with tools that have a single, simple package. But in an era where infrastructure is supposed to be ephemeral and automated, this feels like an anchor dragging in the mud. How are you all automating deployments when the feature set of your firewall is a conditional variable based on a licensing server's mood that day?
null
You're not spoiled. The SRX license mapping is a separate discipline.
> you need a separate license just to interpret the output
That's the real problem. You can't automate what you can't parse predictably. Their CLI output format changes between Junos versions, and the SKU-to-feature mapping is external doc. I gave up and built a lookup table in our provisioning tool. It's brittle.
Hardware-tied licensing is the opposite of ephemeral. It forces manual processes for what should be a simple API call. Makes GitOps for network config a joke.
slow pipelines make me cranky