Configuring Campus Switches To Support Voice and Video Applications

CCNP 3 v4 Module 8
Configuring Campus Switches to

Support Voice and Video
Applications
2003, Cisco Systems, Inc. All rights reserved.
Objectives
Accommodating Voice Traffic on Campus

Switches
Configuring IP Multicast
Overview
Campus networks carry a variety of data
with diverse purposes and impacts on
resources.
Proper design and configuration efforts
will ensure that voice, video and data
traffic efficiently coexist on a single
Campus Infrastructure.
Cisco Infrastructure
Cisco recommends an end-to-end single

vender (Cisco) solution.
This way, each new application such as

video, Web, or telephony represents just
another media type over the same
infrastructure.
Tasks such as QoS configuration and
network upgrades are made easier by using
a single vendor.
IP Telephony Integration
Voice VLANs
Cisco Catalyst switches offer a "voice VLAN"

feature.
The voice VLAN, also known as an auxiliary VLAN,

provides automatic VLAN association for IP
phones.
Voice traffic is on a specific VLAN, and IP

subnet even though voice and data co-exist on
the same physical infrastructure.
Voice VLANs
When a phone is connected to the switch, the switch sends necessary

voice VLAN information to the IP phone.
Voice VLANs and Data VLANs
Placing phone traffic onto a distinct

VLAN allows the phone traffic to be
segmented from the data traffic.
QoS or security policies can be enforced

specifically for the traffic traversing the
phone VLANs without affecting the data
traffic.
Connecting a PC to the IP Phone
To save switchport density and cable runs, a PC can be

connected to the integrated switch of the IP Phone.
In order for the device and the phone to communicate, one of

the following must be true:
They both use the same Layer 2 frame type.
The phone uses 802.1p frames and the device uses

untagged frames.
The phone uses untagged frames and the device uses

802.1p frames.
The phone uses 802.1Q frames, and the voice VLAN equals
the native VLAN.
Connecting a PC to the IP Phone
10
Voice Design Considerations
Deploying IP telephony in the enterprise campus requires

the implementation of various features particular to each
submodule.
Within the Building Access submodule, these features

support IP telephony:
Voice VLANs
802.1p/Q
Hardware support for multiple output queues
Hardware support for in-line power to IP phones
PortFast
Root Guard
Unidirectional Link Detection (UDLD)
UplinkFast
11
IP Telephony on the Network
IP telephony places strict requirements on

the network infrastructure.
Most IP telephony installations are built

on an existing network infrastructure.
To support voice traffic the network may
require enhancements and upgrades with
priority given to voice traffic.
12
Campus Infrastructure Considerations
What features are required for each network device?
Can the physical plan support IP Telephony?
PoE on the switch or a separate inline power patch panel,

power bricks
Is adequate bandwidth available?
Cat5e minimum, available switchports and wall jacks
How will the phones be powered?
VLAN configuration, QoS, inline power
What other bandwidth intensive applications are running?
Will a VoIP implementation require an complete network

overhaul?
13
Quality of Service
QoS is the application of features and

functionality required to actively manage
and satisfy networking requirements of
applications sensitive to loss, delay, and
delay variation (jitter).
QoS allows preference to be given to

critical application flows for the available
bandwidth.
14
QoS and Voice Traffic
Congestion and latency can be caused by speed

mismatches, many-to-one switching fabrics and
aggregation.
When packets are dropped due to network

congestion, these packets must be retransmitted,
causing further congestion.
QoS ensures that prioritized voice traffic is not subject

to the existing network congestion and latency.
15
Switchport Commands for VoIP QoS
16
Switch Configuration Example

Switch(config)#interface fastethernet 0/4
Switch(config-if)#switchport voice vlan 110
Switch(config-if)#mls qos trust cos
Switch(config-if)#mls qos trust device cisco-phone
Switch(config-if)#ctrl-Z
Switch#show interfaces fastethernet 0/4
Switch#show mls qos interface fastethernet 0/4
FastEthernet0/4
trust state: trust cos
trust mode: trust cos
COS override: dis
default COS: 0
pass-through: none
trust device: cisco-phone
17
Step-by-Step Configuration
18
QoS by Network Layer
19
Delay and Packet Loss
Delay (or latency) is the amount of time that it takes a packet

to reach the receiving endpoint from the sending endpoint.
This time period is termed the "end-to-end delay"
End-to-end delay can be broken into two areas:
Fixed network delay
Variable network delay
Fixed network delay includes encoding and decoding time

