Sei sulla pagina 1di 24

LAB WORK INSTRUCTIONS 2*CCME, V. 5.

IP Multimedia Systems Lab: Cisco CallManager Express, Work Instructions

Contents
Objectives Theoretical Background Prerequisites Task 1. IP Telephony System Setup Step 1.1: Local IP PBX Step 1.2: Adding a WAN Link for a Remote Office Task 2. Further Router Configuration Step 2.1: Digit Manipulation Step 2.2: Dual CCME System 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 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 Task 5. Video Streaming Step 5.1: Video Streaming Server Step 5.2: Playing the Video Clip with VLC Client 2 2 2 2 2 6 9 9 10 13 13 14 16 16 16 17 19 20 20 20

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0

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. All lab groups must return the report for the preliminary lab task when arriving to the lab for the first time.

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 Feature Set IOS), two Cisco Catalyst 2950/2960/3550/3560 switches (preferably 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

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0 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.

Figure 1. Initial Lab Network Diagram for Step 1.1. 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 behind the More button. Cisco CallManager Express Router Configuration Basic Router Setup Erase any previous configurations of the router and the switch:
Router/Switch#erase start 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, V. 5.0 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

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 Setup 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. A new basic configuration dialog script is initiated by:
CCME(config)#telephony-service setup

With the following dialogue, you assign a DHCP address pool for the DHCP clients (IP phone sets), deliver the CCME address to them, and do basic IP PBX setup with automatic directory number assignment.
Do you want to setup DHCP service for your IP Phones? [yes/no]: yes IP network for telephony-service DHCP Pool:10.0.3.0 Subnet mask for DHCP network :255.255.255.0 TFTP Server IP address (Option 150):10.0.3.1 Default Router for DHCP Pool:10.0.3.1 Do you want to start telephony-service setup? [yes/no]: yes Enter the IP source address for Cisco IOS Telephony Services: 10.0.3.1 Enter the Skinny Port for Cisco IOS Telephony Services : [2000]:

Press

enter to confirm.

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0


How many IP phones do you want to configure : [0]: 5

Do you want dual-line extensions assigned to phones? [yes/no]: no

(This would

mean double extension number allocation for each telephone line.)


What Language do you want on IP phones [0]: Press enter to choose English. Which Call Progress tone set do you want on IP phones [0]:

Press enter to

choose US. Choose a first call extension number, e.g. 301, but remember the consistency throughout the lab exercise. This setting makes the default extension number allocation.
What is the first extension number you want to configure : Do you have Direct-Inward-Dial service for all your phones? [yes/no]: no

(This is for PSTN trunk lines only.)


Do you want to forward calls to a voice message service?[yes/no]: no Do you wish to change any of the above information? [yes/no]: no

(If you answered yes, you have to start all over again.) 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.

Then 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 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 #.

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0


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.

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. REMOTE Router Configuration Erase both the REMOTE router and the switch:
Router/Switch#erase start 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, V. 5.0

Choose an 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, V. 5.0

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), 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:
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, V. 5.0

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

Make some test calls for example from 302 to 301 by dialing 977317 (*.

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0

10

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, V. 5.0


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

11

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 remove the remote DHCP pool:
REMOTE(config)#hostname CCME500 CCME500(config)#no ip dhcp pool REMOTE

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:
CCME500(config)#telephony-service setup Do you want to setup DHCP service for your IP Phones? [yes/no]: yes IP network for telephony-service DHCP Pool:10.0.5.0 Subnet mask for DHCP network :255.255.255.0 TFTP Server IP address (Option 150) :10.0.5.1 Default Router for DHCP Pool :10.0.5.1 Do you want to start telephony-service setup? [yes/no]: yes Enter the IP source address for Cisco IOS Telephony Services: 10.0.5.1 Enter the Skinny Port for Cisco IOS Telephony Services : [2000]:

Press

enter to confirm.
How many IP phones do you want to configure : [0]: 5

Do you want dual-line extensions assigned to phones? [yes/no]: no What Language do you want on IP phones [0]: Press enter to choose English. Which Call Progress tone set do you want on IP phones [0]:

Press enter to

choose US. Choose a first call extension number, e.g. 501, but remember the consistency throughout the lab exercise. This setting makes the default extension number allocation.
What is the first extension number you want to configure: Do you have Direct-Inward-Dial service for all your phones? [yes/no]: no Do you want to forward calls to a voice message service?[yes/no]: no Do you wish to change any of the above information? [yes/no]: no

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0

12

Power off the Remote IP phone set for a short while. Wait for the remote IP phone registration. 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:
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

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, V. 5.0

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 3550/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 transmitted frames 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/#

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.

*) 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, V. 5.0

14

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? 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 (*. Cisco IP SLA UDP Jitter offers detailed delay, jitter and packet loss information, but it needs quite a few additional components. 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:

*) 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, V. 5.0


HQ#sh ip sla application IP Service Level Agreement Monitor Version: Round Trip Time MIB 2.2.0, Infrastructure Engine-II Time of last change in whole IP SLA Monitor: 10:29:17.483 EET Thu Feb 23 2012 Estimated system max number of entries: 29022 Estimated Number of Number of Number of Number of Type Type Type Type Type Type Type Type Type Type Type Type of of of of of of of of of of of of number of configurable operations: 29020 Entries configured : 2 active Entries : 2 pending Entries : 0 inactive Entries : 0 Operation Types Perform: dhcp Perform: dns Perform: echo Perform: frameRelay Perform: ftp Perform: http Perform: jitter Perform: pathEcho Perform: pathJitter Perform: tcpConnect Perform: udpEcho Perform: voip

15

