Next Gen Services Overview
This topic provides an overview of Next Gen Services and includes the following topics
5G Universal Router Services Overview
The 5G Universal routers support several types of Services interfaces, which provide specific capabilities for inspecting, monitoring and manipulating traffic as it transits a router. Services can be categorized into Adaptive Services and Next Gen Services, with each category providing Inline services interfaces and Multiservices interfaces options. Table 1 lists the cards that provide these services.
The MX-SPC3 replaces MS- type cards providing a significant overall performance improvement together with high-end scale and capacity.
5G Universal Routing Platform |
|||||
|---|---|---|---|---|---|
Adaptive Services |
Next Gen Services |
||||
MPC
Inline services |
MS-DPC
|
MS-MPC
|
MS-MIC
|
MPC
Inline services |
MX-SPC3
|
Adaptive Services can run on MS-DPC, MS-MPC, and MS-MIC cards using Multiservices (MS) PICs or Adaptive Services (AS) PICs.
Next Gen Services can run on MPC cards and the MX-SPC3 security services card.
Inline services are configured on Modular Port Concentrators (MPC)s. Inline services interfaces, are virtual physical interfaces that reside on the Packet Forwarding Engine. They provide high performance processing on traffic transiting the MPC, and allow you to maximize your chassis slot capacity and utilization.
Multiservices Security cards (MS-DPC, MS-MPC, MS-MIC or MX-SPC3), provide services that can be applied to any traffic transiting the chassis beyond just an individual MPC. They also provide dedicated processing to support a variety of security features at scale and high performance.
Adaptive Services Overview
Adaptive Services run inline on MPCs and on MS-DPC, MS-MPC, and MS-MIC Multiservice security cards. Adaptive Services (AS) PICs and Multiservices PICs enable you to perform multiple services on the same PIC by configuring a set of services and applications. The AS and Multiservices PICs offer a range of services that you can configure in one or more service sets.
On Juniper Networks 5G Universal Routing Platforms, the MS-DPC provides essentially the same capabilities as the MS-MPC. The interfaces on both platforms are configured in the same way.
For more information about Adaptive Services including inline services, see Adaptive Services Overview.
Inline Services
Adaptive Services also use inline services interfaces to provide inline services. Inline services interfaces are virtual interfaces that reside on the Packet Forwarding Engine.
You configure inline services only on MPCs using the naming
convention si-fpc/pic/port rather than the ms-fpc/pic/port naming convention.
Next Gen Services
Next Gen Services provide the combined capabilities of security services enabling you to inspect, monitor and manipulate traffic as it transits the router. Next Gen Services are supported both inline on Modular Port Concentrators (MPCs) and the MX-SPC3 security services card in MX240, MX480 and MX960 routers that support this feature. Please refer to Table 2, which provides a summary of Next Gen Services that are supported both inline and on the MX-SPC3 card. Both Inline and MX-SPC3 based services can be used at the same time.
You configure Next Gen Services on the MX-SPC3 security services
card using the virtual multiservices naming convention: vms-fpc/pic/port.
Summary of Services Supported on MX Series 5G Universal Routers
Table 2 provides a summary of the services supported under Next Gen Services.
|
Next Gen Services: Inline (si-) Interface and SPC3 |
||||
|---|---|---|---|---|
|
Service Feature |
Inline Services |
SPC3 |
||
|
Junos OS Release |
Sub-Service |
Junos OS Release |
Sub-Service |
|
|
CGNAT |
19.3R2 |
Basic-NAT44 and NAT66 Static Destination NAT Twice-NAT44 Basic 6rd Softwires NPTv6 |
19.3R2 |
Basic-NAT44 Basic-NAT66 Dynamic-NAT44 Static Destination NAT Basic-NAT-PT NAPT-PT NAPT44 NAPT66 Port Block Allocation Deterministic-nat44 and nat64 End Point Independent Mapping (EIM)/End Point Independent Filtering (EIF) Persistent NAT – Application Pool Pairing (APP) Twice-NAT44 – Basic, Dynamic and NAPT NAT64 XLAT-464 NPTv6 |
|
20.1R1 |
Port Control Protocol (PCP) – v1 and v2 |
|||
|
20.2R1 |
MAP-E |
DS-Lite NAT46 |
||
|
Traffic Load Balancer |
19.3R2 |
19.3R2 |
||
|
SecIntel (ATP Cloud IP Threat Feeds) |
19.3R2 |
N/A |
||
|
Stateful Firewall Services |
N/A |
19.3R2 |
||
|
Intrusion Detection Services (IDS) |
N/A |
19.3R2 |
||
|
DNS Request Filtering |
N/A |
19.3R2 |
||
|
Aggregated Multiservices Interfaces |
N/A |
19.3R2 |
||
|
Inter-chassis High Availability |
N/A |
19.3R2 |
CGNAT, Stateful Firewall, IDS |
|
|
URL Filtering |
N/A |
20.1R1 |
||
|
JFlow |
20.1R1 |
N/A |
||
|
RPM and TWAMP |
20.1R1 |
N/A |
||
|
Video Monitoring |
20.1R1 |
N/A |
||
| IPsec VPN | N/A | 21.1R1 |
Route based Site 2 Site VPN Traffic selector based VPNs AutoVPN Routing protocols (BGP/OSPF) over IPsec |
|
| Inline IPsec | 24.2R1 | N/A | ||
See Configuring IPsec VPN on MX-SPC3 Services Card for more information on IPsec support on SPC3 line card.
Next Gen Services Documentation
You can run Next Gen Services on the MX240, MX480, and MX960 routers that support this feature, if you have the SPC3 services card installed in the router. Refer to our TechLibrary for all router documentation. For Next Gen Services, refer to the following documentation:
To learn about and configure Next Gen Services, see Next Gen Services Interfaces User Guide for Routing Devices (this guide).
For details on installing or replacing the SPC3 card, see MX Series 5G Universal Routing Platform Interface Module Reference.
To monitor flows and sample traffic — See the Monitoring, Sampling, and Collection Services Interfaces Feature Guide, which describes how to configure traffic flow monitoring, packet flow capture, traffic sampling for accounting or discard, port mirroring to an external device, and real-time performance monitoring.
Enabling Next Gen Services
To run Next Gen Services, you must enable it on the router. This enables the operating system to run it’s own operating system (OS) for Next Gen Services.
There are specific steps you’ll need to take if you’re migrating your services from legacy services cards to the SPC3. The Next Gen Services CLI differs from these legacy services. For more information, see Configuration Differences Between Adaptive Services and Next Gen Services.
Compatibility with Other Services Cards
The SPC3 services card is compatible end-to-end with the Switch Fabrics, Routing Engines and MS-MPC line cards as described in Table 3.
Switch Fabric |
Route Engine |
MPC Line Cards |
|---|---|---|
SCBE |
RE-S-1800X4-16G-BB RE-S-1800X4-16G-UPG-BB RE-S-1800X4-16G-S RE-S-1800X4-16G-R RE-S-1800X4-32G-BB RE-S-1800X4-32G-UB RE-S-1800X4-32G-S RE-S-1800X4-32G-R |
MPC2E-3D MPC2-3D-NG MPC3E and MPC3E-3D-NG MPC4E-3D MPC-3D-16XGE |
SCBE2 |
RE-S-1800X4-16G-BB RE-S-1800X4-16G-UPG-BB RE-S-1800X4-16G-S RE-S-1800X4-16G-R RE-S-1800X4-32G-BB RE-S-1800X4-32G-UB RE-S-1800X4-32G-S RE-S-1800X4-32G-R RE-S-X6-64G-BB RE-S-X6-64G-UB RE-S-X6-64G-S RE-S-X6-64G-R RE-S-X6-128G-S-BB RE-S-X6-128G-S-S RE-S-X6-128G-S-R |
MPC2E-3D MPC2-3D-NG MPC3E and MPC3E-3D-NG MPC4E-3D MPC5E and MPC5EQ MPC7E and MPC7EQ MPC-3D-16XGE |
|
SCBE3 |
RE-S-1800X4-16G-BB RE-S-1800X4-16G-UPG-BB RE-S-1800X4-16G-S RE-S-1800X4-16G-R RE-S-1800X4-32G-BB RE-S-1800X4-32G-UB RE-S-1800X4-32G-S RE-S-1800X4-32G-R RE-S-X6-64G-BB RE-S-X6-64G-UB RE-S-X6-64G-S RE-S-X6-64G-R RE-S-X6-128G-S-BB RE-S-X6-128G-S-S RE-S-X6-128G-S-R |
MPC2-3D-NG MPC3E-3D-NG MPC4E-3D MPC5E and MPC5EQ MPC7E and MPC7EQ MPC-3D-16XGE MPC10E-10C MPC10E-15C |
Configuring the SPC3 Services Card
The interfaces on the SPC3 services card are referred to as a virtual multi service (vms) PIC.
When you configure an SPC3 interface, you specify the interface as a
vms- interface as follows:
user@host# set services service-set service-set-name interface-service service-interface vms-slot-number/pic-number/0.logical-unit-number
Aside from the CLI differences, you need to be aware of the basic hardware differences between multiservices (MS) type (MS-DPC, MS-MPC, and MS-MIC) cards and the SPC3 services card. MS type cards contain four CPU complexes whereas the SPC3 card, while more powerful, contains two CPU complexes. Each CPU complex services a single PIC, meaning that MS type cards support four PICs whereas the SPC3 supports two PICs. MS type cards use special multiservices (MS) and adaptive services (AS) PICs, whereas the PICs on the SPC3 card are integrated.
Because the number of PICs directly affects the number of interfaces, you might need to add logical units to each interface on the SPC3 to increase the number of interfaces to four. For example, if you currently use all four interfaces on the MS type card and you have a service set per interface, you can create two logical units per interface on the SPC3 to bring the total number of interfaces to four, and then reassociate the four service sets to these four logical interfaces.
Methods for Applying Services to Traffic
When you configure Next Gen Services, you can apply those services with either of the following methods:
Apply the configured services to traffic that flows through a particular interface on the router.
Apply the configured services to traffic that is destined for a particular next hop.
Configuring IPsec VPN on SPC3 Services Card
To configuring IPsec on SPC3 service card, use the CLI configuration statements at
the [edit security] hierarchy level as the IPsec CLI configuration
at the [edit services] is replaced with the CLI configuration at
the [edit security] hierarchy level as shown in Table 4
| Current MX Configuration | Equivalent MX-SPC3 Configuration |
|---|---|
| set services ipsec-vpn traceoptions | set security ike traceoptions |
| set services ipsec-vpn ike proposal | set security ike proposal |
| set services ipsec-vpn ike policy | set security ike policy |
| set services ipsec-vpn ike policy policy-name respond-bad-spi | set security ike respond-bad-spi |
| set services ipsec-vpn ipsec proposal | set security ipsec proposal |
| set services ipsec-vpn ipsec policy | set security ipsec policy |
| set services ipsec-vpn rule rule-name term term-name from [source-address| destination-address] | set security ipsec vpn vpn-name traffic-selector selector-name [local-ip | remote-ip] |
| set services ipsec-vpn rule rule-name term term-name from ipsec-inside-interface | set security ipsec vpn vpn-name bind-interface |
| set services ipsec-vpn rule rule-name term term-name then remote-gateway | set security ike gateway gw-name address |
| set services ipsec-vpn rule rule-name term term-name then backup-remote-gateway | set security ike gateway gw-name address |
| set services ipsec-vpn rule rule-name term term-name then dead-peer-detection | set security ike gateway gw-name dead-peer-detection |
| set services ipsec-vpn rule rule-name term term-name then dynamic ike-policy | set security ike gateway gw-nameike-policy |
| set services ipsec-vpn rule rule-name term term-name then dynamic ipsec-policy | set security ipsec vpn vpn-name ike ipsec-policy |
| set services ipsec-vpn rule rule-name term term-name then manual | set security ipsec vpn vpn-name manual |
| set services ipsec-vpn rule rule-name term term-name then clear-dont-fragment-bit | set security ipsec vpn vpn-name df-bit clear |
| set services ipsec-vpn rule rule-name term term-name then copy-dont-fragment-bit | set security ipsec vpn vpn-name df-bit copy |
| set services ipsec-vpn rule rule-name term term-name then set-dont-fragment-bit | set security ipsec vpn vpn-name df-bit copy |
| set services ipsec-vpn rule rule-name term term-name then tunnel-mtu | set security ipsec vpn vpn-name tunnel-mtu |
| set services ipsec-vpn rule rule-name term term-name then no-anti-replay | set security ipsec vpn vpn-name ike no-anti-replay |
| set services ipsec-vpn rule rule-name match-direction | set security ipsec vpn vpn-namematch-direction |
| set services ipsec-vpn establish-tunnels | set security ipsec vpn vpn-nameestablish-tunnels |
| set services service-set svc-set-name ipsec-vpn-options local-gateway address | set security ipsec vpn vpn-nameike gateway gateway-name |
| set services service-set svc-set-name ipsec-vpn-options clear-dont-fragment-bit | No global service-set setting. Must be configured on a per vpn object basis. |
| set services service-set svc-set-name ipsec-vpn-options copy-dont-fragment-bit | No global service-set setting. Must be configured on a per vpn object basis. |
| set services service-set svc-set-name ipsec-vpn-options set-dont-fragment-bit | No global service-set setting. Must be configured on a per vpn object basis. |
| set services service-set svc-set-name ipsec-vpn-options udp-encapsulate | set security ipsec vpn vpn-nameudp-encapsulate |
| set services service-set svc-set-name ipsec-vpn-options no-anti-replay | No global service-set setting. Must be configured on a per vpn object basis. |
| set services service-set svc-set-name ipsec-vpn-options passive-mode-tunneling | set security ipsec vpn vpn-name passive-mode-tunneling |
| set services service-set svc-set-name ipsec-vpn-options tunnel-mtu | No global service-set setting. Must be configured on a per vpn object basis. |
| set services service-set svc-set-name ipsec-vpn-rules | set services service-set svc-set-name ipsec-vpn-rules |
| set services ipsec-vpn rule <rule-name> term <term-name> then tunnel-mtu |
set security ipsec vpn <vpn-name> tunnel-mtu |
- Understanding Tunnel MTU
- Difference between st0 MTU and tunnel MTU
- Examples
- Significace of Each MTU Setting
Understanding Tunnel MTU
Tunnel MTU (Maximum Transmission Unit) is the maximum packet size that can be sent through a tunnel without fragmentation. For a route-based IPsec tunnel there are two independent fragmentation points on the clear-text packet and one for the encrypted packet:
- st0 (secure tunnel) MTU is enforced by the PFE on clear-text packets before they are forwarded to the service card. When a packet exceeds the configured st0 MTU, the PFE fragments it before forwarding. The packet is divided into approximately equal-sized fragments, creating as many fragments as necessary, rather than maximizing the size of each fragment up to the MTU limit.
-
tunnel-MTU is enforced by flowd (flow daemon), the packet-processing component responsible for stateful flow handling and IPsec services, during packet encryption. Before encrypting a clear-text packet or fragment received from the PFE, flowd verifies that its size, including IPsec overhead, does not exceed the configured tunnel-MTU. If the packet exceeds the limit, flowd fragments it into smaller packets that fit within the tunnel-MTU and then encrypts each fragment.
-
External (physical) interface MTU is applied to the encrypted packet after IPsec encapsulation on egress.
-
The configured tunnel-MTU must be less than or equal to the st0 MTU; otherwise, the configuration commit fails.
-
When the PFE performs pre-fragmentation, flowd processes the resulting fragments only for session lookup and validation. It does not reassemble the fragments into the original packet. Instead, each fragment is processed independently by flowd.
Difference between st0 MTU and tunnel MTU
- Tunnel-MTU is at different level compared to st0 MTU.
- st0 MTU is interface level MTU and tunnel-MTU feature achieves tunnel level MTU
- In MX-SPC3, PFE checks st0 mtu to fragment or drop the packet. Hence, packet does not reach flowd or IPsec and will not have any control over the MTU action.
- VPN tunnel-mtu configuration value is less than the st0 MTU.
Examples
For the examples that follow, assume a clear-text packet size of about 1862 bytes and IPsec overhead of 60–100 bytes. Therefore, the effective clear-text payload supported by a configured MTU of M is roughly M − overhead.
Case 1: Secure Tunnel MTU > Packet Size (Only tunnel-MTU Causes Fragmentation)
Assume st0 MTU = 9192 (default), tunnel-MTU = 1400, packet size ≈ 1862 bytes. As the packet size is smaller than the st0 MTU, the PFE does not fragment the packet. The packet reaches flowd intact. flowd compares the packet size against the effective tunnel-MTU limit (approximately 1300 bytes after accounting for IPsec overhead). Since the packet exceeds the tunnel-MTU limit, flowd fragments it into appropriately sized pieces, for example, 1300 bytes and 562 bytes. flowd encrypts each fragment and forwards it for transmission.
As a result only one fragmentation operation occurs, and it is performed by flowd based on the tunnel-MTU setting. This is the preferred behavior because tunnel-MTU serves as the sole fragmentation control point, allowing fragments to be sized efficiently to maximize payload utilization.
Case 2: Secure Tunnel MTU < Packet Size and PFE Fragments Still Exceed tunnel-MTU (Double Fragmentation)
Assume st0 MTU = 1500, tunnel-MTU = 700, packet size ≈ 1862 bytes. As the packet exceeds the st0 MTU, the PFE performs the first fragmentation step, splitting the packet into approximately equal-sized fragments (for example, 936 bytes and 926 bytes). These fragments are then passed to flowd for processing. flowd evaluates each fragment against the effective tunnel-MTU limit (approximately 600 bytes after accounting for IPsec overhead). Since both PFE-generated fragments still exceed the tunnel-MTU limit, flowd fragments each one again:
936 → 600 + 336
926 → 600 + 326
flowd processes each fragment independently. It does not reassemble the PFE-generated fragments before applying tunnel-MTU fragmentation.
As a result two fragmentation stages occur- first by the PFE based on the st0 MTU, and then by flowd based on the tunnel-MTU. The original packet is ultimately transmitted as four encrypted fragments. This is an undesirable scenario as it introduces additional fragmentation overhead and reduces efficiency.
Case 3: Secure Tunnel MTU < Packet Size and PFE Fragments Are Smaller Than tunnel-MTU (No Additional tunnel-MTU Fragmentation)
Assume st0 MTU = 1500, tunnel-MTU = 1438, packet size ≈ 1862 bytes. As the packet size exceeds the st0 MTU, the PFE fragments the packet into approximately equal-sized fragments, for example, 936 bytes and 926 bytes. These fragments are then forwarded to flowd for IPsec processing. flowd compares each fragment against the effective tunnel-MTU limit (approximately 1378 bytes after accounting for IPsec overhead). Since both fragments are already smaller than the tunnel-MTU limit, flowd does not perform any additional fragmentation. flowd encrypts and forwards the fragments unchanged.
As a result only one fragmentation step occurs, and it is performed by the PFE based on the st0 MTU. Although a tunnel-MTU is configured, it has no effect because the PFE-generated fragments already fit within the tunnel-MTU limit. In this scenario, the st0 MTU, rather than the tunnel-MTU, determines the resulting fragment sizes.
Significace of Each MTU Setting
-
External interface MTU determines the maximum size of the encrypted packet that can be transmitted on the physical network. It is enforced on egress after IPsec encapsulation.
-
st0 MTU is an interface-level MTU shared by all VPNs and tunnels associated with the st0 interface. It is enforced by the PFE on clear-text traffic before encryption. If a packet exceeds the st0 MTU, the PFE fragments it before forwarding it to flowd.
-
tunnel-MTU is a per-VPN setting enforced by flowd. It provides a VPN-specific packet size limit without affecting other VPNs that share the same st0 interface. tunnel-MTU only applies to packets or fragments that still exceed its limit when they reach flowd.
-
tunnel-MTU must be less than or equal to the st0 MTU. When both settings are configured, st0 MTU controls PFE fragmentation, while tunnel-MTU controls VPN-specific fragmentation performed by flowd.