(for voice and video), as well as the amount of time required
to traverse the media en route to the destination.
Variable network delay refers to network conditions, such as

congestion, that may affect the overall time required for
transit.
20
Types of Delay
Packetization delay The amount of time that it takes to

segment data, sample and encode signals, process data,
and turn the data into packets
Serialization delay The amount of time that it takes to

place the bits of a packet encapsulated in a frame, onto the
physical media
Propagation delay The amount of time that it takes to

transmit the bits of a frame across the physical wire
Processing delay The amount of time that it takes for a

network device to take the frame from an input interface,
place it into a receive queue, and then place it into the
output queue of the output interface
Queuing delay The amount of time that a packet resides in

the output queue of an interface
Delay variation Delay variation (or jitter) is the difference

in the end-to-end delay between packets.
21
Classification and Marking
22
Layer 2 Marking: 802.1p and CoS
23
Layer 3 Marking: ToS, IP Precedence, DSCP
24
Best Effort
Best-effort is a single service model in which an application

sends data whenever it must, in any quantity, without
requesting permission or first informing the network.
Best-effort service is suitable for a wide range of networked

applications such as general file transfers, e-mail and Web
browsing.
25
Differentiated Services
The Differentiated Services or DiffServ is an

IETF architecture standard.
This architecture specifies that each packet

is classified upon entry into the network.
The classification is carried in the IP packet
header, using either the IP precedence or the
preferred Differential Services Code Point
(DSCP).
26
Precedence and DSCP
Represented using the first three (precedence) or six (DSCP) bits of the
Type of Service (ToS) field.
The first 3 DSCP bits are the class selector bits
The second 3 DSCP bits are the drop precedence bits
Classification can also be carried in the Layer 2 frame in the form of

the Class of Service (CoS) field embodied in ISL and 802.1Q frames.
27
DSCP Code Points

Assured Forwarding - AF
Class Selector - Priority
Expedited Forwarding - EF
Drop Precedence - Priority
Internetwork Control
Class 6
110
48 55
Network Control
Class Selector Bits
Class 5
101
40 47 (46)
Class 7
111
56 63
28
Layer 2 and 3 DiffServ
29
Layer 2 and QoS
At the Datalink layer a raw Ethernet frame has

no fields to signify its QoS requirements.
If QoS marking is required, then ISL or

802.1Q/p must be used as these provide a
three-bit Class of Service (CoS) field.
30
Layer 3 and QoS
At the Network layer an IP packet contains a one

byte Type of Service (ToS) field, of which the first
three bits form the IP-Precedence field and the
first six bits form the DSCP fields.
Either of these can be used to signify the QoS

requirements of an IP packet but not both.
DSCP has precedence
31
QoS, CoS and ToS

CoS
ToS IP Precedence
ToS DSCP
32
Modular QoS CLI (MQC)
The Modular QoS Command Line Interface or MQC is

central to Ciscos model for implementing IOS based QoS
solutions.
The MQC breaks down the tasks associated with QoS into
modules that:
Identify traffic flows.
Classify traffic flows as belonging to a common class of

QoS.
Apply QoS policies to that class.
Define the interfaces on which the policy should be

enforced.
The modular nature of MQC allows the reuse of common

traffic classes and policies.
33
Creating Class-maps
The class-map command is used to define a traffic class.
The purpose of a traffic class is to classify traffic that

should be given a particular QoS.
A traffic class contains three major elements:

1. a name - cisco
2. a series of match commands - match
3. and if more than one match command exists in the traffic class,
how to evaluate these match commands match-all | matchany
34
Class-map Commands
switch(config)#ip access-list standard test
Switch(config)#class-map match-any cisco
Switch(config-cmap)#match access-group name test
Switch(config-cmap)#match interface fastethernet 0/1
On the Catalyst 3550 and 6500 the Modular QoS CLI

allows multiple traffic classes to be configured as a
single traffic class, such as nested traffic classes,
or nested class maps.
This nesting can be achieved with the use of the

match class-map command.
35
Policy-maps
The policy-map command is used to create a traffic

policy.
The purpose of a traffic policy is to configure the QoS

features to be associated with the traffic that has been
classified in the traffic class.
Traffic policy contains three elements:

1. Policy Name
2. Traffic class specified with the class command
3. QoS policies to be applied to each class
36
Policy and Class-map Commands

