Ipm Lab Instructions V5dot1

LAB WORK INSTRUCTIONS
2*CCME, IOS 15, V. 5.1
IP Multimedia Systems Lab:

Cisco CallManager Express, Work Instructions
Contents
Objectives
Theoretical Background
Prerequisites
2
2
2
Task 1. IP Telephony System Setup

Step 1.1: Local IP PBX
Step 1.2: Adding a WAN Link for a Remote Office
2
2
6
Task 2. Further Router Configuration

Step 2.1: Digit Manipulation
Step 2.2: Dual CCME System
9
9
10
Task 3. Preparing for QoS

Step 3.1: Inspecting VoIP Call Bandwidth Usage
Step 3.2: Inspecting Network Delay, Delay Variation
And Packet Drop Rate
Step 3.3: Inspecting Network Service Levels for Voice and Data
13
13
Task 4. Configuring QoS Components

Step 4.1: Inspecting FIFO Scheduling Operation, Step 1
Step 4.2: Inspecting Low Latency Queuing, Step 2
Step 4.3: Adding Traffic Policing to Low Latency Queuing, Step 3
19
19
22
22
Task 5. Video Streaming

Step 5.1: Video Streaming Server
Step 5.2: Playing the Video Clip with VLC Client
23
23
24
14
18

2*CCME, IOS 15, V. 5.1
Objectives
Students are guided to make configurations in Cisco Unified Communications Manager
Express (former CallManager Express, CCME) router, and to learn basic IP telephone
network, and call processing settings and operations. Students will also become familiar with
some important details of VoIP traffic behavior and characteristics in modern IP networks,
basic Quality of Service practices, and video streaming with IP Multicast. The project will
proceed in steps, to go through various aspects of a typical IP Telephony solution for a small
enterprise or public organisation.
Theoretical Background
Brief descriptions of the used equipment and protocols are given in a separate document VoIP
Lab: Cisco CallManager Express, Theoretical Background. That document must be studied
in advance for more fluent lab working.
Prerequisites
Students need to have basic knowledge of TCP/IP protocols, IP routing, switched Ethernet,
and of Cisco router and switch configurations. Although all the necessary IOS commands are
given and most of them are separately and clearly explained, students need experience in
using Cisco router IOS for fluent lab working. Understanding the referred protocols is also
essential.
Students should read these lab instructions, and the background material prior to the first lab
session. You should start with your documented plan of IP address and extension numbers.
Task 1. IP Telephony System Setup

Step 1.1: Local IP IBX
At this first step, you set up an IP PBX (Private Area Branch Exchange) with two extensions, and you are able to
make a test call between the IP phones.
The equipment at this step consists of a Cisco 2800 (Advanced IP/Enterprise Feature Set v. 15
IOS), two Cisco Catalyst 3560 switches (with Power over Ethernet), two Cisco 7905G or
79xx IP Phones, external power supply adapters, if not using POE, and a PC for
configurations. The router IOS includes Cisco CallManager Express (CCME)/Unified
Communication Manager Express (CME) IP call control features. The initial lab network
scheme is illustrated in Figure 1.
You may choose any IP subnets, but take care of address consistency issues in the network
throughout the whole exercise. The IP addresses in this work instruction are given for
guidelines. Before starting the equipment configurations, erase all existing configurations of
both routers and switches, and cold boot the equipment. Then connect the equipment
according to the diagram in Figure 1. It is advised not to make additional configurations in

2*CCME, IOS 15, V. 5.1
the routers during the lab exercise, because of possible unexpected influence in the
phenomenon under study.
Figure 1. Initial Lab Network Diagram for Step 1.1.

Connect the devices according to Figure 1. Document all addresses and physical interfaces.
Cisco IP Phone Settings
Restoring Factory Defaults, if necessary
Cisco hardware phone sets will get their IP address and PBX settings from a DHCP pool (to
be created later), and the CCME will allocate subscriber numbers, labels and other phone
service related settings. Sometimes the phone set keeps its old un-matching address settings
(from the previous student group). To erase any settings on the phone set, you can press the
Navigate button, then toggle down to Settings menu, then to Network config, and check if the
settings are locked. If so (indicated by the closed lock symbol in the display), you can unlock
the device with **# keystrokes. Now you can return Factory settings with **2.
Cisco CallManager Express Router Configuration
Basic Router Setup
Erase any previous configurations of the router and the switch:
Router/Switch#erase startup-config
Erasing the nvram filesystem will remove all configuration files! Continue?
[confirm]
[OK]
Erase of nvram: complete
Router/Switch#reload
System configuration has been modified. Save? [yes/no]: no
Proceed with reload? [confirm]

2*CCME, IOS 15, V. 5.1
Make the following basic configurations, for assigning an IP address for the FastEthernet
interface:
Router(config)#interface FastEthernet0/0
Router(config-if)#ip address 10.0.3.1 255.255.255.0
Router(config-if)#no shutdown
Router(config)#do show ip int brief
...
For your convenience you may make the following settings as well.
Router(config)#no ip domain-lookup
Router(config)#line con 0
Router(config-line)#exec-timeout 60
Router(config-line)#logging synchronous
Router(config-line)#exit
Router(config)#hostname CCME
Save settings to NVRAM and start telephony-service and DHCP service setup, remembering
consistency with CCME router FastEthernet0/0 interface IP address and subnetwork. CCME
router DHCP (Dynamic Host Configuration Protocol) service will give IP addresses and other
IP parameters for the IP phones. This service can be used to provide also the PCs connected to
the switch with their IP addresses. You may choose any IP phone line extension numbers you
like (first extension number in the configuration that follows).
Telephone Service Configurations
The previous erase start command flushed also any existing CCME (telephony-service)
configuration in router start-up file. It can also be flushed separately too by a command
CCME(config)#no telephony-service, which deletes and stops running telephonyservices. For a new basic configuration, you need to configure DHCP address pool, to give IP
addresses, subnet mask, default gateway, and CCME address to phone sets:
CCME(config)#ip dhcp pool ITS-HQ
CCME(config-dhcp)#network 10.0.3.0 255.255.255.0
CCME(config-dhcp)#option 150 ip 10.0.3.1
CCME(config-dhcp)#default-router 10.0.3.1
CCME(config-dhcp)#exit
For telephony (CCME) services, we give the maximum number of phones and directory
numbers, CCME address and port, and assign directory numbers automatically to phone sets:
CCME(config)#telephony-service
CCME(config-telephony)#max-ephones 5
CCME(config-telephony)#max-dn 5
CCME(config-telephony)#ip source-address 10.0.3.1 port 2000
CCME(config-telephony)#auto assign 1 to 5
CCME(config-telephony)#exit

