brkccie-3345 final-rev 05 (mpls)

© 2011 Cisco and/or its affiliates. All rights reserved. Cisco PublicBRKCCIE-3345 1

Keith Barker BRKCCIE-3345

A CCIE’s Introduction

to MPLS Networks

Nova Datacom

July 10–14, 2011


Tour Guide

Keith Barker, CCIEx2 #6783, CCDP, CCSI

CCIE Route & Switch, Security

Cisco Certified Design Professional

CISSP and several other random things!

Email: [email protected]

Twitting: @KeithBarkerCCIE & @NovaDatacom

mailto:[email protected]


Tour Guide

Scott Morris, CCIEx4 #4713, CCDE #2009::13, JNCIEx2

CCIE Route & Switch, ISP/Dial, Security, Service Provider

Cisco Certified Design Expert

Juniper Networks JNCIE-M #153 and JNCIE-ER #102

CISSP, CCVP and several other random things!

Email: [email protected]

Twitting: @ScottMorrisCCIE & @NovaDatacom




Journey

MPLS IP Unicast Forwarding

VRFs

MPLS L3 VPNs

Interactive Demonstrations


4.00 Implement MPLS Layer 3 VPNs

4.10 Implement Multiprotocol Label Switching (MPLS)

4.20 Implement Layer 3 virtual private networks (VPNs) on provider edge (PE), provider (P), and customer edge (CE) routers

4.30 Implement virtual routing and forwarding (VRF) and Multi-VRF Customer Edge (VRF-Lite)

From the CCIE R&S Blueprint


MPLS

VRFs

iBGP

Routers that Administrators that know the how the game is played

Ingredients in the MPLS VPN Recipe


Topology


MPLS Building Blocks


Topology


Labels


MPLS (Layer 2.5) Shim Header Fields:

Label, 20 bits

Experimental (CoS), 3 bits

Stacking bit, 1 bit. This is the bottom-of-stack bit. 1=on=last label.

Time to live, 8 bits

MPLS Shim Header

TTLLabel (20 bits) CoS S

IP PacketIP Packet32 bits

L2 HeaderL2 Header MPLS Header


In frame-mode

Inserted between L2 and L3

L2 protocol identifier (PID) is changed to indicate that the packet has an MPLS label

Unlabeled IP unicast PID = 0x 0800

Labeled IP unicast PID = 0x 8847

Where Does the Label Go?


Stacks


So where do these Labels come from?

TTLLabel (20 bits) CoS S

IP PacketIP Packet32 bits

L2 HeaderL2 Header MPLS Header


As routes appear in the routing table, each router assigns a locally significant label for each IP route.

Routers advertise the label to neighbors, using Label Distribution Protocol (LDP). It is like a link local IGP for labels.

Routers use their IP routing information to determine the direction and next hop (the path they will use) to forward a labeled packet.

The Birth of a Label


What do Planes have to do with

networking?


Dynamic protocols build control plane.

Packets are forwarded on the data plane.

IP routers make independent forwarding decision based on IP packet header, and local CEF (Cisco Express Forwarding) and Forwarding Information Base (FIB) table.

Label Switching Routers (LSRs) make independent forwarding decisions based on the MPLS label, and the LFIB (Label Forwarding Information Base).

Control Plane and Data Plane


PUSH – impose label

POP – dispose label

SWAP – which is a pop/push combo

How LSRs Use Labels

Three Major “Operations” Have Been Defined


Ingress LSR – imposes labels

Egress LSR – disposes labels

Intermediate LSR – swaps them

Push, Pop, or Swap

Three “Roles” for Routers Have Been Defined


Implicit Null

Reserved label #3

PHP – Penultimate Hop Pop

Next to last LSR, removes top label, so that egress LSR (PE) doesn’t have to

MPLS Terms


Topology


An ingress LSR (PE), when receiving a IP transit packet, uses the CEF table to forward. In the CEF table, there may be a label, if we have learned a label for the IP destination. If a label is present we will impose/push the label we learned for this network/route, and forward the packet to our downstream LDP neighbor.

If an LSR receives a labeled packet, that it doesn’t have a local label for, it drops it.

To Push, or Not to Push?


The Actual Network Is “Downstream”


LSR – Label Switch Router

Router that supports MPLS

Ingress LSR (upstream)

Provider Edge (PE) first hop. Takes IP naked transit packet and pushes/imposes new label and forwards.

Intermediate LSR

Provider (P) takes labeled packet and swaps labels and forwards to next LSR

Egress LSR (downstream)

