Ipm Lab Instructions v5dot1

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


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


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]


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


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


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


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


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.


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


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


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:


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.


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.


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

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


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


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.


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


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.


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




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.


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




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


24

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

Ipm Lab Instructions v5dot1

Documents

Transcript of Ipm Lab Instructions v5dot1