CCNP 3 v4 Module 8 Configuring Campus Switches to Support Voice and Video Applications

1. CCNP 3 v4 Module 8 Configuring Campus Switches to Support Voice and Video Applications

2. Objectives • Accommodating Voice Traffic on Campus Switches • Configuring IP Multicast

3. Overview • Campus networks carry a variety of data with diverse purposes and impacts on resources. • Proper design and configuration efforts will ensure that voice, video and data traffic efficiently coexist on a single Campus Infrastructure.

4. Cisco Infrastructure • Cisco recommends an end-to-end single vender (Cisco) solution. • This way, each new application such as video, Web, or telephony represents just another media type over the same infrastructure. • Tasks such as QoS configuration and network upgrades are made easier by using a single vendor.

5. IP Telephony Integration

6. Voice VLANs • Cisco Catalyst switches offer a "voice VLAN" feature. • The voice VLAN, also known as an auxiliary VLAN, provides automatic VLAN association for IP phones. • Voice traffic is on a specific VLAN, and IP subnet even though voice and data co-exist on the same physical infrastructure.

7. Voice VLANs When a phone is connected to the switch, the switch sends necessary voice VLAN information to the IP phone.

8. Voice VLANs and Data VLANs • Placing phone traffic onto a distinct VLAN allows the phone traffic to be segmented from the data traffic. • QoS or security policies can be enforced specifically for the traffic traversing the phone VLANs without affecting the data traffic.

9. Connecting a PC to the IP Phone • To save switchport density and cable runs, a PC can be connected to the integrated switch of the IP Phone. • In order for the device and the phone to communicate, one of the following must be true: • They both use the same Layer 2 frame type. • The phone uses 802.1p frames and the device uses untagged frames. • The phone uses untagged frames and the device uses 802.1p frames. • The phone uses 802.1Q frames, and the voice VLAN equals the native VLAN.

10. Connecting a PC to the IP Phone

11. Voice Design Considerations • Deploying IP telephony in the enterprise campus requires the implementation of various features particular to each submodule. • Within the Building Access submodule, these features support IP telephony: • Voice VLANs • 802.1p/Q • Hardware support for multiple output queues • Hardware support for in-line power to IP phones • PortFast • Root Guard • Unidirectional Link Detection (UDLD) • UplinkFast

12. IP Telephony on the Network • IP telephony places strict requirements on the network infrastructure. • Most IP telephony installations are built on an existing network infrastructure. • To support voice traffic the network may require enhancements and upgrades with priority given to voice traffic.

13. Campus Infrastructure Considerations • What features are required for each network device? • VLAN configuration, QoS, inline power • Can the physical plan support IP Telephony? • Cat5e minimum, available switchports and wall jacks • How will the phones be powered? • PoE on the switch or a separate inline power patch panel, power bricks • Is adequate bandwidth available? • What other bandwidth intensive applications are running? • Will a VoIP implementation require an complete network overhaul?

14. Quality of Service • QoS is the application of features and functionality required to actively manage and satisfy networking requirements of applications sensitive to loss, delay, and delay variation (jitter). • QoS allows preference to be given to critical application flows for the available bandwidth.

15. QoS and Voice Traffic • Congestion and latency can be caused by speed mismatches, many-to-one switching fabrics and aggregation. • When packets are dropped due to network congestion, these packets must be retransmitted, causing further congestion. • QoS ensures that prioritized voice traffic is not subject to the existing network congestion and latency.

16. Switchport Commands for VoIP QoS

17. Switch Configuration Example Switch(config)#interface fastethernet 0/4 Switch(config-if)#switchport voice vlan 110 Switch(config-if)#mls qos trust cos Switch(config-if)#mls qos trust device cisco-phone Switch(config-if)#ctrl-Z Switch#show interfaces fastethernet 0/4 Switch#show mls qos interface fastethernet 0/4 FastEthernet0/4 trust state: trust cos trust mode: trust cos COS override: dis default COS: 0 pass-through: none trust device: cisco-phone

18. Step-by-Step Configuration

19. QoS by Network Layer

20. Delay and Packet Loss • Delay (or latency) is the amount of time that it takes a packet to reach the receiving endpoint from the sending endpoint. • This time period is termed the "end-to-end delay" • End-to-end delay can be broken into two areas: • Fixed network delay • Variable network delay • Fixed network delay includes encoding and decoding time (for voice and video), as well as the amount of time required to traverse the media en route to the destination. • Variable network delay refers to network conditions, such as congestion, that may affect the overall time required for transit.

