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).

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

CCIE R&S Written Overview: IPv6

IPv6 Overview

• Main motivation for IPv6 is lack of IPv4 address space

• IPv4 uses 32-bits (4 bytes)

– 2^32 = 4,294,967,296 max addresses

• IPv6 uses 128-bits (16 bytes)

– 2^128 = 34,028,236,692,938,463,463,374,607,431,770,00 0,000+

IPv4 vs. IPv6 Addressing Format

• IPv4 Dotted Decimal

– 1.2.3.4

– Each place denotes 1 byte

• IPv6 Hexadecimal

– XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX

– Two characters = one byte

IPv6 Address Space

• Four main address types

– Global Unicast

• 2000… – 3FFF…

– Unique Local

• FC00…

• Deprecates Site Local (FEC0)

– Link Local

• FE80…

– Multicast

• FF…

Modified EUI-64 Addressing

• IPv6 host addresses are generated from interface MAC address

• MAC address is 48-bits

• IPv6 host address is 64-bits

• Extra 16 bits derived as follows:

– MAC 1234.5678.9012

– Invert 7th most significant bit

• 1034.5678.9012

– Insert “FFFE” in middle

• 1034:56FF:FE78:9012

IPv6 Address Resolution

• Ethernet

– ICMPv6 ND replaces ARP

• NBMA

– Static resolution on multipoint interfaces

– Inverse Neighbor Discover not implemented

ICMPv6 Neighbor Discovery

• ICMPv6 ND

• Replaces IPv4 ARP

• NS – Neighbor Solicitation

– Ask for information about neighbor

• NA – Neighbor Advertisement

– Advertise yourself to other neighbors

• RS – Router Solicitation

– Ask for information about local routers

• RA – Router Advertisement

– Advertise yourself as an active router

• Send neighbor solicitation to solicited node multicast

– FF02:0:0:0:0:1:FF00::/104 + 24 low-order bits

• If no reply address is unique

– Duplicate Address Detection (DAD)

• Send unsolicited neighbor advertisement to announce yourself

– Sent to all hosts multicast

• FF02::1

• Essentially the same as 255.255.255.255

IPv6 Routing Overview

• IPv6 unicast routing off by default

– ipv6 unicast-routing

• Dynamic routing through

– RIPng

– OSPFv3

– EIGRPv6

– IS-IS

– BGP

• Dynamic information recurses to remote link-local address

– Layer 3 to layer 2 resolution on multipoint NBMA medias

IPv6 Static Routing

• Same static routing implications as IPv4

– To next-hop

• Resolve next-hop

– To multipoint interface

• Resolve final destination

– To point-to-point interface

• No resolution required

IPv6 Routing

• RIPng, OSPFv3, & EIGRPv6

– Use separate processes

• BGP & IS-IS

– Use the same process

– Different Address families

RIPng Overview

• RFC 2080 – RIPng

• Similar in operation to RIPv1 / RIPv2

• UDP port 521 multicast to FF02::9

• Configuration

– Interface level ipv6 rip [process] enable

– Automatically enables global process

• Split-horizon enabled globally

– no split-horizon on multipoint NBMA

EIGRPv6 Overview

• Similar in operation to IPv4 EIGRP

• IP protocol 88 multicast to FF02::A

• Configuration

– Interface level ipv6 eigrp [ASN]

– Process level no shutdown

OSPFv3 Overview

• RFC 2740 – OSPFv3

• Similar in operation to OSPFv2

• Router-id is IPv4 address

– Use router-id command if no IPv4 configured

• Configuration

– Interface level ipv6 ospf [process-id] area [area-id]

– Automatically enables global process

OSPFv3 LSAs

• Most LSAs are the same as in OSPFv2

– LSA 1 – Router LSA

– LSA 2 – Network LSA

– LSA 3 – Inter-Area-Prefix-LSA

• Same as OSPFv2 Summary LSA

– LSA 4 – Inter-Area-Router-LSA

• Same as OSPFv2 ASBR Summary LSA

– LSA 5 – AS-External-LSA

– LSA 7 – Type-7-LSA

• Two new LSAs

