Beruflich Dokumente
Kultur Dokumente
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: One Special Document
Maintenance Experience
Bimonthly for Data Products No.6 Issue 153, February / 2009
Have you examined your service polices 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 Editorial Committee ZTE Corporation February, 2009
Contents
February 2009
Issue 153
Maintenance Experience
www.zte.com.cn
BUPC3 board in time. When the ALM indicator of BNPCIX/BNPCH board is constantly on, this indicates that there is a fault on corresponding interface card. Reset the BNPCIX/BNPCH board. If the indicator does not recover to normal situation, it is necessary to change the corresponding interface card or BNPCIX/BNPCH board. When indicators of BNPCH/BNPCIX board flash at random, this indicates that the board is resetting automatically. Observe whether the indicators can recover to normal situation. If the indicators fail to recover to normal situation, it is necessary to change the corresponding interface card or BNPCIX/BNPCH board. Check whether a system halted file is generated.
1.3.3 Abnormal Situation ALM indicators of interface cards are constantly on. 1.3.4 Abnormal Situation Processing When the ALM indicator of an interface card is constantly on, this indicates that there is a fault on the interface card. If services are not affected, reset the interface card when services are not busy (reset the corresponding BNPCIX/BNPCH board). Check whether a system halted file is generated.
Data Products
February 2009
Issue 153
Four indicators of BNPCT board flash at random. 2.1.4 Abnormal Situation Processing When the ALM indicator of active BUPC board is constantly on, check whether the services are normal. If the services are abnormal, telnet to the device and view the display results with show run command and show ip route command. If services and display results are abnormal, this indicates that there is software fault on the active BUPC board. It is necessary to change over to the standby BUPC board by pressing EXCH button on the active BUPC board and reset the active BUPC board in time. When the ALM indicator of BNPCT board is constantly on, this indicates that there is fault on corresponding interface card. Reset the BNPCT board. If the indicator does not recover to normal situation, it is necessary to change the corresponding interface card or BNPCT board. When indicators of BNPCT board flash at random, this indicates that the board is resetting automatically. Observe whether the indicators can recover to normal situation. If the indicators fail to recover to normal situation, it is necessary to change the corresponding interface card or BNPCT board. Check whether a system halted file is generated.
indicator (red) is off. 2.2.3 Abnormal Situation ALM indicator of BIC card is constantly on. 2.2.4 Abnormal Situation Processing When ALM indicator of BIC card is constantly on, this indicates that the rack does not obtain any alarm information about related environment. This does not affect the normal running of the device.
Maintenance Experience
www.zte.com.cn
3.1.3 Abnormal Situation ZXUAS#show run Building configuration... Current configuration: ! version V4.6.01 ! enable secret 5 RcMLuUKvnFZX9kNAV6A/ UA== ! nvram mng-ip-address 168.1.9.8 255.255.0.0 ! nvram boot-username target ! nvram boot-password target ! nvram boot-server 168.1.88.2 ! nvram default-gateway 10.40.89.25 ! nvram imgfile-location local ! hostname ZXUAS ! username ZXUAS password ZXUAS ! user-authentication-type local ! snmp-server contact +86-21-68895000-189572 snmp-server location No.889 bibo Rd. pudong District, Shanghai, China snmp-server packetSize 1400 snmp-server engine-id 830900020300010289d64401 snmp-server view DefaultView system included snmp-server view AllView internet included ! logging on logging buffer 200 logging mode FULLCYCLE logging console NOTIFICATIONS logging level NOTIFICATIONS ! line console idle-timeout 120 Configuration information displayed on device is incomplete. Configuration information displayed is not consistent with the content that users configured. 3.1.4 Abnormal Situation Processing When configuration information displayed on device is incomplete, check whether the services are normal. If the services are normal, change the login mode. If serial port login mode is used, make sure that the login software is Hyper Terminal attached in WINDOW operating system. Change the PC and retry. If configuration information displayed on device is still incomplete, use TELNET login mode to view the configuration information. If the display result is still incomplete after the above operations, this indicates that there may be fault of software. Contact to ZTE customer support center for further processing. When configuration information displayed is not consistent with the commands configured by users manually, check whether the commands configured by users have taken effect or not. If the commands do not take effect, reconfigure them. If the commands have taken effect but are not displayed, look up in command manuals to check whether the configuration is default (default configuration is not displayed in result of show run command). If the commands have taken effect but the display result is not consistent with the content that users configured, this indicates that there may be a display problem about the version. Feed back this situation to ZTE customer support center.
Data Products
February 2009
Issue 153
the configuration of other parameters. For the detailed configuration, refer to command manuals. If the problem still exists, contact to ZTE customer support center for further processing.
255.255.255.252 up
AdminStatus is down, Protocol is down and PhyStatus is up. PhyStatus is down, Protocol is down and AdminStatus is up. AdminStatus and PhyStatus are up, and Protocol is down. 3.2.4 Abnormal Situation Processing When AdminStatus is down, Protocol is down and PhyStatus is up, this indicates that physical connection is normal. The corresponding interface may be shut down. Enter interface configuration mode and input no shut command. When PhyStatus is down, Protocol is down and AdminStatus is up, this indicates that there is a problem on physical connection. Check the physical connection. When AdminStatus and PhyStatus are up, and Protocol is down, check configuration information on the interface. Parameters may be configured incorrectly or the parameters are not configured. Meanwhile, pay attention to
Maintenance Experience
www.zte.com.cn
Oversize : 5
CRC-
port, and make sure that there is no loop, or find out the attack source by port traffic and MAC address on device of lower layer.
Bytes:
Unicasts : 3392041984 Multicasts: 0 Broadcasts: 436610025 64B : 452201789 65-127B : 3840983938 512-1023B : 128-255B : 436380539 2 5 6 - 5 11 B : 2 3 6 3 9 7 7 5 2 Oversize : 0 3.3.3 Abnormal Situation In abnormal situation, interface utilization reaches 80%~90%. If users view the port traffic with show interface command for several times, the result shows that the number of broadcast messages increases rapidly. 3.3.4 Abnormal Situation Processing If interface utilization reaches 80%~90% but the number of broadcast messages does not increase rapidly when users view the port traffic with show interface command for several times, this indicates that the network traffic is large and it is necessary to extend the capacity. There are two recommendations:
ZXUAS#show process CPU RPU 2 MPU 2 SFC 2 NPC 1 NPC 3 NPC 7 NPC 8 5s 0% 0% 2% 0% 0% 0% 0% 30s 0% 0% 2% 1% 0% 0% 0% 2m 30s max total memory buffer utility memory utility 23% 90% 8% 50% 53% 53% 60% 512M 512M 64M 101M 101M 101M 101M 46% 30% 59% 84% 84% 84% 84% utility 0% 0% 0% 0% 0% 0% 0% 0% 0% 2% 6% 0% 7% 1% utility utility utility
In normal situation, CPU utilization sampled at 5s, 30s and 2m must not be more than 50%. 3.4.3 Abnormal Situation CPU utilization is high, reaching 80%~90%. 3.4.4 Abnormal Situation Processing If CPU utilization keeps 80%~90%, check whether services are normal. Generally, CPU utilization of 80%~90% or higher will affect normal services at a certain extent. Check the log information of the device. For ZXUAS 10600 and ZXUAS 10800E, find out the BNPC board of which the CPU utilization keeps high and reset the board. Wait a moment to observe whether the CPU utilization recovers to a
Extend the capacity of current network. Add some devices or egresses to implement load balancing.
If there is no condition to extend the capacity, implement speed limit to users on access layer to ease network congestion. If the number of broadcast messages increases
rapidly when users view the port traffic with show interface command for several times, check whether the services are normal. If the services are not normal, view the alarm information. If there are a lot of alarms for drifting of different IP addresses, there may be broadcast storm in lower network or virus attacks. Check the network connecting to this
Data Products
February 2009
Issue 153
normal value. If CPU utilization does not recover, there may be virus attacks in the network. View log information and find out the attack source, and contact to ZTE customer support center for help as soon as possible.
the peer device. If there is no problem about configuration, contact to ZTE customer support center for further processing.
description: Port Down port fei_1/8 This indicates the course of a physical port
from through to off. Pay attention to this alarm information if it is not caused by man.
description: udp rcv packet has a invalid checksum This indicates that the checksum of received
UDP message is invalid. Generally, such alarm information appears due to the unpredictability of user actions. It can be ignored temporarily.
Maintenance Experience
www.zte.com.cn
description: tcp rcv bad checksum This indicates that the checksum of received
the authentication with any non-mull user name and password. Abnormal Situation Users can not pass authentication with correct user name and password. No. 691 error information appears. No. 678 error information appears. Abnormal Situation Processing Check the connectivity of network and terminal devices. Check whether the configuration of UAS device for user access and user domain management is correct. Check whether the user account is legal. Check whether the communication with AAA server is normal. Check whether the IP address resource of the device is enough. If the problem still can not be solved, please contact to ZTE customer support center for further processing.
TCP message is invalid. Generally, such alarm information appears due to the unpredictability of user actions. It can be ignored temporarily.
description: Time out while reassemble IP datagram This indicates that IP messages time out
during recombination. Pay attention to this alarm information when there is a lot of this alarm information. In this situation, the device may be attacked by fragmentation packets. It is necessary to check the CPU utilization and packet processing statistical information of NP in unit time. If the CPU utilization keeps a high value, or the number of fragmentation packets received by NP reaches the set limit, the device is being attacked. This may block the normal services, decreasing the network speed of users and making users off-line. Please contact to ZTE customer support center for help. There may be other alarm information. If users can not understand the meaning and perniciousness of the alarm information, please contact to ZTE customer support center.
Data Products
February 2009
Issue 153
the sub-interface connecting to users is correct. Check the down-link device to see whether the user is in the right VLAN. Check whether the static ARP binding is configured between the UAS device and client. Check whether the IP address, network gateway and DNS on user terminal are configured correctly. If the problem still can not be solved, please contact to ZTE customer support center for further processing.
10
Maintenance Experience
www.zte.com.cn
3.11.4 Abnormal Situation Processing Check whether the routes from the UAS device to Radius server are reachable and unblocked. Check whether the butted parameters to Radius server on UAS device are configured correctly. Check whether the Radius server can identify UAS devices correctly. If the problem still can not be solved, please contact to ZTE customer support center for further processing.
Data Products
11
February 2009
Issue 153
are the same, but the internal line orders are different. Check the serial port configuration on user terminal. Make sure that the serial port configuration on user terminal meets the requirements in user manual. If there is messy code displayed, it may be caused by unmatched baud rate. On terminal of ZXUAS 10600 and ZXUAS 10800E, baud rate must be 9600, data bits must be 8, parity must be none and stop bits must be 1. If the above configuration is correct, check the login software on the terminal. If third-party software is used, try to use another kind of software to log in. It is recommended to use Hyper Terminal attached in WINDOW operating system. If users log in to UAS device through USB interface and conversion line, the compatibility of the conversion line can cause problem. It is recommended to change a terminal that has serial port and connect to UAS device through the serial port directly. If the problem still exists after the above operations, the CONSOLE port on UAS device may be broken. Please contact to ZTE customer support center for further processing.
Reason1: Telnet address is wrong. Check the telnet address. Make sure that the
address is correct.
Reason2: The number of telnet connections reaches the upper limit. ZXUAS device supports up to four telnet
connections at the same time. Check whether there have been 4 connections on the device with who command through CONSOLE port. If there have been four VTYs, delete idle users with clear tcp vty <number> command and then retry log in to the device through telnet.
Reason3: User name and password is not configured. When users connect to UAS device, there will
be information prompting to input user name and password. If users fail to log in no matter what user name and password they input, log in to the device through CONSOLE port and configure user name and password with username <username> password <password>. After the configuration, retry log in to the device through telnet.
Reason4: Access control of telnet is configured and the device address is not allowed to be log in through telnet. Check the configuration of the UAS device.
Make sure that the UAS device address can be log in through telnet.
Reason4: UAS device is attacked by TCP connections. Check TCP connection information with show
tcp brief command. If there are a lot of connections to the UAS device from the same address, this indicates that the UAS device is being attacked by TCP connections. Configure ACL to filter the address and establish TCP connections again. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
12
Maintenance Experience
www.zte.com.cn
packet, or the numbers of sent packets and received packets do not increase and the number of error packets increases quickly, check the port traffic to find out the problem. If interface state and port traffic are normal, check debugging information to observe whether there are ARP broadcast packets received and whether response packets are sent normally. If there is no ARP broadcast packet, there may be problems on peer devices. Check the peer devices to find out these problems. If ARP broadcast packets are received and response packets are not sent, there may be software fault on UAS device. Please contact to ZTE customer support center for further processing. When the UAS device is on-line and there are a lot of users connecting to the device, debugging will cost wastage of system resources. It is recommended to capture packets and then implement troubleshooting. When peer devices fail to learn the ARP address of this UAS device, perform the following operations. Check the interface configuration and interface information on UAS device and peer devices to observe whether the problem is caused by interface configuration or physical link. Check whether ARP request packets are sent on UAS device and whether ARP response packets are sent on peer devices by capturing packets or debugging information. If ARP request packets are not sent on UAS device, please contact to ZTE customer support center for further processing. If ARP response packets are not sent on peer devices, change a peer
5.1.3 Abnormal Situation UAS device fails to learn ARP addresses of peer device. Peer devices fail to learn the ARP address of this UAS device. 5.1.4 Abnormal Situation Processing When UAS device fails to learn ARP addresses of peer device, perform the following operations. Check whether the configuration on interface is correct. Check whether the interface is up with show ip interface brief command. If the interface is down, check the interface information and find out the problem. If the interface state is normal, check whether packets are sent and received normally with show interface command. If there is no broadcast
Data Products
13
February 2009
Issue 153
device and test again. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
problem. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
14
Maintenance Experience
www.zte.com.cn
User can obtain IP address but fail to obtain gateway information. 5.5.4 Abnormal Situation Processing When user fails to obtain IP address, perform the following operations. Check whether configuration of DHCP server is correct. Check whether configuration of DHCP relay is correct. To check DHCP relay process information, use show ip dhcp config command. Check whether the routes are reachable from DHCP server to the subnet that DHCP agent locates. When user can obtain IP address but fail to obtain gateway information, check whether the gateway address configured on DHCP server is the default gateway address for user. If it is, check whether the address is in the same network segment with the address DHCP agent. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
Data Products
15
February 2009
Issue 153
above operations, please contact to ZTE customer support center for further processing.
16
Maintenance Experience
www.zte.com.cn
6.4.4 Abnormal Situation Processing Check whether portal forcing configuration on UAS device is correct. Check whether the butt parameters and protocol type on portal server and UAS device are consistent. Check whether the routes to portal server from users are reachable. Check whether Internet property of user PC is set correctly. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
Data Products
17
February 2009
Issue 153
ZXUAS#show ip route IPv4 Routing Table: Dest Mask Gw Interface Owner pri metric static 1 0 192.16.1.0 255.255.0.0 196.20.1.1 fei_1/5
7.2.4 Abnormal Situation Processing Check whether configuration is successful. When multiple static routes with the same subnet address and different next hop addresses are configured, if the values of tag are the same, the items configured later are not successful. Modify the values of tag and configure these items again. Check whether the metric values are the same. If the metric values are not the same, the route items have relationship of active and standby. Load balancing can not be implemented in this situation. Check whether the next hop addresses are reachable. If they are not reachable, these static route items are not valid and then load balancing can not be implemented. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
7.1.3 Abnormal Situation Static routes are invalid, and they can not be viewed with show ip route command. 7.1.4 Abnormal Situation Processing Check whether the next hop address is the address of peer device that connects directly. For static routes, the next hop address must be the address of peer device that connects directly. Otherwise, the static can not be valid. Check whether the next hop address is reachable with ping command or show arp command. If the address is not reachable, the static route can not be valid, and then find out the problem on peer device or local device. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
18
Maintenance Experience
www.zte.com.cn
ZTE. If users fail to check, configure ip ospf mtuignore command on butt interface of ZTE device. Check whether the same IP address is configured on UAS device and peer device and whether direct-connected routes are redistributed to both devices. In this situation, even the address is not enabled, OSPF neighbor state can not be FULL. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
check debugging information with debug isis command. If problem is not found according to debugging information, save the debugging information and contact to ZTE customer support center for further processing. Note: Debugging costs system resources. It is recommended to use debug isis command when network is idle. Disable debugging function with no debug all command as soon as possible after the information is collected.
fei_1/2 0000.0a0a.0303 UP/UP L1L2 8/8 802.2 00:e0:63:0b:44:c0 64/64 fei_1/3 0000.0a0a.0505 UP/UP L1L2 7/7 802.2 00:e0:60:0b:06:c0 64/64 7.4.3 Abnormal Situation Neighbors can not be viewed with show isis adjacency [level-1 | level-2] [vrf <vrf-name>] command and adjacency relationship is not established. 7.4.4 Abnormal Situation Processing Check whether IS-IS configuration is correct on devices at both ends, including area-ID, IS-IS level and so on. Check interface configuration and make sure that ip router isis command is configured in interface configuration mode. Ping to the address of peer interface to check link connectivity. If no problem is found by the above operations,
Data Products
19
February 2009
Issue 153
is required to configure neighbor <ipaddress> ebgp-multihop command in BGP route configuration mode. This makes the device at a distance of multiple hops as EBGP neighbor. Meanwhile, make sure that users can ping to the address of EBGP neighbor successfully from UAS device. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
situation, routes can be aggregated successfully. A configuration example is shown below. ZXUAS(config-router) #aggregate-address 10.0.0.0 255.0.0.0 count 2 ZXUAS(config-router) #aggregate-address 10.0.0.0 255.0.0.0 subnet 10.1.0.0 255.255.0.0 ZXUAS(config-router) #aggregate-address 10.0.0.0 255.0.0.0 subnet 10.2.0.0 255.255.0.0 ZXUAS(config-router) #aggregate-address 10.0.0.0 255.0.0.0 subnet 10.3.0.0 255.255.0.0
According to the above configuration, there are three subnets of 10.0.0.0/8. They are 10.1.0.0/16, 10.2.0.0/16 and 10.3.0.0/16. When there are two of the subnets appearing in routing table, aggregation route 10.0.0.0/8 can be generated successfully. Otherwise, aggregation route can not be generated. When the value of parameter <count> is 0, to aggregate a route, there must be routes that are more detailed than the aggregation route in the routing table. Otherwise, aggregation route can not be generated. If keyword strict is configured, only the routes with the same properties of MED and NEXT_HOP can be aggregated. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
20
Maintenance Experience
www.zte.com.cn
7.7.3 Abnormal Situation UAS device fails to learn BGP routes from neighbors. 7.7.4 Abnormal Situation Processing Check whether BGP neighbor relationship state is normal. If the state is normal (Established), check BGP configuration on UAS device and peer device. Pay attention to routing policy. Make sure that the routes to be advertised are not filtered by the routing policy. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
up-link device still sends packets with designated destination address to the down-link device through static route. However, the static route item does not exist any more as the interface is down. This causes a route loop. In this situation, check IP address of corresponding interface on down-link device. If the IP address can not be used, the static route must be deleted on up-link device. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
Data Products
21
February 2009
Issue 153
group-address <ip-address> command. Check interaction information of PIM-SM protocol with debug ip pimsm command. Check whether user circuit is enabled with ip pim sm command, and check whether multicast properties are associated with user template. Check whether IGMP interaction is normal between user and the device by capturing packets at user side. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
PE1#show ip rout vrf vpn1 IPv4 Routing Table: Dest Mask Gw Interface Owner fei_1/1 static fei_1/1 direct pri metric 1 0 0 0 0 20 0 3.3.3.3 255.255.255.255 10.1.1.2 10.1.1.0 255.255.255.252 10.1.1.1 10.1.1.1 255.255.255.255 10.1.1.1
fei_1/1 address 0
11.1.1.0 255.255.255.252 172.10.1.2 fei_1/2 bgp 11.1.1.1 255.255.255.255 172.10.1.2 fei_1/2 bgp
20 0 20 0
VPN routes can be imported in VRF routing table. Check whether VPN labels are distributed normally with show ip protocol routing vrf <vrf> command. An example is shown below. PE1#show ip protocol routing vrf vpn1 Routes of vpn: status codes: *valid, >best, s-stale
Intag 20 18 17 16 19 21
*> 10.1.1.0/30 10.1.1.1 *> 10.1.1.1/32 10.1.1.1 *> 11.1.1.0/30 172.10.1.2 *> 11.1.1.1/32 172.10.1.2
In the result of show ip bgp neighbor command, neighbor relationship state is Established. 8.2.3 Abnormal Situation VPN is not through and VRF routing table is wrong. 8.2.4 Abnormal Situation Processing Check configuration of MPLS VPN on both PE devices. Make sure that MPBGP is configured, VRF routes are advertised to the peer PE, and VRF routes are not filtered by routing policy. If VPN routes exist but they are not imported to VRF routing table correctly, check the policy of RT. If RT policies at both ends do not match, VPN routes can not be imported to VRF routing table correctly.
PE1# show ip rout vpn Routes of vpn: Dest NextHop Type ASN Addr Peer 0 0 0 100 1 100 1 100 1 100 1 100 1 100 1 0.0.0.0 0.0.0.0 0.0.0.0 172.10.1.2 172.10.1.2 172.10.1.2 3.3.3.3/32 10.1.1.2 10.1.1.0/30 10.1.1.1 10.1.1.1/32 10.1.1.1
VRF routing table can be viewed with show ip route vrf <vrf> command. An example is shown below.
22
Maintenance Experience
www.zte.com.cn
If BGP neighbor relationship state is not correct, refer to corresponding connects of processing for BGP neighbor. If public network labels are not distributed normally, check whether the following LDP configuration is configured.
then apply the configuration to interface again. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
Enable MPLS with mpls ip command in global configuration mode. By default, the signaling protocol is LDP. Only when MPLS is enabled globally can mpls ip command be valid on an interface.
Configure mpls ldp router-id loopback1 force. This forces loopback1 to be the router-id in LDP.
Configure mpls ldp access-fec host-route-only. This means that labels are only distributed to host address. If the problem still exists after the above
operations, please contact to ZTE customer support center for further processing.
Data Products
23
February 2009
Issue 153
8.5.3 Abnormal Situation There is no configuration of a community or there is community without AllView. 8.5.4 Abnormal Situation Processing Configure a community with AllView, and make the community read information. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
8.6.2 Normal Situation There is configuration of a community with rw privilege, containing AllView, for example, snmpserver community <community-name> view AllView rw. 8.6.3 Abnormal Situation There is no configuration of a community with rw privilege or there is community without AllView. 8.6.4 Abnormal Situation Processing Configure an rw community with AllView, and make the community write information on NMS. If the problem still exists after the above operations, please contact to ZTE customer support center for further processing.
24
Maintenance Experience
www.zte.com.cn
1 Network Topology
SVLAN is configured on T64G. T64G connects to UAS 10600 through dual up-links. The two interfaces on T64G are gei_4/1 and gei_5/1. T16C-1 and T16C-2 connect to T64G. The network topology is shown in Figure . that services were not normal. When users pinged to the gateway address of UAS 10600 on PC, most of the packets were lost and only few packets reached gateway. The result was the same when engineers pinged to the gateway address of UAS 10600 on PC in machine room of service operator. Network management of T16C-1 and T16C-2 that transmit transparently to UAS 10600 through T64G were normal. That is, engineers could ping to gateway address on UAS 10600 successfully and on packet was lost.
3 Malfunction Analysis
I n t h e n e t w o r k t o p o l o g y, T 6 4 G connected UAS 10600 through dual uplinks. As few packets could reach gateway and network management of T16C-1 and T16C-2 that transmit transparently to
Figure 1. Network Topology
UAS 10600 through T64G were normal (that is, engineers could ping to gateway address on UAS 10600 successfully and on packet was lost), engineers considered that the links from T16C-1 and T16C-2 to UAS 10600 were through, and the network VLAN was normal. This indicated that the problem may be in the configuration of QinQ. Engineers checked whether there was the same VLAN configuration on interfaces of UAS 10600 (that is, gei_2/1 and gei_1/1) that connected to T64G. It was found that there was no
It is required to modify the data of special line user of Internet bar that connects to T16C-1 and T16C-2. Users are shifted to gei_5/1 from gei_4/1 on T64G. Therefore, data on T16C-1, T16C-2, gei_4/1 and gei_5/1 of T64G will be modified. Meanwhile, data on gei_2/1 of UAS 10600 will be shifted to gei_1/1.
2 Malfunction Situation
Configurations on devices were changed correctly. However, users in Internet bar said
Data Products
25
February 2009
Issue 153
such configuration. Meanwhile, both gei_2/1 and gei_1/1 were configured with outer layer label vlan5 and the inner layer labels were different. This indicated that the problem was not on UAS 10600. As both gei_2/1 and gei_1/1 were configured with outer layer label vlan5, the interfaces of T64G (that is, gei_4/1 and gei_5/1) that connected to UAS 10600 must also be configured with outer layer label vlan5. Engineers continued to check interface configurations of T64G. TAGs of gei_4/1 and gei_5/1 were configured correctly. However, outer layer labels were configured to native vlan on the interfaces of T64G (that is, gei_4/2 and gei_4/5) that connected to T16C-1 and T16C-2. Related interface configuration on T64G is shown below. interface gei_4/2 description to-lichuanT16C-1 switchport hybrid native vlan 5 switchport hybrid vlan 5 untag switchport qinq customer interface gei_4/5 description to-lichuanT16C-2 switchport hybrid native vlan 5 switchport hybrid vlan 5 untag switchport qinq customer interface fei_2/1 description to_lichuan2403_1 switchport hybrid native vlan 1 switchport hybrid vlan 5 untag switchport hybrid vlan 4094 untag switchport qinq customer /*vlan 5 configured on this interface is for the old service.*/ Engineers checked configuration of vlan qinq session-node. They found that there was no configuration for data form gei_4/2 and gei_4/5 to gei_5/1 on T64G. This caused the problem. As outer layer label vlan5 was configured on gei_4/1 and gei_5/1 of T64G, data packets form T16C-1 and T16C-2 were sent to these two interfaces. In MAC table of T64G, gei_4/1 had learnt the MAC addresses of T16C-1 and T16C-2. Therefore, data packets from form T16C-1 and T16C-2 were sent to gei_4/1 directly. There were only few broadcast packets received on gei_5/1 of T64G. Then T64G sent these packets to UAS 10600. This was why that few packets could reach gateway when users in Internet bar pinged to gateway address of UAS 10600. In normal situation, if switchport hybrid native vlan 5 was configured
on gei_4/2 and gei_4/5, it was not necessary to configure vlan qinq session-no. However, outer layer label vlan5 was configured on the interfaces of dual up-links on T64G, vlan qinq session-no must be configured on T64G. This made that the data packets from gei_4/2 and gei_4/5 were sent to gei_5/1.
4 Solution
Engineers modified the configuration of gei_4/5 and gei_4/2 on T64G, as shown below. interface gei_4/2 description to-lichuanT16C-1 switchport hybrid native vlan 107 switchport hybrid vlan 5 untag switchport hybrid vlan 4094 untag switchport qinq customer interface gei_4/5 description to-lichuanT16C-2 switchport hybrid native vlan 5 switchport hybrid vlan 5 untag switchport hybrid vlan 4094 untag switchport qinq customer Besides, two vlan qinq session-no commands were added to the configuration, as shown below. vlan qinq session-no 43 customer-port gei_4/2 uplink-port gei_5/1 in-vlan 324-448 ovlan 5 vlan qinq session-no 44 customer-port gei_4/5 uplink-port gei_5/1 in-vlan 324-448 ovlan 5 After modification, engineers tested the network services. The services were normal. The problem was solved.
5 Experience Summary
When a switch connects to a UAS device through dual up-links, do not configure superimposed VLAN no matter if there is single layer label or double layers of labels. For users of dial-up service, No.678 error information will appear when users dial up. For users with fixed IP addresses, they can not get on-line normally.
26
Maintenance Experience
www.zte.com.cn
1 Network Topology
As shown in Figure 1, multiple dial-up user domains are configured on BAS device. In different domains, users are required to obtain IP addresses in designated IP address pools. Therefore, in subscriber-template configuration of domain, user addresses are bound to IP address pools of designated VBUIs.
designated IP address pools. Therefore, in subscriber-template configuration of domain, user addresses are bound to IP address pools of designated VBUIs. An example is shown below. Domain 1 is a DIAL domain. Users in this domain must obtain IP addresses from address pool of VBUI1. Domain 2 is a CNC domain. Users in this domain must obtain IP addresses from address pool of VBUI2.
Domain 3 is an IPTV domain. Users in this domain must obtain IP addresses from address pool of VBUI3. Configuration of VBUI1 is shown below.
interface vbui1 ip address 115.56.144.1 255.255.252.0 ip address 219.154.98.1 255.255.254.0 secondary ip address 222.138.100.1 255.255.254.0 secondary ip address 222.138.70.1 255.255.254.0 secondary ip address 219.154.108.1 255.255.254.0 secondary description for_PPPOE_dial ip pool 1 pppoe_pool1 115.56.144.2 115.56.147.254 ip pool 2 pppoe_pool2 219.154.98.2 219.154.99.254 ip pool 3 pppoe_pool3 219.154.108.2 219.154.109.254 ip pool 4 pppoe_pool4 222.138.70.2 222.138.71.254 ip pool 5 pppoe_pool5 222.138.100.2 222.138.101.254
Figure 1. Network Topology
Configuration of VBUI2 is shown below. interface vbui2 ip address 10.254.64.1 255.255.255.0 description for_help ip pool 21 help_pool1 10.254.64.2 10.254.64.254
2 Malfunction Situation
There are multiple dial-up user domains configured on BAS device. In different domains, users are required to obtain IP addresses in
Data Products
27
February 2009
Issue 153
Configuration of VBUI3 is shown below. interface vbui3 ip address 10.169.72.1 255.255.254.0 description for_IPTV ip pool 31 iptv_pool1 10.169.72.2 10.169.73.254 Configuration of domain 1 is shown below. domain 1 alias dial subscriber-template ip address interface vbui1 Configuration of domain 2 is shown below. domain 2 alias cnc subscriber-template ip address interface vbui2 Configuration of domain 3 is shown below. domain 3 alias iptv subscriber-template ip address interface vbui3 The above configurations meet the requirement that users in different domains will obtain IP addresses in designated IP address pools. However, when IP address pools of VBUI1 are not enough and it is necessary to add new address pools, a problem will appear. For current version, a VBUI interface supports up to 5 IP addresses. One of the addresses is the primary address, and the others are secondary addresses. The five addresses are the gateway addresses of corresponding address pools. In fact, the offices are not able to provide a large segment of continuous addresses. Usually they
provide small segment of discontinuous addresses of C type. When engineers can not define IP addresses of a VBUI, they can decrease the length of subnet mask to provide more addresses in the address pools of this VBUI. The worst situation is that the office provides 5 discontinuous addresses of C type. Therefore, there are up to 5 address pools of C type in the VBUI. This obviously can not meet the fact demand. To add new address pools, engineers have to added new VBUI interface and then add the new address pools. However, subscribertemplate of domain 1 is bound to VBUI1, users in domain 1 still can not obtain the new addresses in the new VBUI interface.
3 Solution
In domain 1, there are a lot of dial-up service users. If the domain is only bound to a fixed VBUI interface, the IP addresses in the address pools of this VBUI are not enough for the users. Therefore, modify the configuration of domain 1, as shown below. domain 1 alias dial subscriber-template ip address interface vrf /*users can obtain IP address from all available VBUI interfaces*/ However, after configuration of domain 1 is modified, another problem will appear. That is, users in domain 1 can obtain IP addresses from all available VBUI interfaces, but address pools of VBUI2 and VBUI3 are not designated. As a result, users in domain 1 can also obtain IP addresses in address pools of VBUI2 and VBUI3. To solve the problem, modify the configuration of VBUI2 and VBUI3. Configuration of VBUI2 is shown below.
28
Maintenance Experience
www.zte.com.cn
interface vbui2 ip address 10.254.64.1 255.255.255.0 description for_help ip pool 21 help_pool1 10.254.64.2 10.254.64.254 domain 2 Configuration of VBUI3 is shown below. interface vbui3 ip address 10.169.72.1 255.255.254.0 description for_IPTV ip pool 31 iptv_pool1 10.169.72.2 10.169.73.254 domain 3 Meanwhile, add a new VBUI interface, VBUI4. Configuration of VBUI4 is shown below. interface vbui4 ip address 61.53.106.1 255.255.255.0 ip address 61.53.107.1 255.255.255.128 secondary description for_PPPOE_dial-1 ip pool 6 pppoe_pool6 61.53.106.2 61.53.106.254 domain 1 ip pool 7 pppoe_pool7 61.53.107.2 61.53.107.126 domain 1
addresses by define multiple IP address pools. When users configure address pools of a VBUI interface, it is recommended to associate these pools to corresponding domains no matter whether it is necessary. When there are multiple domains for dialup service users and users in a domain want to obtain addresses form different VBUI interfaces, it is impossible to associate the users in this domain with multiple VBUI interfaces at the same time. It is only possible to set the address obtainment of subscriber-template in the domain to ip address interface vrf. If an address pool of a VBUI interface is not associated with any detailed domain, the address pool can be distributed to all users. That is, users in a domain of which the address obtainment of subscribertemplate is set to ip address interface vrf can obtain IP addresses from any VBUI interface with such configuration. To modify the configuration of address pool in a VBUI interface, it is required to delete the old address pools. This will make all users who have obtained IP addresses off-line. Therefore, it is recommended to associate these pools to corresponding domains at the very beginning. Generally, common dial-up service users use a lot of address pools. Users of other services use a few address pools. Therefore, it is recommended to set the address obtainment of subscriber-template in a common dial-up service user domain to ip address interface vrf, and set the address obtainment of subscriber-template in other dial-up service user domain to ip address interface interface vbuiX.
4 Experience Summary
For ZXUAS 10600 and ZXUAS 10800E of V2.8.01.B.26 and V2.8.01.B.26.P01, there are up to 5 IP addresses in a VBUI interface. Use continuous network segment and get more addresses by decreasing the length of subnet mask. This decreases the number of advertised route items, and enlarges the capacity of address pool in VBUI. In an IP address pool of VBUI, there are up to 4 IP addresses of C type. If in the segment there are more that 4 IP addresses of C type, hold the
Data Products
29
February 2009
Issue 153
1 Network Topology
It is required to configure link aggregation in VLAN 100 between 2500S and 2826S, as shown in Figure 1.
2 Configuration Process
Configuration of 2500S is shown below. UAS#set vlan 100 create UAS#show trunking TrunkingAgList: --------------1 UAS#show vlan 100 VlanVersionNumber:1 ---------------------------VlanId : 100 VlanStaticName : StaticEgressPorts : (slot-1) 1 (slot-2) 1 2 ForbiddenEgressPorts: UntaggedPorts The following points are to be considered. 1. Add the ports to VLAN 100, as shown below. UAS#set vlan 100 slot 2 port 1 op 1 UAS#set vlan 100 slot 2 port 2 op 1 UAS#no set vlan 1000 slot 2 port 1 op 1 /*delete vlan 1000 on slot 2 port 1/ MaxVlanId:4094 NumVlans:5 MaxSupportedVlans:4094
30
Maintenance Experience
www.zte.com.cn
The ports can be added to the VLAN in batch, as shown below. UAS#set vlan 101-201 slot 2 port 1 op 1 UAS#set trunking slot 2 port 1 agport 1 UAS#set trunking slot 2 port 2 agport 1 2. When a new VLAN is to be added after aggregation, the ports can not be added to VLANs respectively, and VLANs can not be added in batch. Use the following command, as shown in the table given below. UAS#set vlan 300 slot 2 port 1-2 op 1 3. Delete a port from the aggregation group, as shown below. UAS#set trunking slot 2 port 1 agport 0 /*the aggregation group number is 0*/ 4. If UAS2500S is reset, the configuration of aggregation will be lost. No.678 error information will appear when users dial up. Therefore, the following commands must be configured after reset. UAS#set trunking slot 2 port 1 agport 1 UAS#set trunking slot 2 port 2 agport 1 Configuration of 2826S is shown below. zte(cfg)#show run Software version: 1.1 Switch's Mac Address: 00.d0.d0.fc.76.f1 ! syslocation No.68_Zijinghua_Road,Yuhuatai_Di strict,Nanjing,CHINA create user admin loginpass B612AD6F2259089A79740AD7CB5A 38BF line-vty timeout 10 ! ! set port 2 pvid 100 ! set vlan 1 add port 1-24 untag
set vlan 1 add trunk 1-8 untag set vlan 100 enable set vlan 100 add port 2 untag set vlan 100 add port 1,12 tag set vlan 100 add trunk 1 tag ! ! ! set lacp enable set lacp aggregator 1 add port 1,12 set lacp aggregator 1 mode static ! ! create community public public create view zteView include 1.3.6.1 set community public view zteView ! LACP must be set to static on 2826S. Otherwise, information that remote computer does not respond. The configuration is shown below. zte(cfg)#set lacp aggregator 1 mode static zte(cfg)#show lacp Lacp is enabled. Lacp priority is 32768 PortNum LacpActive ----------- -------1 True 12 True After the configuration, users can pass authentication and obtain IP addresses in address pools. After users get online normally, if one of the links in the aggregation group is down, a packet will be lost when engineers implement ping test on PC. When the link recovers, no packet is lost. 1 Static Long 1 Static Long ----------- ----------- ----------- GroupNum GroupMode LacpTime
Data Products
31
February 2009
Issue 153
1 Network Topology
ZXUAS 10600 is in aggregation layer of MAN. It connects HW DSLAM on down-link, and two HW NE80 devices are connected on up-links. IS-IS is enabled. The network topology is shown in Figure 1.
2 Malfunction Situation
IS-IS configuration of ZXUAS 10600 is shown below. router isis area 49.0898 system-id 2180.7714.8032 is-type level-2-only interface loopback1 ip router isis isis circuit-type level-2-only ip address 218.77.148.32 255.255.255.255 interface gei_1/1 ipaddress 218.77.150.138 255.255.255.252 ip router isis isis circuit-type level-2-only Users could view IS-IS neighbors with show isis adjacency command, but they failed to view routes learnt by IS-IS-l2 with show ip route command. This indicates that IS-IS did not run effectively between ZXUAS 10600 and HW NE80 devices.
32
Maintenance Experience
www.zte.com.cn
3 Malfunction Analysis
Engineers could not view the configurations on HW NE80 devices. They only viewed isis circuittype level-2-only type with show isis adjacency command. Engineers modified the value of parameter isis ignore-mtu. This modification was necessary. That is because the MTU on HW devices is more than 1500, and MTU on ZTE devices is 1500. This modification ensures that the data on device at both ends could match and no packets would be lost. However, after the modification, the problem still existed. Engineers also modified the value of parameter priorit, changed the type isis circuit-type level-2only to isis circuit-type level-1-2, and redistributed direct-connected routes. But the problem still existed.
isis 1 is-level level-2 cost-style wide network-entity 49.0898.2180.7714.80 02.00 filter-policy 2003 import default-route-advertise preference 115 interface GisgabitEthernet9/0/4 ip address 218.77.150.137 255.255.255.252 isis enable 1 isis circuit-level level-2 isis cost 150 mpls mpls ldp traffic-policy anti_virus inbound The above information showed that the type of cost-style on HW NE80 was wide. Therefore, engineers modified the type of metric-style on ZXUAS 10600 to wide and then IS-IS ran normally between ZXUAS 10600 and HW NE80 devices.
4 Solution
With the help of office staff, engineers obtained related configuration on HW NE80 devices, as shown below.
5 Experience Summary
By default, the value of parameter metric-style on ZXUAS 10600 is narrow, and that on HW NE 80 is wide. For ISIS configuration, the values of parameters on devices at both ends must be consistent.
Data Products
33
February 2009
Issue 153
34
Maintenance Experience
www.zte.com.cn
I n t h e p a c k e t h e a d e r, M P L S a d d r e s s information is contained for forwarding. The address is the label information shown in Figure . Users can know how to process MPLS packets according to Label Forwarding Information Base (LFIB). A message can be encapsulated with MPLS header for multiple times. In theory, the number of encapsulation layers is only limited by the maximum length of packet that a device can support. According to information shown in Figure , the message is encapsulated with two MPLS headers. The headers are between IP data message of VPN user and Ethernet message header. When the packet leaves the entrance PE device, it reaches a core device (P) of MPLS network. P device only implements operations on the packet according to outer layer encapsulation information, and it does not care other information. This shows transparency of MPLS to information. After MPLS encapsulation, the packet goes through core P devices and then reaches egress PE device. In fact, this is the transparent transmission course of a message with label in LSP. The contents in the message are not changed and the contents are not visible to devices outside the LSP tunnel. The user devices in MPLS network are called CE devices. CE connects with PE directly. There are multiple label distribution protocols, such as LDP, RSVP and BGP. The label format on each Label Switching Router (LSR) is the same. No mater what label distribution policy is used in the label distribution protocol, each LSR generates a unique LFIB to provide basis for MPLS packet forwarding. Establishment of LSP tunnel is related to routing table information. When routes are changed, LSP is also changed. When there are multiple routes to the same destination, load balancing may also be implemented through LSP. LSP is a unidirectional tunnel. That is, the
physical route of the LSP from PE-A to PE-B may be absolutely different with that of the LSP from PE-B to PE-A. The two LSP tunnels are used for data transmission in two directions. To meet the requirement of MPLS application in VPN, common BGP protocol is extended (refer to RFC2283). It is called Multi-protocol Extensions for BGP-4 (MPBGP). MP-BGP succeeds the attributes of common BGP, and some new concepts are also introduced to MP-BGP, such as Route-Distinguisher (RD) and Router Target (RT). RD is introduced to solve the problem of VNP address superposition. MPLS VPN extends the IPv4 address with RD and generates VPNv4 address family. If the same RD is distributed to different MPLS VPNs, what will happen? In fact, if the IP addresses of these VPNs do not overlap, it does not matter. However, if the IP addresses of these VPNs overlap, serious problem will occur. Generally, MPBGP does not enable load balancing on multiple links. If RDs and IPv4 addresses of two VPN are the same, VPNv4 considers that they are the same address and the better route will be used. This will cause serious problems in network where MP-BGP Route Reflector (RR) router is used. RT is a special attribute of BGP Community. It is used to introduce VPN instance. The application of RT makes MPLS VPN network more flexible. Users can set RT according to their requirements. It is RT Rewrite technology. Part information of a MP-BGP update message which is captured in a network is shown in Figure 2. Besides RT and RD information, there
Data Products
35
February 2009
Issue 153
is BGP information in Figure 2. Next-Hop attribute is described below. In application of common BGP, Next-Hop attribute is the basis to generate a routing table. In MPLS VPN, it is used to select LSP tunnel. In Figure , for the message to 20.0.0.0/24, PE adds a MPLS packet header to it with label 22 and selects a LSP tunnel according to the net hop address 4.4.4.4. When BGP advertises route information, if the next hop address is changed, it is required to distribute a new label. This is very important for inter-AS MPLS VPN services. It is to ensure the traceability and consistency of information. In fact, loopback address of a device is usually used as the Next-Hop of BGP routes. What will happen if loopback addresses of some devices in MPLS network are aggregated and only the aggregation route is advertised? As shown in Figure 3, R2 aggregates the loopback addresses of R3, R4 and R5 and sends the aggregation route to R1. When there is a packet to 10.0.0.3 on R1, will R1 add a label 10 to 10.0.0.0/24 to the packet and send it to R2? Of course, R1 will not. As a PE device, R2 implement operation on a packet according to the information in outer layer of MPLS packet header, especially when there are multiple layers of MPLS encapsulation. When R2 receives a packet with label 10, it does not know whether the packet is to 10.0.0.3 or 10.0.0.4. R2 feels confused and the packet is lost. This is a problem that must be solved in inter-AS MPLS VPN services. In intra-AS MPLS VPN networks, it is easy to avoid loopback address aggregation. However, in inter-AS MPLS VPN networks, usually routes are aggregated.
Figure 3. Next-Hop Address Aggregation Figure 2. Part Information of a MP-BGP Update Message
36
Maintenance Experience
www.zte.com.cn
PE-A and PE-B run MP-BGP and create VPNV4 IBGP neighbor relationship. They distribute labels for VPN routes and advertise the results to each other. Both devices use their own loopback address as the Next-Hop address. LDP is used to distribute labels for public routes. A nonstop tunnel based on loopback address is established between PE-A and PE-B. When a user 1.1.1.1 in VPN-1 on PE-A sends a message to user 2.2.2.2, PE-A searches for route related to VPN-1. The route information is shown below.
Address VPN-1: 2.2.2.2 Next-Hop PE-B Label X
same PE, labels distributed for different routes are different. As MP-BGP neighbor relationship is established between PE devices directly, only PE devices know VPN routes and the labels distributed for these routes. A P device does not know how to process a packet only with an inner layer label. With the outer layer label, the packet encapsulated with inner layer label can be sent to destination PE from entrance PE through the nonstop tunnel. This ensures that the messages can be transmitted correctly.
This information is provided by PE-B through MP-BGP. PE-B tells its MP-BGP peer that the messages to 2.2.2.2 in VPN-1 must be added MPLS packet header with label X before the messages are sent to PE-B. Therefore, PE-A adds a MPLS packet header with label X to the message. Then PE-A searches for information in its LFIB and finds out the following information.
Address PE-B Next-Hop INTF-A Label Y
VRF. In two adjacent ASs, ASBR in each AS is configured with VPN instance, and it considers the VPN instance on peer ASBR as CE device. VPN instance routes on peer PE device are redistributed to local PE device by local ASBR. Next-Hop is also the local ASBR. IP messages of users are re-encapsulated with MPLS packet headers by local ASBR before they are transmitted. In the sight of PE device, local ASBR is the destination PE router that connects to peer VPN users. As shown in Figure 5, VPN tunnel is broken between two ASBRs. User data is transmitted in primary message form between ASBRs without MPLS header encapsulation. VPN networks are isolated by VPN instances on ASBRs. The result shows that user private data is exposed to other devices between PE devices. For OPTION-A, to ensure VPN
According to the above information, PE-A adds a header with label Y to the message and sends the message from interface INTF-A. The message to user 2.2.2.2 is encapsulated with two layers of MPLS headers and it is send to PE-B from interface INTF-A on PE-A. When PE-B receives the packet, it searches for information in its LFIB according to the inner layer label X. It knows that the packet is to user 2.2.2.2 in VPN-1 on PE-B. Therefore, PE-B removes the MPLS header and sends the message to user 2.2.2.2. PE devices judge which VPN the received message belongs to according to inner layer label of the packet. That is, inner layer label is used to isolate VPN tunnels established between the same PE devices. For the same VPN instance on the
Data Products
37
February 2009
Issue 153
isolation, it is required for each VPN instance to establish independent inter-connected physical links or logical links. If connections between ASBRs use POS interfaces, there will be great difficulty. However, as device requirements are low and routers that support intra-AS MPLS VPN can be used, as well as it is not necessary to extend protocols, OPTION-A still has its advantages when there are not many VPN networks. In OPTION-B, MP-BGP VPNv4 EBGP neighbor relationship is established between ASBRs. VPN routes and related label information are advertised between ASs. To establish EBGP neighbor relationship, directconnected interfaces on ASBRs are used as the Next-hops, as shown in Figure 6. Although VPN tunnel is broken between two ASBRs, inner layer tunnel between VPN instances is still normal.
When ASBR learns VPN route information from peer ASBR, it advertises the information to IBGP neighbors in AS. The neighbors can be RR. At last, PE device learns the information. Before advertising VPN route information to IBGP neighbors, ASBR determines whether to change next hop address or not. If next hop address is changed, new labels will be distributed. In the sight of PE device, since NextHop is the local ASBR, data is transmitted through LSP between PE and ASBR. For further data forwarding, it is implemented by ASBRs in the two ASs. If next hop address is not changed, the next hop address of VPN route that PE receives is the interface address of ASBR in peer AS that connects local ASBR. Such route will not be broadcasted in local AS and therefore there is no corresponding LSP. When devices of some vendors work as ASBR devices in OPTION-B, local ASBR generates an address in local routing table for interconnection with the peer ASBR automatically. That is a 32-bit host route of Next-hop. This route can be broadcasted to IGP routing table in local AS, and then labels will be distributed and a LSP will be established. The 32-bit host route can also be broadcasted to PE device through BGP. However, this adds another layer of encapsulation label to the VPN packets besides the MPLS packet encapsulation label, which makes processing
38
Maintenance Experience
www.zte.com.cn
of packet on ASBR more complicated. It is important to change the next hop address. That is why devices of some vendors change the next hop address to itself by default. In OPTION-B, ASBR must process a lot of VPN route information. Therefore, devices used in OPTION-B are with high requirements. In application of OPTION-B, if RD filtration function is disabled on all devices, a lot of useless VPN route information will be transmitted between ASs, which costs network resources. It is recommended to use policy to limit route transmission. Another method is to create required VPN instances on ASBR without binding VPN instances to interfaces. OPTION-C is the most complicated. It can establish nonstop tunnel between PE devices in different ASs. In OPTION-C, PE devices obtain VPN route information by establishing MP-BGP VPNv4 EBGP neighbor relationship or by creating RR in ASs. In OPTION-C, VPN route information is transmitted between PE devices directly or forwarded by RR. The next hop address of the received VPN route is the primary promulgator, that is, the loopback address of peer PE device. The address can not be changed. In the sight of PE device, there must be a LSR to peer PE device. Network topology of OPTION-C is shown in Figure 7.
Therefore, it is necessary to extend BGP to make ASBR distribute MPLS label to Next-hop address of local PE and advertise it to peer ASBR. ASBR not only establishes MP-BGP neighbor relationship PE device or RR in local AS, but also establishes IBGP neighbor relationship. Therefore, ASBR can broadcast route information and label information learnt peer ASBR neighbors to local PE device and RR. As a result, PE, ASBR and RR have the Next-hop of VPN route, that is, the loopback address of peer PE device. To transmit data to peer PE device between PE device and ASBR in local AS correctly, it is only necessary to establish a nonstop tunnel between PE device and ASBR in local A, that is, the MPLS outer layer tunnel, as shown in Figure 7. In Figure 7, when device 1.1.1.1 in VPN-1 wants to send a message to device 2.2.2.2, PE-A implements the following steps. 1. PE-A finds the following information.
Address VPN-1: 2.2.2.2 Next-Hop PE-B Label X
This information is learnt by establishing MEBGP neighbor relationship between PE devices. It is necessary to know how to reach the next hop PE-B. 2. PE-A searches for forwarding information to PE-B, as shown below.
Address PE-B
Figure 7. OPTION-C Network Topology
Label Y
3. PE-A searches for forwarding information of ASBR in AS-A (next hop of PE-B), as shown below.
Address AS-A ASBR Next-Hop INTF-A Label Z
The establishment of LSP tunnel between ASBRs in AS-A and AS-B is the application of intra-AS. It is easy to establish the LSP. The key point is to establish a tunnel about PE-B between PE-A and ASBR in AS-B and then connect the tunnel to the established LSP in AS-B. The tunnel between PE-A and ASBR in AS-B can be divided into two tunnels. One is an intra-AS tunnel between PE-A and ASBR in AS-A, the other is an inter-AS tunnel between ASBR in AS-A and ASBR in AS-B.
At last, the message to device 2.2.2.2 is encapsulated with three layers of labels (from inside out, they are X, Y and Z) and transmitted
Data Products
39
February 2009
Issue 153
from interface INTF-A. In OPTION-C, when there is RR in each AS, if the next hop of VPN route is changed to RR itself and MPLS forwarding function is enabled on RR, as long as label is distributed to RR address and the address is advertised, VPN devices can communicate with each other. However, all VPN traffic are forwarded by RR, RR will become the bottleneck in the network.
s w i t c h i n g t e c h n o l o g y. P E d e v i c e s exchange VPN route information and label information through MP-BGP. Messages are encapsulated with MPLS packet headers before transmission. To avoid leaking messages to other devices, it is necessary to establish an outer layer tunnel directly or indirectly between PE devices. This is the basic thought of MPLS VPN. In fact, the technologies and options can be used flexibly. For example, in OPTION-C, instead of distributing public network labels through BGP in AS, it is allowed to broadcast address of peer PE device to IGP routing table directly and then distribute labels through LDP. In a word, MPLS VPN technology can be used flexibly and the options can be used together. For example, in application of Carrier s Carrier network, use OPTION-C in network of level 1 service operator and use OPTION-B in network of level 2 service operator. As long as the technology is used reasonably, expectant goal can be achieved.
4 Summary
In application of intra-AS MPLS VPN, there may be multiple links between ASBRs. For common IP data forwarding, MPLS load balancing can be used on these links. The steps are described below. 1. Implement load balancing of loopback routes on these links. 2. Establish EBGP neighbor relationship between ASBRs based on loopback addresses. To implement MPLS load balancing of intraAS MPLS VPN, there is a third step. It is to enable MPLS forwarding function on each links of ASBR. This is to establish LSP tunnels based on loopback address between ASBRs. MPLS VPN meets the privacy requirement of VPN by establishing tunnels through MPLS
40
Maintenance Experience