-
LAB WORK INSTRUCTIONS 2*CCME, IOS 15, V. 5.1
1
IP Multimedia Systems Lab: Cisco CallManager Express, Work
Instructions
Contents Objectives 2 Theoretical Background 2 Prerequisites 2
Task 1. IP Telephony System Setup 2 Step 1.1: Local IP PBX 2 Step
1.2: Adding a WAN Link for a Remote Office 6 Task 2. Further Router
Configuration 9 Step 2.1: Digit Manipulation 9 Step 2.2: Dual CCME
System 10 Task 3. Preparing for QoS 13 Step 3.1: Inspecting VoIP
Call Bandwidth Usage 13 Step 3.2: Inspecting Network Delay, Delay
Variation And Packet Drop Rate 14 Step 3.3: Inspecting Network
Service Levels for Voice and Data 18 Task 4. Configuring QoS
Components 19 Step 4.1: Inspecting FIFO Scheduling Operation, Step
1 19 Step 4.2: Inspecting Low Latency Queuing, Step 2 22 Step 4.3:
Adding Traffic Policing to Low Latency Queuing, Step 3 22 Task 5.
Video Streaming 23 Step 5.1: Video Streaming Server 23 Step 5.2:
Playing the Video Clip with VLC Client 24
-
LAB WORK INSTRUCTIONS 2*CCME, IOS 15, V. 5.1
2
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
-
LAB WORK INSTRUCTIONS 2*CCME, IOS 15, V. 5.1
3
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]
-
LAB WORK INSTRUCTIONS 2*CCME, IOS 15, V. 5.1
4
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
telephony-services. 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
-
LAB WORK INSTRUCTIONS 2*CCME, IOS 15, V. 5.1
5
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 5 CCME(config-ephone-dn)#number 304
CCME(config-ephone-dn)#exit CCME(config)#ephone 1
CCME(config-ephone)#exit ... CCME(config)#ephone 5
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 telephony-service 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 1 CCME(config-ephone-dn)#label 301 CCME
CCME(config-ephone-dn)#exit
-
LAB WORK INSTRUCTIONS 2*CCME, IOS 15, V. 5.1
6
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 1 CCME(config-ephone)#restart
CCME(config-ephone)#exit 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)#ip
address 10.0.5.1 255.255.255.0 Router(config-if)#no shutdown
Router(config-if)#exit
-
LAB WORK INSTRUCTIONS 2*CCME, IOS 15, V. 5.1
7
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)#ip address
10.0.4.2 255.255.255.252 Router(config-if)#no fair-queue
Router(config-if)#no shutdown 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
-
LAB WORK INSTRUCTIONS 2*CCME, IOS 15, V. 5.1
8
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 2 CCME(config-ephone-dn)#label 302 REMOTE
CCME(config-ephone-dn)#exit CCME(config)#ephone 2
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.
-
LAB WORK INSTRUCTIONS 2*CCME, IOS 15, V. 5.1
9
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
-
LAB WORK INSTRUCTIONS 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
-
LAB WORK INSTRUCTIONS 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:
-
LAB WORK INSTRUCTIONS 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.
-
LAB WORK INSTRUCTIONS 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.
-
LAB WORK INSTRUCTIONS 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.
-
LAB WORK INSTRUCTIONS 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. End with
CNTL/Z. CCME300(config)#ntp master 2 CCME300(config)#ntp server
10.0.3.1 CCME500#conf t Enter configuration commands, one per line.
End with CNTL/Z. CCME500(config)#ntp server 10.0.3.1
CCME500(config)#end
-
LAB WORK INSTRUCTIONS 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 Enter configuration commands, one
per line. End with CNTL/Z CCME500(config)#ip sla responder
CCME500(config)#end 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 codec-numpacket 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
-
LAB WORK INSTRUCTIONS 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.
-
LAB WORK INSTRUCTIONS 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.
-
LAB WORK INSTRUCTIONS 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
-
LAB WORK INSTRUCTIONS 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, policy-map 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.
-
LAB WORK INSTRUCTIONS 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 run CCME500#show
class-map CCME500#show policy-map CCME500#show policy-map interface
[int_number] Measuring VoIP and FTP Performance
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. Amend your table with the following parameters for this QoS
configuration: One-way network delay (latency) for the simulated
RTP packets from Remote Office to Headquarters Average packet loss
percent for the simulated RTP packets from Remote Office to
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.
-
LAB WORK INSTRUCTIONS 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
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. .
-
LAB WORK INSTRUCTIONS 2*CCME, IOS 15, V. 5.1
23
Amend your table with the following parameters for this QoS
configuration: One-way network delay (latency) for the simulated
RTP packets from Remote Office to Headquarters Average packet loss
percent for the simulated RTP packets from Remote Office to
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
-
LAB WORK INSTRUCTIONS 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.