2*CCME, IOS 15, V. 5.1
We have to create all ephone-dn (and phone numbers) and ephone sections manually:
CCME(config)#ephone-dn 1
CCME(config-ephone-dn)#number 300
CCME(config-ephone-dn)#exit
...
CCME(config-ephone-dn)#number 304
CCME(config)#ephone 1
CCME(config-ephone)#exit
...
After the router has finished the telephone-service setup process, wait for a while for the
router to finish IP phone registration. This will take a couple of minutes (see the console
logging messages and the IP phone LCD display). For speeding up the registration, you
should turn off Spanning Tree Protocol (STP) on the IP phone set switchport:
Switch(config)#int fa 0/x
Switch(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast has been configured on FastEthernet0/1 but will only
have effect when the interface is in a non-trunking mode.
If the phone set doesn't register with CCME, unlock the set (**#) and return factory defaults
(**2). If needed, check also the VLAN assignment and port monitoring in the switch.
Check how the IP phones are registered, by a command show telephony-service
ephone, if the IP phone was connected to the switch already. Otherwise connect them now
and wait for phones to be registered. You can follow the registration procedure from the
phone display. They should be registered as ephone 1 and 2, but can be some other ephone
# as well. One ephone # represents a registered IP phone equipment, by default in ascending
order in CCME configuration.
Extension number allocation can be viewed by an EXEC command show telephonyservice ephone-dn. CCME router show run command will provide the same
information.
Then change extension line button informational label settings for IP phone display,
ephone-dn # representing CCME extension phone line, label ***** representing
corresponding informational label for the line on Cisco 7905G IP phone display. The line
extension number can be changed by a command CCME(config-ephone-dn)# number #.
CCME(config-ephone-dn)#label 301 CCME

2*CCME, IOS 15, V. 5.1
If you changed the label settings as described above, you have to reset or restart the IP phone
equipment in order to upload the new configuration. Restart is faster than reset, the latter
causing a complete cold boot, which is necessary for e.g. new IP address and TFTP server IP
address settings for an IP phone:
CCME(config-ephone)#restart
Make a test call. Do not proceed before being able to make a call between the IP phones.
Step 1.2: Adding a WAN Link for a Remote Office

Now you will expand the IP telephony solution by providing IP telephones to users on a remote office, both
using a single IP PBX (Figure 3).
Figure 3: Two-site IP Telehone system of Step 1.3.

Connect the RO devices. Amend your document with address and interface details.
REMOTE Router Configuration
Erase both the REMOTE router and the switch:
Router/Switch#erase startup-config
Router/Switch#reload
Then make the following basic configuration, for REMOTE router interfaces, IP address and
static default route to the Headquater:
Router(config)#interface FastEthernet0/0
Router(config-if)#exit

2*CCME, IOS 15, V. 5.1
Choose the interface identifier according to your router platform and cabling. This is the DTE
interface, so the other end will provide clocking. We enable First In First Out (FIFO)
scheduling, which will be needed in Step 3.2:
Router(config)#interface Serial0/0/0
Router(config-if)#no fair-queue
Router(config-if)#exit
Router(config)#ip route 0.0.0.0 0.0.0.0 10.0.4.1
For your convenience you may make the following settings as well:
Router(config)#no ip domain-lookup
Router(config)#line con 0
Router(config-line)#exec-timeout 60
Router(config-line)#logging synchronous
Router(config-line)#exit
Router(config)#hostname REMOTE
CCME router DHCP service configuration was set in the telephone-service setup
process to provide the local IP phone (and PCs) with an IP address. The IP phone (and PC)
connected to the REMOTE router is located in a different IP subnet region, and we need
another DHCP server configuration in the REMOTE router to provide IP addresses for remote
IP phones. The DHCP service "network" must be within the same subnet as the
FastEthernet interface (fa0/0) for the Remote router, the "option 150" IP address must be
the same as the TFTP (Trivial File Transfer Protocol) Server IP address (Option 150) set up in
CCME router telephone-service setup, and the DHCP service default router IP address is the
fa0/0 interface IP address of the REMOTE router. The router will associate the DHCP pool to
the correct interface according to IP addresses:
REMOTE(config)#ip dhcp pool REMOTE
REMOTE(config-dhcp)#network 10.0.5.0 255.255.255.0
REMOTE(config-dhcp)#option 150 ip 10.0.3.1
REMOTE(config-dhcp)#default-router 10.0.5.1
REMOTE(config-dhcp)#end
Save the configuration in the NVRAM and the remote router configuration is ready.
Serial link on the CCME router
Compatible IP parameters and routes must be configured on the CCME router as well (for
correct interfaces). Set the line speed exactly to 128 kbps on the DCE interface. For
simplicity, you may use a static route to the REMOTE LAN on the HQ CCME router:
CCME(config)#interface Serial0/0/0
CCME(config-if)#ip address 10.0.4.1 255.255.255.252
CCME(config-if)#clock rate 128000
!(In case CCME s0/0/0 is DCE.)
CCME(config-if)#no fair-queue
CCME(config-if)#no shutdown
CCME(config-if)#exit
CCME(config)#ip route 10.0.5.0 255.255.255.0 10.0.4.2

2*CCME, IOS 15, V. 5.1
Check the end-to-end IP connectivity by pinging between CCME and REMOTE LANs.
Disabling STP on the Remote Switch
Enable PortFast on the IP phone port of the switch in the remote office:
Switch(config)#hostname RemoteSwitch
RemoteSwitch(config)#int fa 0/x
RemoteSwitch(config-if)#spanning-tree portfast
Connecting the Remote IP Phone

Connect the remote IP phone set to the remote switch, reset address settings (if necessary),
return to factory defaults (if necessary), and wait for the phone to be registered to
Headquarters CCME. Registration is done automatically and takes a few minutes. Observe IP
phone display. After a successful registration you may repeat the following steps, this time for
remote IP phone configuration, on the HQ CCME router:
CCME(config-ephone-dn)#label 302 REMOTE
CCME(config-ephone)#restart
Make test calls from the remote IP phone to the Headquarters phone and vice versa. You must
be able to make these calls, or otherwise you will not be able to finish properly the following
tests in this lab exercise.
It is worth trying different settings in order to study these basic VoIP network parameters.
You may follow first the samples listed in this work instruction, but your teacher will
appreciate your efforts in building your own network configuration.
Reporting, Task 1, Steps 1.1 and 1.3: In your own words, explain the steps needed to
configure the IPT network of Figure 3. Explain your experiences configuring the routers and
testing your call connectivity, at least by few sentences. Describe any possible problems and
how you solved them. Save your CCME and REMOTE router configurations at step 1.3 and
attach them to your lab report.

2*CCME, IOS 15, V. 5.1
Task 2. Further Router Configuration

Step 2.1: Digit Manipulation
At this step, you will expand the IPT system by integrating home users to a single system.
Digit manipulation means conversion or replacement of digit strings by some other digits or
complete digit strings, which process is usual in production PBX systems. CCME includes
several features for this dialed number processing, and the following examples are for simple
demonstration only. Make these configurations only after your call routing is successful.
Hint: Save the configurations of both routers to NVRAM before configuring any digit
manipulation. Then you are able to revert easily back to the original configuration just by
reloading the router start-up configuration.
Example 1. Outgoing Called ID string could be manipulated by a digit replacement. E.g.
sending a string 301, instead of dialed 977317 (voice translation-rule, id 977, rule 1 below),
enabling a call to #301 by a dial string "977317". This simulates a situation, when a real
called subscriber number needs to be hidden, or a call has to be directed into another
extension than the originally dialed one. Voice translation-rule 977 number must
match with a number in translate called 977. Voice translation-profile
SHOP name must equal with a name in translation-profile outgoing SHOP
command. Finally these digit manipulation rules have to be added in the dial-peer
configuration.
First we create a voice translation-rule (id 977), and define one rule, to translate string 977317
to 301. The HQ CCME router is responsible of call processing:
CCME(config)#voice translation-rule 977
CCME(cfg-translation-rule)#rule 1 /977317/ /301/
CCME(cfg-translation-rule)#exit
Next, we define a translation-profile SHOP, to group the previous translation rule to a profile.
The profile translates the called dial string according to translation-rule 977 above:
CCME(config)#voice translation-profile SHOP
CCME(cfg-translation-profile)#translate called 977
CCME(cfg-translation-profile)#exit
Then we assign our translation-profile SHOP to dialpeer 301 (for this Directory Number), to
handle outgoing calls to that number:
CCME(config)#dial-peer voice 301 voip
CCME(config-dial-peer)#translation-profile outgoing SHOP
Although within a single CCME router, also call routing information must be provided. 97T
indicates a variable-length dial string, starting with digits 9 and 7:
CCME(config-dial-peer)#destination-pattern 97T
CCME(config-dial-peer)#session target ipv4:10.0.3.1
CCME(config-dial-peer)#exit

2*CCME, IOS 15, V. 5.1
10
Make some test calls for example from 302 to 301 by dialing 977317 (*.
Example 2. Our second digit manipulation example is a simple one. A preset string can
replace the dialed string, by using a command: num-exp dialed_string
replaced_by_string. This simulates a call processing feature, where e.g. an external PSTN
or mobile phone subscriber number (for example a company employee's private phone line) is
seen as an ordinary local enterprise PBX extension line. In our example below, a user may
dial 327 in order to actually call to extension 302. 327 represent company internal phone line
numbers (in 3xx extension numbering space), whereas 302 could represent e.g. a public PSTN
number, (but are very short in our simple lab configuration for simplicity):
CCME(config)#num-exp 327 302
Test by calling to 327 from 301.
Step 2.2: Dual CCME System

Now you will add IPT performance and reliability by adding a separate IP PBX to the remote office. Both
PBXes handle local office calls, and use dialpeers to route calls tbetween the offices (Figure 4).
Figure 4: Two CCME network of Step 2.2.

Removing Unnecessary Services
For simplicity, lets remove all digit manipulation rules first. The HQ CCME router will
handle only calls for the 3xx extensions, so we will change the device name to reflect the new
role:
*) Please wait 10 seconds for the number analysis to complete

2*CCME, IOS 15, V. 5.1
11
CCME(config)#hostname CCME300
CCME300(config)#no num-exp 327 302
CCME300(config)#no voice translation-rule 977
CCME300(config)#no voice translation-profile SHOP
CCME300(config)#no dial-peer voice 301 voip
CCME300(config)#do show run
...
Before proceeding, pls verify that you can make calls with the original 301 and 302 extension
numbers.
Then we change the REMOTE router hostname, and modify the remote DHCP pool, to point
to the local CCME service on the RO router:
REMOTE(config)#hostname CCME500
REMOTE(config)#ip dhcp pool REMOTE
REMOTE(config-dhcp)#option 150 ip 10.0.5.1
REMOTE(config-dhcp)#exit
Basic Telephony Service Setup in the Remote Office

Now we can repeat the basic telephony-service configuration for handling local 5xx calls in
the remote office, according to the previous example:
CCME500(config)#telephony-service
CCME500(config-telephony)#...
CCME500(config-telephony)#exit
CCME500(config)#ephone-dn 1
CCME500(config-ephone-dn)#...
CCME500(config)#ephone 1
CCME500(config-ephone)#...
CCME500(config-ephone)#exit
Power off the Remote IP phone set for a short while. Wait for the remote IP phone
registration. Unlock and reset, if necessary. Check VLAN assignment and port monitoring in
the switch, if necessary. If you try to call the HQ phone from the remote office, you probably
wont have any success. Why?
Call Routing between IP PBXes
CCME500 handles calls within the 50x extensions, but it should route calls to 30x numbers to
the HQ PBX. This is configured using a dial-peer pointing to CCME300, and a destination
pattern (wildcard) matching all possible 30x numbers.
Lets first create a new dial-peer (with tag 300), to handle all 30x extensions:
CCME500(config)#dial-peer voice 300 voip
Then we associate all possible three-digit 30x directory numbers to this dial-peer (remember
we configured maximum of five extensions in the HQ PBX). The trailing dot indicates any
third digit:

2*CCME, IOS 15, V. 5.1
12
CCME500(config-dial-peer)#destination-pattern 30.
Next, we give instructions how to route calls to these directory numbers:

CCME500(config-dial-peer)#session target ipv4:10.0.3.1
To ensure, that G.711 voice codec will be used (important in Step 3.1), we specify the
preferred codec for CCME-to-CCME call setup:
CCME500(config-dial-peer)#codec g711alaw
CCME500(config-dial-peer)#exit
With IOS 15.1 and later, we have to disable peer authentication:

CCME500(config)#voice service voip
CCME500(config-voi-serv)#no ip address trusted authenticate
The command DISABLES the ip address authentication on incoming
H.323 or SIP trunk calls for toll fraud prevention supports.
Continue? [confirm]y
CCME500(config-voi-serv)#exit
Then repeat the above-mentioned configuration steps for the HQ router, to handle calls to the
50x directory numbers.
Verifying and Analyzing Call Routing
Make a test call between the offices. If needed, double-check your configurations and debug
voip dialpeer operation.
Analyze a successful call between offices with debug voip dialpeer all command.
Record your debug outcome and amend that to your report for Task 2.
Reporting Task 2, Steps 2.1 and 2.2: Explain your experiences configuring and testing digit
manipulations, at least by a few sentences. Describe any possible problems and how you
solved them.
Attach your dial-peer debug output with short explanation of call routing between the offices.
Save your CCME300 and CCME500 router configurations, but dont attach them in Step 2
report. Submit the first report including Tasks 1 and 2.

2*CCME, IOS 15, V. 5.1
13
Task 3. Preparing for QoS

Step 3.1: Inspecting VoIP Call Bandwidth Usage
For dimensioning, you must find out the bandwidth usage for a VoIP call. The network setup is shown in Figure
5.
Figure 5: Final VoIP lab setup.

Configure the Headquarters Catalyst 3560 POE switch monitoring functionality for VoIP call
inspection purposes, for monitoring the Ethernet frames between the IP phones. There can be
several source and destination interfaces in a single monitor session # configuration, so
be sure to use the correct interfaces (*, when modifying your settings. Use show run or show
monitor session command to check your configuration. The parameter both in source
configuration should be used for monitoring both the sent and received traffic, or parameter
tx for monitoring only the frames transmitted at the monitored switch source port as in the
example below. Configure the following on the 3560 POE switch by the CCME300, and
select the correct source and destination interfaces and source direction according to your
setup. Remember that the switch monitor session destination interface only receives the
mirrored copies, and cannot be used for ordinary traffic:
Switch(config)#monitor session 1 source interface Fa0/# tx|rx|both
Switch(config)#monitor session 1 destination interface Fa0/#
Amend your document with physical interface information.

Make sure, that your phones are still registered with their CCME, and you can make a call. If
not, double-check the monitoring destination port. The destination port cannot be used for
ordinary traffic.
*) You need to monitor the call traffic, which already has passed the serial link, by mirroring
the traffic from the correct interface to the Wireshark host.

2*CCME, IOS 15, V. 5.1
14
Start Wireshark Network Analyzer and test monitoring functionality with a test call and by
inspecting some of your CCME LAN traffic, ping to the IP phone or any such test you like.
Start capturing VoIP packets and make a call between the IP phones. Unfortunately Cisco IP
phones used in this testing do not send RTCP (Realtime Transport Control Protocol)
messages. Use display filters to show only desired voice packets on the screen for inspection.
What is the size of the IP packet, which carries a UDP datagram, which carries an RTP
message, which carries the voice samples? What is the voice codec?
Using Wireshark IO Graphs Statistics, record the bandwidth consumption (including RTP
(Realtime Transport Protocol), UDP, IP and Ethernet headers) for a call, and compare this to
the expected theoretical value. Depending on your switch monitoring session configuration,
test call bandwidth consumption may seem to be double, but when?
Reporting, Step 3.1: Document, in details, your monitoring configuration, including
monitoring commands and port connections. Inspect and report the captured VoIP call
bandwidth consumption. What is the voice codec used by IP phones? Compare in details your
observation with the theoretical value. Explain in writing what the calculated bandwidth is,
and how the observed result complies with the theoretical value.
Step 3.2: Inspecting Network Delay, Delay Variation and Packet Drop Rate
Another pieces of background information are voice packet delay, jitter and drops, which may have a significant
effect on voice quality. Packet delay, jitter and loss rate are measured with Cisco IP SLA, using artificial
packets, which resemble IPT RTP messages.
While observing voice call quality issues in the previous tasks, you should also have noticed
the remarkably long delay over this short and simple VoIP connection. This relatively long
and easily noticeable delay is a typical characteristic of a VoIP call.
You can notice the audible delay better, when you are talking and listening over the same
direction of the VoIP connection. With Wireshark RTP Stream Analysis Statistics facility, we
cannot monitor the absolute network delay (or the total mouth-to-ear delay).
Instead, we generate simulated UDP/RTP packets (180 bytes, DSCP=EF), in bursts, over the
serial line, from Headquarters CCME300 LAN to the remote office CCME500 LAN with IP
SLA (*. Cisco IP SLA UDP Jitter offers detailed delay, jitter and packet loss information, but
it needs quite a few additional components.
*) Do not use the IP phone set as the test target. The phone seems to process ICMP and UDP
requests slowly, leading to extra long measured delay values.

2*CCME, IOS 15, V. 5.1
15
First, IOS Versions

Before continuing, we must make sure, that our routers support Cisco IP SLA with UDP
Jitter. List the IP SLA applications on both routers. If you don't see this kind of output, you
must change the router, copy/paste configurations and check IP connectivity and IPT call
processing:
CCME300#show ip sla application
IP Service Level Agreements
Version: Round Trip Time MIB 2.2.0, Infrastructure Engine-III
Supported Operation Types:
icmpEcho, path-echo, path-jitter, udpEcho, tcpConnect, http
dns, udpJitter, dhcp, ftp, VoIP, rtp, lsp Group, icmpJitter
lspPing, lspTrace, 802.1agEcho VLAN, Port
802.1agJitter VLAN, Port, pseudowirePing, udpApp, wspApp
Supported Features:
IPSLAs Event Publisher
IP SLAs low memory water mark: 53421770
Estimated system max number of entries: 39127
Estimated number of configurable operations: 36141
Number of Entries configured : 0
Number of active Entries
: 0
Number of pending Entries
: 0
Number of inactive Entries
: 0
Time of last change in whole IP SLAs: *11:55:37.503 UTC Tue Feb 3 2015
NTP Time Synchronization

For measuring the one-way delay, a common precise clock is needed. For this, we set the
system clock of the Headquarters CCME300 to correct wallclock time (and timezone), and
later distribute the time with NTP (Network Time Protocol):
CCME300#clock set 14:38:00 Feb 03 2015
CCME300#
*Feb 3 14:38:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated
from 12:49:54 UTC Tue Feb 3 2015 to 14:38:00 UTC Tue Feb 3 2015, configured
from console by console.
CCME300#show clock
14:38:09.707 UTC Tue Feb 3 2015
Then we have to set the HQ router as NTP master, and both routers to use it as the NTP time
server:
CCME300#conf t
Enter configuration commands, one per line.
CCME300(config)#ntp master 2
End with CNTL/Z.
CCME300(config)#ntp server 10.0.3.1

CCME500#conf t
CCME500(config)#ntp server 10.0.3.1
CCME500(config)#end
End with CNTL/Z.

2*CCME, IOS 15, V. 5.1
16
You should check NTP association and result with show ntp associations, show ntp
status and show clock. It may take a while for the NTP client to synchronize.
Cisco IP SLA Responder
For precise delay and jitter measurements, the target Cisco device should run IP SLA
responder. This will be configured in the Remote CCME500 router:
CCME500#conf t
CCME500(config)#ip sla responder
CCME500(config)#end
End with CNTL/Z
You should check IP SLA responder status with sh ip sla monitor responder.
IP SLA UDP Jitter Measurement
The main sources for network anomalies are the congested serial link, and the Headquarters
and Remote office routers. LAN switches probably can handle all frames without extra delay,
so we can concentrate monitoring the main sources for delay and packet drop.
CCME300 in Headquarters will send UDP packets, and report delay, jitter and packet loss
values. We will send five packets, DSCP=EF (*, 20 ms apart, every 10 seconds, from the HQ
LAN to the remote LAN, to UDP port 6000 (**:
CCME300(config)#ip sla 1
CCME300(config-sla)#$ udp-jitter 10.0.5.1 6000 codec g711alaw codecnumpacket 5 codec-nterval 10 codec-size 172 source-ip 10.0.3.1 source-port
6010
CCME300(config-sla-jitter)#dest-ipaddr 10.0.5.1
CCME300(config-sla-jitter)#tos 184
CCME300(config-sla-jitter)#frequency 10
CCME300(config-sla-jitter)#exit
CCME300(config)#ip sla schedule 1 start-time now life forever
CCME300(config)#end
You should check the configuration with sh ip sla configuration 1.

Let's check the output. On an unused network, the delay is low, and no packets are dropped:
CCME300#sh ip sla statistics 1
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Type of operation: udp-jitter
Latest RTT: 36 milliseconds
Latest operation start time: 14:51:28 UTC Tue Feb 3 2015
Latest operation return code: OK
RTT Values:
Number Of RTT: 5
RTT Min/Avg/Max: 29/36/45 ms

2*CCME, IOS 15, V. 5.1
17
Latency one-way time:

Number of Latency one-way Samples: 5
Source to Destination Latency one way Min/Avg/Max: 19/26/35 ms
Destination to Source Latency one way Min/Avg/Max: 9/9/10 ms
Jitter Time:
Number of SD Jitter Samples: 4
Number of DS Jitter Samples: 4
Source to Destination Jitter Min/Avg/Max: 2/4/5 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/1/1 milliseconds
Packet Loss Values:
Loss Source to Destination: 0
Source to Destination Loss Periods Number: 0
Source to Destination Loss Period Length Min/Max: 0/0
Source to Destination Inter Loss Period Length Min/Max: 0/0
Loss Destination to Source: 0
Destination to Source Loss Periods Number: 0
Destination to Source Loss Period Length Min/Max: 0/0
Destination to Source Inter Loss Period Length Min/Max: 0/0
Out Of Sequence: 0
Tail Drop: 0
Packet Late Arrival: 0
Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 1
MOS score: 4.34
Number of successes: 6
Number of failures: 0
Operation time to live: Forever
While monitoring delay, jitter and drop rate for simulated voice packets with IP SLA, make a
call, at the same time. Record the one-way network RTT delay from Remote Office to
Headquarters, for simulated UDP packets, without any other traffic (but the call). This should
be almost the same as before, and the same as the total network processing, queuing,
packetizing and propagation delay, experienced by RTP. Record the delay, jitter and packet
drop rate from the unloaded network as reference values.
Reporting, Step 3.2: Describe briefly your observations of VoIP call network delays in this
lab exercise so far.
Calculate the estimated total mouth-to-ear delay for a VoIP call in this lab network. Add 10
ms codec delay and the known packetization delay in transmission, and 25 ms de-jitter buffer
play-back delay and 10 ms decoder delay in VoIP reception. Present the calculations
comparing them with the audible observed delay.
*) For Cisco IP SLA UDP jitter measurement, you specify only the six DSCP bits in the DS
byte (in the IP header) 4610 = 101 110 indicates the highest priority EF (Expedited
Forwarding). Cisco IP phones mark RTP packets with EF.
**) IP SLA option request-size 172 specifies the UDP payload length. 8-byte UDP header and
20-byte IP header is added to this, leading to 200-byte IP packets. This is the same size as 160
bits of voice, a 12-bit RTP header, an 8-bit UDP header and a 20-bit IP header, sent by the
phone set.
***) 5 * (172B + 8B + 20B + 18B) (for Ethernet) every 10 seconds generates an average of
0,9 kbit/s per direction, which is small compared to bandwidth consumption for a call.

2*CCME, IOS 15, V. 5.1
18
Step 3.3: Inspecting Network Service Levels for Voice and Data
Cisco IP SLA offers good tools for monitoring delay, jitter and packet drop rate components for voice services,
and for received network capacity for throughput-oriented file transfer services.
Make sure, that the Remote Office PC has the FTP service started. Put two files in drive c:
one smaller (about 10 kB), and one larger (about 500 kB). Verify, that you can download the
file from Remote Office PC to Headquarters PC.
Add a second Cisco IP SLA test in the Headquarters CCME300 router: use FTP test, the
Remote Office PC and smaller file as the URL, and schedule it to be repeated every 20
seconds:
CCME300#conf t
CCME300(config)#ip sla 2
CCME300(config-sla)#ftp get ftp://10.0.5.2/smaller.bmp source-ip 10.0.3.1
CCME300(config-sla-ftp)#frequency 30
CCME300(config-sla-ftp)#exit
CCME300(config)#ip sla schedule 2 start-time now life forever
CCME300(config)#exit
You can display this IP SLA test with show ip sla monitor configuration 2.
Check the result of this test:
CCME300#show ip sla statistics 2
...
Without a call active or any other traffic, the FTP test should get almost all the capacity of the
serial link. Calculate the FTP network capacity, and record the result.
Clear IP SLA statistics for the UDP jitter test, and verify that the counters start from zero
values:
CCME300#conf t
CCME300(config)#ip sla restart 1
CCME300(config)#exit
CCME300#show ip sla statistics 1
Now we have two Cisco IP SLA tests running; one for simulated voice, another for a data
service. The UDP jitter test is repeated every 10 seconds, so we can display the latest results
during a call. You should restart the UDP jitter test, to reset packet drop counters. The
bandwidth-hungry FTP test is repeated every 30 seconds, and displays the last transfer details.
In future experiments you should use long enough calls to get at least one FTP test to match
with the call.

2*CCME, IOS 15, V. 5.1
19
Reporting, Step 3.3: Present your result for the FTP throughput measurements, together with
your measuring arrangements. Also present your calculations for the FTP throughput, with a
comparision to the network capacity.
What information and results you can obtain from IP SLA FTP statistics?
Submit the second report including all steps of Task 3, i.e. Steps 3.1, 3.2, and 3.3.
Task 4 Configuring QoS Components

Step 4.1: Inspecting FIFO Scheduling Operation, Step 1
During Task 4, you will implement various QoS configurations and examine their effect on simultaneous voice
and data services. The intention is to repeat a series of measurements, and alter only QoS configurations, to get
comparable results. As the first step and the reference, we start with the FIFO Scheduling in the serial link. This
should give equal service for data and voice.
You will load the network by transferring the large file from the Remote Office host with FTP, and with a
simultaneous call. Voice and data service levels will be monitored with the previous IP SLA tests.
The goal of Task 4 is to get comparable relative results, by keeping the measurement
arrangements exactly the same, and altering only QoS settings. The results will then be
summarized and explained in the final report.
Before any measurements, please recheck that you are using FIFO scheduling in both serial
interfaces (no fair-queue), and 128 kbit/s clock rate for the DCE interface.
Common measurement arrangements for all tests are the following (repeat with current FIFO
setup):
1) Start transferring a large file with FTP from the Remote office to the HQ workstation,
over the serial link. You should leave the FTP transfer active during the call.
2) Make a call, then restart the UDP jitter test.
3) After 20 seconds or more, check the IP SLA monitor results for both tests.
4) Record the results, and make short comparison to validate the values.
Prepare a table for the following parameters:
One-way network delay (latency) for the simulated RTP packets from Remote Office to
Headquarters during congestion
One-way network delay (latency) for the simulated RTP packets from Headquarters to
Remote Office
Average packet loss percent for the simulated RTP packets from Remote Office to
Headquarters during congestion
Average packet loss percent for the simulated RTP packets from Headquarters to Remote
Office
Average data bandwidth for the FTP file transfer during congestion

