12.8 Pipes

This topic describes the functions of pipes in the Cisco TelePresence Video Communication Server (VCS).

A pipe defines the bandwidth limitations between two subzones or between a subzone and a zone.

A pipe applies bandwidth limits to links. By configuring subzones, links, and applying pipes to links, you can create a model of the physical network and its bandwidth limits on network connections such as WAN links. You can apply bandwidth restrictions per call and for the total bandwidth that goes over a link.

When calls are placed between endpoints in different subzones, you can control the bandwidth that is used on each link that is along the path between the two subzones.

First, you must create one or more pipes and configure them with the desired bandwidth limits. Then you must assign the pipes to the links to apply the desired limits. All calls that traverse one or more links that have a pipe applied must find enough available bandwidth on all links that are involved in the call. This implementation ofCAC is similar to Enhanced Location CAC in Cisco Unified Communications Manager.

Pipe Bandwidth Restrictions: Example

This section shows an example of bandwidth restrictions that are applied to links via pipes.

The figure shows an example of a call where pipe bandwidth restrictions apply.

Endpoint 1 calls endpoint 3 at 2 Mbps, but the bandwidth is downsized to 256 kbps because of the Per Call pipe limitation that is applied to the link between the subzones that are involved in the call. If there was no pipe applied to the link, 512 kbps of bandwidth would be used for the call because this bandwidth is the maximum bandwidth that is permitted, based on the bandwidth limits that are configured at the two subzones.

If another call was made between the default subzone and subzone SL, 256 kbps of bandwidth would be used for the second call. A third call between the two subzones would fail, but not because of the total bandwidth limit that is configured at the pipe (2048 kbps), but because of the In&Out bandwidth limit that is configured at the default subzone (512 kbps).

Advertisements

CCIE R&S Written Exam Overview: QoS

Quality of Service (QoS)

QoS Overview

• QoS Components

– Classification & Marking

– Queueing & Congestion Management

– Shaping & Policing

Classification & Marking

• Differentiated Services (DiffServ) Model

– Traffic is grouped into classes

• Classification process defined at network edge

• Classification can be encoded inside packet itself

– Known as packet’s marking

– QoS behavior is defined by traffic’s class

• Called Per-Hop Behavior (PHB)

QoS Markings

• Defines classification of the packet

• Different types of markings

– IPv4 & IPv6 ToS Byte

• DSCP (6 bits)

• IP Precedence (3 bits)

– Layer 2 Markings

• Frame-Relay DE bit (1 bit)

• MPLS EXP bits (3 bits)

• 802.1q/ISL CoS bits (3 bits)

DSCP Default & EF PHBs

• Default

– Best Effort (Worst)

– DSCP value 0 (000000)

• Expedited Forwarding (EF) (Best)

– Priority Traffic

– DSCP value 46 (101110)

DSCP AF PHB

• Assured Forwarding (AF)

– Bandwidth Guaranteed

– Four classes

• AFxy where x = 1 – 4

• Higher is more preferred

– Three drop precedences

• AFxy where y = 1 – 3

• Higher means higher drop precedence

– DSCP value (xxxyy0)

DSCP CS PHB

• Class Selector (CS)

– Backwards compatible with IP Precedence

– Seven classes

• CSx where x = 1 – 7

• Higher is more preferred

Queueing & Congestion Management

• Queueing occurs when packets are delayed by router

• Congestion Management techniques define what happens when queueing occurs

• Techniques include…

– FIFO Queueing

– Fair Queueing & WFQ

– Priority & Low Latency Queueing

– Random Early Detection & WRED

• Technically “congestion avoidance”

– Shaped & Shared Round Robin

Queueing Techniques (Outbound)

• FIFO Queueing

– First packet to enter is first to leave

• Fair Queueing

– Shares resource equally amongst flows

• Weighted Fair Queueing (WFQ)

– Allocates bandwidth per flow proportional to weight

Queueing Techniques (Outbound)

• Class Based Weighted Fair Queueing (CBWFQ)

– WFQ class and weighting are manually defined

– Used to provide bandwidth guarantee to traffic

• Priority Queueing (LLQ)

– Packets marked as priority leave the queue first

