maintenance experience%2c issue276(data praducts)_523290

Data Products Special IssueIssue 1, 2013

Maintenance ExperienceEditorial Committee

Maintenance ExperienceNewsroom

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: [email protected]

Technical support website: http://ensupport.

zte.com.cn

Maintenance ExperienceBimonthly for Data ProductsNo. 1 Issue 276, April, 2013

Director: Chen Jianzhou

Deputy Director: Zeng Li

Technical Senior Editors:Hu Jia, Tao Minjuan, Zhang Jianping,Zhu Xiaopei

Executive Editor:Zhang Fan

Maintenance Experience Editorial CommitteeZTE CorporationApril , 2012

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 ten 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 commissioningand 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: [email protected]. Thank you for making ZTE a part of your telecom experience!

Contents

Brief Introduction About uRPF ............................................................................................................2

Active/Standby VRRP Switchover Failure on the ZXR10 6902 ..........................................................4

Base Station Offline Failure for a Loop in the Network of ZXR10 8902 ...............................................6

ZXR10 T8000 Router Reflector Fails to Reflect VPN Routing Information ..........................................8

FTP Service Failure for Incorrect MTU Setting in the MPLS Network .................................................10

Interconnection Failure between M6000 and Transmission Devices ..................................................12

Active/standby Load Sharing Failure on Multiple Uplinks of the ZXR10 T600 .....................................15

IPTV Users Fails to Watch Programs after the Multicast Service of M6000 is Activated ....................24

Charging Messages on the M6000 are Sent to Two Different Servers ...............................................27

Routing Forward Table Failure for Incorrect BGP Synchronization Setting .........................................28

FAQ .....................................................................................................................................................34

Technical Special

2 ︱Maintenance Experience Issue 276

Brief Introduction About uRPF

Yang Zhiwei / ZTE Corporation

1 uRPF Overview

Unicast Reverse Path Forwarding (uRPF)

prevents the network attacks resulting from

source address spoofing. The reverse path

forwarding is relative to the normal path

forwarding. After receiving packets, routers

obtain destination addresses of packets and

then find routes in accordance with the

destination addresses. If the corresponding

routes are found, packets will be forwarded. If

the corresponding routes are not found,

packets will be discarded.

By obtaining source addresses and

ingresses of packets, the uRPF function uses

source addresses as destination addresses,

and checks whether the interfaces

corresponding to the source addresses in the

forwarding table match ingresses. If the

interface matching fails, it is considered that

the source addresses are fake addresses. In

this case, packets are discarded. With this

method, the uRPF function can effectively

protect the network from malicious attacks

caused by source address modification.

2 uRPF Configuration

The following describes the uRPF

function limitations and configurations on ZTE

high-end switches, routers, and BRAS

products.

(1) Switch

High-end switches support the uRPF

function, but XG-line cards of G-series

switches do not support the uRPF function.

The configuration is as follows:

Enable the URPF function in physical

interface configuration mode:

ZXR10(config-if)#ip verify {strict |

loose}

It is recommended to use the strict mode

for all downstream interfaces, and the loose

mode for all upstream interfaces.

(2) T600/T1200 router

All T600/T1200 routers support the uRPF

function. The configuration is as follows:

Enable the URPF function in physical

interface configuration mode:

ZXR10(config)#interface

<interface-name>

ZXR10(config-if)#ip verify {strict |

loose}

It is recommended to use the strict mode

for all downstream interfaces, and the loose

mode for all upstream interfaces.

(3) M6000 router

The M6000 router supports the uRPF

function. The configuration is as follows:

Downstream interfaces:

app:ds:brief%20introduction

Sincere Service l

Data Products Special Issue Issue 1, 2013︱ 3

Method 1, configure the uRPF function

in global configuration mode:

ZXR10(config)#ipv4 verify unicast

source reachable-via rx interface

<interface-name>


in interface configuration mode:


<interface-name>

ZXR10(config-if)#ipv4 verify unicast

source reachable-via rx

Upstream interfaces:


in global configuration mode:

ZXR10(config)#ipv4 verify unicast

source reachable-via any interface

<interface-name>


in interface configuration mode:


<interface-name>

ZXR10(config-if)#ipv4 verify unicast

source reachable-via any

(4) BAS device

For users connected to VBUI interfaces

of T600, T1200, and M6000 routers, a user

table listing the relationship between the

users and IP addresses exists on the

Broadband Access Server (BAS). If a user IP

address does not match that in the user table

on the BAS, the BAS does not forward

packets. The VBUI interface of the BAS

supports the uRPF function by default.

3 uRPF FAQ

(1) Question: Is the uRPF function is

limited by hardware or software versions of

switches, routers, and BAS devices?

Answer: All hardware (except the XG-line

card of G-series switches) and the current

popular versions support the uRPF function.

(2) Question: Is the URPF function

configured for physical interfaces or

sub-interfaces? Do sub-interfaces inherit the

URPF function of real interfaces?

Answer: Physical interfaces are

independent from sub-interfaces, so both

physical interfaces and sub-interfaces should

be configured with the URPF function. Real

interfaces are independent from

sub-interfaces, so sub-interfaces do not

inherit the URPF function of real interfaces.

(3) Question: Whether to enable the

uRPF function on SmartGroup interfaces?

Answer: The URPF function is enabled

on SmartGroup interfaces of T600/T1200

/M6000.

Maintenance Instances


Active/Standby VRRP Switchover

Failure on the ZXR10 6902

Zhang Jie / ZTE Corporation

Abstract: This section describes the active/standby VRRP switchover failure between two 6902 devices.

The analysis results show that this fault results from the incorrect VLAN setting for interfaces of the

heartbeat line.

Key words:6900, VRRP, active/standby switchover, VLAN, heartbeat line

1 Symptom

As shown in Figure 1, two 6902 devices

act as convergent devices. The upstream

interfaces of 6902 devices are connected to

T64E, while the downstream interfaces of

6902 devices are connected to two 2920

switches that are enabled with the VRRP

function. VRRP packets are transmitted

through the heartbeat line between 6902-1

and 6902-2.

Figure 1. 6902 VRRP Active/Standby

Network Diagram

In general, 6902-1 is in Master status,

