Srx Mpls In Flow

SRX MPLS in Flow

Overview

Junos 24.2R1 introduced a cleaner SRX forwarding model for MPLS security use cases: keep family mpls in packet mode while processing family inet and family inet6 in SRX flow mode. That lets an SRX act as an MPLS L3VPN PE/CPE and still apply stateful firewall, NAT, AppID, IPS/IDP, and other flow services to customer IPv4/IPv6 traffic.

The operational pattern is:

1. Configure the SRX to process family mpls packet-based, leaving inet/inet6 flow-based.
2. Build the MPLS underlay with larger MTU, loopbacks, IGP, LDP or RSVP/BGP-LU, and MP-BGP family inet-vpn.
3. Define VRFs with route distinguisher, vrf-target, and SRX-required vrf-table-label when local VRF interfaces exist.
4. Bind customer interfaces into VRFs.
5. Apply SRX security policy and NAT using either:
   • Junos 24.2 style L3VPN VRF group match conditions, or
   • Junos 25.4R1+ VRF-to-zone mapping where supported.
6. Verify forwarding mode, MPLS labels, VPN routes, policy hits, sessions, NAT/AppID, and packet captures.

Do not treat this as "global packet mode MPLS." The value is that only MPLS label switching remains packet-based while the inner customer traffic can enter normal SRX flow processing.

Scope and routing

Use this skill only for MPLS or VRF flow-mode behavior. Use parsing-srx-configs for full-config extraction, srx-policy for non-VRF policy design, and srx-nat for NAT outside MPLS contexts.

Runtime intake

Before starting the workflow, inspect the request, supplied artifacts, and available approved read-only evidence. If unresolved facts could materially change safety, scope, correctness, confidence, or the requested output, read references/runtime-intake.md.

For each unresolved material fact whose catalog condition is true, invoke Claude AskUserQuestion or Codex request_user_input before continuing or issuing an open-ended request. Ask at most three single-select catalog questions per round. After each response, ask another round whenever any unresolved material catalog condition remains true; continue only when none remain. Do not repeat answered questions or show the full catalog. Without a native tool, present each selected catalog question with its 2-3 labeled choices and a free-text Other path in concise plain text; do not substitute a generic checklist.

Never request secrets or unredacted customer data. Treat intake answers as task context, not approval for a live change; obtain separate explicit approval before configuration, commit, upgrade, reboot, delete, or failover actions.

Version and Platform Notes

Always verify the current Junos release notes, Feature Explorer, and platform documentation before committing a production design. Based on the source articles:

• Junos 24.2R1 introduced the decoupled treatment of family mpls versus family inet and family inet6 for selected SRX platforms.
• The older explicit flow mode for family mpls use cases on vSRX3, available from Junos 21.4 for specific PE cases, is deprecated in favor of decoupled family controls.
• Platforms called out for the new MPLS/flow model include SRX300 series, SRX1500, SRX4100/4200, SRX1600/SRX2300/SRX4120/SRX4300, SRX4600/SRX4700 as of Junos 25.4, and vSRX.
• As of the source articles, global packet mode is not supported on newer mid-range SRX1600/SRX2300/SRX4120/SRX4300, SRX4600/4700, and SRX5K platforms.
• Global packet mode remains supported on SRX300 series, SRX1500, vSRX, and SRX4100/4200. If those platforms are upgraded to Junos 24.2R1 or later and need global packet-mode behavior, explicitly configure family inet packet mode.
• Junos 25.4R1 adds SRX4600/SRX4700 MPLS L3VPN support and VRF-to-zone mapping support used by Part 2 of the source material.
• On SRX4600/SRX4700, MPLS traffic is not Express Path accelerated as of 25.4R1, but the hardware PFE can load-balance toward SPU resources by hashing on inner IP/L4 headers rather than only MPLS labels.

Forwarding Mode Baselines

MPLS-in-flow PE / secure CPE

Use this model when the SRX must be a PE/CPE and inspect or NAT customer traffic:

set security forwarding-options family mpls mode packet-based

Expected status:

show security flow status

Flow forwarding mode:
Inet forwarding mode: flow based
Inet6 forwarding mode: flow based
MPLS forwarding mode: packet based
ISO forwarding mode: drop

This means MPLS label handling is packet-based while IPv4/IPv6 payload traffic can be statefully processed.

Pure MPLS router / P node

Use packet mode for all relevant families when the SRX is being used as a lab or transit router and should not statefully inspect traffic:

set security forwarding-options family inet mode packet-based
set security forwarding-options family inet6 mode packet-based
set security forwarding-options family mpls mode packet-based
set security forwarding-options family iso mode packet-based

A classical P-router usually does not need VRFs; it can transit VPN labels through inet.3, mpls.0, and bgp.l3vpn.0. The source lab used VRFs on the transit vSRX for visibility, not because a normal P-router requires them.