Provider Edge (PE) last hop. Pops/disposes label and forwards naked IP packet

Acronyms and Terms


So which device is the Ingress LSR?


MPLS provider edge (PE) routers do a IP route lookup and if PE down stream LDP neighbor has advertised a label for that IP network, the PE will push the advertised label at layer 2.5 and forward the packet as an MPLS packet to the downstream neighbor.

P router will swap the local label, and put on the label it learned from it’s downstream neighbor, and forward it on.

Downstream neighbors will continue to swap the labels, and forward the MPLS packet until packet reaches the MPLS egress PE.

The egress PE will pop of any remaining label(s), and forward the packet as an IP packet.

MPLS Forwarding


Labels are created and advertised

LDP UDP Hello messages are sent to 224.0.0.2 LDP uses TCP port 646 for neighbor establishment.

MPLS Label Distribution


Using the Labels

Upstream

P-5

Local Label 42

FEC: 7.7.7.0

Label: 3

Directly

connected

Network 7.7.7.0

MPLS Table

In Out

(fa0/0, 3)

MPLS Table

In Out

(fa0/0, 22)

MPLS Table

In Out

(fa1/0, 3)(fa0/1, 22)

FEC: 7.7.7.0

Label: 22

LDP label mapping– Each router assigns local label– Each router advertises that label– Label 3 is a reserved label for implicit null

= Control Plane

Fa0/0

= Data Plane

Fa1/0Fa0/1Fa0/0

(fa0/1, 42)

Intermediate

P-6

Local Label 22

Downstream

PE-7

Local Label imp null

No Label


After locally assigning labels to all known routes, we advertise them to ALL neighbors, up and down stream.

Neighbors calculate best path based on IGP next hop, and addresses that are owned by the LDP neighbors.

Each LDP speaker will remember all the labels received through advertisements, and the best paths go into the LFIB/CEF.

Downstream routers that advertise their labels, without being asked, are considered to be doing down-stream un-solicited label advertising.

When an LSR keeps track of all the advertisements, both best and not best path, it is called Liberal label retention. Nice to have for cutover to another path. Sort of like EIGRPs feasible successor.

Label Advertising and Retention


Each LSR assigns a local label to each IP route, and then shares that local label with it’s LDP neighbors.

If an LSR wants it’s neighbor to pop off a label before forwarding downstream (towards the PE), it advertises an “implicit null” (value is 3) for the given network.

Penultimate Hop Popping (PHP) saves the egress PE from an extra LFIB lookup.

PHP


Implicit Null Advertisement


Lets Play Follow the Label


Follow the bouncing ball (label)


IP Routing protocols populate the Routing Information Base (RIB) –control plane

RIB populates CEF and its Forwarding Information Base (FIB) – data plane

IP only packets: Use CEF

Label Distribution Protocol (LDP) populates the Label Information Base (LIB) – control plane

LDP and RIB populate the Label Forwarding Information Base (LFIB) – data plane

MPLS labeled packets: Use LFIB

CEF also stores label information

Who do we turn to for lookups?


LIB and LFIB


(config)# ip cef

(config)# mpls ip

(config)# interface fastethernet 0/0

(config-if)# mpls ip

MTU is automatically adjusted

Can change with mpls mtu command

Mpls mtu 1512 -- would support 3 labels (4 bytes per label)

MPLS Basic Configuration


(config)# mpls ldp router-id loopback0

(config)# interface fastethernet 0/0

(config-if)# mpls label protocol ldp

Can use TDP, LDP or both on interface

By default all prefixes have labels advertised for them, and all neighbors have labels advertised to them

LDP is the default protocol

Configure per interface

MPLS LDP Configuration


(config)# no mpls ldp advertise-labels

(config)# mpls ldp advertise-labels