and 6902-2 is in Backup status. If the link

between 6902-1 and the corresponding

downstream 2920 is broken, the VRRP

active/standby switchover between 6902-1

and 6902-2 fails. In this case, 6902-1 is still in

Master status, and 6902-2 is still in Backup

status.

2 Fault Analysis

(1) 6902-2 is still in Backup status. It is

judged that 6902-1 still sends VRRP packets

through the heartbeat line, and the data

stream of the heartbeat line is normal after the

downlink of 6902-1 is broken. To verify this

conclusion, the engineer breaks the heartbeat

line. The displayed result on 6902-2 is as

follows:

Sincere Service l


6902-2(config)#

11:10:42 03/14/2009 UTC alarm 512 occurred %PORT% Interface down on gei_1/2 sent

by MEC 1

11:10:44 03/14/2009 UTC alarm 22016 occurred %VRRP% Group 1 of vlan10 changing to

Master sent by MEC 1

The displayed result shows that 6902-1 still sends VRRP packets when its downlink is

broken. All the above information shows that the fault results from 6902-1.

(2) If 6902-1 finds that the interface used by the VRRP group is down, it stops sending

VRRP packets, and then the VRRP active/standby switchover is performed. That is to say,

6902-1 does not find that the downlink is broken, or the downlink is still in UP status.

Check the configuration of used interfaces, such as vlan10, in VRRP Group 1,.

interface vlan 10

ip address 10.40.108.253 255.255.255.0

vrrp 1 priority 200

vrrp 1 out-interface gei_1/2

vrrp 1 ip 10.40.108.254

(3) Check the statuses of used interfaces, such as vlan10, in the VRRP group,.

6902-2(config)#show interface vlan10

vlan10 is up, line protocol is up

(4) VLAN10 is in UP status, so 6902-1 still sends VRRP packets. Only one 2920 switch is

connected to 6902-1, why VLAN10 is still in UP status?

6902-2(config)#show vlan id 10

VLAN Name Status Said MTU IfIndex PvidPorts UntagPorts TagPorts

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

10 VLAN0010 active 100010 1500 0 gei_1/1-2

(5) The heartbeat egress is VLAN1. The heartbeat egress of 6902-2 belongs to another

VLAN and there is no loop, but this configuration interferes with the normal operation of 6902-1.

3 Solution

The problem is solved after interface gei_1/2 is deleted from VLAN10.

4 Conclusion

The VRRP active/standby switchover is triggered by the VLAN protocol status of interfaces

used by the VRRP group. After a heartbeat line is configured, you must ensure that the status of

the downlink should be consistent with the VLAN protocol status of the corresponding

interface.



Base Station Offline Failure for a

Loop in the Network of ZXR10 8902

Li Yong / ZTE Corporation

Abstract: This section describes the offline fault of base stations caused by a loop.

Key words: 8902, loop, base station offline, high-usage, SuperVLAN

1 Symptom

ZXR10 8902 switch in a network acts as

a gateway, and tens of 2G or 3G base

stations connected to the ZXR10 8902 switch

are often offline. After telneting to this switch,

engineers cannot execute any command

properly.

2 Fault Analysis

(1) Engineers telnet to 8902 remotely and

check device alarms. The OSPF connection

between this switch and that of a central office

interrupts frequently, and there is no rule.

(2) The CPU usage of the only NP line

card of this switch exceeds 80%, and the MP

usage of the master main control board is up

to 80%. The pre-judgment result is that there

is a loop in the network.

ZXR10#show logging alarm

alarm 16901 occurred %OAM% CPU load

exceeds the highest threshold 75% MP(M)

panel 1 current CPU load is: 98% sent by

MEC 1

(3) Engineers turn on the MAC address

floating switch of 8902. No MAC address

floating alarm is generated.

ZXR10(config)#mac logging-alarm

mac-move enable

(4) Engineers observe the traffic of

interfaces gei_2/19 and gei_2/20 connected to

this switch. There is no obvious abnormality,

and the increment of broadcast packets and

multicasts are smooth.

(5) When the out-of-band management

interface gei_2/20 of this switch that connects

to a L2 network device is disabled, engineers

still cannot execute any command properly in

Telnet mode, and the CPU usage of both the

line card and the main control board is high.

After that, engineers enable this interface.

(6) When the out-of-band management

interface gei_2/19 of this switch that connects

to a L2 network device is disabled, engineers

can execute all commands properly in Telnet

mode, the CPU usage of both the line card

and the main control board is normal. The

pre-judgment result is that many packets exist

in interface gei_2/19, so the CPU usage of

Sincere Service l


both the line card and the main control board

is high.

(7) Engineers enable interface gei_2/19

and then obtain CPU packets of the above

line card by executing the capture command.

The command is as follows:

ZXR10(config)#capture npc 2

readspeed 10

(8) Engineers enable interface gei_2/19

and then obtain the following information:

ARP Packet on NPC: 2

OP SND_MAC SND_IP DST_MAC DST_IP DIR Port

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

ARP Packet on NPC: 2

OP SND_MAC SND_IP DST_MAC DST_IP DIR Port

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

1 0000.5e00.0101 10.127.76.129 0000.0000.0000 255.255.255.255 RX 19

IP Packet on NPC: 2

ProType DST_IP SRC_IP OVID IVID TTL PRO SRCPN DSTPN DIR Port

VRRP 224.0.0.18 10.127.76.129 1155 NULL 255 112 NULL NULL RX 19














(9) The printed information shows that

interface gei_2/19 receives many ARP

packets and VRRP protocol packets. The

configuration shows that all source addresses

of these packets are configured on a

SuperVLAN interface of 8902, and interface

SuperVLAN is enabled with the VRRP

function. The printed OVID information is

consistent with the SubVLAN information of

the SuperVLAN interface. The SuperVLAN

interface is the gateway for interface gei_2/19

connected with these offline base stations.

The above result shows that the network

where interface gei_2/19 is connected to has

a loop. Packets sent from interface gei_2/19

by 8902 are also sent to interface gei_2/19, so

the CPU usage of the line card is high. This

OSPF connection is broken, so the base

stations are often offline.

3 Solution

The above analysis shows that there is a