2*CCME, IOS 15, V. 5.1
20
Your subjective view of the voice quality in MOS (Mean Opinion Score) (15) during
congestion.
Record also the step (4.1) and QoS configuration (FIFO) by the results. Leave space for future
measurements of the same parameters, with different QoS configurations.
Reporting, Step 4.1: Estimate, in theory, how much bandwidth will be allocated to RTP and
data streams on this setup. Give a short reasoning for your values.
Step 4.2: Inspecting Low Latency Queuing, Step 2

At this step, you will set up your remote link to give higher priority to VoIP traffic.
The main idea of this test is to perceive the effect of a simple Quality of Service traffic
conditioning setup, and to compare the results with the results in the previous Task. Add a
Low Latency Queuing (LLQ) configuration in both routers, in serial interfaces (s0/0/0 or
alike), as follows in the example for CCME router.
Class-map IPT is used to classify IP Telephony packets (both RTP and signaling) to a class
called IPT. Policy-map LLQ_FOR_IPT is then used to give IPT packets (class IPT) absolute
priority up to 94 kbit/s (codec bandwidth plus headers plus 5% for signaling plus IP SLA
bandwidth). Policy-map LLQ_FOR_IPT is finally attached to the output direction of Interface
Serial0/0/0 of the router. The names of class-maps and policy-maps have only local
significance, but must of course match locally together (class-map IPT with class IPT, policymap LLQ_FOR_IPT with service-policy LLQ_FOR_IPT). Class-map and policy-map names
are case sensitive (*.
IOS will create automatically the default class named class-default for all un-matching
traffic. There is no option for this system-defined default class name, and it cannot be seen in
show run listing, unless modified.
You need to classify traffic according to the DSCP (Differentiated Services Code Point)
values in the IP packet header. Cisco IP phones mark RTP packets with EF (Expedited
Forwarding), and Skinny signaling packets with AF31 (Assured Forwarding Class 31). Both
should go to the IPT class (**. Enter these configuration commands to both routers.
CCME300/500(config)#class-map match-any IPT
CCME300/500(config-cmap)#match dscp ef
CCME300/500(config-cmap)#match dscp af31
CCME300/500(config-cmap)#exit
CCME300/500(config)#policy-map LLQ_FOR_IPT
CCME300/500(config-pmap)#class IPT
CCME300/500(config-pmap-c)#priority 94
CCME300/500(config-pmap-c)#exit
*) I have a habit to use CAPITALIZED names for my own identifiers, to make them clearly
distinguishable from IOS reserved words.
**) 18410 = 1011 10002 = 101 110 00 in the ping command indicates EF DSCP. Such packets
should match class-map IPT rules.

