Ipm Lab Instructions V5dot1
Ipm Lab Instructions V5dot1
Ipm Lab Instructions V5dot1
Contents
Objectives
Theoretical Background
Prerequisites
2
2
2
2
2
6
9
9
10
13
13
19
19
22
22
23
23
24
14
18
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.
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
the routers during the lab exercise, because of possible unexpected influence in the
phenomenon under study.
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
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 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 1
CCME(config-ephone-dn)#label 301 CCME
CCME(config-ephone-dn)#exit
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.
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
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
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
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.
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
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
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
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:
12
CCME500(config-dial-peer)#destination-pattern 30.
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
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.
13
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.
15
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
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.
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 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
17
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.
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.
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.
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
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.
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.
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]
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?
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.
.
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.
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.