loop in the network. After going to the field,

related engineers find that the loop is caused

by the network cabling failure during the

commissioning. The fault is solved after the

loop is deleted.

ZXR10 T8000 Router Reflector Fails to Reflect VPN Routing Information

Fan Wei / ZTE Corporation

Abstract: This section describes if T8000 that acts as a router reflector needs to reflect VPN routing

information, the Route-Target attribute filtering function must be disabled.

Key words: T8000, vpnv4, reflector, VRF, MPLS, Route-Target

1 Symptom

As shown in Figure 1, T8000 acting as a

router reflector is connected to two M6000

devices, and runs L3 MPLS VPN services.

After the Label Distribution Protocol (LDP)

and VPNv4 are configured, the neighbour

relationship of two M6000 devices is

established successfully, but these two

M6000 devices cannot learn routes from each

other.

Figure 1. T8000 Router Reflector Topology

Sincere Service l


2 Fault Analysis

The possible reasons are as follows:

(1) VPN route information is not notified.

(2) The RT setting of two M6000 devices

is incorrect.

(3) T8000 does not forward VPN routes.

(4) VPN routes are filtered.

Perform the following steps to locate the

fault:

(1) Check the Label Distribution Protocol

(LDP) forwarding table. The related labels are

allocated properly.

(2) After establishing the corresponding

VRF on T8000, engineers find that M6000

devices can learn VRF routes from each other.

Once when the VRF is deleted, VRF routes

disappear.

(3) The BGP protocol supports the

MPLS-VPN application. For VPNv4 routes,

the Route-Target attribute must be enabled.

For router reflectors and inter-domain EBGPs,

the Route-Target function must be disabled. If

not, router reflectors will filter VRF RTs. In this

case, the client cannot receive related

information, so VRF routes of the peer end

cannot be learnt.

3 Solution

After the no bgp default route-target filter

command is executed in the BGP

configuration of T8000, two M6000 devices

can learn VPN routes from each other. The

fault is solved.

4 Conclusion

During the router reflector configuration,

the Route-Target attribute filtering function is

enabled by default. To reflect related VPN

route information, you need to execute the no

bgp default route-target filter command to

disable the Route-Target function.



FTP Service Failure for Incorrect MTU Setting in the MPLS Network

Li Jing / ZTE Corporation

Abstract: The Maximum Transfer Unit (MTU) of an interface on a router is smaller than the length of

a packet, so the FTP client cannot transfer files to the FTP server. This fault is solved after the MTU of an

interface on the router is modified.

Key words: MPLS, FTP, MTU, fragment

1 Symptom

Most bearer networks use the MPLS

network. In core networks, files, such as LOG

files, are transferred between the FTP client

and the FTP server through the MPLS

network, as shown in Figure 1.

Normally, the FTP client can successfully

ping the IP address of the FTP server.

However, files cannot be transferred even if

the FTP client can successfully ping the FTP

server.

2 Fault Analysis

(1) Engineers can successfully ping the

FTP server from the FTP client, which means

that the VPN route is normal.

(2) Files cannot be transferred when the

FTP client can successfully ping the FTP

server, which means that maybe the MTU

setting is incorrect.

Figure 1. FTP Service Failure for Incorrect MTU Setting in the MPLS Network

Sincere Service l


In general, the MTU for an interface of a

network device, including the clients and the

server in the core network, is set to 1500

bytes by default. When a packet passes

through an MPLS network, two layers of TAG

labels are added. The length of each TAG

label is 4 bytes. In this case, the total bytes of

a packet with 1500 bytes on the PE side

become 1508 bytes, which exceeds the MTU

that is set for an interface on the router. In this

case, the packet is discarded.

3 Solution

After setting the IP MTU for interfaces on

the network side of routers in the network to

1508 bytes, the FTP service becomes normal.

If there is a transmission device between

routers, and the IP MTU cannot be modified

by the transmission device. You need to set

the IP MTU of interfaces on routers to the

default value (1500 bytes), and then set the IP

MTU of the system to 1492 bytes on both the

FTP client and the FTP server. In this case,

the FTP service also becomes normal.

4 Conclusion

The FTP service does not fragment a

packet during the transmission. When a

packet passes through an MPLS network, the

packet will be discarded if the size of the

packet exceeds the set IP MTU.

When the service is invalid after the

device route in a network is connected, you

need to consider the setting of the IP MTU.



Interconnection Failure between M6000 and Transmission Devices

Li Yunfeng / ZTE Corporation

Abstract: This section describes the interconnection failure between M6000 and transmission devices.

The analysis results show that the fault results from inconsistent V5 bytes. This fault is solved after the V5

byte is modified.

Key words: M6000, CPOS, E1, transmission, interconnection

1 Symptom

During the network reconstruction of one

company, M6000 interconnects with

transmission devices of other manufacturers

and E1 links of each sub-company through

the CPOS. However, the E1 link divided by

the CPOS cannot interconnect with the E1 link

of a sub-company successfully.

Figure 1. Interconnection Between M6000 and Transmission Device through the CPOS

2 Fault Analysis

(1) The network and router (including the

version) of this company are the same as

those of the associated companies. The E1

interconnection in other networks is

successful, so the fault is unrelated to the

router and its version.

(2) The intermediate transmission

devices are from the same manufacturer. The

only difference is that the transmission device

of this company is updated. Maybe the

interconnection fault may result from the

Sincere Service l


parameter change after the update of the

transmission device.

(3) When executing the show controller

cpos3-0/0/0/1 command on M6000, engineers

find that the E1 interconnection of the CPOS

high order path (AU4) is normal, but that of

the lower order path (VC12) is unsuccessful.

The detailed information are as follows:

M6000#show controller e1 cpos3-0/0/0/1 au4 1 tug3 2 tug2 2 e1 1

Low order path: AU-4 1, TUG-3 2, TUG-2 2, C-12 1

Active Alarm: TIM

History Alarm: AIS = 2 RDI = 2

LOP = 0 LOM = 2

TIM = 2 TIU = 2

SLM = 0 SLU = 0

PDI = 0 UNEQP = 0

Error : BIP2 = 0 LPREI(V5) = 16284