2*CCME, IOS 15, V. 5.1
21
CCME300/500(config-pmap)#class class-default
CCME300/500(config-pmap-c)#fair-queue
CCME300/500(config-pmap-c)#exit
CCME300/500(config-pmap)#exit
CCME300/500(config)#interface Serial0/0/0
CCME300/500(config-if)#service-policy output LLQ_FOR_IPT
CCME300/500(config-if)#exit
Cisco Express Forwarding (IP CEF) must be enabled for the LLQ to operate correctly. Make
sure this in enabled in both routers (you remembered to configure LLQ on both routers, didn't
you). It may be enabled by default (check still), or it might be disabled, depending on the IOS
version. Enable it by IOS global configuration command ip cef .
CCME300/500(config)#ip cef
Check IP connectivity with ping, and make a test call, to generate both voice and data traffic.
You can verify your LLQ configuration by the following commands. show policy-map
displays also the default Committed Information Rate (CIR) and burst size, which we do not
alter in this lab. The last command in the following list displays the statistics of matched
packets as well, which is an ideal command to see whether the LLQ configuration is working
at all. Check this, and enclose the show policy-map interface output in your report.
CCME500#show
CCME500#show
CCME500#show
CCME500#show
run
class-map
policy-map
policy-map interface [int_number]
Measuring VoIP and FTP Performance