21. Types of Delay • Packetization delay – The amount of time that it takes to segment data, sample and encode signals, process data, and turn the data into packets • Serialization delay – The amount of time that it takes to place the bits of a packet encapsulated in a frame, onto the physical media • Propagation delay – The amount of time that it takes to transmit the bits of a frame across the physical wire • Processing delay – The amount of time that it takes for a network device to take the frame from an input interface, place it into a receive queue, and then place it into the output queue of the output interface • Queuing delay – The amount of time that a packet resides in the output queue of an interface • Delay variation – Delay variation (or jitter) is the difference in the end-to-end delay between packets.

22. Classification and Marking

23. Layer 2 Marking: 802.1p and CoS

24. Layer 3 Marking: ToS, IP Precedence, DSCP

25. Best Effort • Best-effort is a single service model in which an application sends data whenever it must, in any quantity, without requesting permission or first informing the network. • Best-effort service is suitable for a wide range of networked applications such as general file transfers, e-mail and Web browsing.

26. Differentiated Services • The Differentiated Services or DiffServ is an IETF architecture standard. • This architecture specifies that each packet is classified upon entry into the network. • The classification is carried in the IP packet header, using either the IP precedence or the preferred Differential Services Code Point (DSCP).

27. Precedence and DSCP • Represented using the first three (precedence) or six (DSCP) bits of the Type of Service (ToS) field. • The first 3 DSCP bits are the class selector bits • The second 3 DSCP bits are the drop precedence bits • Classification can also be carried in the Layer 2 frame in the form of the Class of Service (CoS) field embodied in ISL and 802.1Q frames.

28. Assured Forwarding - AF Expedited Forwarding - EF Class Selector - Priority Class 5 101 40 – 47 (46) Internetwork Control Class Selector Bits Class 6 110 48 – 55 Drop Precedence - Priority Network Control Class 7 111 56 – 63 DSCP Code Points

29. Layer 2 and 3 DiffServ

30. Layer 2 and QoS • At the Datalink layer a raw Ethernet frame has no fields to signify its QoS requirements. • If QoS marking is required, then ISL or 802.1Q/p must be used as these provide a three-bit Class of Service (CoS) field.

31. Layer 3 and QoS • At the Network layer an IP packet contains a one byte Type of Service (ToS) field, of which the first three bits form the IP-Precedence field and the first six bits form the DSCP fields. • Either of these can be used to signify the QoS requirements of an IP packet but not both. • DSCP has precedence

32. CoS ToS – IP Precedence ToS – DSCP QoS, CoS and ToS

33. Modular QoS CLI (MQC) • The Modular QoS Command Line Interface or MQC is central to Cisco’s model for implementing IOS based QoS solutions. • The MQC breaks down the tasks associated with QoS into modules that: • Identify traffic flows. • Classify traffic flows as belonging to a common class of QoS. • Apply QoS policies to that class. • Define the interfaces on which the policy should be enforced. • The modular nature of MQC allows the reuse of common traffic classes and policies.

34. Creating Class-maps • The class-map command is used to define a traffic class. • The purpose of a traffic class is to classify traffic that should be given a particular QoS. • A traffic class contains three major elements: • a name - cisco • a series of match commands - match • and if more than one match command exists in the traffic class, how to evaluate these match commands match-all | match-any

35. Class-map Commands switch(config)#ip access-list standard test Switch(config)#class-map match-any cisco Switch(config-cmap)#match access-group name test Switch(config-cmap)#match interface fastethernet 0/1 • On the Catalyst 3550 and 6500 the Modular QoS CLI allows multiple traffic classes to be configured as a single traffic class, such as nested traffic classes, or nested class maps. • This nesting can be achieved with the use of the match class-map command.

36. Policy-maps • The policy-map command is used to create a traffic policy. • The purpose of a traffic policy is to configure the QoS features to be associated with the traffic that has been classified in the traffic class. • Traffic policy contains three elements: • Policy Name • Traffic class specified with the class command • QoS policies to be applied to each class

37. Apply to outgoing packets Policy and Class-map Commands Switch(config)#policy-map policy1 Switch(config-pmap)#class cisco Switch(config-pmap-c)#bandwidth 3000 Switch(config-pmap-c)#exit Switch(config-pmap)#class class-default Switch(config-pmap-c)#bandwidth 2000 Switch(config-pmap)#exit • The service policy command is used to attach the traffic policy to an interface. Switch(config)#interface fastethernet 0/1 Switch(config-if)#service-policy output policy1 Switch(config-if)#exit