NEWPTR = 0 PSE = 0

NSE = 0

V5(TX): 0x01

V5(RX): 0x02

V5(EX): 0x01

J2(TX): "ZTE ZXR10 T8000"

CRC-7 : 0xaf

5a 54 45 20 5a 58 52 31 30 20 54 38 30 30 30

J2(RX): "HuaWei SBS "

CRC-7 : 0x96

48 75 61 57 65 69 20 53 42 53 20 20 20 20 20

J2(EX): "ZTE ZXR10 T8000"

CRC-7 : 0xaf

5a 54 45 20 5a 58 52 31 30 20 54 38 30 30 30

E1 is down

Work mode: unframed

Clock source: internal

Loopback: not set

Active Alarm: NONE

History Alarm: LOS = 0 AIS = 0

LOF = 0 RAI = 0

AISD = 0 CRCMLOF = 0

CRCMCRC = 0 CRCMCFEBE = 0

CRCMOOF = 0 CASMLOF = 0

CASMRMAI = 0 CASMAISD = 0

Error : FER = 0 CRCERR = 0

FEBE = 0



The above information shows that there

are many lower-order path remote error

indication (LPREI) errors on M6000. This

alarm results from the inconsistency of V5

bytes of both devices. The above information

shows that the V5 byte sent by the router is

0x01, but the V5 byte received from the peer

end is 0x02. This is the reason why E1

interconnection fails.

3 Solution

Solution 1, Set the V5 byte of the

transmission device to 0x01 in order to be

consistent with that of M6000.

Solution 2, Set the V5 byte of M6000 to

0x02 in order to be consistent with that of the

transmission device.

The modification commands on M6000

are as follows (010 in binary format is equal to

0x02 in Hex format):

controller cpos3-0/0/0/1

framing sdh

aug mapping au4

au4 1 tug3 1

mode e1

tug2 1 e1 1

flag v5 010

4 Conclusion

During the interconnection of

transmission devices from different

manufacturers, the parameter configuration

must be consistent.

Sincere Service l


Active/standby Load Sharing Failure on Multiple Uplinks of the ZXR10 T600

Wang Lei / ZTE Corporation

Abstract: The cost value calculated by the OSPF is the same, so the traffic passes through each uplink.

In this case, the link with a wide bandwidth cannot be the master link, and the link with a narrow

bandwidth cannot be a standby link. This fault is solved after the reference bandwidth that is used by the

OSPF during calculating the cost value is modified.

Key words: T600, OSPF, cost, reference bandwidth, active/standby link

1 Symptom

As shown in Figure 1, the ZXR10 T600

BRAS of one area has six 1GE uplinks (black

line). Two 10GE boards are added, that is to

say, two 10G uplinks are added (red line). In

this case, there are eight uplinks. It is hoped

that the traffic is forwarded through two 10GE

uplinks, and six 1GE uplinks are backup links.

After the service cutover, the traffic

passes through eight uplinks instead of the

two 10GE uplinks.

2 Fault Analysis

(1) Check the configuration of

T600-BRAS. The OSPF configuration is as

follows:

Figure 1. Topology of T600 with Multiple Uplinks

router ospf 100

router-id 10.20.252.77

maximum-paths 8 /* eight uplinks share the load*/

network 10.10.129.54 0.0.0.0 area 0.0.1.10

network 10.10.129.58 0.0.0.0 area 0.0.1.10

network 10.10.231.19 0.0.0.0 area 0.0.1.10

network 10.10.241.34 0.0.0.0 area 0.0.1.10

network 10.10.241.38 0.0.0.0 area 0.0.1.10



network 10.10.241.54 0.0.0.0 area 0.0.1.10

network 10.10.241.58 0.0.0.0 area 0.0.1.10

network 10.20.244.182 0.0.0.0 area 0.0.1.10

network 10.20.244.186 0.0.0.0 area 0.0.1.10

network 10.20.244.190 0.0.0.0 area 0.0.1.10

network 10.20.252.77 0.0.0.0 area 0.0.1.10

(2) When checking the cost value of the OSPF interface by executing the show ip ospf

interface command, engineers find that the cost value of both 1GE ports and expanded 10GE

ports is 1.

ZXR10#show ip ospf interface

OSPF Router with ID (10.20.252.77) (Process ID 100)

xgei_3/1 is up

Internet Address 10.10.129.54 255.255.255.252 enable

Up for 8w0d

In the area 0.0.1.10 POINT_TO_POINT

Cost 1, Priority 1, Network Type point-to-point

Transmit Delay(sec) 1, Authentication Type null

Timer intervals(sec) : Hello 10, Dead 40, Retransmit 5

Number of Neighbors 1, Number of Adjacent neighbors 1

10.10.255.230

xgei_5/1 is up


Up for 8w0d






10.10.255.231

gei_2/5 is up


Up for 36w1d






Sincere Service l


10.10.255.231

gei_6/1 is up


Up for 8w0d






10.10.255.230

gei_1/5 is up


Up for 8w0d






10.10.255.230

gei_8/1 is up


Up for 14w2d






10.10.255.231

gei_1/1 is up


Up for 8w0d






10.10.255.231

gei_2/1 is up




Up for 8w0d






10.10.255.230

(3) The cost value is calculated by the

automatic calculation formula in the OSPF

protocol, that is to say, the ospf cost value

(round down) of an interface is equal to

100/interface bandwidth. For the gei interface,

the cost value is the round-off number of 0.1,

that is to say, the cost value is 1. For the

10GE interface, the cost value is also the

round-off number of 0.01, that is to say, the

cost value is also 1. In this case, the cost

value of interface gei and interface xgei is the

same, so the initial requirement cannot be

met.

3 Solution

You can execute the auto-cost

reference-bandwidth <1-4000000> command

to modify the reference bandwidth in the

OSPF configuration and then modify the cost

value. The configuration after the modification

is as follows:

router ospf 100

router-id 10.20.252.77

auto-cost reference-bandwidth 10000 /*adding a reference bandwidth*/

maximum-paths 8 /* eight links share the load*/

network 10.10.129.54 0.0.0.0 area 0.0.1.10

network 10.10.129.58 0.0.0.0 area 0.0.1.10