Switch(config)#policy-map policy1
Switch(config-pmap)#class cisco
Switch(config-pmap-c)#bandwidth 3000
Switch(config-pmap-c)#exit
Switch(config-pmap)#class class-default
Switch(config-pmap-c)#bandwidth 2000
Switch(config-pmap)#exit
The service policy command is used to attach

the traffic policy to an interface.
Switch(config)#interface fastethernet 0/1

Switch(config-if)#service-policy output policy1
Switch(config-if)#exit
Apply to outgoing packets

37
Classification at Access Layer
In order to be effective, QoS should be implemented

end-to-end within a network as soon as possible at the
network edge or access layer.
Frames and packets can be marked as important by

using Layer 2 Class of Service (CoS) settings in the User
Priority bits of the 802.1p portion of the 802.1Q header
or
The IP Precedence/Differentiated Services Code Point

(DSCP) bits in the Type of Service (ToS) Byte of the IPv4
header
38
Trust Do you trust me?
In order to take advantage of COS at the edge then

the access layer device must trust the QoS
devices/applications it is connected to.
The default action is for a switch with QoS features

activated not to trust edge devices that have
written CoS features into the frame.
Any frames that enter the switch will have their CoS rewritten to the lowest priority of zero.
If the edge device can be trusted then the switch

will switch the frame without changing the Cos
setting.
39
Trusted vs. Untrusted Ports
Trusted
Untrusted
Trusted
40
QoS Trust Boundaries
41
Class of Service at the Switch
Depending on the switch model, it may be necessary to

first activate QoS:
switch(config)#mls qos
This command is required on both the Catalyst 3550 and

the Catalyst 6500.
The Catalyst 2950 has QoS enabled by default.
The trust is configured on the switch port using the

command:
switch(config-if)#mls qos trust cos
42
Remember Native VLAN?
If an untagged frame arrives at the switch port,

the switch will assign a default CoS to the frame
before forwarding it. (native VLAN)
By default untagged frames are assigned a CoS

of zero.
This can be changed using the interface

configuration command:
switch(config-if)#mls qos cos [cos-value]
Where [cos-value] is a number between 0 and 7.
Traffic that passes through the port will be

automatically tagged with the new CoS value.
43
Override the CoS Field
In some cases it may be desirable not to trust any

CoS value that may be present in frames sourced
from an edge device.
For this reason, it is possible to use the override

parameter to tell the switch to ignore any existing
CoS value that may be in the frame and apply the
default value.
switch(config-if)#mls qos cos [cos-value]

Switch(config-if)#mls qos cos override
This will re-write the CoS value for any frame entering the
switch port to the default setting.
44
MAC ACL to Assign DSCP
It is not always possible to classify the CoS of a

frame, based on an ingress port.
The ingress port may be attached to a hub or a

simple workgroup switch that does not support
QoS.
This hub or switch may be connecting to multiple
workstations that all require different CoS values.
Differing types of devices may be on the same subnet
(IP ACL will not work)
45
MAC ACL to Assign DSCP
Not all frames can be assigned a CoS based on

ingress port
46
Configure a MAC ACL
However, in the QoS context, the permit and deny

actions in the access control entries (ACEs) have
different meanings than with security ACLs:
If a match with a permit action is encountered, known

as the first-match principle, the specified QoS-related
action is taken.
If a match with a deny action is encountered, the ACL

being processed is skipped, and the next ACL is
processed.
If no match with a permit action is encountered and all

the ACLs have been examined, no QoS processing
occurs on the packet.
Switch(config)#mac access-list extended [name]

47
MAC ACL Example

Switch(config)#mac access-list extended receptionph
Switch(config-ext-macl)#permit host 000.0a00.0111 any
Switch(config-ext-macl)#exit
Switch(config)#
Switch(config)#class-map match-all ipphone
Switch(config-cmap)#match access-group name receptionph
Switch(config-cmap)#exit
Switch(config)#policy-map inbound-accesslayer
Switch(config-pmap)#class ipphone
Switch(config-pmap-c)#set ip dscp 40
Switch(config)#interface range fastethernet 0/1 - 24
config-if-range)#service-policy input inbound-accesslayer
48
Using an IP ACL
Using the Modular QoS Command Line Interface (MQC) it is

possible to classify traffic based on its IP or TCP properties
In this FTP example, an IP ACL is used to identify the packets:
Switch(config)#ip access-list extended 100