– LSA 8 – Link-LSA

• Link-Local scope

• Used for link-local next-hop calculation

– LSA 9 – Intra-Area-Prefix-LSA

• Area scope

• Used to advertise global addresses of connected links

• LSA 1 & 2 are still used to build the graph of the network, but are now decoupled from the actual addresses on the links

OSPFv3 Network Types

• Same network types as OSPFv2

– Broadcast

• DR/BDR Election

– Non-broadcast

• DR/BDR Election

• Unicast updates to link-local address

– Point-to-point

– Point-to-multipoint

– Point-to-multipoint non-broadcast

• Unicast updates to link-local address

BGP for IPv6 Overview

• Same process for IPv4 and IPv6

– Uses address-family configuration

• Normal BGP rules apply

– Requires underlying IGP transport

– iBGP loop prevention

• Don’t advertise iBGP learned routes to other iBGP neighbors

• Exception through route-reflection / confederation

– EBGP loop prevention

• Don’t accept routes with your own AS in the path

– Same best-path selection process

Tunneling IPv6 over IPv4

• Static tunnels

– GRE

• Default tunnel mode

– IPv6IP

• Less overhead, but no CLNS transport

• Automatic tunnels

– IPv4 Compatible Tunnel

• IPv6 next-hop is IPv4 address, e.g. ::192.168.1.1

– Automatic 6to4

• Imbeds IPv4 address into IPv6 prefix to provide automatic tunnel endpoint determination

– ISATAP

• Automatic host to router and host to host tunneling

CCIE R&S Written Overview: BGP

BGP Overview

• Border Gateway Protocol

– Standards based Exterior Gateway Protocol (EGP)

– RFC 4271 A Border Gateway Protocol 4 (BGP-4)

• Path Vector Protocol

– Uses multiple “attributes” for inter-domain routing between Autonomous Systems

BGP Features

• “Classless” Protocol

– Supports VLSM and summarization

• Highly Scalable

– IGPs can scale to thousands of routes

– BGP can scale to hundreds of thousands of routes

– Current Global (Internet) BGP table ~ 400,000 routes

• Highly Stable

– Internet routing table never converges

– BGP stable enough to handle routing and decision making at the same time

• Used to Enforce Routing Policy

– IGP uses link cost for routing decision

• Effective traffic engineering nearly impossible with IGP

– BGP uses attributes of the route itself

• Traffic engineering feasible and simple to implement

• Uses Autonomous System Number (ASN) to identify process

– BGP ASNs originally 2-byte field

• Values 0-65535

– RFC 4893 defines 4-byte ASNs

• 65535.65535 “AS Dot” notation

• 0.[0-65535] denote original 2-byte ASNs

• Doesn’t use its own transport

– Uses unicast TCP at port 179

• BGP peers are not discovered

– Manually configured via neighbor statement

• BGP neighbors do not have to be connected

– IGP is always on a link-by-link basis

– BGP is a logical peering over TCP

– Implies that BGP always needs IGP underneath

• BGP has different types of neighbors

– External BGP vs. Internal BGP

• Path vector attributes

– Choose BGP bestpaths to build routing table

• Control Plane Security

– Supports TCP MD5 Signature Option

• Extensible

– Multiprotocol BGP extensions beyond normal IPv4 Unicast routing

Establishing BGP Peerings

• Like IGP, first step in BGP is to find neighbors to exchange information with

• Peering establishment and maintenance uses four types of packets

– OPEN

– KEEPALIVE

– UPDATE

– NOTIFICATION

BGP OPEN Message

• Used to negotiate parameters for peering

• Includes…

– BGP version

• Should be 4

– Local ASN

– Local Router-ID

– Hold time

• Negotiated to lowest requested value

– Options

• AKA “capabilities”

BGP KEEPALIVE Message

• Used for dead neighbor detection

• If hold time = 0, keepalives disabled

BGP UPDATE Message

• Used to advertise or withdraw a prefix

• Includes..

– Withdrawn routes

• List of routes that should be discarded

– NLRI

• Route being advertised

– Path vector attributes

• Attributes of route being advertised