network 10.10.231.19 0.0.0.0 area 0.0.1.10

network 10.10.241.34 0.0.0.0 area 0.0.1.10

network 10.10.241.38 0.0.0.0 area 0.0.1.10

network 10.10.241.54 0.0.0.0 area 0.0.1.10

network 10.10.241.58 0.0.0.0 area 0.0.1.10

network 10.20.244.182 0.0.0.0 area 0.0.1.10

network 10.20.244.186 0.0.0.0 area 0.0.1.10

network 10.20.244.190 0.0.0.0 area 0.0.1.10

network 10.20.252.77 0.0.0.0 area 0.0.1.10

Execute the show ip ospf interface command to check the port after the modification. The

result is as follows:

Sincere Service l


ZXR10#show ip ospf interface

OSPF Router with ID (10.20.252.77) (Process ID 100)

xgei_3/1 is up


Up for 8w0d






10.10.255.230

xgei_5/1 is up


Up for 8w0d






10.10.255.231

gei_2/5 is up


Up for 36w1d






10.10.255.231

gei_6/1 is up


Up for 8w0d






10.10.255.230



gei_1/5 is up


Up for 8w0d






10.10.255.230

gei_8/1 is up


Up for 14w2d






10.10.255.231

gei_1/1 is up


Up for 8w0d






10.10.255.231

gei_2/1 is up


Up for 8w0d






10.10.255.230

Sincere Service l


Check the port traffic. The detailed information is as follows:

ZXR10#show interface xgei_3/1

xgei_3/1 is up, line protocol is up

MAC address is 00d0.d0c0.0320

The port is optical

Duplex full

ARP Timeout: 04:00:00

Internet address is 10.10.129.54/30

IP MTU 1500 bytes

MRU 7600 bytes

MTU 1600 bytes BW 10000000 Kbits

Last clearing of "show interface" counters never

120 seconds input rate : 616702041Bps, 710654 pps

120 seconds output rate: 196551666Bps, 461783 pps

Interface peak rate :

input 725773412Bps,output 281997203Bps

Interface utilization : input 49%, output 15%

Input:

Packets : 6237211371020 Bytes : 5040435755736334

Unicasts : 6237203196739 Multicasts: 7880991

Broadcasts: 293290 64B : 333351442209

65-127B : 1706566208851 128-255B : 314313153568

256-511B : 118028738416 512-1023B : 144522828338

1024-1518B: 3620266192982 Undersize : 0

Oversize : 162806656 CRC-ERROR : 0

Output:

Packets : 4873272205284 Bytes : 2197434703453395


Broadcasts: 103 64B : 869560676016

65-127B : 1995645961955 128-255B : 295637721093

256-511B : 64218865493 512-1023B : 93262949507

1024-1518B: 1554051505129 Oversize : 894526091

ZXR10#show interface xgei_5/1

xgei_5/1 is up, line protocol is up


The port is optical

Duplex full



IP MTU 1500 bytes

MRU 7600 bytes










Input:

Packets : 5909167868576 Bytes : 4765843744345818


Broadcasts: 293867 64B : 311979849260

65-127B : 1626534764575 128-255B : 297439240589

256-511B : 111511295278 512-1023B : 136637845848

1024-1518B: 3424957650589 Undersize : 0


Output:

Packets : 5455649213711 Bytes : 2460199055761584


Broadcasts: 118 64B : 982469129919

65-127B : 2222358893314 128-255B : 332457557334

256-511B : 73619528091 512-1023B : 106630120260

1024-1518B: 1735509368992 Oversize : 2604615801

ZXR10#show interface gei_1/1 /* Other GE ports are just similar*/

gei_1/1 is up, line protocol is up


The port is optical

Duplex full



IP MTU 1500 bytes

MRU 7600 bytes








Input:

Packets : 1519036653750 Bytes : 1155108969461211


Broadcasts: 525067 64B : 85063231893

65-127B : 451390192631 128-255B : 83821966538

Sincere Service l


256-511B : 26785522283 512-1023B : 41692690477

1024-1518B: 830237297111 Undersize : 0


Output:

Packets : 1208948795938 Bytes : 534669095751132


Broadcasts: 134 64B : 186289980847

65-127B : 526768727390 128-255B : 76365658974

256-511B : 13593552803 512-1023B : 25813774860

1024-1518B: 380074304673 Oversize : 42796391

The above information shows that the traffic passes through two 10GE ports, and there is no

traffic pass through the 1GE ports. The initial requirement is met.

4 Conclusion

You need to master the application of the auto-cost reference-bandwidth command in the

OSPF. You can execute this command to modify the reference bandwidth used by the OSPF

during calculating the cost value as required.



IPTV Users Fails to Watch Programs after the Multicast Service of M6000 is Activated

Yun Yuejun / ZTE Corporation

Abstract: This section describes that IPTV users cannot watch programs because the M6000

configuration is inconsistent with the T600 configuration.

Key words: M6000, T600, IPTV, multicast, static

1 Symptom

IPTV services of one area are activated,

and multicast duplication spots are set on

BRAS nodes. 50 pilot programs are activated

in advance. M6000 acts as the BRAS device,

and connects to convergence switches.

Convergence switches provide the access

function to the Optical Line Terminal (OLT),

Access Gateway (AG), and L2.

M6000 acts as the BRAS device when it

connects to the network for the first time, and

the IPTV service is activated. New IPTV users

can only watch programs on demand instead

of live programs. Engineers configure the

M6000 in accordance with theT600

configuration. But, IPTV pilot programs are

activated in the T600 configuration.

In accordance with the activation

requirements of users, static multicast groups

of 50 pilot programs activated in advance are

configured on the BRAS device. Static

multicast groups have the following

advantages:

(1) The multicast route is steady, and it

exists no matter multicast data exists or not.

(2) The management on the multicast

source and the multicast range is simple

because the multicast route is steady.

(3) No dynamic multicast route is

established, so the delay is low during the first

live program.

The IPTV service allocates two accounts

to users. One is the PPPoE account, which is

used to obtain IP address, and the other is the

IPTV platform account, which is used for the

IPTV platform authentication. After two

accounts are configured for the set-top box on