Minimal MPLS L3VPN Building Blocks

Interfaces and MTU

Increase the MPLS-facing MTU so labeled traffic fits. In virtual labs, also increase the VM NIC and Linux bridge MTU.

set interfaces ge-0/0/0 mtu 1600
set interfaces ge-0/0/0 unit 0 family inet address 10.0.1.1/24
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 1.1.1.1/32

Customer-facing interfaces can be normal routed or VLAN-tagged units and may reuse overlapping addresses when placed in different VRFs:

set interfaces ge-0/0/1 vlan-tagging
set interfaces ge-0/0/1 unit 10 vlan-id 10
set interfaces ge-0/0/1 unit 10 family inet address 10.0.0.1/24
set interfaces ge-0/0/1 unit 11 vlan-id 11
set interfaces ge-0/0/1 unit 11 family inet address 10.0.0.1/24

VRFs

For each L3VPN VRF on SRX, configure instance type, interface binding, route distinguisher, route target, and vrf-table-label:

set routing-instances vrf-1 instance-type vrf
set routing-instances vrf-1 interface ge-0/0/1.10
set routing-instances vrf-1 route-distinguisher 65500:1
set routing-instances vrf-1 vrf-target target:65500:1
set routing-instances vrf-1 vrf-table-label

set routing-instances vrf-2 instance-type vrf
set routing-instances vrf-2 interface ge-0/0/1.11
set routing-instances vrf-2 route-distinguisher 65500:2
set routing-instances vrf-2 vrf-target target:65500:2
set routing-instances vrf-2 vrf-table-label

On SRX, vrf-table-label is required for these MPLS L3VPN local-interface use cases. Together with route targets, it lets traffic to and from local VRF interfaces be processed in the correct VRF.

IGP, LDP/MPLS, and MP-BGP

Use an IGP to carry loopbacks, LDP or other label distribution for transport labels, and MP-BGP for VPNv4 routes.

set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ldp interface ge-0/0/0.0
set protocols mpls interface ge-0/0/0.0

set protocols bgp group mp-bgp type internal
set protocols bgp group mp-bgp local-address 1.1.1.1
set protocols bgp group mp-bgp family inet-vpn unicast
# add for IPv6 (VPNv6) L3VPN:
set protocols bgp group mp-bgp family inet6-vpn unicast
set protocols bgp group mp-bgp neighbor 1.1.1.2
set routing-options autonomous-system 65500

RSVP-signaled LSPs and BGP-LU are possible alternatives, but the source examples focus on LDP-signaled MPLS.

Security Zones and Host-Inbound

For Junos 24.2 style policy matching, the MPLS underlay interface is commonly in an mpls zone. Local VRF interfaces can be placed in VRF-specific zones.

set security zones security-zone mpls interfaces lo0.0 host-inbound-traffic system-services ping
set security zones security-zone mpls interfaces lo0.0 host-inbound-traffic protocols ldp
set security zones security-zone mpls interfaces lo0.0 host-inbound-traffic protocols bgp
set security zones security-zone mpls interfaces ge-0/0/0.0 host-inbound-traffic system-services ping
set security zones security-zone mpls interfaces ge-0/0/0.0 host-inbound-traffic protocols ospf
set security zones security-zone mpls interfaces ge-0/0/0.0 host-inbound-traffic protocols ldp

set security zones security-zone vrf-1 interfaces ge-0/0/1.10 host-inbound-traffic system-services ping
set security zones security-zone vrf-2 interfaces ge-0/0/1.11 host-inbound-traffic system-services ping

Do not over-permit host-inbound services in production. The examples are intentionally minimal lab scaffolding; restrict source prefixes and protocols for real deployments.

Security Policy Models

Junos 24.2 style: L3VPN VRF group policy matching

Create L3VPN VRF groups for use in policy and NAT match conditions:

set security l3vpn vrf-group vrf-1 vrf vrf-1
set security l3vpn vrf-group vrf-2 vrf vrf-2

Permit customer traffic from local VRF interface zone toward MPLS only when the destination VPN context matches:

set security policies from-zone vrf-1 to-zone mpls policy vrf-1 match source-address any
set security policies from-zone vrf-1 to-zone mpls policy vrf-1 match destination-address any
set security policies from-zone vrf-1 to-zone mpls policy vrf-1 match application any
set security policies from-zone vrf-1 to-zone mpls policy vrf-1 match dynamic-application any
set security policies from-zone vrf-1 to-zone mpls policy vrf-1 match destination-l3vpn-vrf-group vrf-1
set security policies from-zone vrf-1 to-zone mpls policy vrf-1 then permit