Switch(config-ext-nacl)#permit tcp any any eq ftp
Traffic is classified as reducedservice if it is permitted by the

access list.
Switch(config)#class-map reducedservice
Switch(config-cmap)#match access-group 100
49
Policing and Marking

out of profile
Traffic policing involves placing a constraint on

the maximum traffic rate.
When the traffic rate reaches the configured

maximum rate, excess traffic is dropped or
remarked to a lower DSCP value
50
Policing Flow Chart

Packets that exceed the limits are said
to be out of profile or nonconforming.
51
Committed Access Rate (CAR)
CAR implements both classification services and policing

through rate limiting.
The classification services of CAR allow traffic flow limits

to be placed on incoming traffic.
These limits specify the average rate, rate-bps, and the

burst rate, burst-byte, that is permissible.
Traffic that is nonconforming either because it exceeds

the average rate or the burst rate specified can be
marked down in terms of DSCP.
Traffic is then dropped based on the new DSCP value as

part of congestion avoidance
52
CAR Configuration
The policy-map command that enables CAR is

'police' and is specified for a given class of
traffic.
Switch(config)#police [rate-bps] [burst-bps] [exceed-action

{drop | policed-dscp-transmit}]
In order to mark down the DSCP value of

nonconforming traffic, the switch uses a map
to translate between the initial DSCP value and
the marked down DSCP.
53
Configuring Classification using CAR
Create an IP standard ACL to permit traffic,

this will be used to match traffic.
Traffic that matches this ACL will receive a

DSCP value in the incoming packet is trusted
In the following example, traffic that exceeds

an average traffic rate of 48000 bps and a
normal burst size of 8000 bytes is marked
down.
54
CAR Example drop

Switch(config)#access-list 1 permit 10.1.0.0 0.0.255.255
Switch(config)#class-map ipclass1
Switch(config-cmap)#match access-group 1
Switch(config-cmap)#exit
Switch(config)#policy-map flow1t
Switch(config-pmap)#class ipclass1
Switch(config-pmap-c)#trust dscp
Switch(config-pmap-c)#police 48000 8000 exceed-action drop
Switch(config-pmap)#exit
Switch(config)#interface gigabitethernet0/1
Switch(config-if)#service-policy input flow1t
55
Scheduling
The process of assigning packets to one of

multiple queues, based on classification, for
priority treatment through the network is called
scheduling.
Examples of different scheduling techniques are:
First In First Out - FIFO
Weighted Fair Queuing - WFQ
Class Based Weighted Fair Queuing - CBWFQ
56
First In First Out
The simplest form of scheduling and the default for

interfaces 2 Mbps and faster.
The FIFO queue offers no preferential service for traffic,

packets are forwarded in the order they are received.
57
Weighted Fair Queuing
Weighted Fair Queuing (WFQ) classifies traffic entering the queue

based on traffic flows.
Classification can be based on source and destination addresses,

the protocol and TCP port numbers
Each flow is given its own queue.
WFQ services each of these queues on a round robin basis.
Every flow of traffic has an equal share of the available bandwidth
In some cases, the weight needs to be modified so that WFQ

does not share bandwidth on a round-robin basis, but is
influenced by the class or priority of the traffic in the flow.
58
Weighted Fair Queuing
Weighted fair queuing is activated on

a Layer 3 interface:
Router(config)#interface serial 0/0
Router(config-if)#fair-queue
59
WFQ and IP Precedence
WFQ is IP precedence-aware.
WFQ can detect higher priority packets marked

with precedence and schedule them faster.
Higher priority packets are assigned a lower
weight and a greater share of the total bandwidth
In order for WFQ to be truly fair, every flow

would have to have the same precedence.
60
Weight and Precedence
Weight is calculated inversely to precedence.
The higher the precedence, the lower the weight
W=K/precedence + 1
K = 4096 with Cisco IOS 12.0(4)T and earlier
releases, and 32384 with 12.0(5)T and later
releases.
Bandwidth is proportional to precedence.
Each flow will get precedence + 1 parts of the link
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 = 36
Therefore, precedence 0 traffic will get 1/36 of
the bandwidth, precedence 1 traffic will get
2/36, and precedence 7 traffic will get 8/36.
61
Class Based WFQ (CBWFQ)
Allows for user defined traffic classes using match

criteria including protocols, ACLs, and input
interfaces.
CBWFQ provides for up to 64 classes -- WFQ is limited
to 7 classifications (queues)
Once a class has been defined according to its