the user side, the set-top box can be

connected to the IPTV platform.

2 Fault Analysis

(1) M6000 and metropolitan area

networks (MANs) converge on the NE5000E

side, and the PIMSM neighbour is normal.

The mroute command shows that there are

(*,G) and (S,G) items and multiple channels.

Sincere Service l


M6000#show ip pimsm neighbor

Neighbor Address Interface DR Priority Uptime Expires Ver

121.30.9.197 xgei-0/1/0/1 1 18d10h 00:01:33 V2

121.30.9.193 xgei-0/0/0/1 1 41d0h 00:01:25 V2

M6000#show ip mroute

(*, 226.0.2.41), RP: 218.26.134.127, TYPE: DYNAMIC, FLAGS: NS

Incoming interface: xgei-0/1/0/1, flags: NS

Outgoing interface list:

vbui2, flags: F/S

(10.112.2.69, 226.0.2.41), TYPE: DYNAMIC, FLAGS:

Incoming interface: xgei-0/1/0/1, flags:


vbui2, flags: F/S




vbui2, flags: F/S




vbui2, flags: F/S




vbui2, flags: F/S




vbui2, flags: F/S




vbui2, flags: F/S




vbui2, flags: F/S

(2) When checking the dialing information

of the top-set box, the user finds that the

bandwidth authentication is successful. When

the top-set box is connected to the IPTV

platform, the system prompts that the top-set



box cannot be connected to the remote

server.

(3) The above information about M6000

shows that the bandwidth account of the user

is online.

(4) In general, the generated (*,G) and

(S,G) items mean that multicast stream is sent

properly. The IPTV service of all users

connecting to the T600 device is normal.

(5) The M6000 router is first used for

China Unicom MAN, and engineers configure

the IPTV service of T6000 in accordance with

the T600 configuration. Engineers doubt that

maybe the configuration mode of different

software platforms is different. After

consultation, engineers find that the

configuration location of the static multicast

group on M6000 is incorrect.

The static multicast group on T600 is

configured on the VBUI interface.

interface vbui3

ip address 10.143.206.1

255.255.254.0

ip pim sm

ip igmp static-group 226.0.2.1




The static multicast group on M6000 is

configured on the interface of the user side,

so users cannot watch IPTV programs.

subscriber-manage

igmp service-profile 1

static-group 226.0.2.1




3 Solution

It is not required to configure the static

group joint function for the multicast on the

user side. Static users are added to a group

when they are online. A user can be added to

multiple groups. In this case, heavy traffic will

be sent to the user, so the packet will be

discarded.

To split static stream, execute the

following commands:

M6000#(config)#ip multicast-routing

M6000#(config-mcast)#router igmp

M6000#(config-mcast-igmp)#interface

loopback1

M6000#(config-mcast-igmp-if-loopback

1)#static-group 226.0.2.1







Sincere Service l


Charging Messages on the M6000 are Sent to Two Different Servers

Lv Zhongwei / ZTE Corporation

Abstract: This section describes charging messages on M6000 are sent to two different servers.

Key words: M6000, charging, RADIUS, copy to, domain name

1 Network Requirement

The IP addresses of the current RADIUS servers in a network are 10.10.97.5 and 10.10.97.3.

A new enabled service needs to copy the charging information in the abc.cn domain to

10.10.107.19.

2 Implementation Method

Configure the ZXR10 M6000:

/*Configure the source RADIUS group*/

radius authentication-group 1

server 1 10.10.97.5 master key 88----89 port 1645

server 2 10.10.97.3 key 88----89 port 1645

alias zradius

deadtime 1

nas-ip-address 222.83.19.8

/*Configure a RADIUS copying group on the BRAS*/

radius

accounting-group 100

server 1 10.10.107.19 key test port 1813

aaa-accounting-template 2

description Acct_zradius

aaa-accounting-type radius

accounting-radius-group first 1 second 100

/*Copy the charging information in the abc.cn domain to 10.10.107.19*/

accounting-template 2

description pppoe

bind aaa-accounting-template 2

domain 1

bind accounting-template 2

alias abc.cn



Routing Forward Table Failure for Incorrect BGP Synchronization Setting

Xu Xiaoguang / ZTE Corporation

Abstract: This section describes that routes fail to be forwarded because the BGP synchronization

function is not disabled.

Key words: BGP, synchronization, EBGP, IBGP, IGP

1 Symptom

As shown in Figure 1, the routing forwarding table of one router is abnormal.

Figure 1. DHCP Users Fail to Go Online

2 Fault Analysis

The results show that BGP synchroni-

zation function in the current network is not

disabled, so routing forward tables fail to be

generated. The following analyzes the

operations in cast that the BGP synchroni-

zation function is enabled or disabled:

(1) Command explanation: The no

synchronization command means that the

BGP synchronization function is disabled.

When the BGP synchronization function is

disabled, the BGP router notifies network

routes instead of waiting for the IGP

synchronization.

(2) Instructor explanation: When the BGP

synchronization function is enabled, the BGP

router cannot notify the BGP routes learnt

from the IBGP neighbor to its own EBGP

neighbor. The BGP router notifies the BGP

routes to the EBGP router except that these

BGP routes exist in the IGP routing table.

3 Solution

Configure the BGP on R3:

R3#show running-config bgp

! <BGP>

router bgp 200

redistribute connected

neighbor 2.2.2.2 remote-as 200

neighbor 2.2.2.2 activate

neighbor 2.2.2.2 next-hop-self

neighbor 2.2.2.2 update-source

loopback1

! </BGP>

Sincere Service l


Check the local BGP routing table:

R3(config)#show ip bgp route

Status codes: *-valid, >-best, i-internal, s-stale

Origin codes: i-IGP, e-EGP, ?-incomplete

Dest NextHop Metric LocPrf RtPrf Path

*i 1.1.1.1/32 2.2.2.2 100 200 100 i

*> 3.3.3.3/32 3.3.3.3 0 0 ?

*> 100.1.1.4/30 100.1.1.6 0 0 ?

*i 172.16.0.0/24 2.2.2.2 100 200 100 i

*i 172.16.1.0/24 2.2.2.2 100 200 100 i