– Used to provide low delay to traffic

• Weighted Random Early Detection (WRED)

– Drops packets randomly before queue is full

– Higher a packet’s weighting, less likely it is to be dropped

– TCP Windowing can be modified to slow down conversation

Shaping & Policing

• Used to force congestion to occur

• Traffic Shaping

– Goal is to normalize traffic flow to specified rate

– Delay and Queue exceeding traffic

– Can only apply outbound

• Traffic Policing

– Marks packets that exceed metered rate

• Drop is also a mark action

– Does not queue excess traffic

– Can be applied inbound or outbound

MQC

• Modular Quality of Service Command Line Interface

– Syntax implementation of QoS

– Allows multiple QoS methods per interface per direction and for hierarchy

– “Legacy” QoS did not

• Previously called CBWFQ

– Class Based Weighted Fair Queueing

– Now called Hierarchical Queueing Framework (HQF) as of IOS 12.4(20)T

MQC Configuration

• Define traffic classes

– class-map

– Define traffic match criteria

• Define traffic policy

– policy-map

– Define actions

• Apply policy

– service-policy [in/out] on interface

MQC Classification Options

• Match-Any vs. Match-All

• Access-Lists

• DSCP/IP Precedence

• NBAR

• Source Interface

• Source/Destination MAC address

• Can combine multiple matches in one class

MQC QoS Types

• Admission Control

– Policing

• Classification and Marking/Re-Marking

– Shaping

• Congestion Management & Avoidance

– Queueing Disciplines

• Link Optimization

CCIE R&S Written Exam Overview: Network Services

Network Services Overview

• Two main categories

– IP specific services

• Documented under IP Addressing Services and IP Application Services

– General IOS and management services

• Documented under Network Management and System Management

IP Addressing Services

• First Hop Redundancy Protocols

– HSRP

– VRRP

– GLBP

• Network Address Translation

• DHCP

• DNS

IP Application Services

• IP SLA

• Enhanced Object Tracking

• NetFlow

• WCCP

Management Services

• NTP

• SNMP v1/2/3

• RMON Alarms/Events

• Syslog

• Telnet/SSH

• System banners

• EEM Scripting

CCIE R&S Written Overview: Security

Access-Lists Overview

• Used to filter traffic in the data plane

• Types of ACLs…

– Standard

– Extended

– Time Based

– Dynamic

– Reflexive

• ACLs also support logging of traffic hits

URPF

• Unicast Reverse Path Forwarding

– Used for data plane filtering based on the routing table

– Simple way of preventing spoofing attacks as opposed to long BOGON ACL filters

• Supports two modes of operation

– Strict

– Loose

TCP Intercept

• Prevents TCP SYN Flood Attacks

– TCP 3-way handshake not completed

• SYN, ACK SYN…

– Results in “half-open” or “embyonic” session

• Server’s TCP stack only supports so many connections

• TCP Intercept tries to prevent this two ways

– Intercept mode

• Proxy for all connections

• Only connect to server after 3-way handshake completes

– Watch mode

• Passively monitor session establishment

• Send TCP RST if 3-way handshake does not complete in time

Context Based Access Control

• CBAC adds true stateful inspection to IOS

• Performs protocol-specific inspection

– Protocols matched based on port-number

– Port-map table defined with ip port-map

• Inspection rule defines protocols to inspect

– ip inspect name <NAME>

– Applies to an interface inbound or outbound

– Opens hole in ACL applied in opposite direction

• CBAC integrates TCP Intercept

Zone Based Firewall

• Syntax wrapper to CBAC

– Same inspection engine inside

• Works with security zones, not interfaces

– Zones group multiple interfaces together

– Traffic is allowed inside one zone but prohibited between

– Zone defined via zone security command

• Special zone “self” is allocated to router

– By default all traffic to/from this zone is allowed

Zone Based Firewall

• Inter-zone communication requires “zone pairing”

– Defined with zone-pair

– Associated policy-map of type inspect to permit traffic

• Action “inspect” vs action “pass”

• ZFW configuration uses MQC syntax

– Class-maps/policy-maps of type inspect

– Traffic classified with match protocol