Amend your table with the following parameters for this QoS configuration:
Headquarters
Headquarters
Average data bandwidth for the FTP file transfer
Your subjective view of the voice quality in MOS (Mean Opinion Score) (15).
Record also the step (4.2) and QoS configuration (LLQ) by the results.

2*CCME, IOS 15, V. 5.1
22
Please double check that you get traffic into both classes with the show policy-map
interface command. Attach the output in your Report.
Reporting, Step 4.2: Based on the show policy-map interface command output, explain why
you are sure, that your LLQ scheduling is working properly. How much bandwidth is
allocated to RTP and data streams, while the G.711 VoIP call is on?
Step 4.3: Adding Traffic Policing to Low Latency Queuing, Step 3

Next, you will alter your QoS configuration so, that it restricts the non-VoIP bandwidth consumption to 20
kbit/s.
This time, we modify the IOS policy-map VOIP default class class-default (created by
default by IOS) of both routers. Limit the Best Effort = class-default bandwidth by policing it
strictly to 20 000 bit/s (police 20000) by dropping excessive packets. This leaves the rest of
the bandwidth (128k - 20k) for RTP traffic. This is called class-based policing. The two last
configuration lines are the default configuration, but are shown here for additional
information. Do not make any other alterations in router configurations.
CCME300/500(config)#policy-map LLQ_FOR_IPT
CCME300/500(config-pmap)#class class-default
CCME300/500(config-pmap-c)#police 20000
CCME300/500(config-pmap-c-police)#conform-action transmit
CCME300/500(config-pmap-c-police)#exceed-action drop
CCME300/500(config-pmap-c-police)#end
Depending on the IOS version, you may have to combine the police, conform-action and
exceed-action commands as a single command.
Check IP connectivity with ping, and make a test call, to generate both voice and data traffic.
You should verify your LLQ configuration by the show policy-map interface
command, which displays the statistics of matched packets as well. This is an ideal command
to see whether the configuration is working at all. Clear interface and policy-map counters
with clear counters serial 0/0/0. Enclose the show policy-map interface output
on your report, with the Step 4.3 indication.
Measuring VoIP and FTP Performance
.