match criteria, characteristics can be assigned to it.
To characterize a class, bandwidth, weight, and
maximum packet limit are specified.
62
CBWFQ Class Characteristics
The bandwidth assigned to a class is the

guaranteed bandwidth delivered to that class
during congestion.
After a queue has reached its configured packet

limit, queuing of additional packets to the class
causes further packets to be dropped.
A default class can be configured with a

'bandwidth' policy-map class configuration
command, for all unclassified traffic
This traffic is put into a single FIFO or WFQ queue and

given treatment according to the configured bandwidth.
63
CBWFQ Example
64
Configuring CBWFQ
Router(config)#mls qos
Router(config)#class-map prioritytraffic
Router(config-cmap)#match dscp 50
Router(config)#policy-map prioritybw
Router(config-pmap)#class class-default fair-queue
Router(config-pmap-c)#class prioritytraffic bandwidth percent 40
queue-limit 200
Router(config)#interface gigabitethernet0/1
Router(config-if)#service-policy output prioritybw
65
END PART 1
PART 1 STOP HERE
66
Multicast Traffic
IP Multicast is an efficient means of delivering

bandwidth intensive content to many hosts over
a single IP flow.
Multimedia such as streaming video
IP Multicast is the transmission of an IP data

frame to a host group that is defined by a single
IP Multicast address.
Multicasting conserves bandwidth by replicating

packets only onto segments or individual switchports
where listening devices exist
67
IP Multicast
68
IP Multicast Characteristics
Delivers a multicast datagram to a destination multicast

address (also known as a multicast group) with the same
best-effort reliability as a regular unicast IP datagram
Allows group members to join and leave dynamically
Supports all host groups regardless of the location or

number of members
Supports the membership of a single host in one or more

multicast groups
Can carry multiple data streams to a single group address
Can use a single group address for multiple host

applications
Multicast server does not keep track of the number of

recipients
69
Multicast at the Transport Layer
Multicast traffic is handled at the transport

layer using the User Datagram Protocol
(UDP).
Because of the simplicity of UDP, data

packet headers contain fewer bytes and
consume less network overhead than TCP.
70
IP Multicast Group Membership
IP multicast relies on the concept of group

members and a group address.
The group address is a single IP Multicast address

that is the destination address of all packets sent
from a source.
Receiving devices join that group and listen for

packets with the destination IP address of the
group.
Essentially, the destination address is the group

since all multicast group members will receive data
at that destination address.
71
IP Multicast Group Example
72
Multicast Addresses
Multicast uses Class D IP address space.

Class D = 224.0.0.0 239.255.255.255
Class D address consists of 1110 as the high-order bits in

the first octet, followed by a 28-bit group address.
The last 28 bits of the IP address identify the multicast
group ID.
Multicast addresses may be dynamically or statically
allocated.
Multicast IP addresses map directly to a range of MAC

addresses which allows an IP multicast group to be
translated to a group of hosts on an Ethernet LAN.
Every host that is a member of that multicast group will
begin listening for traffic at the MAC address that
matches the IP multicast address.
http://www.iana.org/assignments/multicast-addresses
73
Well-known Layer 3 Multicast Address

224.0.0.1
All multicast-capable hosts on the segment
224.0.0.2
All multicast-capable routers on the segment
224.0.0.4
All DVMRP routers on the segment
224.0.0.5
All OSPF routers
224.0.0.6
All OSPF designated routers
224.0.0.9
All RIPv2 routers
224.0.0.13
All PIM routers
74
IP Multicast to MAC Address Mapping
01-00-5e identifies the frame as multicast
Only the MAC address range from 0100.5e00.0000 through

0100.5e7f.ffff is the available for carrying multicast frames.
75
Multicast MAC Calculation
76
The Missing 5 bits
Because the first 5 bits of the lower 28

bits are unused, not all multicast IP
address to multicast MAC address
mappings are unique.
This means that there are 25 IP addresses
that will map to any one MAC address.
224 239. X128 . X . X
0000.0
8 4 2 1.128
77
IP to MAC Address Examples

224.10.8.5 = 0100.5e0a.0805
224.138.8.5 = 0100.5e0a.0805
225.10.8.5 = 0100.5e0a.0805
239.138.8.5 = 0100.5e0a.0805
239.138.24.5 = 0100.5e0a.1805
224.74.9.13 = 0100.5e4a.090d
As long as the last 23 bits do not change, you will always get the same
MAC address.
However, if we change any of the last 23 bits, we get a different MAC.
78
Reverse Path Forwarding
Multicast-capable routers create distribution