– Application still defined with ip port-map

Layer 2 Security

• Port Security

• VACLs

• DHCP Snooping

• IP Source Guard

• Dynamic ARP Inspection (DAI)

CCIE R&S Written Exam Overview: Multicasting

*To be honest the video for this lesson was extremely painful. I have without a doubt identified my weakest area of the CCIE material. Just look at these notes… what a beast!! Ciscos recommend reading on Multicasting is this badboy:

http://www.amazon.co.uk/Developing-IP-Multicast-Networks-Volume/dp/1587142899

I think for this particular topic I will really need to get into the book and then go back to the video. It surprised me how detailed this ‘overview’ really was.. The problem as well is I have never touched any kind of multicasting IPv4 network.. so to be an expert at this topic is currently way off!!

D

IP Multicast

Multicast Section Objectives

• Understand the components of…

– Multicast Addressing

– Multicast Control Plane

– Multicast Data Plane

IPv4 Multicast Addressing

• IPv4 multicast uses Class “D” Addresses

– 224.0.0.0/4 (224.0.0.0–239.255.255.255)

• Includes reserved ranges

– Link-local Addresses

• 224.0.0.0/24 (224.0.0.0 – 224.0.0.255)

– Source Specific Multicast

• 232.0.0.0/8 (232.0.0.0 – 232.255.255.255)

– Administratively Scoped

• 239.0.0.0/8 (239.0.0.0 – 239.255.255.255)

Multicast Control Plane

• Multicast control plane used to determine

– Who is sending traffic and to what group(s)

– Who is receiving traffic and for what group(s)

– How traffic should be forwarded when it is received

• The Multicast “Tree”

• Control plane is built with a combination of

– Host to Router communication (IGMP)

– Router to Router communication (PIM and MSDP)

Multicast Data Plane

• Once the tree from sender to receiver(s) is built, traffic begins to flow

• Before forwarding, Data Plane checks occur

– Reverse Path Forwarding (RPF) check

• Was traffic received on the correct interface?

– Multicast Routing Table

• What interface(s) should I forward the packets out?

Control Plane – IGMP

• Internet Group Management Protocol

– Used for receiver to signal routers on the LAN that it wants traffic for a specific group

• IGMP host signals membership to router via Report

– IGMPv1/v2 supports only group specific joins

• (*,G) Report

– IGMPv3 supports group and source specific joins

• (S,G) Report

• IOS Router listens for IGMPv1/2 when PIM is enabled

Control Plane – PIM

• Protocol Independent Multicast

– Used for routers to signal each other how to build the Multicast Tree

• “Protocol Independent” because it does not advertise its own topology information

– Implies IGP already runs in the network to build a loop-free topology

• IOS runs PIMv2 by default

PIM Modes

• PIM modes control how the tree is built and who receives what traffic

• Dense Mode

– Considered implicit join

– All traffic unless you say you don’t want it

– Uses Flood & Prune behavior

• Sparse Mode

– Considered explicit join

– No traffic unless you ask for it

– Uses Rendezvous Point (RP) to process join requests

• Sparse Dense Mode

– Sparse for groups with an RP assigned

– Dense for all others

Control Plane – MSDP

• Multicast Source Discovery Protocol

– Used for RPs to signal each other about Multicast Senders

• Originally designed for Inter-AS Multicast

• Can be used for Intra-AS Anycast RP

Data Plane – RPF Check

• PIM does not exchange topology information

– How do we know the network is loop free?

• RPF check prevents loops in the Data Plane

• When packet is received…

– Check source IP address and incoming interface

– If incoming multicast interface == outgoing unicast interface back to source, RPF check passes

– If incoming multicast interface != outgoing unicast interface, RPF check fails and packet is dropped

Data Plane – Multicast Routing Table

• Using PIM, routers learn where sources and receivers exist

– Interface facing upstream towards source is the “incoming interface”

– Interface(s) facing downstream towards receivers make up the “outgoing interface list” or OIL

– Split-horizon like behavior stops an interface from being in OIL if it is already an incoming interface

• If RPF check passes…

– Prefer (S,G) over (*,G) in routing table

– Switch packets from incoming interface to all interfaces in the