*i 172.16.2.0/24 2.2.2.2 100 200 100 i

*i 172.16.3.0/24 2.2.2.2 100 200 100 i

Check the local routing forward table:

R3#show ip forwarding route

IPv4 Routing Table:

status codes: *valid, >best

Dest Gw Interface Owner Pri Metric

*> 2.2.2.2/32 100.1.1.5 gei-0/0/0/2 ospf 110 1

*> 3.3.3.3/32 3.3.3.3 loopback1 address 0 0

*> 100.1.1.0/30 100.1.1.5 gei-0/0/0/2 ospf 110 2

*> 100.1.1.4/30 100.1.1.6 gei-0/0/0/2 direct 0 0

*> 100.1.1.6/32 100.1.1.6 gei-0/0/0/2 address 0 0

Change the configuration to no synchronization:

R3(config)#show running-config bgp

! <BGP>

router bgp 200

no synchronization





neighbor 2.2.2.2 update-source loopback1

! </BGP>

The BGP routing table is added to the routing forward table.


IPv4 Routing Table:



*> 1.1.1.1/32 100.1.1.5 gei-0/0/0/2 bgp 200 0

*> 2.2.2.2/32 100.1.1.5 gei-0/0/0/2 ospf 110 1




*> 100.1.1.0/30 100.1.1.5 gei-0/0/0/2 ospf 110 2

*> 100.1.1.4/30 100.1.1.6 gei-0/0/0/2 direct 0 0

*> 100.1.1.6/32 100.1.1.6 gei-0/0/0/2 address 0 0

*> 172.16.0.0/24 100.1.1.5 gei-0/0/0/2 bgp 200 0

*> 172.16.1.0/24 100.1.1.5 gei-0/0/0/2 bgp 200 0

*> 172.16.2.0/24 100.1.1.5 gei-0/0/0/2 bgp 200 0

*> 172.16.3.0/24 100.1.1.5 gei-0/0/0/2 bgp 200 0

The above information shows that BGP

routes can be added to the local routing

forward table only when the synchronization

function of the BGP route on R3 is disabled. In

addition, during the EBGP route distribution

between R2 and R1, EBGP routes of other

ASs are added to the local routing forward

table no matter the BGP synchronization

function is disabled or not.

Instructor explanation: When the BGP


router cannot notify the BGP routes learnt

from the IBGP neighbor to its own EBGP

neighbor. The BGP router notifies the BGP

routes to the EBGP router except that these

BGP routes exist in the IGP routing table.

The verification steps are as follows:


router bgp 200

no synchronization


network 33.33.33.33 255.255.255.255





! </BGP>


router bgp 200







BGP routes on R2 are not added to the forwarding routing table. The details are as follows:

R2#show ip bgp route



Sincere Service l



*> 1.1.1.1/32 100.1.1.1 20 100 i

*i 3.3.3.3/32 3.3.3.3 100 200 ?

*i 33.33.33.33/32 3.3.3.3 100 200 i

*i 100.1.1.4/30 3.3.3.3 100 200 ?

*i 100.1.1.8/30 3.3.3.3 100 200 ?

*> 172.16.0.0/24 100.1.1.1 20 100 i

*> 172.16.1.0/24 100.1.1.1 20 100 i

*> 172.16.2.0/24 100.1.1.1 20 100 i

*> 172.16.3.0/24 100.1.1.1 20 100 i


IPv4 Routing Table:



*> 1.1.1.1/32 100.1.1.1 gei-0/0/0/1 bgp 20 0


*> 3.3.3.3/32 100.1.1.6 gei-0/0/0/2 static 1 0

*> 4.4.4.4/32 100.1.1.6 gei-0/0/0/2 ospf 110 2

*> 100.1.1.0/30 100.1.1.2 gei-0/0/0/1 direct 0 0

*> 100.1.1.2/32 100.1.1.2 gei-0/0/0/1 address 0 0

*> 100.1.1.4/30 100.1.1.5 gei-0/0/0/2 direct 0 0

*> 100.1.1.5/32 100.1.1.5 gei-0/0/0/2 address 0 0

*> 100.1.1.8/30 100.1.1.6 gei-0/0/0/2 ospf 110 2

*> 172.16.0.0/24 100.1.1.1 gei-0/0/0/1 bgp 20 0

*> 172.16.1.0/24 100.1.1.1 gei-0/0/0/1 bgp 20 0

*> 172.16.2.0/24 100.1.1.1 gei-0/0/0/1 bgp 20 0

*> 172.16.3.0/24 100.1.1.1 gei-0/0/0/1 bgp 20 0

At the same time, R2 cannot notify route 33.33.33.33 distributed by R2 to the EBGP

neighbor (R1) because the R2 routing table does not include route 33.33.33.33. This meets the

synchronization enabling rule.

The BGP table of R1 does not include route33.33.33.33:

R1(config)#show ip bgp route




*> 1.1.1.1/32 1.1.1.1 0 0 i

*> 3.3.3.3/32 100.1.1.2 20 200 ?

*> 100.1.1.4/30 100.1.1.2 20 200 ?

*> 100.1.1.8/30 100.1.1.2 20 200 ?

*> 172.16.0.0/24 172.16.0.1 0 0 i



*> 172.16.1.0/24 172.16.1.1 0 0 i

*> 172.16.2.0/24 172.16.2.1 0 0 i

*> 172.16.3.0/24 172.16.3.1 0 0 i

If the IGP table of R3 includes the 33.33.33.33 network segment that is distributed by the

OSPF, add this network segment to R2, and then check whether R2 notifies route 33.33.33.33 to

R1.


IPv4 Routing Table:




*> 3.3.3.3/32 100.1.1.2 gei-0/0/0/1 bgp 20 0

*> 33.33.33.33/32 100.1.1.2 gei-0/0/0/1 bgp 20 0

*> 100.1.1.0/30 100.1.1.1 gei-0/0/0/1 direct 0 0

*> 100.1.1.1/32 100.1.1.1 gei-0/0/0/1 address 0 0

*> 100.1.1.4/30 100.1.1.2 gei-0/0/0/1 bgp 20 0

*> 100.1.1.8/30 100.1.1.2 gei-0/0/0/1 bgp 20 0

