CCIE Archives — Page 4 of 5

MPLS Fundamentals: 2 – Forwarding Labeled Packets

CEF switching is the only IP switching mode that you can use to label packets. Other IP switching modes, such as fast switching, cannot be used, because the fast switching cache does not hold information on labels. Because CEF switching is the only IP switching mode that is supported in conjunction with MPLS, you must turn on CEF when you enable MPLS on the router.

The local label (or tag) is the label that this LSR assigns and distributes to the other LSRs.
If this LSR receives a packet with top label 16, it removes all labels and forwards the packet as an IP packet, because the outgoing label (tag) is Untagged.

The incoming label 23 is swapped with label 20, and label 16 is pushed onto label 20.

Continue reading “MPLS Fundamentals: 2 – Forwarding Labeled Packets”

Share this!

MPLS Fundamentals: 1 – Architecture

Ingress LSRs —Ingress LSRs receive a packet that is not labeled yet, insert a label (stack) in front of the packet, and send it on a data link. One that is doing imposition is an ingress LSR
Egress LSRs—Egress LSRs receive labeled packets, remove the label(s), and send them on a data link. Ingress and egress LSRs are edge LSRs. One that does disposition is an egress LSR.

A Forwarding Equivalence Class (FEC) is a group or flow of packets that are forwarded along the same path and are treated the same with regard to the forwarding treatment.

The same FEC have the same label. However, not all packets that have the same label belong to the same FEC, because their EXP values might differ; the forwarding treatment could be different, and they could belong to a different FEC. The router that decides which packets belong to which FEC is the ingress LSR. This is logical because the ingress LSR classifies and labels the packets.

All packets with a destination IP address for which the IP lookup in the routing table recourses to the same BGP next-hop address will be mapped to the same FEC.

Labels are local to each pair of adjacent routers.

The implementation for distance vector routing protocols (such as EIGRP) is straightforward, because each router originates a prefix from its routing table. The router then just binds a label to that prefix.

For link state routing protocols, a separate protocol is preferred to distribute the labels.

BGP is a routing protocol that can carry prefixes and distribute labels at the same time.

These received bindings become remote bindings. The neighbors then store these remote and local bindings in a special table, the label information base (LIB).

You can have one label per prefix or one label per prefix per interface, but the LSR gets more than one remote binding because it usually has more than one adjacent LSR.

The routing table (sometimes called the routing instance base, or RIB) determines what the next hop of the IPv4 prefix is. The LSR chooses the remote binding received from the downstream LSR, which is the next hop in the routing table for that prefix. It uses this information to set up its label forwarding information base (LFIB) where the label from the local binding serves as the incoming label and the label from the one remote binding chosen via the routing table serves as the outgoing label.

LDP does not bind labels to BGP IPv4 prefixes.

All these remote bindings are found in the LIB. The LFIB chooses only one of the possible outgoing labels from all the possible remote bindings in the LIB and installs it in the LFIB. The remote label chosen depends on which path is the best path found in the routing table.

It is the egress LSR that created the label binding for that FEC, and it knows what that FEC is.

Independent LSP Control mode: In this control mode, each LSR creates a local binding for a particular FEC as soon as it recognizes the FEC. Usually, this means that the prefix for the FEC is in its routing table.
Ordered LSP Control mode: an LSR only creates a local binding for a FEC if it recognizes that it is the egress LSR for the FEC or if the LSR has received a label binding from the next hop for this FEC.

If the LSR were running in Independent LSP Control mode, it would assign a local binding for each IGP prefix in the routing table. If the LSR were running in Ordered LSP Control mode, this LSR would only assign a local label binding for the IGP prefixes that are marked as connected in its routing table and also for the IGP prefixes for which it has already received a label binding from the next-hop router (as noted in the routing table). Cisco IOS uses Independent LSP Control mode. ATM switches that are running Cisco IOS use Ordered LSP Control mode by default.

The label stack sits in front of the transported packet. If the transported packet is an IP packet, the label stack is behind the Layer 2 header but before the IP header.