OIL

PIM Dense Mode

• RFC 3973 “Protocol Independent Multicast – Dense Mode (PIM-DM)”

• Uses “push” model or “implicit join”

– Called flood and prune

– All traffic flooded throughout entire network

– Routers that have no receivers prune (unjoin) unused links

• Only suitable for small multicast implementations

– Doesn’t scale because of flooding and (S,G) state creation

PIM Dense Mode Operation

• Discover PIM neighbors

– 224.0.0.13 (PIM) to find neighbors on attached links

• Flood all multicast traffic

• Prune unwanted traffic

• Multicast table maintenance

– Graft

– Assert

– State Refresh

PIM Dense Mode Flooding

• Router attached to LAN listens for senders

– Sender does not communicate multicast control plane

• Once traffic is received…

– Insert (*,G) and (S,G) into routing table

• Incoming interface is attached to sender

• OIL is all other PIM interfaces

– Flood traffic to OIL

• Next downstream router(s) continue the process

– Flooding results in a Shortest Path Tree (SPT)

PIM Dense Mode Pruning

• Prune used to tell upstream neighbor to stop sending traffic for (S,G)

• Prune occurs if

– Multicast feed fails RPF check

– No downstream neighbors or receivers

– Downstream neighbors have already sent prune

– LAN Prune Override exception

• Once prune occurs, traffic flow stops but (S,G) remains in table

– Even after prune, traffic is periodically re-flooded at a set interval

PIM Dense Mode Graft

• What happens if I have pruned an (S,G), but then I receive an IGMP join from receiver?

• Graft message used as dense mode “join” to un-prune (S,G) from upstream neighbor

– Graft continues up reverse path back towards Source until tree is rebuilt

– Used to speed up convergence and not wait for periodic flooding

PIM Dense Mode Assert

• Used to prune duplicate multicast feed transmissions

– Typically needed when multiple routers attach to the same multicast enabled LAN

• Triggered when (S,G) feed is receive in an interface already in the OIL

• Assert winner determined by

– Lowest metric to source

– Highest IP address if metric is equal

PIM Dense Mode State Refresh

• Normally once an (S,G) is pruned, traffic is reflooded about every 3 minutes

– Limits scalability of dense mode

• State refresh is a keepalive for prune state

– Originated by root of the SPT

– If downstream routers agree, traffic is not reflooded

– Still doesn’t fix (S,G) state information in the routing table

PIM Sparse Mode

• RFC 4601 “Protocol Independent Multicast – Sparse Mode (PIM-SM)”

• Uses “pull” model or “explicit join”

– Traffic is not flooded unless you ask for it

• Uses both Shared Trees (RPT) and Source Based Trees (SPT)

– Dense mode uses only source trees

– More scalable than dense mode and usually the better design choice

Shared vs. Source Trees

• Multicast tree determines how traffic is routed from sender to receivers

• Source based trees

– Uses shortest path from sender to receiver

– Dense mode or sparse mode

• Shared trees

– Uses shortest path from sender to Rendezvous Point (RP), then shortest path from RP to receiver

– Sparse mode only

– Used to eliminate flooding and pruning and make routing table more scalable

PIM Sparse Mode Operation

• Discover PIM neighbors & elect DR

• Discover RP

• Tell RP about sources

• Tell RP about receivers

• Build shared tree from sender to receivers through RP

• Join shortest path tree

• Leave shared tree

• Multicast table maintenance

RP Overview

• RP is used as a reference point for the root of the shared tree

• RP learns about sources through unicast PIM

Register messages

– Register tells the RP about an (S,G)

• RP learns about receivers through PIM Join messages

– Tells the RP to add an interface to the OIL for (*,G)

• RP is used to merge the two trees together

PIM Register Message

• As the root of all shared trees, the RP must know about all sources

• When the first-hop router connected to sender hears traffic, a unicast Register message is sent to the RP

– If multiple first-hop routers, only the DR registers

• If RP accepts this message, it acknowledges with Register Stop and inserts (S,G) into the table

• At this point only DR and RP know (S,G)

PIM Join Message

• As the root of all shared trees, the RP must also know about all receivers