*> 172.16.0.0/24 172.16.0.1 loopback2 direct 0 0


*> 172.16.1.0/24 172.16.1.1 loopback3 direct 0 0


*> 172.16.2.0/24 172.16.2.1 loopback4 direct 0 0


*> 172.16.3.0/24 172.16.3.1 loopback5 direct 0 0


4 Conclusion

It is necessary to know the influence and

purpose on the current network when the

synchronization function of the EBGP or IBGP

is enabled or disabled.

The understanding on the no

synchronization command in the BGP is

divided into two parts:

(1) In the EBGP neighbor, after the no

synchronization command is executed, the

BGP router notifies the BGP routes learnt

from the IBGP neighbor to its EBGP neighbor

even if these routes do not exist in its own IGP

routing table.

(2) In the IBGP neighbor, after the no

synchronization command is executed, the

BGP router adds the BGP routes to the local

routing forward table instead of waiting for the

IGP synchronization.

After you configure the no

synchronization command in the BGP, you do

not need to execute the redistribut

bgp-int/bgp-ext command in the IGP (such as

OSPF).

Sincere Service l


In most cases, the IBGP routes and the

IGP routes in the same AS are consistent.

Once a route of other AS is added, and the

EBGP neighbor is established, there are two

selections. One is to distribute the BGP route

to the IGP route protocol for the EBGP again,

for example, execute the redistribut

bgp-int/bgp-ext command in the OSP, and the

other is to execute the no synchronization

command for the EBGP or IBGP. In most

networks, the synchronization function is

disabled by default.

The above details how to disable the

synchronization function. In fact, it describes

how the BGP route establishes an IP routing

forward table.

The following two methods can be used

to establish an IP routing table.

(1) Add an EBGP route to an IP routing

table

1) In the BGP topology table, the EBGP

route is considered as the optimized route.

2) If the same route that is learnt from

other IGP or static routes exists, the

administrative distance of BGP external

routes is shorter than that of other routes. By

default, the administrative distance of BGP

external routes is 20, which is shorter than

that of other dynamic routes (except that the

administrative distance of the EIGRP

summary route is 5).

In this case, the operation that R2 obtains

inter-domain EBGP routes is not affected by

the synchronization function of R2. All routes

are added to the IP routing forward table.

(2)Add the IBGP route to an IP routing

table

1) This route must be the optimized BGP

route.

2) Compared with other routes, this route

is the optimized route based on the

administrative distance.

3) For the IBGP route, the IGP

synchronization function must be considered.

The IGP synchronization function in the router

is enabled by default. When the IGP


notifies route information to another ASs and

adds the routes to the IP routing forwarding

table till the IGP propagates the route

information to its AS successfully. When all

BGP routers in the AS are connected, the

synchronization function can be disabled.

On R3, the BGP routes are not added to

the IP routing forward table because R2 is

always waiting for the IGP synchronization. In

most BGP networks, all IBGP are connected

(or using RR), so the synchronization function

is disabled. However, the synchronization

function is enabled by default (the

synchronization function of CISCO is disabled

by default).

FAQ


FAQ

Question: How does M6000 allocate ports to users when M6000 acts as the BAR and the nat444 service is enabled?

Answer:

The M6000 allocates ports to users with

two modes, dynamic mode and static mode.

Dynamic mode: After a user dials a

number successfully, the M6000

allocates initial ports to the user.

cgn-pool test poolid 1

pool-type port-range 128

After the user dials a number

successfully, the M6000 allocates 1-128

ports to the user. When the user

downloads software through the BT or

performs other on-line services, initial

ports are insufficient. In this case, M6000

continues allocating ports to the user.

128 ports are allocated to the user once a

time, and the corresponding log is

generated.

Static mode: After a user dials a number

successfully, the M6000 allocates fixed

ports to the user. After all ports are used

up, the M6000 will not allocate ports.

Question: What is the difference between Address Translation and Address Proxy?

Answer:

Both the address translation technology

and the address agent technology provide a

private address to access the Internet. The

difference is the location in the TCP/IP

protocol stack. The address translation

technology works in the network layer, while

the address agent technology works in the

application layer.

The address translation technology is

transparent to all applications, but the address

agent technology must specify the IP address

of an agent server in the application program.

For example, when you access a Website

through the address translation technology,

you do not need to configure the browser. If

you access a Website through the address

Proxy technology, you need to configure the

IP address of the Proxy in the browser. If the

Proxy only supports the HTTP protocol, you

can access the Website only through the

address Proxy technology, and you cannot

access the Website through the FTP. The

above information shows that the address

translation technology is better than the

address Proxy technology because you do

not need to configure the browser.

Sincere Service l


However, the address translation

technology cannot provide the authentication

based on the user name and the password.

With the address Proxy technology, only the

user whose user name and password are

authenticated can access the Internet.

Question: What is the size of the local-buffer configured in the RADIUS charging? Can you configure the size? What should you do when the buffer is full?

Answer:

The size of the local-buffer is 3072

messages, and the size cannot be configured.

When the buffer is full, new messages can be

saved to the buffer only after the messages

stored in the buffer are sent out.

Question: In the dual-server hot-backup system, the VRRP is used to determine the active/standby server. When the heartbeat line is broken, both servers are active VRRP. Whether the user online is affected when two BRASs are in active status?

Answer:

If the heartbeat line of the VRRP is

broken, the heartbeat line will be in init status.

Servers are independent, so the user online is

not affected. After one server does not

receive VRRP messages, it will become the

active server after a period of time. In this

case, maybe two servers are in active status.

In this case, the server that gives a response

to the user packet first forwards user data.

The backup mode of the device is similar to

the cold standby.

Address: ZTE Plaza, No.55, Hi-tech Road South, Shenzhen, P.R.China Post code: 518057

Customer Support Hotline: +86-755-26771900 Tel:+86-755-26776049Fax: +86-755-26772236Customer Support Email: [email protected] Support Website: http://ensupport.zte.com.cnPublication Date: April 10, 2013

maintenance experience%2c issue276(data praducts)_523290

Documents

zte products

zte engineers

ftp service failure

zte plaza

zte employees

interconnecti failure

commissioningand service

service policies