38. Classification at Access Layer • In order to be effective, QoS should be implemented end-to-end within a network as soon as possible at the network edge or access layer. • Frames and packets can be marked as important by using Layer 2 Class of Service (CoS) settings in the User Priority bits of the 802.1p portion of the 802.1Q header or • The IP Precedence/Differentiated Services Code Point (DSCP) bits in the Type of Service (ToS) Byte of the IPv4 header

39. Trust – Do you trust me? • In order to take advantage of COS at the edge then the access layer device must “trust” the QoS devices/applications it is connected to. • The default action is for a switch with QoS features activated not to trust edge devices that have written CoS features into the frame. • Any frames that enter the switch will have their CoS re-written to the lowest priority of zero. • If the edge device can be trusted then the switch will switch the frame without changing the Cos setting.

40. Trusted Untrusted Trusted Trusted vs. Untrusted Ports

41. QoS Trust Boundaries

42. Class of Service at the Switch • Depending on the switch model, it may be necessary to first activate QoS: switch(config)#mls qos • This command is required on both the Catalyst 3550 and the Catalyst 6500. • The Catalyst 2950 has QoS enabled by default. • The trust is configured on the switch port using the command: switch(config-if)#mls qos trust cos

43. Remember Native VLAN? • If an untagged frame arrives at the switch port, the switch will assign a default CoS to the frame before forwarding it. (native VLAN) • By default untagged frames are assigned a CoS of zero. • This can be changed using the interface configuration command: switch(config-if)#mls qos cos [cos-value] • Where [cos-value] is a number between 0 and 7. • Traffic that passes through the port will be automatically tagged with the new CoS value.

44. Override the CoS Field • In some cases it may be desirable not to trust any CoS value that may be present in frames sourced from an edge device. • For this reason, it is possible to use the override parameter to tell the switch to ignore any existing CoS value that may be in the frame and apply the default value. switch(config-if)#mls qos cos [cos-value] Switch(config-if)#mls qos cos override • This will re-write the CoS value for any frame entering the switch port to the default setting.

45. MAC ACL to Assign DSCP • It is not always possible to classify the CoS of a frame, based on an ingress port. • The ingress port may be attached to a hub or a simple workgroup switch that does not support QoS. • This hub or switch may be connecting to multiple workstations that all require different CoS values. • Differing types of devices may be on the same subnet (IP ACL will not work)

46. MAC ACL to Assign DSCP • Not all frames can be assigned a CoS based on ingress port

47. Configure a MAC ACL • However, in the QoS context, the permit and deny actions in the access control entries (ACEs) have different meanings than with security ACLs: • If a match with a permit action is encountered, known as the first-match principle, the specified QoS-related action is taken. • If a match with a deny action is encountered, the ACL being processed is skipped, and the next ACL is processed. • If no match with a permit action is encountered and all the ACLs have been examined, no QoS processing occurs on the packet. Switch(config)#mac access-list extended [name]

48. MAC ACL Example Switch(config)#mac access-list extended receptionph Switch(config-ext-macl)#permit host 000.0a00.0111 any Switch(config-ext-macl)#exit Switch(config)# Switch(config)#class-map match-all ipphone Switch(config-cmap)#match access-group name receptionph Switch(config-cmap)#exit Switch(config)#policy-map inbound-accesslayer Switch(config-pmap)#class ipphone Switch(config-pmap-c)#set ip dscp 40 Switch(config-pmap-c)#exit Switch(config)#interface range fastethernet 0/1 - 24 config-if-range)#service-policy input inbound-accesslayer

49. Using an IP ACL • Using the Modular QoS Command Line Interface (MQC) it is possible to classify traffic based on its IP or TCP properties • In this FTP example, an IP ACL is used to identify the packets: Switch(config)#ip access-list extended 100 Switch(config-ext-nacl)#permit tcp any any eq ftp • Traffic is classified as “reducedservice” if it is permitted by the access list. Switch(config)#class-map reducedservice Switch(config-cmap)#match access-group 100

50. Policing and Marking “out of profile” • Traffic policing involves placing a constraint on the maximum traffic rate. • When the traffic rate reaches the configured maximum rate, excess traffic is dropped or remarked to a lower DSCP value