Preface

In this issue of ZTE's Maintenance Experience, we continue to pass on various field reports and resolutions that are gathered by ZTE engineers and technicians around the world. The content presented in this issue is as below: Two Technical Special Documents

Maintenance Experience
Bimonthly for Data Products No. 2 Issue 270, April 2012

Maintenance Experience Editorial Committee

Director: Qiu Weizhao Deputy Director: Zeng Li Editors: Fang Xi, Wang Zhaozheng, Xu Xinyong, Zhang Jian, Zhang Jiebin, Zhao Cen, Zhou Guifeng, Xiao Shuqing, Ge Jun, Zhao Haitao, Huang Ying, Xu Zhijun, Jiang Haijun, Dong Yemin, Dong Wenbin Technical Senior Editors: Hu Jia, Tao Minjuan, Zhang Jianping,Zhu Xiaopei Executive Editor: Zhang Fan

Eight Maintenance Cases of ZTE's Data Products

Have you examined your service policies and procedures lately? Are you confident that your people are using all the tools at their disposal? Are they trained to analyze each issue in a logical manner that provides for less downtime and maximum customer service? A close look at the cases reveals how to isolate suspected faulty or mis-configured equipment, and how to solve a problem step by step, etc. As success in commissioning and service is usually a mix of both discovery and analysis, we consider using this type of approach as an example of successful troubleshooting investigations. While corporate leaders maintain and grow plans for expansion, ZTE employees in all regions carry out with individual efforts towards internationalization of the company. Momentum continues to be built, in all levels, from office interns to veteran engineers, who work together to bring global focus into their daily work. If you would like to subscribe to this magazine (electronic version) or review additional articles and relevant technical materials concerning ZTE products, please visit the technical support website of ZTE CORPORATION (http://ensupport.zte. com.cn). If you have any ideas and suggestions or want to offer your contributions, you can contact us at any time via the following email: doc@zte.com.cn. Thank you for making ZTE a part of your telecom experience!

Maintenance Experience Newsroom

Address: ZTE Plaza,No. 55, Hi-tech Road South, ShenZhen, P.R.China Postal code: 518057 Contact: Ning Jiating Tel: +86-755-26776049 Fax: +86-755-26772236 Document support Email: doc@zte.com.cn Technical support website: http://ensupport. zte.com.cn

Maintenance Experience Editorial Committee ZTE Corporation April, 2012

Contents

Technical Specials
PIM Snooping Overview...............................................................................................................................2 Cross-VLAN Multicast..................................................................................................................................4

Maintenance Instances
A LAN Multicast Test Case...........................................................................................................................9 Switch L2 Multicast Isolates Broadcast........................................................................................................13 Layer-2 Multicast Fault.................................................................................................................................16 Handling of Some Channels Being Abnormal for ZXR10 8905 Multicast Service. .......................................18 Handling of Multicast Flow Fault Caused by DR Switching under VRRP Interface. .....................................20 Handling of a Problem with Multicast Forwarding on G and 39 Series Interfaces in Access Mode. ............21 Multicast Service Interruption Caused by OSPF Type 7 LSA Translation Failures......................................24 Abnormal Multicast Route............................................................................................................................26

April 2012

Issue 270

Technical Specials

PIM Snooping Overview

Qian Yuemei / ZTE Corporation
Abstract: This section describes the basic function of the PIM Snooping. It concludes the trend of data stream and message stream when the PIM Snooping function is enabled and when it is disabled. Key words: PIM Snooping, Join, Switch, Multicast

1 PIM Snooping Overview

In the multicast network, when a backbone switch is connected to multiple routers, this switch still sends multicast messages to the ports of all routers even if some router has no downstream receiver. In this case, the network flow is increased, and the efficiency is reduced. When the PIM Snooping function is enabled, the switch only sends multicast messages to the ports that receive the PIM SM adding request from the downstream router. In this case, the network flow is reduced.

When the PIM Snooping function is enabled, The switch learns the HLLO message, and obtains the relationship between the IP address and the port of the downstream router. The switch learns the JOIN/PRUNE message, and obtains the multicast routing port that will receive messages. The following describes the trend of data stream and message stream when the PIM Snooping function is disabled and when it is enabled. As shown in Figure 1, when the PIM Snooping function is disabled, the PIM adding messages are sent to the ports of all routers.

Figure 1. Direction of PIM Adding Message Stream (Disabled PIM Snooping function)

Maintenance Experience

www.zte.com.cn

As shown in Figure 2, the multicast data stream is sent to the ports of all routers in the same VLAN when the PIM Snooping function is disabled.

Figure 2. Direction of Multicast Data Stream (Disabled PIM Snooping function)

As shown in Figure 3, the PIM adding message is only sent to the ports of specified routers when the PIM Snooping function is enabled.

Figure 3. Direction of PIM Adding Message Stream ( (Enabled PIM Snooping function)

As shown in Figure 4, the multicast data stream is sent to the ports of specified routers when the PIM Snooping function is enabled.

Figure 4. Direction of Multicast Data Stream (Enabled PIM Snooping function)

Data Products

April 2012

Issue 270

Technical Specials

Cross-VLAN Multicast
Qian Yuemei / ZTE Corporation
Abstract: This section describes the background, application, and the basic principle of the cross-VLAN multicast, and gives the basic configuration method. The cross-VLAN multicast is a sub-function of the IPTV technology. Key words: PIM Snooping, VLAN, IPTV, CAC, PRV, CDR

1 Multicast Application Problem

With the development of multimedia services, such as IPTV, video conference, and VOD, on the Internet, the number of users are increased greatly. In the MAN access network, the VLAN division for the users becomes more refined. Sometimes, the access network planning is that one user-to-one VLAN. In this case, there may be thousands of VLANs on the

convergence switch in the MAN. These VLANs are terminated on the SR equipment through a subport or the SuperVLAN technology. According to the multicast principle, the IGMP protocol on the L3 equipment is enabled. This L3 equipment acting as a multicast point (that is the multicast copy point) is used for user access, and sends multicast stream to users. However, according to the current network features in telecommunication industry, thousands of multicast streams must be copied on the multicast access point SR for users. That is to say, one VLAN must be accompanied with a copy of multicast stream. The effect is just equal to that of a unicast, and a large amount of bandwidth is occupied. So, this network does not have the advantage of multicast network. Figure 1 shows a typical multicast application instance. The MAN access network is planned according to the above description. The details are as follows: Each user has a VLAN. It is assumed that one convergence switch has N users with N VLANs, and these VLANs are terminated on the SR equipment. The IGMP protocol is enabled on the SR equipment which acts as a multicast copy point. If the value of N is small, such as 100, the flow is not obvious. In this case, 100 copies of multicast streams must be copied from the SR equipment to the convergence switch.

Figure 1. Typical Multicast Application

Maintenance Experience

www.zte.com.cn

With the extension of network scale, if the value of N is 5000, 5000 copies of multicast streams must be copied from the SR equipment to the convergence switch. It is assumed that the value of each multicast stream is 2M, the value of all multicast streams to be copied is 10000M (5000*2M). There are also multiple copies of multicast streams from the convergence switch to each access switch, and the number of copies is based on the number of users connected to this access switch. In this case, a large amount of network bandwidth is occupied.

2 Solutions
The above description indicates that the multicast copy point SR is only available to the network with small-scale and less users. If the number of users exceeds a threshold, the multicast advantage in this network is missing. In this case, it is necessary to move the multicast copy point to the device on the access layer. As shown in Figure 2, it is assumed that the multicast copy point is moved to the device on the access layer, such as switch//OLT/DSAM. In this case, the SR only needs to send a copy of multicast stream, and the convergence switch only sends a copy of multicast stream to each access switch, which reduces the bandwidth greatly.
Figure 2. Moving Multicast Copy Point to a Switch through CrossVLAN Multicast

introduces the multicast stream from the SR equipment with the MVLAN (In the MVLAN, the switch acts as a multicast receiver of the SR equipment), and then copies the multicast stream of the MVLAN to the user VLAN (In the MVLAN, the switch acts as the multicast control point of the user). The cross-VLAN multicast technology is implemented through the IGMP Snooping function in the switch. 1. After receiving the IGMP adding message, the switch records the VLAN ID, and port information of the message. 2. The switch sends the IGMP message to the MVLAN, and then the MVLAN sends this message to the SR. After that, the multicast stream is introduced to the MVLAN. 3. After receiving multicast stream from the MVLAN, the switch copies the multicast stream to the user VLAN according to the information recorded by the IGMP Snooping function.

3 Definition of Cross-VLAN Multicast

The multicast copy point is moved to the convergence switch or the access switch (DSLAM). However, these devices do not support the IGMP protocol and cannot access the control point as a multicast user because they are on layer 2. In this case, to realize the multicast copy function, the cross-VLAN multicast copy function must be used. The cross-VLAN multicast copy means to copy a multicast stream from one VLAN to another VLAN. In the cross-VLAN multicast copy function, a multicast VLAN, that is MVLAN, is defined. The switch

Data Products

April 2012

Issue 270

Technical Specials

4 IPTV Function
Tr a d i t i o n a l m u l t i c a s t t e c h n o l o g y lacks control over unauthorized user multicast services, thereby failing to satisfy operators control and management demands. So the controllable multicast technology emerges as required. The socalled controllable multicast technology is the old multicast technology with an extension of multicast control policy, in a bid to control the users access to the multicast services. The IPTV function is launched for this purpose. The controllable multicast needs to finish the job below: Authenticate the access users to make clear whether they have access rights. If they have, they will be allowed to access services and then authentication and accounting will be performed as well. If they dont have the rights, they will be denied. The user rights include query and preview. The query right means a user has the right to query the channel as long as it is not in arrears. The preview refers to the situation in which the user has the right to preview the channel only within a specified time, for example 10 minutes. Once the time expires, the preview right becomes unavailable. To realize these rights, the IPTV function should include IGMP Snooping, CAC, PRV, and CDR.

allows another part of the users to preview the channel, and denies the access of the rest users. In addition, the CAC is capable of specifying source port of the multicast group the multicast traffic must pass through the source port, and of controlling query messages. If there isnt a right for the query messages, the messages will be dropped. They can only be handled once a query right is added. The IGMP Snooping modules acquires port, VLAN, MAC, IP and multicast address of the desired channels from the IGMP reports sent by the users. And then it transmits the information to the CAC. The CAC determines the way in which the IGMP Snooping module handles the messages according to the stored user multicast access rights. If the multicast group requested by the user is not in the active multicast range, the multicast message will be dropped. If the user hasnt ordered the multicast group and is not permitted to preview the channel, the message will be dropped. If the preview is permitted, the preview process will be started. If the multicast group is ordered, the user will be permitted to query it. The CAC monitors the login time and logout time of the user, and transmits the information to the CDR (Call Data Recording) to generate user records. There is a record for both the login and logout of the user. Preview (PRW) is to control the users login and logout based on the maximum number of times a user can preview the multicast, the maximum preview time, the preview interval between channels, and the preview reset time.

CAC (Channel Access Control) is to authorize the users according to the multicast channel access rights preset for them. The CAC system supports three types of user rights, deny, preview, and permit. According to the multicast channel access rights preset for the users, the CAC permits the users that have ordered the multicast channel to query the multicast, and

CDR (Call Data Recording) is to store and report the multicast records. The multicast records are generated by CAC and PRV. When the CAC and PRV think it is necessary to generate a multicast record, they will send this multicast record to the CDR for processing. The

Maintenance Experience

www.zte.com.cn

CDR saves this record to the switch temporarily and reports it to the SMS (service management system) after the sync interval expires. After receiving the response from the SMS, the CDR clears this record. Because there are huge amounts of information, TCP Socket link mode is used between the CDR and the SMS as a communication channel, in order to guarantee the reliability.

authorization. It authenticates the users according to the user information sent by the IGMP Snooping. In the cross-VLAN multicast, the user authentication is not necessary all users have the right to query the multicast. Thus, just set the CAC to enable all the users with the query right. And then the authentication can be skipped. The IGMP Snooping is responsible for listening to the users IGMP requests and generating forwarding tables accordingly. The IGMP Snooping sets multicast forwarding tables according to the configured MVLAN, user port, and VLAN. If the MVLAN and user VLAN do not refer to one VLAN, then an L3 multicast forwarding table will be set to realize the cross-VLAN multicast. If they refer to one VLAN, then an L2 forwarding table will be set. The cross-VLAN multicast is realized in a process as follows.

5 Cross-VLAN Multicast Technology

The cross-VLAN multicast, as a sub-feature of the IPTV technology, only needs to duplicate the multicast traffic from the MVLAN to the user VLAN, without the need to authenticate/authorize/account the users, for the simple reason that all the users have the query right. Therefore, to realize the cross-VLAN multicast, you just focus on the IGMP Snooping and the CAC of the IPTV. The CAC is responsible for user authentication/

Figure 3. Cross-VLAN Multicast Implementation Flow Chart

Data Products

April 2012

Issue 270

Technical Specials

6 Cross-VLAN Multicast Configuration

6.1 Configuration Method
Configuration of cross-VLAN multicast refers to the following aspects: 1. Enable IPTV function of the device; 2. Create an IPTV channel and set a multicast VLAN where the channel locates; 3. Configure CAC, including the CAC rules and the channel rights. ZXR10 series switches are slightly different in cross-VLAN multicast configuration. The following takes 8900 series switches to illustrate the basic configuration of the cross-VLAN multicast. Other switches share the similar configuration. For details, refer to relevant user manuals.

6.2 Configuration for 89 Series Switches

1. In nas mode, enable IPTV function iptv control { enable | disable } 2. Create an IPTV channel create iptv channel { special < channel-id > address <address> | general <channel-id > } Each special channel is assigned a multicast address. General channel is mapped to all multicast groups. 3. Set a multicast VLAN where the channel locates iptv channel <channel-list> mvlan <vlan-id> 4. Create CAC rules create iptv cac-rule < rule-id > [ port < portname> ] [ vlan <vlan-id> ] [ mac-base ] 5. Set channel rights iptv cac-rule <rule-list> right { order | preview | query } <channel-id> One channel corresponds to one right. When the query is specified, the rule must be for the port.

Maintenance Experience

www.zte.com.cn

A LAN Multicast Test Case

Liu Hui / ZTE Corporation
Abstract: This section describes how to configure the LAN multicast. Cross-VLAN multicast is configured on both 2826S and 3928. In this case, two solutions are formed. Key words: Multicast, LAN, Cross-VLAN, IPTV, IGMP

1 Network Description
LAN subscribers are hard to use IPTV service than ADSL subscribers do. At present, home gateway is a good solution to this problem. So far, each vendor has provided their own home gateway products. Moreover, some of them are integrated with IAD and other features, which can provide multiple services, such as telephone, TV and broadband. In this test, ZTEs H110 is used for testing IPTV and PPPoE.

IPTV service is classified into two types: unicast and multicast. The set top box (STB) acquires IP from unicast VLAN to get start and enter EPG interface. Then, unicast programs become available. If subscribers want to watch multicast programs, the STB sends an IGMP report to request for multicast stream. The whole network runs uniform multicast VLAN, with multicast VLAN ID being 29 for the operator.

Figure 1. Network Topology

Data Products

April 2012

Issue 270

Maintenance Instances

2 Solution 1
Configure cross-VLAN multicast on 2826S. Actually, the cross-VLAN multicast on 2826S couldnt duplicate the multicast stream from VLAN to VLAN. In the downlink interface, it forwards the untagged multicast stream or the multicast stream tagged 29 (29 is the multicast VLAN). Whether the multicast stream is tagged 29 depends on whether the downlink interface is tagged in VLAN 29. Nevertheless, the downlink interface must locate in VLAN 29. The multicast stream tagged 29 is insignificant to home gateway. If the stream is sent to H110 in untag mode, H110 port must be able to support hybrid mode, which identifies services by configuring PVID. However, H110 port doesnt support the mode, so this way is also unavailable. Only when the downlink interface of 2826S is directly connected to the set top box, is it possible to provide the single IPTV service. Below is the cross-VLAN multicast configuration method for 2826S. 1. VLAN configuration
set vlan 29,3999 enable set vlan 29 add port [downlink set top box port] untag box port joins multicast vlan in untag mode */ box port joins vlan 3999 in untag mode */ pvid=3999*/ set vlan 3999 add port [downlink set top box port] untag set port [downlink set top box port] pvid 3999 set vlan 29,3999 add port [uplink port] tag in tag mode */ /* Add vlan and enable it */ /* Downlink set top /* Downlink set top

/* Set downlink set top box

/* Uplink port joins each vlan

2. IGMP Snooping configuration

set igmp snooping enable /* Enable igmp snooping */

set igmp snooping add vlan 29

set igmp snooping fastleave enable

/* Enable and listen to vlan29*/ /* Enable fast leave */

3. IPTV control configuration, namely cross-VLAN multicast configuration

config nas /* Enter nas configuration mode */ /* Enable IPTV */ /* Create an iptv common channel, which has

iptv control enable

create iptv channel general 256 iptv channel 256 mvlan 29

no restrictions on multicast address.*/

source locates specify multicast vlan */ create iptv cac-rule 1 vlan 3999 3999*/ iptv cac-rule 1 right order 256

/* Specify the vlan where the channel multicast /* Create an access rule for access vlan /* Specify right for the access rule */

3 Solution 2
Configure cross-VLAN multicast on 3928. 2826S is enable with IGMP SNOOPING. Multicast VLAN terminates on 3928. Unicast VLAN and PPPoE service VLAN are transparently transmitted to H110 all the way. The solution is feasible. After the test, IPTV and PPPoE services both can be used. The following is the configuration and description for each device.

10

Maintenance Experience

www.zte.com.cn

1. Cross-VLAN multicast configuration for 3928

interface fei_1/1 /*Downlink interface, connecting to 2826S*/ /*Enable igmp protocol for protection*/

description to-2818S negotiation auto

protocol-protect mode igmp enable switchport mode trunk

switchport trunk native vlan 1 switchport trunk vlan 3999 ! switchport qinq normal switchport trunk vlan 35

/* Unicast vlan */

/*PPPoE VLAN*/

interface gei_2/1

/*85 is enabled with flexible QinQ. Pppoe dual label is for bas while multicast single label is for iptv bearer network */ hybrid-attribute fiber protocol-protect mode igmp enable negotiation auto

description to-8505

/* Uplink interface, connecting to 8505*/

*/

/* Enable igmp protocol for protection

switchport mode trunk

switchport trunk native vlan 1 switchport trunk vlan 29 switchport trunk vlan 3999 ! switchport qinq normal switchport trunk vlan 35

/*Multicast VLAN*/ /*PPPoE VLAN*/

/*Unicast VLAN*/

ip igmp snooping */

ip igmp snooping proxy

/* Enable igmp snooping; enabled by default */

/* Enable igmp snooping proxy; enabled by default /* Enable querier globally */

ip igmp snooping querier vlan 3999 !

ip igmp snooping query-interval 60 igmp snooping querier

/* Enable querier in vlan */

nas

iptv control enable here */

/* Enter nas configuration mode */

/* Enable iptv control to achieve cross-VLAN multicast /* Define a general channel, which has no

create iptv channel general 1024 iptv channel 1024 mvlan 29 create iptv cac-rule 1

restrictions on multicast group */

the general channel locates multicast vlan */ indicating all VLANs */

/* Specify the VLAN where the multicast source of

/* Create rule 1, without vlan parameter followed, /* Purchase channel for rule 1*/

iptv cac-rule 1 right order 1024 the uplink interface */

create iptv cac-rule 2 port gei_2/1 iptv cac-rule 2 right query 1024

/* Create rule 2 and specify mr-port as /* Purchase channel for rule 2*/

Data Products

11

April 2012

Issue 270

Maintenance Instances

Notes: (1) The querier doesnt take effect until it is enabled both in global and vlan modes.(Why the querier is enabled is because IGMP snooping function of the downlink 2826S couldnt take effect until the uplink interface receives IGMP query packet). (2) The two commands create iptv cacrule 2 port gei_2/1 and iptv cac-rule 2 right query 1024 are configured because 3928 doesnt form mr-port until the port receives
set vlan 35 enable /*PPPoE VLAN*/

IGMP query packet or PIM packet, the same to 2826S. Then, IGMP snooping can work normally. Configuring the two commands is to specify the uplink interface as gei_2/1. In other words, query packet is only received at gei_2/1, so as to guarantee the correctness of mr-port. (3) The mr-port indicates the port destined for multicast router multicast uplink interface. The querier sends IGMP query packet to ports other than mr-port. 2. Controllable multicast configuration for 2826S:

set vlan 3999 enable to 3928*/

set vlan 3999 add port 1-16 tag set vlan 35 add port 1-16 tag connecting to home gateway */ ! set igmp snooping enable

/*Unicast VLAN*/

/* port 1 is an uplink interface, connecting /* port 2 is a downlink interface,

set igmp snooping add vlan 3999 !

/*Enable IGMP Snooping*/

set igmp snooping fastleave enable iptv control enable

/* Enable igmp snooping in vlan 3999*/ /* Enable fast leave */

for enabling cross-vlan multicast. It is configured for achieving controllable multicast */ create iptv channel general 256 iptv channel 256 mvlan 3999 /* Create an iptv general channel, which /* Specify the VLAN where the channel

/* The configuration from now on is similar to that

has no restrictions on multicast address */

multicast source locates specify multicast vlan. Because 3928 is already unicast vlan 3999*/ 2*/ */

configured with cross-vlan multicast, 2826S receives multicast stream in the create iptv cac-rule 1 port 2 vlan 3999 iptv cac-rule 1 right order 256 /*Create an access rule 1 for port /*Order a channel for access rule 1 /*Create an access rule 2 for port 3.

create iptv cac-rule 2 port 3 vlan 3999

The rule 2 is not ordered a channel, so on the switch only port 2 can request for multicast stream while port 3 couldnt.*/

12

Maintenance Experience

www.zte.com.cn

Note: 2826S after being enabled with IGMP snooping will not form mr-port until the uplink interface receives IGMP query or PIM. Then, 2826S can forward IGMP report packet to mr-port. 3.H110 configuration (web configuration process is not illustrated here),as shown in Figure 2.
Figure 2. VLAN Schematic Configuration Completed

Switch L2 Multicast Isolates Broadcast

Yang Zhiwei/ZTE Corporation
Abstract: This section describes how to configure the IGMP Snooping function and the static Drop group on the switch, and explains the meaning of drop. Key words: Multicast, IGMP Snooping, Drop, Switch, Layer-2

1 Network Description
As shown in the figure 1, a multicast source is connected the network via fei_1/1. Two multicast clients are connected to fei_1/2 and fei_1/3 of the switch respectively. Three PCs locate in one VLAN.

2 Fault Symptom
If the multicast source PC sends multicast traffic, the multicast clients of the switch act as L2 multicast. The traffic sent by the multicast source is broadcasted in this VLAN if the switch has no other configuration. Even if there are no clients or the clients have no ports that can originate IGMP join request, the multicast traffic can also be broadcasted.
Figure 1. Network Topology

Data Products

13

April 2012

Issue 270

Maintenance Instances

3 Fault Analysis
In this situation, port bandwidth is consumed and the client ports that haven t used the multicast or havent joined the group forward useless traffic. The solution to this problem is to use the IGMP snooping technique. The IGMP snooping is working at the data link layer. When L2 device receives an IGMP packet transmitted between the host and the router, IGMP snooping analyzes the information it carries, sets up and maintains the multicast MAC address table at L2. The multicast packets to be delivered from the router will be forwarded according to the multicast MAC address table. When the switch receives a leave request from the host, it deletes the port that has received the packet from the egress interface list. If the user is the last one in the group, the multicast forwarding entry will be deleted and the packet will be forwarded out the uplink port. Without the IGMP Snooping, the multicasts will be broadcast at the layer 2. After the IGMP Snooping is configured, the multicasts will be multicasted rather than broadcasted at the layer 2.

record the user port. And thus all multicast traffic is still broadcasted. The configuration is as follows:
ip igmp snooping ip igmp snooping proxy vlan 10

ip igmp snooping querier igmp snooping querier

igmp snooping drop 238.1.1.10 igmp snooping drop 238.1.1.9 igmp snooping drop 238.1.1.8 igmp snooping drop 238.1.1.7 igmp snooping drop 238.1.1.6 igmp snooping drop 238.1.1.5 igmp snooping drop 238.1.1.4 igmp snooping drop 238.1.1.3 igmp snooping drop 238.1.1.2 igmp snooping drop 238.1.1.1

Command meaning: When the IGMP snooping is enabled and there are no users, the group is configured into drop mode, so as not to broadcast multicast data. After the no form of the command is used, the multicast data is broadcasted. igmp snooping drop < ip-address > [ num <num> ] The parameter after drop is the multicast group address that needs to be configured statically for denying broadcast. The parameter <num> after the address refers to the number of consecutive multicast groups starting from this address. After the drop group is configured, the IGMP snooping will record client ports and their VLAN IDs for relevant multicast groups configured statically;
3928(config)#show ip igmp snooping S = Static; D = Dynamic. Index VLAN 1 10 Group ID Ports

4 Solutions
By default, ZTEs switch is enabled with IGMP snooping and so is each VLAN, but why the multicast traffic is still being broadcasted? In fact, after the IGMP snooping is enabled, relevant multicast group also needs to be configured with drop. Otherwise, the IGMP snooping doesnt detect the multicast group or

--------------------------------------

239.255.255.250 fei_1/2/D,

14

Maintenance Experience

www.zte.com.cn

In addition, after the command debug ip igmpsnooping is executed, the device will print user join and leave information:
IGMP SNOOPING Rcv 238.1.1.1 Group IN RouterIpAddr.

5 Lessons Learned
The switch doesnt want the multicast traffic close to the multicast source to be broadcasted. If the number of multicast sources is big, the port bandwidth may be consumed and thereby packet loss takes place and services are interrupted. Note that in addition to the IGMP snooping, relevant drop group should also be configured statically so as to achieve the purpose of not broadcasting the multicast traffic.

Report Msg: From Vlan 10, Port fei_1/2 addr=0.0.0.0,HostIpAddr.addr=1.1.1.2 Report Msg: From Vlan 10, Port fei_1/2 IN RouterIpAddr. addr=0.0.0.0,HostIpAddr.addr=1.1.1.2 Report Msg: From Vlan 10, Port fei_1/2 IGMP SNOOPING Rcv 238.1.1.1 Group IGMP SNOOPING Rcv 238.1.1.1 Group

And query user information regularly:

IGMP SNOOPING send Group-Specific Query 238.1.1.1 Group to fei_1/2 in vlan 10. Query 238.1.1.1 Group to fei_1/2 in vlan 10. IGMP SNOOPING send Group-Specific

After finding all users in the group have left, the IGMP snooping queries the users for several times and then deletes the multicast group forwarding port. The multicast traffic will not be broadcasted and the switch will drop it;
IGMP SNOOPING Rcv Group 238.1.1.1 IGMP SNOOPING send Group-Specific

Leave Msg: From Vlan 10, Port fei_1/2 Query 238.1.1.1 Group to fei_1/2 in vlan 10. IGMP SNOOPING send Group-Specific

Query 238.1.1.1 Group to fei_1/2 in vlan 10. IGMP SNOOPING send Group-Specific

Query 238.1.1.1 Group to fei_1/2 in vlan 10. IGMP SNOOPING Delete Host For Leave

Slowly Group = 238.1.1.1,From Vlan 10, Port fei_1/2

Data Products

15

April 2012

Issue 270

Maintenance Instances

Layer-2 Multicast Fault

Li Weiyan/ZTE Corporation
Abstract: This section describes how to configure the IGMP Snooping function in the actual network. Key words: Multicast, IGMP Snooping, Drop, layer-2, agent query

1 Fault Symptom
Figure 1 shows the network topology. The 8905 equipment is connected to the BRAS, and the 5116 equipment is convergence equipment on layer 2. In which, the BRAS implements the IPTV and voice services. The IP voice service under the BRAS is delayed and dropped. In addition, the IPTV service is often interrupted.

2 Fault Analysis
When checking the port information for the 8905 equipment, the engineer finds that each port on the 5116 and 8905 equipment has a large mount of multicast packages. In addition, when the uplink multicast source is disconnected, each port on the 5116 equipment also has a large mount of multicast packages. The downlink multicast users send a large mount of multicast messages, so the streams on the switch are increased greatly, and services on other ports are affected. The principle for the IGMP Snooping protocol is that: When one port sends an IGMP adding request, it receives the multicast message only after receiving the IGMP adding response. By default, if the no IGMP adding request is received, the switch will send multicast packages to each port in broadcast mode.

Figure 1. Layer-2 Multicast Fault

3 Solutions
To prevent that the multicast stream is forwarded to other ports which receive no request, configure the following commands: 1. Configure the layer-2 multicast on the 5166 equipment.
set igmp snooping enable

/*Enabling the IGMP Snooping function. This function is disabled by default*/ set igmp snooping add vlan 100 /*Adding specified VLAN 100 for multicast interception*/ set port 1-16 multicast-filter enable /*Adding multicast filtering function to all ports*/

If the multicast filtering command is not configured, the 5116 equipment will send multicast packages to the ports which receive no request in broadcast mode.

16

Maintenance Experience

www.zte.com.cn

2. Configure the layer-2 multicast on the 8905 equipment. Enable the IGMP protocol protection function for the ports where all multicast VLAN 100 are located.
interface gei_2/32 enable ipv4 protocol-protect mode igmp

Add the IGMP Snooping agent query function in the VLAN 100.
vlan 100

igmp snooping querier

By default, 89 series switches enable the ip igmp snooping function, even if in the VLAN.

protection function for the ports*/ switchport trunk vlan 100

/*Enabling the IGMP protocol

4 Lessons Learned
If the 5116 equipment is connected to a switch instead of multiple users, you need to add the multicast agent query function for the 5116 equipment. The command is as follows:
set igmp snooping query vlan 100 enable

In global mode, set the multicast-limit parameter for the multicast package. The default value is 1024. Set the value of the multicast-limit parameter to 256. In VLAN mode, enable the igmp snooping drop function. If the multicast IP address is 233.1.1.101, execute the following command in VLAN 100 mode:
vlan 100

igmp snooping drop 233.1.1.101

The common query command is as follows:

show ip igmp snooping vlan 100 /*Checking the adding of the multicast group*/

If this command is not configured, the switch will send the multicast stream in the VLAN 100 in broadcast mode when there is no IGMP request from multicast users. This command ensures that the multicast stream is only forwarded to the ports with the IGMP request. If there are multiple groups, you need to add many of this command in the VLAN 100.

If there is an abnormal multicast group, the 8905 equipment executes the igmp snooping drop command to prevent it from broadcasting multicast data.

Data Products

17

April 2012

Issue 270

Maintenance Instances

Handling of Some Channels Being Abnormal for ZXR10 8905 Multicast Service
Hu Jing/ZTE Corporation
Abstract: A loop is generated in the network because a port is not configured during the SmartGroup configuration. In this case, multicast service fault is generated. Key words: Multicast, IGMP, SmartGroup, loop, VLAN

1 Fault Symptom
Service description: IPTV MDU board sends multicast request. Multicast router distributes multicast service to switch 8905, which forwards the service to IPTV MDU. In vlan 400, IPTV MDU sends more than 60 multicast requests in different multicast channels. 12 services are abnormal while the rest are normal.
Figure 1. Network Topology

2 Fault Analysis
1. At the beginning, we didnt think it was the bearer network problem. If it was the bearer network that experiences problems, all of the services would be affected, because all channels located
ZXR108902-01#show ip igmp snooping Total-group-num is 63. Exist-host-group-num is 63. Cfg-drop-group-num is 0. Cfg-prejoin-group-num is 0. S = Static; D = Dynamic. Index VLAN Group ID 1 400

in one vlan and the switch could not distinguish between them. 2. We checked the service side for many times but no problem was found. Then we had to suspect the bearer network. 3. We carried out routine inspection for the device.

Cfg-max-host-group-num is 0. Drop Prejoin MaxHostNum 0 0 0 Ports

--------------------------------------------------------------------232.84.1.180

D:gei_2/24, smartgroup1

18

Maintenance Experience

www.zte.com.cn

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400 400

232.84.1.152 232.84.1.137 232.84.1.136 232.84.1.195 232.84.1.187 232.84.1.42 232.84.1.48 232.84.1.46 232.84.1.27 232.84.1.32 232.84.1.26 232.84.1.10 232.84.1.3 232.84.1.4 232.84.1.2 232.84.1.24 232.84.1.159 232.84.1.128

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24, smartgroup1 D:gei_2/24, smartgroup1 D:gei_2/24, smartgroup1 D:gei_2/24, smartgroup1 D:gei_2/24, smartgroup1 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24 D:gei_2/24, smartgroup1 D:gei_2/24, smartgroup1

232.84.1.28 232.84.1.29 232.84.1.30 232.84.1.21 232.84.1.17 232.84.1.7 232.84.1.54 232.84.1.18 232.84.1.15 232.84.1.13

D:gei_2/24, smartgroup1

D:gei_2/24, smartgroup1 D:gei_2/24, smartgroup1 D:gei_2/24, smartgroup1

4. Suddenly, we found several channels had two multicast forwarding ports. One was gei_2/24 while the other was smartgroup1. Why was there a smartgroup1? According to normal procedure, smartgroup1 should not send igmp request, so it would not be added into the multicast forwarding table. In total there were 12 channels. We checked with the engineers from the service side and found that the 12 channels service was abnormal. 5. Then, efforts were made to find why smartgroup1 sends igmp request. 6. We checked the standby 8905-2 and found the connected service side hadnt sent IGMP request. We checked the two switches port configuration and found 4-port link aggregation was used between 8905-1 and 8905-2. On 8905-2, an interconnected port gei_2/48 didn

t join the smartgroup1. Thus, due to the missing configuration here, a loop took place between 8905-1 and 8905-2. Since smartgroup is load shared by default, only a part of the services had problems.

3 Solutions
We added the 8905-2s gei_2/48 into the aggregation group. The services returned to normal.

4 Lessons Learned
Multicast forwarding mechanism is different from the traditional IP packet forwarding mechanism. Once a problem like this happens, we should think about it in a way different than before.

Data Products

19

April 2012

Issue 270

Maintenance Instances

Handling of Multicast Flow Fault Caused by DR Switching under VRRP Interface

Li Donglei/ZTE Corporation
Abstract: When the multicast and VRRP are used at the same time, you need to pay attention to the path of the PIM DR and the VRRP traffic. Key words: VRRP, PIM, and DR

1 Fault Symptom
5928-2 and 5928-3 were both enabled with PIM-SM. Each of two switching boards in stream media server VS8000 generated two multicast flows. Unicast gateways are located on 5928-2 and 5928-3. In other words, the two 59 devices were enabled with VRRP. VRRP packets were exchanged between stream media server VS8000. However, when master VRRP interface (VLAN 11) on 5928-3 got UP, area 1 could only receive half of the multicast channel.
Figure 1. Network Topology

switching. So now we focused on PIM DR. 3. We executed show ip pimsm interface to observe how DR changed when 5928-3 was connected. 5928-3 interface address is 125 while 5928-2 is 126. We compared addresses when the priority was 1 by default. 126 would become the DR. When 125 interface got up, VRRP switching happened but DR switching didnt take place, so multicast flow failed to be forwarded properly, thereby half of the flow disappeared.

2 Fault Analysis
1. Several attempts lead to this result, with only multicast programs being normal when 5928-2 was working. However, when 5928-3 was up, half of the flow exactly the multicast flow that should be forwarded on VLAN 11 5928-3 disappeared. 2. Because the multicast is realized based on the unicast, first we checked the unicast route and used static configuration. No problem was found. The multicast flow was bound to pass through DR. When 5928-3 interface was up, it might be the DR priority that had caused the DR

3 Solutions
Finally, we solved the problem by promoting the PIM DR priority under VLAN interface so as to leave 5928-3 interface as DR constantly. The fact proved that our previous analysis is correct!

20

Maintenance Experience

www.zte.com.cn

5928-3(config-if)#ip pim dr-priority 100 5928-3#show ip pimsm in Address Interface 10.18.0.250 10.18.0.94 10.18.0.125 vlan7 vlan10 vlan11 State Nbr Query Count Intvl Up 1 30 Up 1 30 Up 1 30 DR DR Priority 10.18.0.249 1 10.18.0.93 1 10.18.0.125 100

Handling of a Problem with Multicast Forwarding on G and 39 Series Interfaces in Access Mode
Shi Jingfeng / ZTE Corporation
Abstract: When a switch transmits the multicast stream, you need to pay attention to both the port mode and the label. The multi-untag command can be used to ensure that the multicast stream is transferred properly if necessary. Key words: VRRP, PIM, DR

1 Fault Symptom
T64G and 3906 are enabled with PIM-SM. T64G acts as RP of PIM-SM and 3906 runs IGMP. Multicast source sends multicast data to 225.1.1.1. On T64G, (*, G) and (S, G) route entries can be found. 3906 can detect the joining of multicast members, advertise this message to RP through PIM-SM, and ping the multicast source and T64Gs

loopback from multicast client successfully. But T64G hasnt copied multicast data for the outgoing interface, so the client could not receive the multicast flow.

2 Fault Analysis
1. Check multicast forwarding tables on T64G and 3906:

Figure 1. Network Topology

Data Products

21

April 2012

Issue 270

Maintenance Instances

T64G#show ip mroute

IP Multicast Routing Table

Flags:D -Dense,S -Sparse,M -Manual,C -Connected,L -Local,P -Pruned, R -RP-bit set,F -Register flag,T -SPT-bit set,J -Join SPT, M -MSDP created entry,N -No Used,U -Up Send, * -Assert flag A -Advertised via MSDP,X -Proxy Join Timer Running, Statistic:Receive packet count/Send packet count Timers:Uptime/Expires Interface state:Interface,Next-Hop or VCD,State/Mode (*, 225.1.1.1), 00:27:14/00:03:35, RP 1.1.1.1 , 0/0, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list:

interconnecting to 3906 locates */

vlan10, Forward/Sparse, 00:03:15/00:03:15

/* the vlan where the port

(10.0.0.2, 225.1.1.1), 00:06:29/00:03:35 , 28017/14027, flags: TA Incoming interface: vlan100, RPF nbr 0.0.0.0 Outgoing interface list: vlan10, Forward/Sparse, 00:03:15/00:03:15

interconnecting to 3906 locates */

/* the vlan where the port

Check multicast forwarding table on T64G. You can find 225.1.1.1 pointing to 3906 route entry. This indicates the client under 3906 has registered on 3906
3906#show ip mroute

through IGMP successfully, and in the meantime, 3906 has forwarded a join message to T64G successfully. 2. Check multicast forwarding tables on 3906:

IP Multicast Routing Table

Flags:D -Dense,S -Sparse,C -Connected,L -Local,P -Pruned, M -MSDP created entry,N -No Used,U -Up Send, * -Assert flag

R -RP-bit set,F -Register flag,T -SPT-bit set,J -Join SPT, A -Advertised via MSDP,X -Proxy Join Timer Running,

Statistic:Receive packet count/Send packet count Timers:Uptime/Expires Interface state:Interface,Next-Hop or VCD,State/Mode (*, 224.1.1.1), 00:01:45/00:01:50, RP 1.1.1.1 , flags: SP Incoming interface: vlan10, RPF nbr 192.168.0.1 Outgoing interface list: NULL

(*, 225.1.1.1), 00:01:33/00:02:02, RP 1.1.1.1 , flags: SC Incoming interface: vlan10, RPF nbr 192.168.0.1 Outgoing interface list:

vlan200, Forward/Sparse, 00:01:33/00:01:57 C

22

Maintenance Experience

www.zte.com.cn

Check multicast forwarding table on 3906 and find 225.1.1.1 multicast group has only one (*, G) entry. In normal circumstances, you can find (*, G) and (S, G) entries coexist for a multicast group in the multicast forwarding table on 3906. 3. This indicates 3906 hasnt performed SPT switching while ZXR10 has triggerred SPT switching through traffic monitoring. As long as relevant multicast group traffic reaches 3906, the SPT switching will be triggered. After switching, you can find the generated (S, G) in the forwarding table. Then, we suspect because 3906 hasnt received 225.1.1.1 multicast group traffic forwarded by T64G, the SPT switching on 3906 could not be triggered, therefore the (S, G) entry has no way of being generated in the forwarding table. 4. Check T64G and 3906 and find interconnected interfaces between T64G and 3906 are in access mode; interconnected interfaces between 3906 and client are in access mode, and interconnected interfaces between T64G and multicast source are in access mode. By default, for T64G/T160G series and 3900/3200 series devices, the data forwarded in L3 multicast mode carries 802.1Q. According to this feature, when T64G duplicates multicast flow to 3906, it will attach the flow with vlan tag by default. But because the interconnected interfaces between 3906 and T64G are in access mode, 3906 drops the packets with vlan tag. Thus, 3906 could not receive them to trigger the SPT switching. Of course, the client could not receive them either. After this configuration is added on site, the client and the multicast source can communicate with each other normally.

4 Lessons Learned
When all of the following threes prerequisites are satisfied, the command multi-untag must be configured for the interconnected interfaces: 1. Our device is interconnected to peer device in access mode; 2. Multicast data flow needs to be forwarded to the peer device from our device; 3. The peer device is not a ZTE switch.

3 Solutions
To resolve this problem, it is necessary to specify untag vlan for multicast forwarded on the interfaces between T64G and 3906, and between 3906 and client.
ZXR10(config)#interface <interface-name>

ZXR10(config-if)#multicast untag-vlan <vlan id> ZXR10(config-if)#exit

/* VLAN ID is irrelevant to interface PVID;it is specified on demand */

Data Products

23

April 2012

Issue 270

Maintenance Instances

Multicast Service Interruption Caused by OSPF Type 7 LSA Translation Failures

Fu Tao/ZTE Corporation
Abstract: In the OSPF protocol, the uplink router cannot learn the route from the network section of the multicast source, so the RPF detection fails, and the multicast stream is lost. Key words: OSPF, LSA, Type, RPF, Translation

1 Network Description
ZTEs two 8912 switches and HUAWEI s two NE40 switches are interconnected through the OSPF protocol in the shape of a rectangle. The OSPF area where the 8912 and NE40 locate is the NSSA area while the area where the two NE40 devices are interconnected to the MAN is the backbone area 0. The 8912 devices are connected with a multicast central node server at the

downstream for providing multicast services for the MAN remote users. The services are dual up-linked to the two 8912 devices through the L2 switch of the server. Each link sends a multicast stream of a different channel. And the two 8912 devices act as the DR (by modifying the priority) to receive the streams. Establish MSDP adjacency between the two NE40 devices and use Anycast RP for load sharing and RP hot swap.

2 Fault Symptom
The customer complained that when the remote users were watching live channels, the images always freeze every few minutes.

3 Fault Analysis
1. The blocked or mosaic video may result from the loss of multicast packets. Because after the multicast packets are dropped, the multicast data arriving at the users is incomplete. Thus, the users cannot see the complete picture. 2. Then we check the physical links and protocol processing. According to the feedback, all the users distributed throughout the network were soon affected after the fault occurred. Therefore, it is concluded that the problem might locate in the core equipment room (The Figure above shows the
Figure 1. Network Topology

devices in the core equipment room) instead of the

24

Maintenance Experience

www.zte.com.cn

user node. 8912 pings the interconnected device in the core equipment room and no packets are lost. Thus, lets focus on the protocol processing. 3. First, to examine whether the 8912 devices have sent the multicast packets out, check whether the multicast routing tables are normal.

redistribute connected in the OSPF configuration to advertise the IP of the multicast source, so the 8912 devices generate type 7 LSA for these routes. After these routes are advertised to the NE40 devices, the NE40 devices serving as the ABR (area border router) need to translate these type 7 LSAs into type 5 before calculating the routes. So it might be the LSA translation that causes the NE40 devices to continue to withdraw the route of the multicast source. Thus, we advertise the IP of the multicast source through the command network instead of the type 7 LSA. In this way, the NE40 devices dont need to translate and calculates the routes directly according to the LSAs sent by the 8912 devices. The command is as follows:
router ospf 1

Execute the command show ip mroute and find that most of the channels have the multicast routing tables (*,G), that (S,G) entries are normal, and that packet count is increasing.

Execute the command show ip pimsm neighbor to examine the pim adjacency between 8912 and NE40. And it is normal.

Execute the command show logging alarm. And then no alarms occur. 4. Because we could not find a clue, we contacted

the person responsible for the interconnected devices to work out the cause together. We contacted HUAWEI and then checked the NE40 for related information. We found that on NE40 there were continuous reports about OSPF route withdrawal. The withdrawn routes were bound for the server network (including network IP of multicast source) under the 8912. 5. So we are sure the fault was caused by NE40 s withdrawal of routes for the multicast source network under the 8912. After arriving at the NE40, the multicast data could not pass the RPF (reverse path forwarding) of the NE40 and thus was dropped. Therefore, the users could not receive the multicast and the videos became blocked. But the NE40 didn t keep withdrawing the routes. When it was able to load the routes, the RPF detection succeeded, the multicast data could be forwarded normally, and thus the services restored.

network 10.10.125.140 0.0.0.3 area 10.10.125.128

The network stub routing information advertised through this command is included in the type 1 LSA. After the configuration, the NE40 devices can learn the routes of the network where the multicast source locates and the services recover. The next question is to examine whether it was the NE40 software bug or performance problem that caused the failure of translation into type 5 LSA.

4 Solutions
Now, it has been clear the problem was caused by the NE40s withdraw of routes of the network where the multicast source locates. For this problem, the explanation is as follows: The 8912 and NE40 are interconnected in the NSSA area, and the 8912 devices execute the command

5 Lessons Learned
1. Once the fault happens, you can collect the geographical distribution information of the devices to roughly estimate which devices may have the fault. 2. During the search for the fault, if our devices are interconnected to the devices from

Data Products

25

April 2012

Issue 270

Maintenance Instances

another vendor, we should coordinate with it to find out the fault cause together to improve the troubleshooting efficiency. 3. For the fault search, it is necessary to examine all service related information. Here is the multicast problem, so we need to examine the multicast routing table status (including whether the increase of the packet count is normal and whether the aging time of the entries is normal),

pim neighbor status, IGMP group join, and DR election status. For the unicast routes, we need to examine the OSPF neighbor status, route learning status and database status. 4. Besides the packet loss, the blocked multicast may be caused by receipt of multiple multicast streams at the same time. And because the user side ADSL access bandwidth is insufficient, one of the multicast streams gets lost and the videos become blocked.

Abnormal Multicast Route

Huang Wentao/ZTE Corporation
Abstract: The (S, G) routing item fails to be formed because the RPF detection fails. Key words: VRRP, PIM, SPT, RPF, static route

1 Fault Symptom
Figure 1 shows two faults, including: The equipment cannot form a normal (S, G) routing item. The multiple stream received by the terminal of the user is only transferred through the (*, G) route.

2 Fault Analysis
1. Verify that the multicast routing table of the 8912-3 equipment only includes the (*, G) item.

Figure 1. Abnormal Multicast Route

26

Maintenance Experience

www.zte.com.cn

8912-3#show ip mroute

IP Multicast Routing Table

Flags:D -Dense,S -Sparse,B -By Hand,C -Connected,L -Local,P -Pruned, R -RP-bit set,F -Register flag,T -SPT-bit set,J -Join SPT, M -MSDP created entry,N -No Used,U -Up Send, * -Assert flag A -Advertised via MSDP,X -Proxy Join Timer Running, Statistic:Receive packet count/Send packet count Timers:Uptime/Expires Interface state:Interface,Next-Hop or VCD,State/Mode (*, 239.100.0.1), 14:36:49/00:03:35, RP 10.234.63.124 , 273052/273052, flags: SC Incoming interface: vlan92, RPF nbr 192.168.43.181 Outgoing interface list: vlan50, Forward/Sparse, 14:36:49/00:03:17 C

2. After the (*, G) routing item is formed, the equipment performs the SPT handover automatically after the first multicast stream is received, and sends a PIM adding message to S. In this case, the (S,G) routing item is generated. The subsequent stream is
8912-3#show ip route 10.234.63.111 IPv4 Routing Table: Dest 0.0.0.0 Mask Gw Interface

transferred through the (S,G) route. It is doubted that the RPF detection on the onsite multicast fails. When checking the route to the source, the engineer finds that RPT detection fails.

0.0.0.0 192.168.43.180

vlan92[xgei_ 5/2]

Owner

static

Pri Metric 1

RPF information:

8912-3#show ip rpf 10.234.63.111 RPF interface is vlan92 (pimsm) RPF metric preference is 1 RPF metric value is 0 RPF type is unicast

RPF neighbor is 192.168.43.180 (isn't neighbor)

3. When checking the user network, and the PIM neighbor of the 8912-3 equipment, the engineer finds that the VRRP function between the 8912-1 and 8912-3 equipment is enabled.
8912-3#show ip pimsm neighbor Neighbor Address 192.168.43.181 Interface vlan92

The IP address of the IPM neighbor is 192.168.43.181. In which, 192.168.43.180 is the virtual IP address of the VRRP.

DR Priority 1

/* Showing the PIM neighbor of the equipment*/ Uptime 4d20h Expires 00:01:44 Ver V2

Data Products

27

April 2012

Issue 270

Maintenance Instances

3 Solutions
After adding another route to the 8912-3 equipment, the engineer finds that the RPF detection is passed.
8912-3(config)#ip route 10.234.63.111 255.255.255.255 192.168.43.181 /* Adding a static route to the source*/ 8912-3(config)#show ip rpf 10.234.63.111 RPF information: RPF interface is vlan92 (pimsm) RPF metric preference is 1 RPF metric value is 0 RPF type is unicast /*Normal RPF detection*/

RPF neighbor is 192.168.43.181 (is neighbor)

The engineer finds that the multicast routing table is normal, and the (S, G) routing item is generated.
8912-3(config)#show ip mroute IP Multicast Routing Table /*The multicast routing table is normal*/

Flags:D -Dense,S -Sparse,B -By Hand,C -Connected,L -Local,P -Pruned, R -RP-bit set,F -Register flag,T -SPT-bit set,J -Join SPT, M -MSDP created entry,N -No Used,U -Up Send, * -Assert flag A -Advertised via MSDP,X -Proxy Join Timer Running, Statistic:Receive packet count/Send packet count Timers:Uptime/Expires Interface state:Interface,Next-Hop or VCD,State/Mode (*, 239.100.0.1), 14:42:41/00:03:35, RP 10.234.63.124 , 274877/274877, flags: SC Incoming interface: vlan92, RPF nbr 192.168.43.181 Outgoing interface list: vlan50, Forward/Sparse, 14:42:41/00:02:58 C

(10.234.63.111, 239.100.0.1), 00:00:09/00:03:35 , 1211/1211, flags: CJT Incoming interface: vlan92, RPF nbr 192.168.43.181 Outgoing interface list: vlan50, Forward/Sparse, 00:00:09/00:03:21 C

28

Maintenance Experience