LER, LSR, PE, P, CE and tables

Theoretical foundations and architecture

MPLS architecture explicitly separates router roles and forwarding tables. An LER (Label Edge Router) resides at the edge: the ingress LER classifies incoming IP packets into FECs and pushes a label stack, while the egress LER pops the label and delivers native packets to the customer. In carrier networks, LERs are known as PEs (Provider Edge), and customer devices are CEs (Customer Edge). Inside the core, LSRs (Label Switching Routers), called P (Provider) routers, never inspect IP headers; they perform label swaps purely using incoming labels. Routers maintain four tables: RIB (Routing Information Base holding IGP/BGP routes), FIB (Forwarding Information Base for native IP forwarding), LIB (Label Information Base storing all advertised LDP bindings), and LFIB (Label Forwarding Information Base used by hardware for incoming labelled packets). A route existing in the RIB does not guarantee MPLS forwarding until a valid binding is programmed into the LFIB.

Device roles: who decides what

In MPLS a role is defined not by the router model but by the operation it performs on a packet. The LER (Label Edge Router) sits on the domain boundary: at ingress it takes a plain IP packet, does a FIB lookup (longest prefix match), determines the FEC and pushes a label; at egress it pops the last label and does a normal IP lookup or a VRF lookup. In operator terminology the LER is usually called a PE (Provider Edge) and the customer router is a CE (Customer Edge). The CE knows nothing about MPLS: it sends plain IP and talks to the PE over static routes, OSPF or BGP. The core LSR is called a P (Provider) router: it switches packets by the top label only and holds neither customer routes nor VRFs. This is the BGP-free core principle: customer prefixes (hundreds of thousands) live only on PEs, while P routers need only PE loopbacks and links - a few hundred LFIB entries. The same physical router can be a PE for some services and a P for transit of others; the RR (route reflector) is a separate control-plane role and normally is not in the data path.

Four structures: RIB, FIB, LIB, LFIB

The RIB is built by routing protocols (connected, static, IGP, BGP) and holds all candidates with metrics and administrative distances. The FIB is an optimized copy of the best routes for IP forwarding (on Cisco this is CEF together with the adjacency table, on Junos the forwarding table in the PFE, on Huawei the FIB on line cards). The LIB (Label Information Base) is the software database of all "prefix -> label" bindings: both the local binding (the label the router allocated itself and advertises to neighbors) and remote bindings (labels received from each LDP neighbor, even from one that is not the next hop). The LFIB is what is actually used for switching: one entry per incoming label with the action and outgoing information. For the data plane what matters is the pair FIB (for push at ingress) and LFIB (for swap/pop at transit and egress); the LIB is a control-plane store from which these entries are selected. RFC 3031 terminology covers the same concepts: FTN (FEC-to-NHLFE) is the ingress rule, ILM (Incoming Label Map) is the lookup by incoming label, NHLFE (Next Hop Label Forwarding Entry) is the action, outgoing label and next hop.

Names by vendor: Cisco - show mpls ldp bindings (LIB), show mpls forwarding-table (LFIB), show ip cef (FIB with labels). Junos - inet.0 (RIB), inet.3 (routes to PEs with a push label, used only by BGP to resolve next hops), mpls.0 (transit swap/pop by incoming label); the LIB is viewed separately with show ldp database. Huawei - display ip routing-table, display fib, display mpls lsp. MikroTik - /ip/route, /mpls/ldp/local-mapping + /mpls/ldp/remote-mapping, /mpls/forwarding-table.

Where the label for a prefix comes from

By default a label is allocated independently of the rest of the network (downstream unsolicited, liberal label retention; ordered/independent control depends on the platform): as soon as an IGP route appears in the RIB the LSR creates a local binding and advertises it to all LDP neighbors in a Label Mapping message (FEC TLV + Label TLV). Cisco does this for all IGP prefixes, including links, so mpls ldp label / allocate global prefix-list narrows the list to /32 loopbacks - this reduces the LIB size. Huawei by default triggers LSPs only for /32 host routes (lsp-trigger host), Junos by default advertises only the loopback address (lo0), and anything else must be allowed with an egress-policy. If a prefix is directly connected or is the router itself - this router is the egress for the FEC and advertises implicit null (label 3): the penultimate hop pops the label itself (PHP) and the egress avoids a double lookup. Reserved values 0-15: 0 - explicit null IPv4, 1 - router alert, 2 - explicit null IPv6, 3 - implicit null (never appears on the wire), 7 - ELI, 13 - GAL, 14 - OAM alert. The dynamic range starts at 16 (Cisco IOS-XE), Junos allocates LDP labels from 299776, and Huawei VRP usually from 1024 (the range depends on the version).

The key rule: LDP matches a FEC to a route by exact prefix match. The binding for 10.255.0.2/32 is usable only if the RIB contains exactly 10.255.0.2/32 and the next hop of that route is the LDP neighbor that sent the label. Labels from other neighbors stay in the LIB (liberal retention) as a backup: when the best path changes the LFIB is rebuilt without new requests.

Lookup on each role

Ingress PE: FIB (LPM on the destination IP) -> the entry contains the next hop and the outgoing label (on Cisco label 17-(local:21) in show ip cef detail) -> push; the label TTL is copied from the IP TTL (propagation is on by default) and EXP/TC is taken from DSCP by policy. Transit P: an exact (not LPM) lookup on the 20-bit incoming label in the LFIB -> swap to the new label, TTL decremented by 1. Penultimate P: the outgoing label is implicit null, so the action is Pop (Cisco Pop Label, Junos Pop); the packet goes to the egress with one label less. Egress PE: if only the VPN label remains, it identifies the VRF or interface; for a plain IPv4 LSP the packet arrives already unlabeled and is handled by an ordinary IP lookup. An LFIB lookup is faster and simpler than LPM: a hash/index on 20 bits instead of a prefix search.