trees that control the path that IP multicast
traffic takes through the network.
Multicast traffic is forwarded away from the source

rather than toward the receiver.
This is called Reverse Path Forwarding (RPF)
Multicast-capable routers create distribution

trees that control the path that IP multicast
traffic takes through the network, away from
the source.
79
Reverse Path Forwarding
Traffic flows away from the source.
80
Multicast Distribution Trees
Multicast distribution trees fall into the

categories:
1. Source based trees
2. Shared trees
81
Source Distribution Trees
A source tree is the simplest form of a multicast

distribution tree.
A source tree has its root at the source and branches

forming a tree through the network toward the receivers.
shortest path tree (SPT)
An SPT is identified by a special notation of (S, G),

where S is the IP address of the source and G is the
multicast group address to which receivers belong.
Source trees are used for PIM Dense Mode (PIM-DM)
82
Source Distribution Tree

(S,G) Notation
(192.168.1.1, 224.1.1.1)
83
Shared Distribution Trees
Unlike source trees that have their root at

the source, shared trees use a single
common root placed at a chosen point in
the network.
This shared root is called a "rendezvous
point (RP)."
Multicast traffic is then forwarded from the
RP to reach all of the receivers.
84
Shared Distribution Tree

Multicast traffic from the sources (hosts A and D)
travels to the RP (router D) and then down the
tree to the two receivers (hosts B and C).
(*, G) Notation
85
Source Trees vs. Shared Trees
Source trees have the advantage of creating the optimal

path between the source and the receivers.
This guarantees the minimum amount of network
latency.
However, the routers must maintain path information for
each source which can quickly drain the routers
resources.
Shared trees consume less memory resources from the

router since fewer paths are created.
However, since one shared distribution tree is used for
all source to receiver paths, the path any one source
uses may not be optimal.
Multicast traffic must first get to the rendezvous point
and then from the RP to the receiver.
86
Reverse Path Forwarding (RPF) Check
In multicast forwarding, the source sends traffic to a group

of hosts represented by a multicast group address.
The multicast router determines which direction is

upstream (toward the source) and which is downstream
(toward the receivers).
If there are multiple downstream paths, the router

replicates the packet down all appropriate downstream
paths (interfaces).
When a multicast packet arrives at a router, the router will

perform an RPF check on the packet.
If the check is successful, the router will forward the

packet. If the check fails, the packet is dropped.
87
Reverse Path Forwarding Check
This RPF check is used to guarantee that the

distribution tree is loop-free.
RPF uses the unicast routing table to validate

from which interface upstream multicast traffic
should arrive.
When a packet arrives at one of the routers

interfaces, the router compares the source address
to the unicast routing table.
If a packet has arrived on the interface leading back

to the source, the RPF check is successful and the
packet will be forwarded.
88
RPF Check Example
89
Multicast Protocols
In order to gain the benefits of using multicast

to send data, network devices must be
configured to support multicast.
Otherwise network devices will treat multicast

traffic like broadcast traffic.
By default, Layer 3 devices block multicast traffic.
Devices must be configured to support

multicast to ensure that the multicast traffic is
contained only to those network segments that
have group members.
90
IP Multicast Protocols
Internet Group Management Protocol (IGMP)
and IGMP Snooping
Cisco Group Management Protocol (CGMP)
Protocol Independent Multicast (PIM)
PIM Dense Mode (PIM-DM)
PIM Sparse Mode (PIM-SM)
PIM Sparse-dense Mode
More on this later
91
Internet Group Management Protocol (IGMP)
IGMP is used to register individual hosts with a multicast

group that want to receive the multicast traffic.
There are three versions of IGMP (IGMPv1 - 3)
IGMPv1 is defined by RFC 1112, v2 is RFC 2236 and v3 is

RFC 3376.
IGMP uses queriers and hosts.
Querier is the router
The set of queriers and hosts make up the multicast group
The router (querier) sends query messages to discover

which hosts are members of the multicast group.
Hosts then send report messages in response to the query

message to inform the router of their membership.
http://www.networksorcery.com/enp/protocol/igmp.htm
92
IGMPv1 and v2 Packet Format
93
Joining a Multicast Group
IGMPv1 was designed to allow hosts to join a multicast

