# Srx Mpls In Flow

> Design, configure, audit, and troubleshoot Juniper SRX MPLS L3VPN in flow mode. Use when handling Junos 24.2R1+ family mpls with inet or inet6 flow, secure PE or CPE, VRFs, LDP, MP-BGP, l3vpn vrf-group policy, VRF-to-zone mapping, VRF-aware NAT or AppID, PowerMode or RFP, MTU, labels, or policy matching.

- **Type:** Skill
- **Install:** `agentstack add skill-fastrevmd-lab-fwskillsshare-srx-mpls-in-flow`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [fastrevmd-lab](https://agentstack.voostack.com/s/fastrevmd-lab)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** Apache-2.0
- **Upstream author:** [fastrevmd-lab](https://github.com/fastrevmd-lab)
- **Source:** https://github.com/fastrevmd-lab/fwskillsshare/tree/main/skills/srx-mpls-in-flow
- **Website:** https://mechub.org

## Install

```sh
agentstack add skill-fastrevmd-lab-fwskillsshare-srx-mpls-in-flow
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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.

## 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:

```junos
set security forwarding-options family mpls mode packet-based
```

Expected status:

```text
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:

```junos
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.

```junos
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:

```junos
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`:

```junos
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.

```junos
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.

```junos
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:

```junos
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:

```junos
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:

```junos
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:

```junos
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.

```junos
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:

```junos
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:

```junos
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:

```junos
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:

```junos
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:`
- 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:

```junos
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:

```text
show security flow status
show security flow session destination-port  extensive
```

In extensive session output, check each wing for:

```text
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:

```junos
set security flow drop-flow max-sessions 0
```

## Verification Workflow

### 1. Forwarding mode

```text
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

```text
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

```text
show bgp summary
show route advertising-protocol bgp  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

```text
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:

```text
monitor traffic interface  matching "mpls" no-resolve
monitor traffic interface  no-resolve
```

In Linux/KVM labs:

```bash
tcpdump -n -i  mpls
tcpdump -n -i  host 
```

### 6. Application identification

```text
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

| Symptom | Likely cause | Checks / fix |
|---|---|---|
| `MPLS forwarding mode` i

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [fastrevmd-lab](https://github.com/fastrevmd-lab)
- **Source:** [fastrevmd-lab/fwskillsshare](https://github.com/fastrevmd-lab/fwskillsshare)
- **License:** Apache-2.0
- **Homepage:** https://mechub.org

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-fastrevmd-lab-fwskillsshare-srx-mpls-in-flow
- Seller: https://agentstack.voostack.com/s/fastrevmd-lab
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.