An ordered sequence of LSRs is a label switched path (LSP). A Forwarding Equivalence Class (FEC) is a group or flow of packets that receive the same forwarding treatment throughout the MPLS network. The FEC is thus determined by the label stack and the EXP bits in the label.

The LIB is the table that stores the label bindings, whereas the LFIB is the lookup table that forwards labeled packets.

Share this!

MPLS Fundamentals: 3 – LDP

Basic MPLS LDP Configuration

ip cef
mpls ldp router-id Loopback0 [force]
mpls label protocol ldp

224.0.0.2 group IP multicast address. The UDP port used for LDP is 646.

LDP Discovery

LDP discovery timers manipulation

mpls ldp discovery {hello {holdtime | interval } seconds

The default value for holdtime is 15 seconds for link Hello messages, and the default value for interval is 5 seconds.
If the two LDP peers have different LDP Hold times configured, the smaller of the two values is used as the Hold time for that LDP discovery source.

Cisco IOS might overwrite the configured LDP Hello interval. It will choose a smaller LDP Hello interval than configured so that it can send at least three LDP Hellos before the Hold time expires. (At least nine Hellos are sent in the case of a targeted LDP session)

Continue reading “MPLS Fundamentals: 3 – LDP”

Share this!

RT & RD difference

It’s given that customers of a Service Provider will have overlapping IP addressing in their VPNs, e.g. you will have more than two customers who use the 10.0.0.0/8 network. The RD is how you tell them apart. If you have customer “A” with RD “A” and customer “B” with RD “B” the routes “A:10.0.0.0/8” and “B:10.0.0.0/8” become unique. This is all the RD does.

What is an RD? An RD is a 64 bit value that is attached to the customer’s IPv4 address, to make it a Unique 96 bit address called VPNv4. These addresses are ONLY exchanged between the PE routers.

Once the PE router attaches the RD to the CE routes, it then sends the VPNv4 address/es to the other PE router/s. The receiving PE router strips the RD from the VPNv4 prefix, and it s left with an IPv4 address.

The Route Target tells you which VRF table the route belongs to. You have to separate the two attributes because sometimes you want the same route to belong to multiple VRF tables. This is common in what’s known as “Central Services VPNs”. For example if the Service Provider hosts email for customers, that route to the mail server would have to be in the routing table of multiple customers. This doesn’t break the rule of the route having to be unique though, which is what the RD does.

NOW How does the receiving PE know which VRF does the IP address belong to? The answer is Route-Target .

The Route-target is a BGP extended community that indicates which routes should be exported from a given VRF or imported into a given VRF.

Share this!

IPExpert CoD: MPLS-VPN

This post contains my notes from an old version of IPX Class on Demand by Joe Astorino.

RD has no special meaning—it is only used to make potentially overlapping IPv4 addresses globally unique

Route Targets are additional attributes attached to VPNv4 BGP routes to indicate VPN membership

Export Route Targets identifying VPN membership are appended to customer route when it is converted into VPNv4 route

RD & RT are extended BGP communities; neighbor send-community extended is required!

RR for VPNv4 does not need to be the same as RR of IPv4.

PE imposes 2 labels, the one if from LDP, and the bottom one is from VPNv4 address-family.

Each bgp address-family is a different RIB.

Import policy means that routes will come from the VPN extended community
Export policy means that routes will go to the VPN extended community

ARF –Automatic Route Filtering: Only VPN information matching a locally configured RT will be imported
Could be disabled: no default bgproute-target filter

By default, when running OSPF over Frame-Relay and network type is anything except point-to-multipoint, on a spoke, the nexthop for a route originated from another spoke will be that spoke.
But when the network type is point-to-multipoint, the nexthop will be the hub, and a host route for each spoke will exist.
So make sure to use point-to-multipoint when using MPLS.

RIP/EIGRP address-family version and summarization is different form the RIP/EIGRP’s itself.

When the customer needs the same AS on multiple sites, the AS Override feature should be triggered. So the PE will override its (prepend). Another way to handle this requirement is using allowas-in. Continue reading “IPExpert CoD: MPLS-VPN”

Share this!