Licensing Changes in 8.0
When upgrading to Secure Access Service 8.0 or Access Control Service 5.0 from a prior release, every effort is made to retain the existing behavior. For example, if a device was previously defined as a license client, it is configured as a client device after the upgrade. If a device was previously defined as a license server, it is configured as a license service device after the upgrade.
The following list summarizes the licensing changes for this release:
- All devices, including virtual appliances, will have all applicable Juniper features enabled by default after upgrading or resetting to the Secure Access Service 8.0 or Access Control Service 5.0 software version. Some optional features still require keys to unlock their usage. Note that EULA acceptance is still mandatory and you are entitled to use the features of the software that you have licensed within the limits of your Proof of Entitlement.
- All licenses on a device prior to the upgrade are listed on the license summary page after the upgrade. Juniper licenses, however, will list the full capacity for each feature.
- All temporary licenses, such as LAB, EVAL and ICE, will expire as with previous releases.
- All subscription licenses will expire as with previous releases. Subscription licenses related to Juniper features will have no effect on the corresponding feature when they expire. When optional subscription licenses expire, their feature counts will be affected as with previous releases.
- Some optional features still require licenses, a license server, or both, and expire as with the previous release. These features include:
- ACCESS-RDP-countU-yearsYR (Secure Access Service only)
- ACCESS-PRM-countU-yearsYR (Access Control Service only)
- IC4000/6000/4500/6500-SOH (Access Control Service only)
- CONN-PULSE-countU-yearsYR (Access Control Service only)
- Clustering works as follows:
- Because all devices already have maximum user counts enabled, there is no need to install Juniper-featured licenses with similar counts on each node in a cluster.
- For optional features, each node in a cluster should have similar license counts.
- Adding or deleting Juniper feature licenses (such as Concurrent Users, Collaboration, RADIUS, and IF-MAP) will not have an impact on the features available on the device. Features are enabled by default and at maximum capacity.
- Auto-increment, sometimes called Trust but Verify, works as follows:
- Optional features will continue to function as with previous releases.
- For Juniper-related features:
- If a license client device is running Secure Access Service 8.0 or Access Control Service 5.0, it will never auto-increment because it is already at maximum capacity.
- License server devices running Secure Access Service 8.0 or Access Control Service 5.0 will support auto-increments for clients running previous versions of the Secure Access Service or Access Control Service software.
- License client devices running software versions prior to Secure Access Service 8.0 or Access Control Service 5.0 will behave as before.
- Surrendering and recalling of user count licenses (Concurrent Users and Collaboration) that have no duration associated with them is supported regardless of whether a license member license is present when a device upgrades to Secure Access Service 8.0 or Access Control Service 5.0.
- IVS will continue to be supported on platforms except for virtual appliances and MAG Series devices.
- For Access Control Service, if the Guest Access license was installed prior to the upgrade, then it is available as a device mode option after the upgrade.
For Juniper features and the license server:
- Although your license server can run a different software version than your license client devices, Juniper Networks strongly suggests that you upgrade both your license server and license client devices to Secure Access Service 8.0 or Access Control Service 5.0.
- If a license client is running a software version prior to Secure Access Service 8.0 or Access Control Service 5.0 and is connected to a license server running Secure Access Service 8.0 or Access Control Service 5.0, it will continue to lease license capacity as before.
- License servers running Secure Access Service 8.0 or Access Control Service 5.0 have maximum capacity licenses for Concurrent Users and Junos Pulse Collaboration.
- License clients running Secure Access Service 8.0 or Access Control Service 5.0 connected to a license server running software prior to Secure Access Service 8.0 or Access Control Service 5.0 will lease reserved capacity but not incremental capacity. Incremental leasing is not required because the device has maximum capacity for Juniper features. Any existing incremental capacity before upgrading to Secure Access Service 8.0 or Access Control Service 5.0 is retained until the expiration of the incremental lease period.
Note: Administrators must explicitly remove the configuration for Concurrent Users and Pulse Collaboration from the client configuration on the license server so the device does not lease unnecessary capacity from the license server’s pool of licenses.
- If the license client and license server are both running Secure Access Service 8.0 or Access Control Service 5.0, they will stop leasing Juniper features. The admin GUI is unchanged from previous releases even though leasing no longer occurs. Capacity already leased for Juniper features are freed up on the license server and license clients will drop all capacity leased for Juniper features.
Difference between MSS and MTU
If you start to study the protocols of the Internet and particular TCP/IP you may bump into MSS & MTU
MSS and MTU are almost the same, but not quite.
MSS is the Maximum Segment Size which is the largest TCP segment (layer 4, yet not including the layer 4 header) that can fit on the current physical medium.
MTU is the Maximum Transmission Unit which is the largest IP packet (layer 3, including the layer 3 header) that can be transmitted.
The MSS is used during the 3-way handshake of TCP to let each side know that maximum segment size they can transmitt in a single frame. It’s purpose is to minimize IP fragmentation. However, that is only each side. Who only knows what is in the middle. That is why each entity in between must know what its MTU size is in case fragmentation is required somewhere along the path.
For example, if you were on an ethernet segment:
Maximum frame size: 1518
less the DLC header – 18 *
equals MTU: 1500
less IP header – 20 **(default)
less TCP header – 20 ***(default)
equals MSS: 1460
* DLC contains 6 bytes for destination MAC address, 6 for source, 2 for Ethertype, and 4 for CRC
** IP header is 20 bytes by default, but can be as large as 60 bytes.
*** TCP header is 20 bytes by default, but can be as large as 60 bytes. It is much more common for the TCP header to have options and therefore be larger than the default.