• Used for bestpath selection

BGP NOTIFICATION Message

• Used to convey error messages

• After notification sent, BGP session closed

• Examples

– Unsupported Version Number

– Unsupported Optional Parameter

– Unacceptable Hold Time

– Hold Timer Expired

BGP Peering Types

• External BGP (EBGP) Peers

– Neighbors outside my Autonomous System

• Internal BGP (iBGP) Peers

– Neighbors inside my Autonomous System

• Update and path selection rules change depending on what type of peer a route is being sent to/received from

EBGP Peerings

• Peers in different ASes

• Usually directly connected neighbors

– e.g. DS3 Frame Relay link to ISP

• Can be “multihop”, but TTL defaults to 1

• Uses AS-Path attribute for loop prevention

– If I receive an update from an EBGP peer with my own ASN in the AS-Path, discard it

iBGP Peerings

• Peers in the same AS

• Many times not directly connected

– Implies IGP needed to provide TCP transport

• Loop prevention via route suppression

– Routes learned from an iBGP peer cannot be advertised on to another iBGP peer

– Implies that all routers running BGP within the AS must peer with each other

• i.e. “iBGP full mesh” of n*(n-1)/2 peerings

iBGP Full Mesh

• Can be fixed with two exceptions

– Route Reflectors

• Same logic as OSPF DR/IS-IS DIS

– Confederation

• Split the AS into smaller Sub-ASes

BGP Peering Redundancy

• BGP peering is based on TCP reachability to peer address

• If peer address is unreachable, peering goes down – e.g. if IP address of Serial link is used for peering and Serial link is down, peer goes down

• Using Loopback addresses for peerings allows rerouting around link failures and adds redundancy – e.g. as long as any link is up, Loopback can be reached

• Can also be used for load balancing

Building the BGP Table

• Once peerings are established, UPDATE messages are exchanged to advertise NLRI and build the BGP table

• NLRI can be originated by…

– Network statement

– Redistribution

– Aggregation

– Conditional Route Injection

• Unlike IGP, networks do not have to be directly connected to be advertised, they only have to be in the routing table – e.g. prefixes in local routing table learned via OSPF can be advertised with BGP network statement

BGP Path Vector Attributes

• UPDATE includes path vector attributes for a route

• Attributes fall into different categories…

– Well-known vs. optional

• Well-known must be implemented

• Optional may or may not be implemented

– Mandatory vs. discretionary

• Mandatory must be present in update

• Discretionary may or may not be present

– Transitive vs. non-transitive

• Transitive passes between EBGP and iBGP neighbors

• Non-transitive passes only between iBGP neighbors

• Well-known mandatory

– Next-hop

– AS-Path

– Origin

• Well-known discretionary

– Local Preference

– Atomic Aggregate

• Optional transitive

– Aggregator

• Optional non-transitive

– MED

BGP Bestpath Selection

• Once updates are exchanged, path selection begins

– Bestpath selection algorithm compares path vector attributes and elects one route as “best” for each prefix

– Only best route is sent to the routing table

– Only best route can be advertised to other BGP peers

– Multipath can occur, but in very strict circumstances

BGP Bestpath Selection Order

• Algorithm runs top down until a deciding match occurs

• Cisco IOS selection order is…

– Weight (highest)

– Locally significant Cisco proprietary attribute

– Local Preference (highest)

– Locally originated routes

– AS-Path (shortest)

– Origin (lowest)

– MED (lowest)

– EBGP learned routes over iBGP learned routes

– Smallest IGP metric to next-hop value

• Other tie-breaking checks occur if no bestpath

– Oldest route, lowest Router-ID, lowest interface IP address, etc.

Manipulating BGP Bestpath Selection

• Vector attributes can be manually modified to define different routing policy for different routes

– E.g. control inbound/outbound traffic flow on a per-prefix basis

• Attributes typically modified are…

– Weight

– Local-Preference

– AS-Path

– MED

• Inbound routing policy affects outbound traffic

– Change weight or local-pref in to affect traffic out

• Outbound routing policy affects incoming traffic

– Change AS-Path or MED to affect traffic in