group.
Multicast routers send periodic membership queries to

determine if there is a host on a segment (routers interface)
that belongs to a multicast group.
The routers sends the membership query to the all hosts
multicast address, 224.0.0.1.
Host respond by sending a report message of the groups
they want to receive multicast traffic for to the all routers
multicast address, 224.0.0.2.
Only one host from the group responds to the query.
Hosts do not have to wait for a query message to send a

report message.
When a host wants to join a group, it just sends the join
message (unsolicited Version 2 Membership Report).
94
Maintaining Groups
Internet Group Management Protocol (IGMP) provides
communication between the local router and multicast hosts
95
Response Suppression
In order to save bandwidth, only one host responds to the

query message.
This is called response suppression
When a host hears a query message it begins a

countdown timer.
The countdown timer can be between 0 and 10 seconds.
The countdown timer is selected randomly.
If the timer expires before the host hears a response, then

that host will send the report message.
If the host hears a response before the timer expires then

the host will not send (suppress) a report message.
96
Leaving a Multicast Group IGMPv1
With IGMPv1, there was no way for a host to

announce that it wanted to leave the group.
Hosts, left quietly.
Hosts that no longer need to be part of a multicast

group just ignore the query messages.
Eventually, no hosts will reply with a report

message when the router sends a query
message.
The router will then assumes that there are no

members attached to that interface and will
remove the group.
97
IGMPv2
IGMPv2 includes the definition of groupspecific query.
This way, the router can send a query message to

any one particular group instead of sending it to the
all hosts address.
IGMPv2 also defines a leave group message

(leave report) which allows hosts to leave a
group more quickly.
This is known as "low leave latency" .
98
IGMPv3
IGMPv3 enables a multicast host to indicate to

the router the groups from which it wants to
receive multicast traffic, as well as the unicast
addresses of the source.
IGMPv3 does this by sending two different

report messages:
Include Mode send traffic from these sources
Exclude Mode do not send traffic from these

sources
This is known as source filtering
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtigmpv3.htm
http://www.ciscosystems.cd/univercd/cc/td/doc/product/software/ios122s/122snwft/release/122s14/fs_xtrc.htm
99
IGMP Snooping
The default behavior of a switch is to treat multicast traffic

like an unknown unicast. - Why?
This means that multicast traffic will be sent out every port
of the switch/VLAN.
IGMP snooping is an IP multicast constraining mechanism

for switches.
IGMP snooping runs on a Layer 2 switch.
The switch snoops the content of the IGMP join and leave
messages sent between the hosts and the router.
When the switch sees an IGMP report message, the switch

creates a CAM entry for Layer 2 multicast group address for
the switchport that the report message was heard on.
This way, multicast traffic is only forwarded out the
switchports that have hosts for that group.
100
IGMP Snooping Configuration
IGMP Snooping is enabled globally on the switch by

default.
This means that IGMP snooping is enabled on all VLANs

by default.
If IGMP Snooping is disabled for some reason, you can reenable it using the global configuration command:
Switch(config)#ip igmp snooping
Switch(config)#ip igmp snooping vlan 10
immediate-leave
The second command allows a switchport to leave an

IGMP group as soon as it sees an IGMPv2 leave message
on that switchport.
101
Multicast Routing
By default, a Layer 3 device will isolate multicast traffic to the

segment on which it was generated, not forwarding it across
the router to other network segments.
This is because most multicast traffic has a TTL of 1
Enabling IP multicast routing allows a Layer 3 device to

forward multicast packets based upon the configuration of
the Multicast routing protocol.
To configure multicast routing:
Enable multicast routing globally
Enable a multicast routing protocol at the interfaces

that are going to participate in multicasting
Configure the RP for sparse mode operation
http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225see/scg/swmcast.htm
102
Protocol Independent Multicast (PIM)
PIM is a multicast routing protocol that makes

packet-forwarding decisions independent of
standard or unicast IP routing protocols.
PIM uses the unicast routing tables to perform

multicast forwarding functions.
PIM has three forwarding modes:
Dense Mode PIM DM
Sparse Mode PIM SM
Sparse-Dense Mode
103
PIM Example
104
PIM Dense Mode
This mode uses a push model to flood multicast traffic to

every router in the network and then prune routers that do
not support members of that group.
Dense mode is typically used when:
There are active receivers on every subnet in the network
The volume of multicast traffic is high
Senders and receivers are in close proximity to each

