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)


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


• 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


• 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


• 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




• Network Address Translation



IP Application Services


• Enhanced Object Tracking

• NetFlow


Management Services


• 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


• 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


– 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


• 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:


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!!


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

– (–

• Includes reserved ranges

– Link-local Addresses

• ( –

– Source Specific Multicast

• ( –

– Administratively Scoped

• ( –

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


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

– (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



• Legacy Cisco proprietary method

• Uses two functional roles

– Candidate RP(s)

• Device(s) willing to be the RP

• Sends advertisement to MA via

– Mapping Agent

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

• Sends advertisement to all routers via

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

– Everyone must listen for

• 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 and

– 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 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


• 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