2*CCME, IOS 15, V. 5.1
23
Amend your table with the following parameters for this QoS configuration:
Headquarters
Headquarters
Average data bandwidth for the FTP file transfer
Your subjective view of the voice quality in MOS (Mean Opinion Score) (15).
Record also the step (4.3) and QoS configuration (LLQ&Policing) by the results.
Check and record the IP address parameters and routing tables of all equipment. Also record
the configurations for both routers.
Reporting, Step 4.3: How was your FTP file transfer behaving with this configuration? Why?
How much bandwidth is now allocated to IPT and data streams, during a VoIP call?
Present, in your own words, all QoS measures that were used during the project. Explain why
this final configuration should theoretically be the best choice for a VoIP QoS configuration.
Generally, what is the most suitable QoS configuration of this whole lab exercise according
to your own experiences?
Reporting, Task 4: Prepare a table of your traffic measurement results for Steps 13, and
explain the results. Include also a comparison with the theoretical relative voice and data
service levels, and explain how well your subjective and objective results match with the
theory.
Reporting, Tasks 14: Review your preliminary lab report, submitted at the beginning of the
project. Compare the actual routing table entries with your plan. Explain any differences, if
there are any. Submit the third report including all steps of Task 4.
Task 5 Video Streaming

In this last task, you will expand voice services with local video streaming in the headquarters. Pre-recorded
video clips will be distributed using IP/UDP/RTP transport. Client workstations can join a multicast and start
playing the stream. Because of the high bandwidth needed for video, streaming services will be limited (during
this project) just for the Headquarters site.
Step 5.1: Video Streaming Server