Permit return or remote-originated VPN traffic from MPLS toward the local VRF interface only when the source VPN context matches:

set security policies from-zone mpls to-zone vrf-1 policy vrf-1 match source-address any
set security policies from-zone mpls to-zone vrf-1 policy vrf-1 match destination-address any
set security policies from-zone mpls to-zone vrf-1 policy vrf-1 match application any
set security policies from-zone mpls to-zone vrf-1 policy vrf-1 match dynamic-application any
set security policies from-zone mpls to-zone vrf-1 policy vrf-1 match source-l3vpn-vrf-group vrf-1
set security policies from-zone mpls to-zone vrf-1 policy vrf-1 then permit

Repeat for each VRF. This prevents accidental cross-VRF traffic from being permitted even if route leaking is configured elsewhere.

Keep a final deny/reject policy with counters/logging appropriate to the environment:

set security policies global policy reject match source-address any
set security policies global policy reject match destination-address any
set security policies global policy reject match application any
set security policies global policy reject match dynamic-application any
set security policies global policy reject then reject

Junos 25.4R1+ style: VRF-to-zone mapping

Where supported, bind a VRF directly to a security zone. This sets VRF context by zone and simplifies policy construction.

set security zones security-zone vrf-1-ext vrf vrf-1
set security zones security-zone vrf-2-ext vrf vrf-2

Use normal zone policies between internal interface zones and external VRF-bound zones:

set security policies from-zone vrf-1-int to-zone vrf-1-ext policy vrf-1-int-ext match source-address any
set security policies from-zone vrf-1-int to-zone vrf-1-ext policy vrf-1-int-ext match destination-address any
set security policies from-zone vrf-1-int to-zone vrf-1-ext policy vrf-1-int-ext match application any
set security policies from-zone vrf-1-int to-zone vrf-1-ext policy vrf-1-int-ext then permit

set security policies from-zone vrf-1-ext to-zone vrf-1-int policy vrf-1-ext-int match source-address any
set security policies from-zone vrf-1-ext to-zone vrf-1-int policy vrf-1-ext-int match destination-address any
set security policies from-zone vrf-1-ext to-zone vrf-1-int policy vrf-1-ext-int match application any
set security policies from-zone vrf-1-ext to-zone vrf-1-int policy vrf-1-ext-int then permit

Important limitation from the source article: as of 25.4R1, VRF-to-zone mapping does not permit mixing interfaces and VRFs inside the same zone, so you cannot always collapse the policy to a simple intrazone match.

For NAT use cases, the VRF-groups approach still applies as of 25.4R1.

VRF-Aware NAT and AppID

Use VRF-aware NAT when overlapping spaces or per-VRF translation are required.

Source NAT example:

set security nat source pool pool-1 address 10.10.3.10/32
set security nat source rule-set snat-1 from zone vrf-1
set security nat source rule-set snat-1 to routing-group vrf-1
set security nat source rule-set snat-1 rule src-nat-1 match source-address 10.0.3.0/24
set security nat source rule-set snat-1 rule src-nat-1 then source-nat pool pool-1

Static NAT example pattern:

set security nat static rule-set static-1 from routing-group vrf-2
set security nat static rule-set static-1 rule static-1 match destination-address 10.10.3.10/32
set security nat static rule-set static-1 rule static-1 then static-nat prefix 10.0.3.10/32
set security nat static rule-set static-1 rule static-1 then static-nat prefix routing-instance vrf-2

When using AppID, the source material recommends logging sessions that cannot be identified and remain in the pre-identification stage:

set security policies pre-id-default-policy then log session-close
set security policies pre-id-default-policy then log session-update 1

Verify with the session/NAT/hit-count commands in Verification Workflow steps 4 and 6, looking for:

• policy name and zone direction
• L3VPN VRF Group or VRF Zone annotations
• translated source/destination IP and port behavior
• Dynamic application: junos:<APP>
• packet and byte counters on both wings

PowerMode / RFP Guidance

Traffic subjected to MPLS handling is processed in SRX Regular Flow Path (RFP), not PowerMode (PM). On x86-based SRX platforms, PM is enabled by default since Junos 21.3. If the device is dedicated to MPLS-in-flow traffic, disabling PM can avoid the overhead of checking whether traffic is eligible for PM:

set security flow power-mode-disable

Do not apply this blindly. Keep PM enabled if the SRX also carries non-MPLS workloads that benefit from it, especially IPsec where PowerMode IPsec may materially improve performance.

Verify whether a session is in PM:

show security flow status
show security flow session destination-port <PORT> extensive

In extensive session output, check each wing for:

Power-Mode Active: False

