Forwarding Equivalence Class

What Is a Forwarding Equivalence Class?

Forwarding Equivalence Class (FEC) is a fundamental concept in MPLS: a classification of packets that are treated identically by the network as they travel toward their destination. Packets assigned to the same FEC follow the same path, receive the same priority, and are subject to the same forwarding policies — regardless of where they individually originated.

This is the entire idea behind MPLS in one sentence: instead of every router making an independent forwarding decision for every packet, packets are grouped into classes once at the network edge, and the rest of the network simply follows the label.

What Does an FEC Do?

Key characteristics

Classification — an FEC is a group of packets forwarded the same way (same destination, QoS treatment, or path).
Label mapping — every FEC maps to a unique MPLS label at each router, stored in the Label Forwarding Information Base (LFIB).
Consistent treatment — because membership is decided at the edge, every core router handles a packet the same way without re-evaluating it.

What can define an FEC?

Packets destined for the same IP subnet (e.g., 192.168.1.0/24).
Packets belonging to a specific VPN (Layer 3 VPN or Layer 2 circuit).
Packets requiring the same traffic-engineering constraint (e.g., a low-latency path).

The FEC, not the packet, is what the network reasons about.

The components around it

Component	Role relative to the FEC
LER (Label Edge Router)	Ingress/egress router — classifies packets into FECs, pushes/pops labels
LSR (Label Switch Router)	Core router — swaps labels and forwards based on the LFIB
LSP (Label Switched Path)	The unidirectional path a packet takes, determined by the FEC and its label bindings
LDP	Protocol that distributes label mappings for FECs between routers
LFIB	The forwarding table mapping incoming labels to outgoing labels and interfaces

The Problem FECs Solve

Traditional IP forwarding has a structural limitation: every router, for every packet, makes its own longest-prefix lookup decision based solely on the destination IP address. That design has three consequences:

Problem with per-packet IP forwarding	How FECs solve it
Every router re-classifies every packet — the same decision is made N times along the path	Classify once at the ingress LER; the label carries that decision through the network
Forwarding is bound to destination-only logic — no way to say “route these packets via this path, with this priority”	An FEC can be defined on anything: destination, VPN membership, QoS class, or TE constraint
Core routers must inspect the full IP header	Core LSRs switch on a fixed-size label and never look at Layer 3
Services like VPNs, TE, and fast reroute are bolt-on hacks on top of destination forwarding	FECs make them first-class: a VPN or a protected path is an FEC

In short: the FEC decouples what a packet is (its class) from how the network forwards it (the label). That single abstraction is what makes MPLS forwarding efficient, scalable, and service-aware.

FEC in Action: Push, Swap, Pop

Consider the flow R1 → R2 → R3 → R4 for the FEC 10.0.0.0/24:

terminal

[IP Packet] --> [Ingress LER] --> [LSR 1] --> [LSR 2] --> [Egress LER] --> [Destination]
                    R1: push       R2: swap     R3: swap     R4: pop

Ingress LER — label push. R1 receives an IP packet destined to 10.0.0.1, classifies it into the FEC 10.0.0.0/24, and pushes label 100 onto the packet before forwarding it to R2.
Core LSR — label swap. R2 looks up label 100 in its LFIB, swaps it for label 200, and forwards to R3 — without inspecting the IP header.
Core LSR — label swap. R3 performs the same swap: label 200 → label 300, forwarded to R4.
Egress LER — label pop. R4’s LFIB says label 300 is the penultimate (or final) hop: the label is popped, revealing the original IP packet, which is then forwarded normally to its destination.

The LFIB tables behind that flow

R1 (Ingress LER):

FEC	Label	Action	Next Hop
10.0.0.0/24	100	Push	R2

R2 (LSR):

In Label	Out Label	Action	Next Hop
100	200	Swap	R3

R3 (LSR):

In Label	Out Label	Action	Next Hop
200	300	Swap	R4

R4 (Egress LER):

In Label	Action	Next Hop
300	Pop	10.0.0.1

Each table entry is an FEC-to-label binding — the LFIB is where the FEC concept becomes actual forwarding state.

Seeing FECs on Junos

On a Juniper router running LDP, the FECs in the LDP database and their label bindings are directly visible:

junos

show ldp fec
show ldp database
show route table mpls.0

show ldp fec — the FECs LDP knows about, their prefixes and how they were learned.
show ldp database — the actual label bindings advertised to and received from each LDP neighbor.
show route table mpls.0 — the resulting label-switched forwarding entries installed in the MPLS table.

Summary

An FEC is a group of packets that receive identical forwarding treatment through the MPLS network.
It is assigned once at the edge and represented hop-by-hop by labels in each router’s LFIB.
It solves the core limitation of destination-only IP forwarding: classification happens once, forwarding decisions become cheap label swaps, and services (VPNs, traffic engineering, fast reroute) become native properties of the class.
Push → swap → pop is the entire MPLS data plane — and every step of it is anchored to an FEC.