Video content, streaming server, streaming client software in client workstations, and video
compatible network is needed for a video distribution system. Our goal is to set up a simple
streaming system for prerecorded clips for HQ site users.
The HQ workstation (not the Wireshark host) will be the video streaming server. Open the
VLC application (2.1.5) in the video server host. Using the VLC Streaming/Exporting wizard,
set it up to stream a sample .mp4 video clip as RTSP controlled stream, from the local drive

2*CCME, IOS 15, V. 5.1
24
(Source), using RTSP control (Destination). Use any suitable UDP port. Select to display the
video locally for troubleshooting, and disable transcoding. (VLC Menus > Media >
Streaming...Source > File: File Selection: Add... > Select a video file > Open > Stream >
Next. You will stream to a RTSP-controlled stream (Destinations: RTSP Stream > Add).
Make a note of the port, and leave the path as default (/). We don't need (or want to use)
transcoding. Select the tickbox for sending all element streams.
Make sure, that the video is displayed locally with good quality.
Step 5.2: Playing the Video Clip with VLC Client

We won't need a workstation in the Remote site any more, so you can move it to the
Headquarters switch, to be used as a streaming client. Check switchport configurations,
change the IP address of the workstation to the HQ subnet, and check IP connectivity between
the new streaming client in HQ and the HQ video server. Change port monitoring settings for
the Wireshark host so, that it monitors all packets sent and received by the streaming client
(the former Remote host). Make sure, that you will see copies of all the frames sent to and
received by the streaming client workstation in Wireshark (and you still have IP connectivity
between the server and the workstation).
On the destination workstation, select the destination stream by entering the RTSP URL of
the server and the program (VLC Menus > Media > Open Network...) and start watching the
video.
Start capturing video streaming traffic in the Wireshark host. Wireshark may not decode RTP
PDUs correctly, because of the non-standard UDP port number. If needed, we can add a
Decode rule manually: Wireshark > Select a UDP datagram > Analyze > Decode As >
Decode UDP destination (5004) port(s) as RTP > Apply.
Study the video traffic, and IP and RTP PDU header fields with Wireshark, and find out
answers to the questions in the reporting section.
Reporting Task 5, Steps 5.1 and 5.2: How much bandwidth does this video streaming
consume, in bits/s? Would it be possible to use the HQ-Remote connection of the previous IP
Telephony system for good quality video transport with tight QoS rules?
How often RTP messages are sent? To which address? Why this address?
Figure out, how RTP can help in detecting lost and mis-ordered packets.
Submit your final report in time.
Extra: To earn extra points for your group, please list all errors, unclear items and
improvement ideas for the lab instructions, to promote thorough learning of the subject.

Ipm Lab Instructions V5dot1

Uploaded by

Document Information

Original Description:

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

Ipm Lab Instructions V5dot1

Uploaded by

Copyright:

Available Formats

LAB WORK INSTRUCTIONS

2*CCME, IOS 15, V. 5.1

IP Multimedia Systems Lab:

Task 1. IP Telephony System Setup

Task 2. Further Router Configuration

Task 3. Preparing for QoS

Task 4. Configuring QoS Components

Task 5. Video Streaming

LAB WORK INSTRUCTIONS

Task 1. IP Telephony System Setup

LAB WORK INSTRUCTIONS

Figure 1. Initial Lab Network Diagram for Step 1.1.

LAB WORK INSTRUCTIONS

LAB WORK INSTRUCTIONS

LAB WORK INSTRUCTIONS

Step 1.2: Adding a WAN Link for a Remote Office

Figure 3: Two-site IP Telehone system of Step 1.3.

LAB WORK INSTRUCTIONS

LAB WORK INSTRUCTIONS

Connecting the Remote IP Phone

LAB WORK INSTRUCTIONS

Task 2. Further Router Configuration

LAB WORK INSTRUCTIONS

Test by calling to 327 from 301.

Step 2.2: Dual CCME System

Figure 4: Two CCME network of Step 2.2.

*) Please wait 10 seconds for the number analysis to complete

