1 © 2003, Cisco Systems, Inc. All rights reserved. CCNP 3 v4 Module 8 Configuring Campus Switches to Support Voice and Video Applications

1© 2003, Cisco Systems, Inc. All rights reserved.

CCNP 3 v4 Module 8 Configuring Campus Switches to

Support Voice and Video Applications


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


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


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.


Campus Infrastructure Considerations

• What features are required for each network device?

– VLAN configuration, QoS, inline power

• Can the physical plan support IP Telephony?

– Cat5e minimum, available switchports and wall jacks

• How will the phones be powered?

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

• Is adequate bandwidth available?

– What other bandwidth intensive applications are running?

• Will a VoIP implementation require an complete network overhaul?


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.


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.


Switchport Commands for VoIP QoS


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


Step-by-Step Configuration


QoS by Network Layer


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.


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.


Classification and Marking


Layer 2 Marking: 802.1p and CoS


Layer 3 Marking: ToS, IP Precedence, DSCP


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.


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


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.


DSCP Code Points

Assured Forwarding - AF

Class Selector - Priority

Dro

p P

rece

den

ce -

Pri

ori

ty

Expedited Forwarding - EF

Class 5

Internetwork Control

Class 6

Network Control

Class 7

101

110

111

Class S

elector B

its

40 – 47 (46)

48 – 55

56 – 63


Layer 2 and 3 DiffServ


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.


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


QoS, CoS and ToS

CoS

ToS – IP Precedence

ToS – DSCP


Modular QoS CLI (MQC)

• The Modular QoS Command Line Interface or MQC is central to Cisco’s 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.


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 | match-any


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.


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


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


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


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

re-written 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.


Trusted vs. Untrusted Ports

Trusted

Trusted

Untrusted


QoS Trust Boundaries


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


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.


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.


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)


MAC ACL to Assign DSCP

• Not all frames can be assigned a CoS based on ingress port


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]


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


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


Policing and Marking

• 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

“out of profile”


Policing Flow Chart

Packets that exceed the limits are said to be “out of profile” or nonconforming.


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


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.


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.


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


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


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.


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.


Weighted Fair Queuing

Weighted fair queuing is activated on a Layer 3 interface:Router(config)#interface serial 0/0Router(config-if)#fair-queue


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.


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.


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.


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.


CBWFQ Example


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


END PART 1

PART 1 STOP HERE


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


IP Multicast


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


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.


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.


IP Multicast Group Example


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


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


IP Multicast to MAC Address Mapping

Only the MAC address range from 0100.5e00.0000 through 0100.5e7f.ffff is the available for carrying multicast frames.

5

01-00-5e identifies the frame as multicast


Multicast MAC Calculation


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. X±128 . X . X 0000.0

8 4 2 1.128


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.090dAs long as the last 23 bits do not change, you will always get the sameMAC address.

However, if we change any of the last 23 bits, we get a different MAC.


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.


Reverse Path Forwarding

Traffic flows away from the source.


Multicast Distribution Trees

• Multicast distribution trees fall into the categories:

1. Source based trees

2. Shared trees


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)


Source Distribution Tree

(S,G) Notation(192.168.1.1, 224.1.1.1)


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.


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


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 router’s 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.


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.


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 router’s

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.


RPF Check Example


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.


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…


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


IGMPv1 and v2 Packet Format


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 (router’s 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).


Maintaining Groups

Internet Group Management Protocol (IGMP) provides

communication between the local router and multicast hosts


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.


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.


IGMPv2

• IGMPv2 includes the definition of group-specific 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" .


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 filteringhttp://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


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.


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 re-enable 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.


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


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


PIM Example


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.


PIM Dense Mode Example


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


Sparse Mode Example

When a router determines that ithas 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.


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.


Multicast Routing Configuration

http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225see/scg/swmcast.htm


Configuring Multicast Routing

Router(config)#ip multicast-routingRouter(config)#int fa0/0Router(config-if)#ip pim sparse-dense-modeRouter(config)#ip pim rp-address 192.168.1.254Router(config)#ip pim autorp (Cisco only)

pim

Switch(config-if)#no switchportMust be a routed port

Documents

1 © 2003, Cisco Systems, Inc. All rights reserved. CCNP 3 v4 Module 8 Configuring Campus Switches to Support Voice and Video Applications