• When a last-hop router receives an IGMP Report, a PIM Join is generated up the reverse path tree towards the RP

• All routers in the reverse path install (*,G) and forward the Join hop-by-hop to the RP

• At this point the RP and all downstream devices towards the receiver know (*,G)

Merging the Trees

• Once the RP knows about both sender and receiver…

– RP sends a PIM Join message up reverse path to source

• All routers in the reverse path from the RP to the source install (*,G) with OIL pointing towards RP

• Once (S,G) begins to flow, the tree is built end to end through the RP

Joining the SPT

• The shared tree is made up of two Shortest Path Trees

– SPT from receiver to RP

– SPT from RP to sender

• SPT from receiver to sender may not be the same as the shared tree

– Result is that Shared Tree is not optimal forwarding

• To fix this, last-hop router…

– Joins SPT to source with (S,G) Join

– Leaves the RPT by sending (*,G) Prune to RP

• Can be modified with ip pim spt-threshold {kbps | infinity} [group-list access-list]

Routing Table Maintenance

• Like PIM Dense Mode, PIM Sparse Mode uses State Refresh to ensure that feeds do not timeout

– (*,G) join sent to RP or up SPT to refresh the OIL

• Sparse Prune message can be used to speed up state information timeout if IGMP Leave is heard from end host

RPF Check and Sparse Mode

• RPF check is different in Sparse vs. Dense

• RP performs RPF on…

– Control Plane PIM Register from DR

– Data Plane packets from Source

• Receivers perform RPF check on…

– RP for (*,G) Shared Tree

– Source for (S,G) SPT

Changing the RPF

• RPF is based on unicast routing table

– Implies changing unicast routing affects multicast routing

• RPF can be modified

– Manually with ip mroute

– Dynamically with Multicast BGP

• RPF controls how tree must be built, not how it can be built

• RPF can be verified with…

– show ip rpf

– show ip mroute count

– debug ip mpacket

Learning the RP’s Address

• Without the RP…

– Sources can’t register

– Joins can’t be processed

• All routers must agree on the same RP address on a pergroup basis

– Registers and joins are rejected for invalid RPs

• RP address can be assigned

– Statically

– Dynamically

• Auto-RP

• BSR

Auto-RP

• Legacy Cisco proprietary method

• Uses two functional roles

– Candidate RP(s)

• Device(s) willing to be the RP

• Sends advertisement to MA via 224.0.1.39

– Mapping Agent

• Chooses the RP among candidates and relays this information to the rest of the PIM domain

• Sends advertisement to all routers via 224.0.1.40

Auto-RP Caveats

• Dynamically learned RP mappings are preferred over statically configured ones

• Auto-RP control plane messages are subject to RPF check

• To successfully advertise Auto-RP information

– Mapping Agent must listen for 224.0.1.39

– Everyone must listen for 224.0.1.40

• In PIM Sparse Mode

– Cannot join the Auto-RP groups without knowing where the RP is

– Cannot know where the RP is without joining the Auto-RP groups

– Recursive logic

Auto-RP Solutions

• Default RP assignment

– Assign a static RP for groups 224.0.1.39 and 224.0.1.40

– Defeats the purpose of automatic assignment

• PIM Sparse-Dense Mode

– Dense for groups without an RP

– Sparse for all others

• Auto-RP Listener feature

– Dense for 224.0.1.39/224.0.1.40 only

– Sparse for others

Bootstrap Router

• Standard per PIMv2

– Functionally similar to Auto-RP

• Defines two roles in BSR domain

– RP Candidate

• Analogous to Candidate RP in Auto-RP

• Uses unicast PIM to advertise itself to the Bootstrap Router

– Bootstrap Router (BSR)

• Analogous to Mapping Agent in Auto-RP

• Advertises RP information to other routers with multicast PIM on a hop-by-hop basis

Bidirectional PIM

• Traditional Sparse Mode forms two trees

– Unidirectional SPT from source to RP

– Unidirectional Shared tree from RP to receivers

• Results in (*,G) and (S,G) entries in control plane

– For many-to-many multicast applications, doesn’t scale well

• Bidirectional PIM solves this by only allowing the Shared Tree (*,G) and never a SPT (S,G)