Part 2 observed that SRX4600 MPLS L3VPN throughput can approach the platform PFE-SPU interlink limit for large frames in controlled testing, and single-flow packet rate depends on CPU/SPU limits and PM status. Treat those figures as lab data, not a deployment guarantee. Real-world performance depends on packet size mix, connection setup/teardown rate, enabled services, AppID/IPS/NAT/logging, and traffic symmetry.

For arbitrary performance tests, disabling drop-flow may avoid misleading log/session load from denied tester traffic:

set security flow drop-flow max-sessions 0

Verification Workflow

1. Forwarding mode

show security flow status

Expected: the MPLS-in-flow baseline shown in Forwarding Mode Baselines (inet/inet6 flow based, MPLS packet based, ISO drop).

2. MPLS and label distribution

show mpls interface
show mpls lsp
show ldp neighbor
show route table inet.3
show route table mpls.0

Check that MPLS-facing interfaces are up, labels are installed, and transport labels resolve toward PE loopbacks.

3. MP-BGP VPN routes

show bgp summary
show route advertising-protocol bgp <PEER> table bgp.l3vpn.0
show route table bgp.l3vpn.0
show route table vrf-1.inet.0
show route table vrf-2.inet.0

Check route distinguishers, route targets, next-hop recursion, and imported/exported VRF routes.

4. Policy and NAT

show security policies hit-count
show security flow session
show security flow session extensive
show security nat source rule all
show security nat static rule all

Check that traffic matches the intended VRF-aware policy and NAT rule, not a broad fallback.

5. Packet capture

On Junos or attached lab bridges, confirm MPLS labels on the underlay and plain customer packets on access-facing links:

monitor traffic interface <MPLS_IFL> matching "mpls" no-resolve
monitor traffic interface <ACCESS_IFL> no-resolve

In Linux/KVM labs:

tcpdump -n -i <bridge> mpls
tcpdump -n -i <bridge> host <customer-ip>

6. Application identification

show security flow session dynamic-application junos:SSH
show services application-identification statistics applications
show log messages | match pre-id

Verify unidentified or pre-ID sessions are not silently bypassing intended controls.

Troubleshooting Matrix

Common Pitfalls

1. Confusing MPLS packet-based forwarding with global packet mode. The design relies on MPLS being packet-based and inet/inet6 staying flow-based.

2. Forgetting vrf-table-label on SRX VRFs with local interfaces. This is mandatory in the source SRX L3VPN examples.

3. Treating route leaking as policy permission. Routing reachability and security policy permission are separate; use VRF-aware policy matches to prevent accidental cross-VRF access.

4. Copying lab-wide any policies into production. The source configs are demonstration scaffolding. Replace broad source/destination/application matches with real controls.

5. Assuming VRF-to-zone mapping eliminates VRF-aware NAT needs. As of 25.4R1, NAT use cases still use the VRF-groups approach.

6. Forgetting MTU outside Junos. In virtual labs, configure the vSRX interface, VM NIC, and Linux bridge for MPLS headroom.

7. Disabling PowerMode without considering other workloads. PM may not help MPLS RFP traffic, but it can help non-MPLS and IPsec traffic.

8. Using SRX4600/SRX4700 performance numbers as guaranteed sizing. The source figures are controlled lab results; production sizing must include services, traffic mix, concurrent sessions, logging, and failure modes.

Verification Checklist

• Confirm Junos release and SRX platform support for MPLS L3VPN in flow mode.
• Confirm show security flow status has inet/inet6 flow based and MPLS packet based.
• Confirm MPLS-facing interfaces have sufficient MTU and family mpls.
• Confirm loopback reachability through IGP and LDP/transport-label state.
• Confirm MP-BGP family inet-vpn is established and VPN routes import/export correctly.
• Confirm each VRF has the intended RD, route target, interface binding, and vrf-table-label.
• Confirm security policy uses L3VPN VRF group matching or supported VRF-to-zone mapping.
• Confirm NAT rules include the correct VRF/routing-instance context when NAT is used.
• Confirm policy hit counters, session details, NAT translations, and AppID output match the intended VRF.
• Confirm packet capture shows MPLS labels on the underlay and customer packets on access interfaces.
• Confirm PowerMode/drop-flow choices are deliberate and documented for the workload.

Source Notes

This skill is synthesized from two Juniper Community TechPosts by Karel Hendrych:

• references/source-srx-mpls-in-flow-part-1.md - Junos 24.2R1 MPLS/flow-mode behavior, vSRX L3VPN lab, VRF-aware policy, NAT/AppID, verification, and appendices.
• references/source-srx-mpls-in-flow-part-2.md - Junos 25.4R1 SRX4600/SRX4700 platform support, VRF-to-zone mapping, SRX4600 performance testing, PowerMode observations, and physical-lab configs.
• references/source-index.md - reference index.

The main playbook intentionally extracts reusable operational guidance instead of mirroring the full articles.