[for (ACL-of-networks)] [to (ACL-

peers)

(config-if)# mpls label range 200

120000

Conditional LDP Advertisements


IP IGP routing protocols build the IP tables

LSRs assign a local label for each route

LSRs share their labels with other LSRs using LDP

LSRs build their own LIB, LFIB and FIBs based on what they have learned from their LDP neighbors

The Order of Things


Two step process

Hello messages

LDP link hello uses destination UDP port 646 and is sent to 224.0.0.2

Hello may include the IP address desired for peering, different than the source IP in the header.

Indicates if the label space is system wide, or per interface.

Setup LDP session with neighbor who says hello.

Session is TCP based on destination port 646

Router with highest LDP router ID will initiate this TCP session ( called the active LSR ). Keepalives are sent every 60 seconds.

Won’t You Be My Neighbor?


LDP router ID is highest IP on loopback, but we can force it.

(config)# mpls ldp router-id loopback0

IGP Routing may disagree with LDP processes –RID must be reachable over connected interface, unless we use:

(config-if)# mpls ldp discovery transport-address interface

Why LDP Won’t Neighbor Up


Security – Computes MD5 Signatures

(config)# mpls ldp neighbor (ip#) password (pw)

Label filters – inbound from neighbor

(config)# mpls ldp neighbor (ip#) labels accept (#)

(ip#) = IP address of LDP neighbor

(#) = number of access-list of network prefixes

Other LDP Features


TTL and MPLS vs IP Headers


Traceroute uses TTL manipulation to trigger feedback.

Disabling the TTL propagation will not copy the initial IP TTL to the MPLS TTL, and MPLS will start at 255.

Results: MPLS LSRs become the invisible network to the eyes of traceroute.

Hide the MPLS Core from the Client


No mpls ip propagate-ttl (on All LSRs)


show mpls ldp parameters

show mpls interface

show mpls ldp discovery

show mpls ldp neighbor [detail]

show mpls ldp bindings (the LIB)

show mpls forwarding table (the LFIB)

show ip route a.b.c.d (the RIB)

show ip cef a.b.c.d [detail] (the FIB)

show cef interface

debug mpls ldp

debug mpls lfib

debug mpls packets

Monitoring MPLS


LDP neighborship failed

MPLS not enabled, LDP TCP/646 or TDP TCP/711 ports filtered, no L3 route to LDP neighbor LSR router-id, highest loopback address.

Labels not assigned

CEF not enabled

Labels not shared

Compatible LDP between neighbors

Slow convergence

Get rid of RIP IGP is biggest factor in convergence delay

Large packets dropped

MTU not supported by switches. Multiple labels may be present pushing the MTU to a size not supported by the infrastructure.

Troubleshooting MPLS


Verify routing protocol is running properly

Show ip route 10.10.10.0

Verify CEF Switching

Show ip cef 10.10.10.0 detail

Verify MPLS Operations

Show mpls interface

Verify Label Distribution

Show mpls ldp discovery

Verify Label Binding

Show mpls ip binding

Ping/Traceroute

Useful MPLS Troubleshooting

Commands


Live and Interactive

Demonstration of

MPLS Label Switching


Interactive Demonstration (note the labels)


Interactive Live Demo


What label should PE-3 choose for network 7.7.7.7 ?

33

Pick a label PE-3


What label should P5 choose for network 7.7.7.7 ?

42

Pick a label P5


What label should P6 choose for network 7.7.7.7 ?

22

Pick a label P6


What label should PE-7 choose for network 7.7.7.7 ?

Remember, it’s directly connected.

3, implicit null

Pick a label PE-7


Interactive Demonstration (note the labels)


Stretch- 1, 2, 3 go!


Leveraging MPLS

for L3VPNs


Ingredient List for L3 VPNs…


MPLS

VRFs

iBGP



Cisco can have multiple VRFs

VRF: Virtual Routing and Forwarding instance

Some details about VRFs:

Router can have multiple VRFs

Each VRF has its own RIB and CEF table

Interfaces are allocated to a specific VRF

Interfaces not assigned to a VRF are part of the global routing table on the router.

VRFs contains identity information such as Route Targets (RT), and Route Distinguishers (RD)

More on RT and RD coming up.

VRF: The Virtual Routing Table


Creating a VRF and allocating an interface

ip vrf CompanyC

rd 300:300

route-target export 300:300

route-target import 300:300

interface e0/0

ip vrf forwarding CompanyC

ip address 10.2.22.2 255.255.255.0


Red VRF and Green VRF, with interfaces


MPLS

VRFs

iBGP

Routers and Admins that know about the game



How MPLS L3 VPNs may appear to some.


A customer router (CE) at site A peers with a provider router (PE).

Customer shares all their routes with provider, and provider keeps all of these routes in a local VRF on the provider router.

Provider takes the routes from the VRF, and exports them from the VRF into Multiprotocol BGP (MP-BGP). The routes are now called VPNv4 routes.

MP-BGP is used to share these routes with other MP-BGP routers in the provider network with iBGP connections.

A provider router (PE) peering with a customer router (CE) at site 2, takes the VPNv4 routes from MBGP and imports them into the local VRF for that same customer, and shares the routes from PE to CE at site 2.

MPLS L3VPN Game Plan


What if ACME and Widgets both use the

same network of 10.0.0.0/8 ?


What if customer A and customer B both have a 10.0.0.0/8network, how do we differentiate these inside of MP-BGP?

Wait for it....

Route Distinguisher (RD) is a 64-bit quantity pre-pended to each IPv4 address to make it globally unique inside of MP-BGP

The resulting 96-bit address is called VPNv4 address

VPNv4 addresses are only exchanged via BGP between PE routers

BGP supporting other address families than IPv4 addresses is called multi-protocol BGP

Uniquely Identifying Similar Routes


How the RD is defined

ip vrf CompanyC

rd 300:300

route-target export 300:300

route-target import 300:300

interface e0/0


ip address 10.2.22.2 255.255.255.0


Route Distinguisher


Viewing Routes in MP-BGP by RD


How do we deliver the correct routes from Site-1

to Site-2, as well as Site-A to Site-B?


Export Route Targets identifying VPN membership are added as extended community values with the customer route when it is converted into a VPNv4 route (exported out of the VRF into MP-BGP)

Each virtual routing table has a set of associated import Route Targets that select routes to be inserted into the virtual routing table (imported into the VRF from MP-BGP)

Import/Export Route Targets


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

Extended BGP communities are used to encode these attributes

Extended communities carry the meaning of the attribute together with its value

Any number of route targets can be attached to a single route

Route Target (Cont.)


How the RT is defined

ip vrf CompanyC

rd 300:300

route-target export 7.7.7.7:20

route-target import 7.7.7.7:20

interface e0/0


ip address 10.2.22.2 255.255.255.0


Different than Route Distinguisher

Used as extended community information inside MP-BGP for import/export to/from VRFs

MPLS Route Target


Viewing the Route Target in MP-BGP


Let’s follow the Control Plane for 8.8.8.0

8.8.8.0/24


PE-7 Local Label for 8.8.8.0/24


MP-BGP Update from PE-7


PE-3 knows the route to 8.8.8.0, R7’s VPN Label for that

route, as well as R7’s address as the next hop (18 and 42).

8.8.8.0/24


Here are the SP internal network labels


Happy user at ACME Site-1, sends a ping to device at Site-2

on the 8.8.8.0/24 network. What does ingress PE-3 do?

8.8.8.0/24


Ingress PE imposes two labels

Top label is from LDP (for the next hop of iBGP peer)

Bottom label is from MP-BGP (sourced by egress router)

VPN Label Assignments


PE-3 Imposes the VPN and Transit Labels


The VRF represents a partitioned route table on a PE

Not all PEs need all VRFs, just whenever customer’s links are present

Creating and Assigning VRFs


Import policy means that routes will come from the VPN extended community (MP-GBP VRF)

Export policy means that routes will go to the VPN extended community (VRF MP-BGP)

You can have multiple import targets in a VRF

Import or export policies can filter when desired

Secret to remembering import/export


Small individual steps

8.8.8.0/24


CE peers with PE and shares their routes with PE.

PE places learned routes into VRF for that customer (ACME Inc, Site 2 as an example).

This same PE exports routes from VRF into MP-BGP and adds the RD and Export Route Target(s) associated with that VRF. PE also includes the local VPN label it assigned for that prefix/route.

PE shares this routing info via iBGP with remote PE

The remote PE (the iBGP peer) imports routes from MP-BGP into local VRF, and then shares those via peering with local CE.

The process:


PE-3 and PE-7 iBGP/MP-BGP Peers


Complete Your Online Session Evaluation

Receive 25 Cisco Preferred Access points for each session evaluation you complete.

Give us your feedback and you could win fabulous prizes. Points are calculated on a daily basis. Winners will be notified by email after July 22nd.

Complete your session evaluation online now (open a browser through our wireless network to access our portal) or visit one of the Internet stations throughout the Convention Center.

Don’t forget to activate your Cisco Live and Networkers Virtual account for access to all session materials, communities, and on-demand and live activities throughout the year. Activate your account at any internet station or visit www.ciscolivevirtual.com.

http://www.ciscolivevirtual.com/


Visit the Cisco Store for Related Titles

http://theciscostores.com

http://theciscostore.com/


Thank You

MPLS IP Unicast Forwarding

VRFs

MPLS L3 VPNs

Thank you for joining us today!

Keith Barker / Scott Morris


Thank you.

brkccie-3345 final-rev 05 (mpls)

Documents

vpn extended

forwarding

virtual routing

definedip

cef table

control plane

target export

route targets