LAB WORK INSTRUCTIONS

Basic Telephony Service Setup in the Remote Office

LAB WORK INSTRUCTIONS

Next, we give instructions how to route calls to these directory numbers:

With IOS 15.1 and later, we have to disable peer authentication:

LAB WORK INSTRUCTIONS

Task 3. Preparing for QoS

Figure 5: Final VoIP lab setup.

Amend your document with physical interface information.

LAB WORK INSTRUCTIONS

LAB WORK INSTRUCTIONS

First, IOS Versions

NTP Time Synchronization

End with CNTL/Z.

CCME300(config)#ntp server 10.0.3.1

End with CNTL/Z.

LAB WORK INSTRUCTIONS

End with CNTL/Z

You should check the configuration with sh ip sla configuration 1.

LAB WORK INSTRUCTIONS

Latency one-way time:

LAB WORK INSTRUCTIONS

LAB WORK INSTRUCTIONS

Task 4 Configuring QoS Components

LAB WORK INSTRUCTIONS

Step 4.2: Inspecting Low Latency Queuing, Step 2

LAB WORK INSTRUCTIONS

Measuring VoIP and FTP Performance

LAB WORK INSTRUCTIONS

Step 4.3: Adding Traffic Policing to Low Latency Queuing, Step 3

LAB WORK INSTRUCTIONS

Task 5 Video Streaming

Step 5.1: Video Streaming Server

LAB WORK INSTRUCTIONS

Step 5.2: Playing the Video Clip with VLC Client