other
Routers that do not have members of the group send a

prune message back towards the source.
105
PIM Dense Mode Example
106
PIM Sparse Mode
Sparse mode is used when receivers are widely

dispersed over a larger area, like a WAN.
This mode uses a pull model to deliver multicast traffic.
Sparse multicast is most useful when there are few

receivers in a group and multicast traffic is
intermittent.
Sparse mode uses a shared tree distribution

system.
Sparse mode uses a shared distribution tree, also

called Core-Based Tree (CBT)
When a source begins to generate a flow, it is

directed to a rendezvous point.
Configuring a Rendezvous Point:

http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225see/scg/swmcast.htm#wp1024288
107
Sparse Mode Example

When a router determines that it
has receivers out its interfaces,
it registers with the rendezvous point.
The routers in the path will optimize
the path automatically to remove
any unnecessary hops.
108
PIM Sparse-Dense Mode
PIM sparse-dense mode allows individual

groups to be run in either sparse or dense
mode depending on whether RP information is
available for that group.
If the router gleans RP information for a

particular group, it will be treated as sparse
mode; otherwise that group will be treated as
dense mode.
109
Multicast Routing Configuration
http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225see/scg/swmcast.htm
110
Configuring Multicast Routing
Must be a routed port

Switch(config-if)#no switchport
pim
Router(config)#ip multicast-routing
Router(config)#int fa0/0
Router(config-if)#ip pim sparse-dense-mode
Router(config)#ip pim rp-address 192.168.1.254
Router(config)#ip pim autorp (Cisco only)
111

Configuring Campus Switches To Support Voice and Video Applications

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configuring Campus Switches To Support Voice and Video Applications

Uploaded by

Copyright:

Available Formats

CCNP 3 v4 Module 8

Configuring Campus Switches to

Accommodating Voice Traffic on Campus

2003, Cisco Systems, Inc. All rights reserved.

2003, Cisco Systems, Inc. All rights reserved.

Cisco recommends an end-to-end single

This way, each new application such as

2003, Cisco Systems, Inc. All rights reserved.

2003, Cisco Systems, Inc. All rights reserved.

Cisco Catalyst switches offer a "voice VLAN"

The voice VLAN, also known as an auxiliary VLAN,

Voice traffic is on a specific VLAN, and IP

2003, Cisco Systems, Inc. All rights reserved.

When a phone is connected to the switch, the switch sends necessary

2003, Cisco Systems, Inc. All rights reserved.

Voice VLANs and Data VLANs

Placing phone traffic onto a distinct

QoS or security policies can be enforced

2003, Cisco Systems, Inc. All rights reserved.

Connecting a PC to the IP Phone

To save switchport density and cable runs, a PC can be

In order for the device and the phone to communicate, one of

They both use the same Layer 2 frame type.

The phone uses 802.1p frames and the device uses

The phone uses untagged frames and the device uses

2003, Cisco Systems, Inc. All rights reserved.

Connecting a PC to the IP Phone

2003, Cisco Systems, Inc. All rights reserved.

Voice Design Considerations

Deploying IP telephony in the enterprise campus requires

Within the Building Access submodule, these features

Hardware support for multiple output queues

Hardware support for in-line power to IP phones

Unidirectional Link Detection (UDLD)

IP Telephony on the Network

IP telephony places strict requirements on

Most IP telephony installations are built

2003, Cisco Systems, Inc. All rights reserved.

Campus Infrastructure Considerations

What features are required for each network device?

Can the physical plan support IP Telephony?

PoE on the switch or a separate inline power patch panel,

Is adequate bandwidth available?

Cat5e minimum, available switchports and wall jacks

How will the phones be powered?

VLAN configuration, QoS, inline power

What other bandwidth intensive applications are running?

Will a VoIP implementation require an complete network

2003, Cisco Systems, Inc. All rights reserved.

QoS is the application of features and

QoS allows preference to be given to

2003, Cisco Systems, Inc. All rights reserved.

QoS and Voice Traffic

Congestion and latency can be caused by speed

When packets are dropped due to network

QoS ensures that prioritized voice traffic is not subject

2003, Cisco Systems, Inc. All rights reserved.

Switchport Commands for VoIP QoS

2003, Cisco Systems, Inc. All rights reserved.

Switch Configuration Example

2003, Cisco Systems, Inc. All rights reserved.

2003, Cisco Systems, Inc. All rights reserved.

QoS by Network Layer