Troubleshooting Video Issues in a Converged Network
The growth of video and rich media in enterprises not only strains networks, it also fundamentally changes them. Current IP networks must evolve to better handle rich media in its many forms and formats. Traditional IP networks struggle with interactive and real-time requirements, make delivery and quality of media unpredictable, and increase complexity for the network operators and managers.
This section addresses the challenge of troubleshooting the network infrastructure supporting video and rich media traffic. This section has two parts: The first part outlines the considerations, requirements, and the common issues; the second part demonstrates troubleshooting methods that can be used to approach some of the potential problems you may face in your video-ready network.
Common Video-Integration Issues
Enterprises understand the need and significant benefit of adopting the various media-rich applications because they dramatically improve productivity, increase collaboration, and reduce cost. They also can help enterprises meet the challenge of globalization while simplifying and optimizing business processes and operations. Several different media-rich applications that can positively affect business are available for enterprises. High-definition room-based interactive video such as Cisco TelePresence and standard-definition desktop collaboration applications such as Cisco Unified Videoconferencing Systems are examples of such applications. There are also various streaming and broadcast types of video applications such as digital signage, video on demand (VoD), and video surveillance (see Figure 8-13).
All of these types of video applications have different characteristics: Some of them are less interactive, and some of them are more interactive. Some of them are more massive than the others, in terms of network traffic volume, reaching bigger audiences in the enterprise. All of these types of video applications impose strict requirements on the underlying network infrastructure and services.
This growing use of video on networks requires a better and intelligent network. Delivering new video experiences will place additional demands on IP networks in terms of performance, adaptability, and manageability. Networks will need to scale and deliver an optimized quality of experience (QoE), introducing additional complexity. Networks that were designed for an era of best-effort delivery, low bandwidth, and high latency do not work for video. Because video is the most demanding media type, a network optimized for interactive video will support many other rich-media types.
Converging video with data and voice is more complex than converging data and voice: It demands more considerations, and it imposes stricter requirements on the underlying IP network. As you look at the Figure 8-14, you notice the similarities of this diagram and its components with a voice-enabled network. In fact, the good news is that several components and infrastructure services are shared between video and voice applications. Sometimes the endpoints are the same, or at least integrated. Some of the critical protocols, such as SIP, are going to be the same too. SIP is a signaling protocol that is used to initiate, manage, and terminate voice calls but also video sessions. The end user is going to experience an integrated service (for example, IP phones and video solutions such as Cisco Unified Video Advantage coordinating a person-to-person videoconference transparently).
As you review the challenges of enabling video applications in the network, you will see the similarities with voice requirements, and also the differences. Both need end-to-end QoS; however, converging video into an IP network is much more complex than converging VoIP because video is much more bandwidth intensive and very bursty. A high-definition stream could require more than 20-Mbps bandwidth for delivery over the network. Packet sizes are much larger, and there are several different types of video applications, such as live and on-demand high-definition streaming video, high-definition video surveillance, desktop videoconferencing, and high-definition virtual-presence interactive video. Each type of video application has unique requirements and characteristics and requires a networkwide strategy to help ensure a high-quality user experience. Table 8-2 outlines the QoS requirements for some of the main video applications.
Table 8-2: Video Application QoS Requirements | Metric | Video Collaboration | Cisco TelePresence | Video Surveillance |
| Latency | 200 ms | 150 ms | 500 ms |
| Jitter | 10 ms | 10 ms | 10 ms |
| Loss | 0.05% | 0.05% | 0.5% |
In terms of high availability, video applications require millisecond-level network service recovery because video traffic cannot accept unpredictable or large network recovery timeouts. Therefore, convergence targets will be higher, and packet loss due to network outage must be minimal. This makes redundancy design and the convergence of routing protocols and spanning tree extremely critical.
Building a multicast-aware network is another important consideration. This lesson does not intend to be a multicast primer, and it will not detail multicast operations; however, it will try to identify the multicast components and explain the tools needed to verify their configuration and existence in routers and switches.
Finally, security is also a major matter for consideration. It is important to know how existing security controls affect video traffic. In simple terms, access control and threat management mechanisms need to consider the various protocols and traffic flows that result from a video-enabled network, and allow them to exist in a controlled manner. Similar to the voice deployments, the protocols that might need to be permitted are SIP, H.323, SCCP (Skinny), RTP, RTCP, and perhaps some others.
Multicast traffic is used to send the same data packets to multiple receivers efficiently. If you were to transport video across the network using unicast, the transmitter would send multiple copies of data, one copy for each receiver. Multicast transmission sends a single copy of data to multiple receivers (see Figure 8-15). The way multicast works is that the sender sends only one copy of a single data packet, but addressed to a group of receivers called a multicast group. Multicast groups are nothing more than IP addresses that use the Class D address space. Class D addresses are denoted by the high-order 4 bits of the address set to 1110. This results in the range of addresses 224.0.0.0 through 239.255.255.255. Downstream multicast routers replicate and forward the data packet to all those branches where receivers (might) exist. They do it intelligently; traffic will be forwarded only to those “branches” of the network where there are “subscribers” to the group. Receivers express their interest in multicast traffic by registering at their first-hop router.
This model and resulting protocols make video deployments more efficient, protecting bandwidth resources, saving in resource utilization on routers and switches and improving QoS and the user experience overall. There are two main protocols involved. In the multicast network, routers will run a multicast routing protocol, typically Protocol Independent Multicast (PIM) whose main role is to advertise the location of multicast receivers, by indicating which interfaces of each router “point” to receivers, and therefore should forward multicast streams. The second main component is the way receivers subscribe to groups, and announce themselves as members of the group. As illustrated in Figure 8-16, this is done in the LAN, typically using Internet Group Management Protocol (IGMP).
IGMP is a highly dynamic protocol. It will run on first-hop routers and LAN switches. Using this protocol is a requirement in multicast networks because it is the protocol that allows hosts to become members of multicast groups, maintain their membership, receive multicast traffic, and then leave their group and stop receiving multicast traffic. Figure 8-17 illustrates the process of a multicast client joining a multicast group using IGMP. Members joining a multicast group do not have to wait for a Membership Query from a router to join; they send an unsolicited report indicating their interest. This action reduces join latency for the end system joining if no other members are present. Once the Membership Report is received by the router, it starts advertising the news to the rest of the network. Multicast sources will forward traffic directed to the group to this router because there are members of the group that have joined it.
The multicast group will remain active and is advertised by the router as long as there are members in the group within that network segment. As long as there is at least one member, the group will remain active (see Figure 8-18).
At some point, users terminate their multicast based application and when they do, their applications send “leave” messages to the router. The router then sends a query, just to verify whether there are still members of the group in the segment. If a device replies, the group remains active and the router advertises it. If no reports are received, it means that there are no more members of the group in the segment. At that point, the router stops advertising the group to the rest of the network (see Figure 8-19).
Common video-integration issues include the following:
-
Excessive bandwidth utilization
-
Lack of control
-
Poor quality (lack of QoS)
-
Security issues (filtering of key protocols, and stateful requirements)
-
Multicast issues
The bursty nature of video traffic, along with its packet sizes and massive deployment, makes QoS a common problem. Video traffic tends to monopolize the available bandwidth, and at the same time it is a delay-sensitive application that must be protected and prioritized, to the detriment of other traffic classes. Your network security might also interfere with video traffic. Firewalls, ACLs, and other security controls can get in the way of protocols such as RTP, RTCP, SIP, H.323, and others. All of these protocols are critical to video traffic. You need to consider all these factors because you might have to change your security policies to allow video traffic in the network. Multicast configuration, if enabled in the network, is always a source of potential issues. In terms of IGMP, the only multicast protocol that was briefly explained here, common problems are related to group filtering, where routers might not accept join request from certain multicast group addresses. Another potential issue in multicast is related to differences in IGMP versions between the router and the hosts sending multicast traffic.
Video-Integration Troubleshooting Example: Performance Issues Due to STP Topology
The first troubleshooting example is based on the network topology shown in Figure 8-20. This case is a classic example of one of the most complex troubleshooting issues: performance. Users complain about “poor” performance of their video application. The scenario includes the switched network in the figure, where the video clients reside in two VLANS, 10 and 20, implemented in the access switch. The access switch is serviced by two distribution switches that connect the clients to the campus network, where the video server resides. The distribution switches have recently been upgraded to a new version of Cisco IOS Software. After the change, users started complaining about the poor performance.
Using a structured troubleshooting method, the first thing you need to do is to clarify what users mean by the “poor performance” of their application. You must translate the quality of user experience with the application into something tangible you can measure, such as delay, jitter, or packet loss. You should also try to determine the scope of the problem by finding out if the performance degradation occurring for all video applications, for all server destinations, or for all clients. After some information gathering, you have determined that the server location is inside the campus, and that the issue occurred after the change on the distribution switches. The exact symptom, as told by the users of the application is choppy video, long download and buffering times, and that streaming video stops every few seconds for the application to buffer video frames.
You will use a follow-the-path troubleshooting approach and start with the access switch, as it is the first device in the path between the clients and the server. At each device, you will use a bottom-up troubleshooting approach, checking the physical layer, and move up layer by layer according to the OSI model. On the access switch, you enter the show interfaces status command to see some Layer 1 and Layer 2 status information about all interfaces, as demonstrated in Example 8-38. The four trunks connecting this switch to the distribution layer switches show as connected and trunking.
Example 8-38: The Output of the show interfaces status on the Access Switch
ASW1# show interfaces status
Port Name Status vlan Duplex Speed Type
Fa0/1 disabled 1 auto auto 10/100BaseTX
Fa0/2 disabled 1 auto auto 10/100BaseTX
Fa0/3 connected 10 a-full a-100 10/100BaseTX
Fa0/4 disabled 1 auto auto 10/100BaseTX
Fa0/5 disabled 1 auto auto 10/100BaseTX
Fa0/6 disabled 1 auto auto 10/100BaseTX
Fa0/7 disabled 1 auto auto 10/100BaseTX
Fa0/8 disabled 1 auto auto 10/100BaseTX
Fa0/9 To DSW2 connected trunk a-full a-100 10/100BaseTX
Fa0/10 To DSW2 connected trunk a-full a-100 10/100BaseTX
Fa0/11 To DSW1 connected trunk a-full a-100 10/100BaseTX
Fa0/12 To DSW1 connected trunk a-full a-100 10/100BaseTX
Fa0/13 disabled 1 auto auto 10/100BaseTX
Fa0/14 disabled 1 auto auto 10/100BaseTX
Fa0/15 disabled 1 auto auto 10/100BaseTX
Fa0/16 disabled 1 auto auto 10/100BaseTX
Fa0/17 disabled 1 auto auto 10/100BaseTX
--More--
Next, you will verify that the trunks are allowing all the necessary VLANs. For that verification, you use the show interfaces command on one of the trunk interfaces, Fa 0/9 for example, and include the switchport keyword. As shown in Example 8-39, all VLANs are allowed on this trunk interface, and the interface is enabled and active. However, you also notice that this trunk is a member of a bundle, port channel 1. This indicates that the documentation is not complete, because its diagram does not specify EtherChannel connections between the switches.
Example 8-39: The Output Shows That All VLANs Are Allowed on the Trunk Interface
ASW1# show interfaces fa0/9 switchport
Name: Fa0/9
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk (member of bundle Po1)
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: on
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
--More--
You use the show etherchannel summary command to see a snapshot of the EtherChannel configuration, and see how these bundles are configured, as demonstrated in Example 8-40. The output shows two bundles, one for each of the distribution layer switches. It is a good practice to examine the traffic and utilization levels on these connections, so you immediately display the statistics for port channel 1 (physical interfaces Fa 0/9 and Fa 0/10) using the show interfaces po1 command.
Example 8-40: Cisco IOS IPS CLI Configuration
ASW1# show etherchannel summary
Flags: D - down P - in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 2
Number of aggregators: 2
Group Port-channel Protocol Ports
———+———————+—————+———————————————————————-
1 Po1(SU) - Fa0/9(P) Fa0/10(P)
2 Po2(SU) - Fa0/11(P) Fa0/12(P)
ASW1#
ASW1# show interfaces po1
Port-channel1 is up, line protocol is up (connected)
Hardware is EtherChannel, address is 001b.Oc91.7f8a (bia 001b.Oc91.7f8a)
Description: TO DSW2
MTU 1500 bytes, BW 200000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Full-duplex, 100Mb/s, link type is auto, media type is unknown
input flow-control is off, output flow-control is unsupported
Members in this channel: Fa0/9 Fa0/10
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 02:34:07, output hang never
Last clearing of "show interface" counters 01:16:51
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 619000 bits/sec, 59 packets/sec
5 minute output rate 616000 bits/sec, 54 packets/sec
275043 packets input, 354702160 bytes, 0 no buffer
Received 23141 broadcasts (0 multicast)
--More--
The indicators related to load are low (almost none), but you wonder if this is because the network is merely not congested at this moment. Therefore, you look at other indicators in the output, such as the 5-minute input/output rates, but those numbers are very low, too. Next, we look at the other port channel and compare the two. The numbers themselves might not be important, but differences in the numbers are. The output for the Po2 is shown in Example 8-41, and you can see marked differences between the two uplinks. In fact, there is 0 packet output rate over the past 5 minutes on the second uplink.
Example 8-41: The Po2 Interface Shows No Output Over the Past 5 Minutes
ASW1# show interfaces po2
Port-channel1 is up, line protocol is up (connected)
Hardware is EtherChannel, address is 001b.Oc91.7f8a (bia 001b.Oc91.7f8a)
Description: TO DSW1
MTU 1500 bytes, BW 200000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Full-duplex, 100Mb/s, link type is auto, media type is unknown
input flow-control is off, output flow-control is unsupported
Members in this channel: Fa0/11 Fa0/12
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 02:35:01, output hang never
Last clearing of "show interface" counters 01:17:38
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 2000 bits/sec, 4 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
24200 packets input, 1796256 bytes, 0 no buffer
Received 23272 broadcasts (0 multicast)
--More--
Even though both EtherChannel trunk uplinks from the access switch to the distribution switches are connected and active, one carries much more traffic than the other. To find the reason, you use the show interfaces trunk command, and as you can see in Example 8-42, Po2 is not carrying traffic from any of the VLANs. These VLANs are not in spanning-tree Forwarding state; in other words, the port is in Blocking state for those VLANs. There is redundancy built in the network, but it is not set up correctly. You are only using one of the two uplinks.
Example 8-42: Po2 Trunk Allows All VLANs, but None Are in Forwarding State
ASW1# show int trunk
Port Mode Encapsulation Status Native vlan
Po1 on 802.1q trunking 1
Po2 on 802.1q trunking 1
Port vlans allowed on trunk
Po1 1-4094
Po2 1-4094
Port vlans allowed and active in management domain
Po1 1, 10, 20, 30, 40, 50, 60
Po2 1, 10, 20, 30, 40, 50, 60
Port vlans in spanning tree forwarding state and not pruned
Po1 1, 10, 20, 30, 40, 50, 60
Po2 none
ASW1#
Ideally, you would like to share the load across both trunks. Redundancy and load sharing are achieved by proper setup of physical links and proper configuration of spanning tree.
The ideal command for this situation is show spanning-tree blockedports. This command displays the ports that are in the Blocking state. The output shown in Example 8-43 confirms that all VLANs are blocking on port channel 2.
Example 8-43: All the VLANs Show as Blocking on the Po2 Interface
ASW1# show spanning-tree blockedports
Name Blocked Interfaces List
—————————— ——————————————————
VLAN0001 Po2
VLAN0010 Po2
VLAN0020 Po2
VLAN0030 Po2
VLAN0040 Po2
VLAN0050 Po2
VLAN0060 Po2
Number of blocked ports (segments) in the system : 7
ASW1#
| Note | Common Spanning Tree (CST) uses only one instance of spanning tree for all VLANs. This means that in a situation similar to the example, one of the uplink ports will go into blocking for all VLANs while the other ports goes into forwarding for all the VLANs. Cisco Systems designed Per-VLAN Spanning Tree Plus (PVST+), which will run one instance of STP per VLAN. With that ability, and careful selection and placement of the root bridge per STP instance, different ports would be blocked for different VLANs, allowing traffic to utilize multiple links. Multiple Spanning Tree (MST) creates one instance of spanning tree per group of VLANs, allowing you to distribute the load according to traffic volume analysis for all of your VLANs. Ports would be blocked per instance of STP again, but this time each instance would include traffic from multiple VLANs. |
You can discover which type of STP is configured on the switch via the show spanning-tree summary command. As shown in Example 8-44, the switch spanning-tree mode is Rapid PVST. You need to find out why the switch is choosing to block all VLANs on Po2.
Example 8-44: The Switch Spanning Tree Is in Rapid-PVST Mode
ASW1# show spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: none
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
EtherChannel misconfig guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short
Name Blocking Listening Learning Forwarding STP Active
—————————— ———————— ————————— ———————— —————————— ——————————
VLAN0001 1 0 0 1 2
VLAN0010 1 0 0 2 3
VLAN0020 1 0 0 1 2
VLAN0030 1 0 0 1 2
VLAN0040 1 0 0 1 2
--More--
You must verify if the problem is the selection of the root; the root might be the same for all VLANs. Using the show spanning-tree root command, as shown in Example 8-45, you see the root ID is the same for all VLANs. That is the problem. You are not using the redundancy in the network effectively. You can tell from the output that the root port on the switch is the port channel 1 interface. That means port channel 2 is the alternate port for all VLANs, explaining why it is blocking for all VLANs.
Example 8-45: Po1 Is the Selected Root Port for All VLANs
ASW1# show spanning-tree root
Root Hello Max Fwd Root Port
vlan Root ID Cost Time Age Dly
————————— ———————————————————— ———— ———— ——— ——— —————————
VLAN0001 32769 0012.7f4b.ba80 12 2 20 15 Po1
VLAN0010 32769 0012.7f4b.ba80 12 2 20 15 Po1
VLAN0020 32769 0012.7f4b.ba80 12 2 20 15 Po1
VLAN0030 32769 0012.7f4b.ba80 12 2 20 15 Po1
VLAN0040 32769 0012.7f4b.ba80 12 2 20 15 Po1
ASW1#
Now you confirm that DSW1 is actually the root, using the show spanning-tree root command on DSW1. As Example 8-46 shows, the Root Port column is empty. DSW1 is indeed the root for all VLANs.
Example 8-46: DSW1 Has No Root Port for Any VLAN; It Is the Root for All VLANs
DSW1# show spanning-tree root
Root Hello Max Fwd Root Port
vlan Root ID Cost Time Age Dly
————————— ———————————————————— ————— ———— ——— ——— —————————
VLAN0001 32769 0012.7f4b.ba80 0 2 20 15
VLAN0010 32769 0012.7f4b.ba80 0 2 20 15
VLAN0020 32769 0012.7f4b.ba80 0 2 20 15
VLAN0030 32769 0012.7f4b.ba80 0 2 20 15
VLAN0040 32769 0012.7f4b.ba80 0 2 20 15
VLAN0050 32769 0012.7f4b.ba80 0 2 20 15
VLAN0060 32769 0012.7f4b.ba80 0 2 20 15
DSW1#
To fix this problem, you can designate DSW1 as the root for VLANs 10, 30, and 50, and DSW2 as the root for VLANs 20, 40, and 60. In a production network, traffic for VLANs would be analyzed and distributed based on volume; arbitrary division as we did here may not distribute the load in balance. There is an IOS macro that allows you to specify the switch to be the primary or the back up root for one or more VLANs. You will use that macro to make DSW1 the primary root for VLANs 10, 20, and 30, and to make it secondary root for VLANs 20, 40, and 60. You do the opposite on the DSW2 switch. This work is shown in Example 8-47.
Example 8-47: Using the Root Primary and Root Secondary Macros on DSW1 and DSW2
DSW1(config)# spanning-tree vlan 10,30,50 root primary
DSW1(config)# spanning-tree vlan 20,40,60 root secondary
DSW1(config)#
================================================================================
DSW2(config)# spanning-tree vlan 10,30,50 root secondary
DSW2(config)# spanning-tree vlan 20,40,60 root primary
DSW2(config)#
Now you go back to the access switch and look at the blocked ports again. You might have to wait a few seconds to allow STP to converge to a consistent state. You type the show spanning-tree blockedports command again and see the result shown in Example 8-48. Now you see that spanning tree is blocking for VLANs 1, 10, 30, and 50 on Po2 and it is blocking for VLANs 20, 40, and 60 on Po1. The output of the show spanning-tree root command demonstrates the same results.
Example 8-48: Po1 and Po2 Are Now Sharing the Blocking for Different VLANs
ASW1# show spanning-tree blockedports
Name Blocked Interfaces List
—————————— ———————————————————————
VLAN0001 Po2
VLAN0010 Po2
VLAN0020 Po1
VLAN0030 Po2
VLAN0040 Po1
VLAN0050 Po2
VLAN0060 Po1
Number of blocked ports (segments) in the system : 7
ASW1#
ASW1# show spanning-tree root
Root Hello Max Fwd Root Port
vlan Root ID Cost Time Age Dly
————————— ———————————————————— ————— ———— ——— ——— —————————
VLAN0001 32769 0012.7f4b.ba80 12 2 20 15 Po1
VLAN0010 32769 0012.7f4b.ba80 12 2 20 15 Po1
VLAN0020 32769 0012.7f4b.ba80 12 2 20 15 Po2
VLAN0030 32769 0012.7f4b.ba80 12 2 20 15 Po1
VLAN0040 32769 0012.7f4b.ba80 12 2 20 15 Po2
VLAN0050 32769 0012.7f4b.ba80 12 2 20 15 Po1
VLAN0060 32769 0012.7f4b.ba80 12 2 20 15 Po2
ASW1#
Going back to check traffic statistics on Po1 and Po2, you see that both links are now being used somewhat evenly, as shown in Example 8-49.
Example 8-49: Traffic Statistics Show Even Distribution Between Po1 and Po2
ASW1# show int po1 | include rate
Queueing strategy: fifo
5 minute input rate 1443000 bits/sec, 143 packets/sec
5 minute output rate 1501000 bits/sec, 272 packets/sec
ASW1# show int po2 | include rate
Queueing strategy: fifo
5 minute input rate 1163000 bits/sec, 107 packets/sec
5 minute output rate 1162000 bits/sec, 103 packets/sec
ASW1#
Because you do not want to sacrifice reliability, you need to make sure that the network is resilient to a failure on these links (one at the time). To test that, you shut down both ports in the port channel 1 EtherChannel. Spanning tree should be fast enough so that in the event of a network outage, applications do not time out. Spanning tree should reconverge and unblock ports. The output from the show spanning-tree blockedports command shows that no ports are blocked after the link failure. This is critical for sensitive traffic such as video. These results are shown in Example 8-50. The problem is solved.
Example 8-50: Cisco IOS IPS CLI Configuration
ASW1(config)# int range fa0/9-10
ASW1(config-if-range)#shut
ASW1(config-if-range)#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to
down
%LINK-5-CHANGED: Interface FastEthernet0/9, changed state to administratively down
%LINK-5-CHANGED: Interface FastEthernet0/10, changed state to administratively down
%LINK-3-UPDOWN: Interface Port-channel1, changed state to down^Z
ASW1#
ASW1# show spanning-tree blockedports
Name Blocked Interfaces List
——————————- ———————————————————————
Number of blocked ports (segments) in the system : 0
ASW1#
Video-Integration Troubleshooting Example: IP Multicast Configuration Error
The second troubleshooting example for this section is based on the network topology shown in Figure 8-21. This network is simulating an IGMP network, with R1 acting as an IGMP client, similar to a PC running a video application and joining multicast groups. R2 will act as the first-hop router, listening to IGMP join and leave transactions. And R3 will act as the video server, pushing multicast traffic downstream. The video server is simulated by the loopback interface with the IP address 100.100.100.100 on R3. R2 and R3 are preconfigured to communicate multicast group information through Protocol Independent Multicast (PIM). R1 and R2 are preconfigured to use IGMP to allow R1 to join multicast groups. The problem here is that users in the R1 LAN are not able to watch the video stream; they are able to connect to the server and request the video, but the video stream is not reaching them after that. The application team has verified that the software is installed correctly and the server is configured properly, and they suspect the network is to blame.
Because the video application is the only one that is not working, you can discard IP reachability and routing issues as the problem, except of course for the networks that are related to the video application. Because you are dealing with a multicast issue, keep in mind that end devices must join a multicast group before they can receive traffic directed to that group. So, you get on R2 to see the multicast groups the hosts in this LAN have joined. Use the show ip igmp groups command; the result is shown in Example 8-51. R1 is not joining any group. The group that you see on the example output is on the serial 0/0/0 interface, while R1 is on the LAN interface Fa 0/0. The show ip igmp membership command, which shows all members of all groups, does not list the IP address of R1 (10.12.12.1) anywhere.
Example 8-51: Cisco IOS IPS CLI Configuration
R2# show ip igmp group
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
224.0.1.40 Serial0/0/0 00:08:48 Stopped 10.23.23.2
R2#
R2# show ip igmp membership
Flags: A - aggregate, T - tracked
L - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G)
Reporter:
- last reporter if group is not explicitly tracked
/ - reporter in include mode, reporter in exclude
Channel/Group Reporter Uptime Exp Flags Interface
*.224.0.1.40 10.23.23.2 00:09:24 stop 2LA Se0/0/0
R2#
Now you try debug ip igmp on R2, but you also will go to R1 and try to simulate joining a group. Because R1 is simulating an IGMP client, you enter the command ip igmp join-group and join the group 224.8.8.8. This work is shown on Example 8-52. The debug you enabled on R2, however, does not display any sign of activity.
Example 8-52: R2 Does Not Show Any Activity After R1 Joins a Multicast Group
R2# debug ip igmp
IGMP debugging is on
R2#
R1# config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# int fa0/0
R1(config-if)# ip igmp joi
R1(config-if)# ip igmp join-group 224.8.8.8
R1(config-if)#
The first step you must take to further isolate the problem is to determine whether IGMP is actually running on router R2. So, you use the show ip igmp interface command on R2. The result is shown on Example 8-53. There is only one interface enabled for IGMP in this router and that is serial 0/0/0. Because IGMP is not enabled on the R2’s Fa 0/0 interface, R1 could not join the multicast group, and that is why multicast connectivity is not working.
Example 8-53: On R2, the Only Interface Where IGMP Is Enabled Is Serial 0/0/0
R2# show ip igmp interface
Serial0/0/0 is up, line protocol is up
Internet address is 10.23.23.2/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 1 joins, 0 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
IGMP querying router is 0.0.0.0 (this system)
Multicast groups joined by this system (number of users):
224.0.1.40(1)
R2#
You will configure IGMP on router R2’s Fa 0/0 interface by enabling PIM on this interface, using the command ip pim sparse-dense (see Example 8-54). The debug output shows R2 sending IGMP Version 2 query and receiving a report from R1 (10.12.12.1 joining the multicast group 224.8.8.8).
Example 8-54: Upon Enabling PIM on R2’s Fa 0/0, Multicast Query and Reports Begin
R1# config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# int fa0/0
R1(config-if)# ip pim
R1(config-if)# ip pim sp
R1(config-if)# ip pim sparse-d
R1(config-if)# ip pim sparse-dense-mode
R1(config-if)#
IGMP(0): Send v2 init Query on FastEthernet0/0
%PIM-5-DRCHG: Dr change from neighbor 0.0.0.0 to 10.12.12.2 on interface
FastEthernet0/0
IGMP(0): Received v2 Report on FastEthernet0/0 from 10.12.12.1 for 224.8.8.8
IGMP(0): Received Group record for group 224.8.8.8, mode 2 from 10.12.12.1 for 0
sources
IGMP(0): WAVL Insert group: 224.8.8.8 interface: FastEthernet0/0Successful
IGMP(0): Switching to EXCLUDE mode for 224.8.8.8 on FastEthernet0/0
IGMP(0): Updating EXLUDE group timer for 224.8.8.8
IGMP(0): MRT Add/Update FastEthernet0/0 for (*,224.8.8.8) by 0
The show ip igmp interface command output now informs you that IGMP Version 2 is enabled on interface Fa 0/0 (see Example 8-55). It is important to notice and verify that the IGMP versions used by the hosts and the router are compatible. You enter the show ip igmp groups command next, and discover that 224.8.8.8 is now known on Fa 0/0 with last reporter as R1 (10.12.12.1).
Example 8-55: IGMP Is Now Enabled on Both Serial 0/0/0 and FastEthernet 0/0 Interfaces
R2# show ip igmp interface
Serial0/0/0 is up, line protocol is up
Internet address is 10.23.23.2/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 1 joins, 0 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
IGMP querying router is 0.0.0.0 (this system)
Multicast groups joined by this system (number of users):
224.0.1.40(1)
FastEthernet0/0 is up
Internet address is 10.12.12.2/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
--More--
R2#
R2# show ip igmp group
IGMP Connected Group Membership
Group Interface Uptime Expires Last Reporter Group Accounted
Address
224.8.8.8 FastEthernet0/0/0 00:08:48 00:02:51 10.12.12.1
224.0.1.40 Serial0/0/0 00:19:43 stopped 10.23.23.2
R2#
Finally, you need to verify that multicast connectivity is working end to end. You go to the video server, R3 in this example, and ping 224.8.8.8. This action simulates multicast traffic originating from the multicast server (R3), which must reach the members of the multicast group 224.8.8.8. In just a few moments a reply is received from R1 (see Example 8-56). This result simulates the situation that the multicast server is pushing video, and the client is able to receive it and watch it. The problem is fixed.
Example 8-56: Ping to the Multicast Address 224.8.8.8 from R3 Receives Reply from R1
R3# ping 224.8.8.8
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.8.8.8, timeout is 2 seconds:
Reply to request 0 from 10.12.12.1, 1 mss
R3#
Summary
Troubleshooting a wireless network requires the following considerations:
-
Is the wireless network based on the autonomous model or the split MAC (lightweight) model?
-
What are the switch capabilities and requirements in terms of Power over Ethernet (PoE), trunking, WLAN-to-VLAN mapping, security, and quality of service (QoS)?
-
How will the Lightweight Access Point Protocol (LWAPP) be handled?
-
What type of roaming will the network support?
Common wireless integration issues include the following:
-
Problems at the wireless to wired boundary: In case of the autonomous model, the AP has a wired connection to a switch and this connection must be in working condition. In case of the split MAC model, the lightweight AP (LWAP) sends and receives control and data to the wireless LAN controller (WLC) using LWAPP. This communication must be in working condition.
-
Filters might be blocking traffic: In addition to the switches, the radio and Ethernet side of the APs must be checked for filters that might be blocking legitimate traffic such as LWAPP or security/authentication. LWAPP control uses UDP port 12223, and LWAPP data uses UDP port 12222.
-
Wireless QoS and wired QoS mapping might be incorrect: QoS markings must be maintained and remain consistent across wireless-to-wired boundaries.
-
PoE issues: The AP might need PoE on the switch port it connects to, and power amount must be appropriate.
-
Trunk issues: All trunks must be checked to make sure they allow appropriate VLANs.
Some useful switch troubleshooting commands to support wireless LANS are as follows:
The design and troubleshooting considerations of integrating unified communications into a campus LAN are as follows:
-
QoS: Adequate trust boundaries, plus proper router and switch QoS configurations.
-
High availability: Usage of resilient technologies such as RSTP and HSRP.
-
Security: Implementation of voice VLAN(s) and accurate filters and firewall configurations.
-
Availability and correct provisioning of other services: PoE, DHCP, TFTP, NTP, CDP, and so on.
The IP phone boot process consists of the following main steps:
Useful converged network troubleshooting commands include the following:
Video-integration considerations and requirements are as follows:
-
Quality of service: QoS considerations for video are not quite the same as VoIP; video requires more bandwidth and can be bursty.
-
High availability: Video applications require millisecond-level network service recovery because video traffic cannot withstand unpredictable or large network recovery timeouts.
-
Multicast: Improper router and switch multicast (PIM, IGMP, and so on) configurations impede operation of multicast-based video applications.
-
Security: Access control and threat management mechanisms must consider the various protocols and traffic flows that result from a video-enabled network and allow them in the network in a controlled manner.
Common video-integration issues include the following:
-
Excessive bandwidth utilization
-
Lack of control
-
Poor quality (lack of QoS)
-
Security issues (filtering of key protocols, and stateful requirements)
-
Multicast issues
0 comments
Post a Comment