Supported Operation to Operation to Operation to Operation to Operation to Operation to Operation to Operation to Operation to Operation to Operation to Operation to

IP SLA Monitor low memory water mark: 3963104

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 10:09:00 ? <1-31> Day of the month MONTH Month of the year CCME300#clock set 10:09:00 Feb 23 2012 CCME300# *Feb 23 08:09:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 10:16:45 EET Thu Feb 23 2012 to 10:09:00 EET Thu Feb 23 2012, configured from console by console. CCME300#sh clock 10:09:05.519 EET Thu Feb 23 2012

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 CCME300(config)#ntp server 10.0.3.1 CCME500#conf t Enter configuration commands, one per line. End with CNTL/Z. End with CNTL/Z.

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0


CCME500(config)#ntp server 10.0.3.1 CCME500(config)#end

16

You should check NTP association and result with show ntp associations, show ntp status and show clock. 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 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#conf t Enter configuration commands, one per line. End with CNTL/Z. HQ(config)#ip sla 1 CCME300(config-sla-monitor)#$ udp-jitter 10.0.5.1 6000 codec g711alaw codec-numpacket 5 codec-nterval 10 codec-size 172 source-ip 10.0.3.1 CCME300(config-sla-monitor-jitter)#dest-ipaddr 10.0.5.1 CCME300(config-sla-monitor-jitter)#dest-port 6010 CCME300(config-sla-monitor-jitter)#tos 184 CCME300(config-sla-monitor-jitter)#frequency 10 CCME300(config-sla-monitor-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 monitor configuration 1. The network should treat these ICMP packets like RTP (***. Let's check the output. On a unused network, the delay is low, and no packets are dropped:
HQ#sh ip sla statistics 1 Round trip time (RTT) Index 1 Latest RTT: 27 ms Latest operation start time: 11:13:31.263 EET Thu Feb 23 2012 Latest operation return code: OK

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0


RTT Values Number Of RTT: 10 RTT Min/Avg/Max: 27/27/27 ms Latency one-way time milliseconds Number of one-way Samples: 5 Source to Destination one way Min/Avg/Max: 14/14/14 ms Destination to Source one way Min/Avg/Max: 13/13/13 ms Jitter time milliseconds Number of SD Jitter Samples: 4 Number of DS Jitter Samples: 4 Source to Destination Jitter Min/Avg/Max: 0/0/0 ms Destination to Source Jitter Min/Avg/Max: 0/0/0 ms Packet Loss Values Loss Source to Destination: 0 Loss Destination to Source: 0 Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0 Voice Score Values Calculated Planning Impairment Factor (ICPIF): 0 Mean Opinion Score (MOS): 0 Number of successes: 1 Number of failures: 0 Operation time to live: Forever

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.

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0

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-monitor)#ftp get ftp://10.0.5.2/smaller.bmp sourceipaddr 10.0.3.1 CCME300(config-sla-monitor-ftp)#frequency 30 CCME300(config-sla-monitor-ftp)#exit CCME300(config)#p 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 1 restart 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. 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.

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0 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.

19

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. 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. Make a call, then restart the UDP jitter test. After 20 seconds or more, check the IP SLA monitor results for both tests. 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 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 Average packet loss percent for the simulated RTP packets from Headquarters to Remote Office 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.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.

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0

20

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), and both should go to the IPT class (**.
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 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

*) 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 (and 4610 = 101 110 in tcmonlite) indicates EF DSCP. Such packets should match class-map IPT rules.

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0

21

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]

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. Make a call, then restart the UDP jitter test. After 20 seconds or more, check the IP SLA monitor results for both tests. 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. 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?

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0

22

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

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. 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. Make a call, then restart the UDP jitter test. After 20 seconds or more, check the IP SLA monitor results for both tests. 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.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.

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0

23

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 streams (and program advertisements) will be distributed using IP multicast. 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. We will use RTP transport over IP multicast, and announce the program(s) with Service Advertisement Protocol. The HQ workstation (not the Wireshark host) will be the video streaming server. Open the VLC application (1.1.7, The Luggage) in the video server host. Using the VLC Streaming/Exporting wizard, set it up to stream a sample .ps video clip with MPEG TS details, from the local drive (Source), to a privately scoped multicast address (239.255.0.0 239.255.255.254), using RTP stream (Destination), with SAP announcements (Options). Use any suitable UDP port. In a pure Layer 2 network, you can use the default Time to Live of 1. Select to display the video locally for troubleshooting, and disable transcoding. Add SAP announcement and program details. (VLC Menus > Media > Streaming... > File: File Selection: Add... > Select a video file > Open > Stream > Next > Destinations: New destination: RTP/MPEG Transport Stream > Add > Give the multicast address and Base port > Next > Miscellaneous Options: Enable SAP announce, and give the announcement text and group > Stream). Make sure, that the video is displayed locally with good quality.

LAB WORK INSTRUCTIONS 2*CCME, V. 5.0

24

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. Check switchport configurations, change the IP address of the workstation to the HQ subnet, and check IP connectivity between the new HQ workstation and the HQ video server. Change port monitoring settings for the Wireshark host so, that it monitors the receiving workstation (the former Remote host). Make sure, that you will see copies of all the frames sent to the receiving workstation in Wireshark (and you still have IP connectivity between the server and the workstation). The server advertises the multicast IP address, the UDP port, and availability of the stream with SAP. On the destination workstation, browse for announced programs (VLC menus > View > Playlist > Local Network > Network streams (SAP)), and join receiving the multicast RTP stream. Then play the stream. 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 video and SAP 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 a SAP advertisement is sent? To which address? Why this address? 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.

Potrebbero piacerti anche