Source Specific Multicast

• IGMPv2 and PIM Sparse mode use (*,G) Joins to discover sources

– This is why the RP is needed

• IGMPv3 and SSM change these rules

– Clients generate (S,G) IGMPv3 Joins

– Routers build SPT directly to S for G

• Removes the need for RP

– Since no RP, no Register messages

– Source discovery is out of band

• Typically uses address range 232.0.0.0/8

MSDP

• RFC 3618 – Multicast Source Discovery Protocol

• Allows Service Provider to use their own internal RPs

– Don’t rely on internal routing of another AS

• MSDP used to communicate between RPs

– Who are the active multicast sources?

• Does not eliminate the need for PIM

How MSDP Works

• RPs in different ASes peer via MSDP

– TCP transport required

• When RP receives PIM Register for (S,G), it informs

MSDP peers using Source Active (SA) message

– Allows other ASes to know what senders there are

• If another RP receives (*,G) Join for G, (S,G) Join sent to S

– MSDP peers are used just for control, not necessarily data plane

Anycast RP

• Uses anycast load balancing to decentralize the placement of RPs

– PIM Register and Join messages go to the closest RP in the topology

– If one RP goes down, convergence is up to IGP

– As long as one anycast RP is up, network is functional

• Anycast RP Design Issues

– For anycast to work, all RPs must share the same information about senders and receivers

– What if PIM Register is sent to one anycast RP, and PIM Join is sent to another?

• Solution: MSDP

How Anycast RP Works

• Anycast RPs assign a duplicate Loopback address and advertise into IGP

• All routers point to anycast RP address

– Could be static or dynamic assignment

• Anycast RPs are MSDP peers using a unique address

– If three of more RPs, usually a mesh group

• When PIM Register is received, MSDP SA is sent to MSDP peers

– Results in synchronization of (S,G) information

CCIE R&S Written Overview: MPLS

MPLS Layer 3 VPNs

MPLS Overview

• Multiprotocol Label Switching

• Open standard per RFC 3031

“Multiprotocol Label Switching Architecture”

• Previously Cisco proprietary Tag Switching

MPLS Overview – Multiprotocol

• Can transport different payloads

• Layer 2

– Ethernet, HDLC, PPP, Frame Relay, & ATM

• Layer 3

– IPv4 & IPv6

MPLS Overview – Label Switching

• Traffic is switched between interfaces based on locally significant label values

• Similar to how a Frame Relay or ATM switch uses input/output DLCIs and VPI/VCIs

MPLS Label Format

• 4 byte header used to switch packets

• RFC 3032 – “MPLS Label Stack Encoding”

– 20 bit Label = Locally significant to router

– 3 bit EXP = Class of Service

– S bit = Bottom of Stack

• If 1, label is last in the stack

– 8 bit TTL = Time to Live

How Labels Work

• MPLS Labels are bound to FECs

Forwarding Equivalency Class

– Mainly IPv4 prefix for our purposes

– Could also be IPv6 prefix or layer 2 circuit

• Router uses MPLS LFIB to switch traffic

– Essentially CEF table + Label

• Switching logic

– If traffic comes in if1 with label X send it out if2 with label Y

MPLS Device Roles

• PE / LER Provider Edge Router / Label Edge Routers

• Connects to Customer Edge (CE) devices

• Receives unlabeled packets and adds label

– AKA “label push” or “label imposition”

• In L3VPN performs both IP routing & MPLS lookups

• P / LSR devices Provider Router / Label Switch Routers

• Connects to PEs and/or other P routers

• Switches traffic based only on MPLS label

Label Push / Pop / Swap

• PE and P routers perform three major operations

Label push

– Add a label to an incoming packet

– AKA label imposition

• Label swap

– Replace a label on an incoming packet

• Label pop

– Remove a label from an outgoing packet

– AKA label disposition

Label Distribution

• Adjacent P/PEs must agree on label per FEC

• Label binding can be dynamic through…

Tag Distribution Protocol (TDP)

• Cisco proprietary and legacy

Label Distribution Protocol (LDP)

Resource Reservation Protocol (RSVP)

• Used for MPLS Traffic Engineering (MPLS TE)

Multiprotocol BGP (MP-BGP)

Label Distribution Protocol (LDP)

• Standard per RFC 3036 “LDP Specification”

• Neighbor discovery

– UDP port 646 to 224.0.0.2

• Neighbor adjacency

– TCP port 646 to remote LDP Router-ID

• Label advertisement

– Advertise FEC for connected IGP interfaces

– Advertise FEC for IGP learned routes

Penultimate Hop Popping (PHP)

• Penultimate means next to last

• Normally last hop must…

– Lookup MPLS Label

– Pop MPLS Label

– Lookup IPv4 destination

• PHP avoids extra lookup on last hop

• Accomplished through Implicit NULL label advertisement for connected prefixes

MPLS Layer 3 VPNs

• RFC 4364 – BGP/MPLS IP Virtual Private Networks (VPNs)

• AKA MPLS L3VPN

• Combines logic of MPLS Tunnels with separation of layer 3 routing information

– PEs learns customer routes from CEs

– PEs advertises CEs routes to other PEs via BGP

– BGP next-hops point to MPLS tunnels

• E.g. Loopbacks of PE routers

How MPLS L3VPNs Work

• MPLS L3VPNs have two basic components

• Separation of customer routing information

– Virtual Routing and Forwarding (VRF) Instance

– Customers have different “virtual” routing tables

• Exchange of customer routing information

– MP-BGP over the MPLS network

– Traffic is label switched towards BGP next-hops

Virtual Routing and Forwarding

• Each VRF has its own routing table

show ip route vrf [name | * ]

• Interfaces not in a VRF are in the global table

show ip route

• VRF and global routes are separate

– Implies addressing can overlap in different VRFs

– Implies VRFs can’t talk to each other because they have no routes to each other

• VRFs without MPLS is considered “VRF Lite”

VRF Aware Routing

• Routing inside a VRF can be through…

– VRF aware static routes

– VRF aware IGPs

• RIP, EIGRP, OSPF, or IS-IS

– MP-BGP

– Policy Routing

VRF Lite vs. MPLS VPNs

• In VRF Lite all devices in transit must carry all routes

– Same as normal IP routing logic

• In MPLS VPNs only PE routers need customer routes

• Accomplished through…

VPNv4 Route

• RD + Prefix makes VPN routes globally unique

MPLS VPN Label

• PE routers exchange label for each customer route via VPNv4

Transport Label

• Label towards PE’s BGP next-hop

Multiprotocol BGP

• RFC 4364 “BGP/MPLS IP Virtual Private Networks (VPNs)”

– MP-BGP defines AFI 1 & SAFI 128 as VPN-IPv4 or “VPNv4”

• 8 byte Route Distinguisher (RD)

– Unique per VPN or per VPN site

– ASN:nn or IP-address:nn

• 4 byte IPv4 address

– Unique per VPN

– Implies globally unique routes

Controlling VPNv4 Routes

• Route distinguisher used solely to make route unique

• New BGP extended community “route-target” used to control what enters/exits VRF table

• “export” route-target

– What routes will be go from VRF into BGP

• “import” route-target

– What routes will go from BGP into VRF

• Allows granular control over what sites have what routes

– “import map” and “export map” allow control on a per prefix basis

VPNv4 Route Target

• 8 byte field per RFC 4360 “BGP Extended Communities Attribute“

• Format similar to route distinguisher

– ASN:nn or IP-address:nn

• VPNv4 speakers only accept VPNv4 routes with a route-target matching a local VRF

– Route reflection exception

– no bgp default route-target filter

• VPNv4 routes can have more than one route target

• Allows for complex VPN topologies

– Full mesh

• Import and export same everywhere

– Hub and Spoke

• Spokes import only hub’s routes

– Central services

• Multiple VPNs can import routes from a central site or from a central server

– Management VPNs

• Management Loopback on CE routers can be exported into special management VPN

 

Some screencaps from the MPLS Layer 3 VPN Overview videos:

IMG_0441 IMG_0443 IMG_0445 IMG_0446 IMG_0448 IMG_0449 IMG_0451 IMG_0463