Product Type Technical Description

ZXUN-xGW GGSN GRE Configuration GuideV1.1

Product Type Technical Proposal

II 2013

ZTE Confidential Proprietary 2012 ZTE Corporation. All rights reserved.1(26)

LEGAL INFORMATION

By accepting this certain document of ZTE CORPORATION you agree to the following terms. If you do not agree to the following terms, please notice that you are not allowed to use this document.

Copyright 2013 ZTE CORPORATION. Any rights not expressly granted herein are reserved. This document contains proprietary information of ZTE CORPORATION. Any reproduction, transfer, distribution, use or disclosure of this document or any portion of this document, in any form by any means, without the prior written consent of ZTE CORPORATION is prohibited.

and are registered trademarks of ZTE CORPORATION. ZTEs company name, logo and product names referenced herein are either trademarks or registered trademarks of ZTE CORPORATION. Other product and company names mentioned herein may be trademarks or trade names of their respective owners. Without the prior written consent of ZTE CORPORATION or the third party owner thereof, anyones access to this document should not be construed as granting, by implication, estopped or otherwise, any license or right to use any marks appearing in the document.

The design of this product complies with requirements of environmental protection and personal security. This product shall be stored, used or discarded in accordance with product manual, relevant contract or laws and regulations in relevant country (countries).

This document is provided as is and as available. Information contained in this document is subject to continuous update without further notice due to improvement and update of ZTE CORPORATIONs products and technologies.

ZTE CORPORATION

Address:NO. 55Hi-tech Road SouthShenZhenP.R.China518057

Website:http://support.zte.com.cn

Email:800@zte.com.cn

Revision History

Product VersionDocument VersionSerial NumberReason for Revision

ZXUN-xGW GGSN V4 universalV1.01st draft

V1.1Modified some descriptions

Author

Document Version DatePrepared byReviewed byApproved by

V1.02012-11-28Huang JunWang Dayou

V1.12013-10-25Huang JunZhu Wei

TABLE OF CONTENTS1Overview12Working Principle22.1Format of GRE Packets22.2GRE Tunnel Encapsulation32.3GRE Tunnel De-capsulation33Application Scenario and Network Planning53.1Single-Tunnel and Dual-Tunnel53.2Dedicated Interface and Shared Interface64Configuration Example of a Single-Tunnel Using a Dedicated Sub-Interface74.1Data Planning74.2GGSN Configuration Commands84.2.1Configuring the VRF84.2.2Configuring the PFU Interface and Sub-Interface84.2.3Configuring the GRE Tunnel104.2.4Configuring the APN114.2.5Configuring the Route125Configuration Example of a Single-Tunnel Sharing a Sub-Interface145.1Data Planning145.2GGSN Configuration Commands155.2.1Configuring the VRF155.2.2Configuring the PFU Interface and Sub-Interface155.2.3Configuring the GRE Tunnel165.2.4Configuring the APN175.2.5Configuring the Route186Configuration Example of a Dual-Tunnel196.1Data Planning196.2GGSN Configuration Commands206.2.1Configuring the VRF206.2.2Configuring the PFU Interface and Sub-Interface206.2.3Configuring the GRE Tunnel226.2.4Configuring the APN246.2.5Configuring the Route257GRE Maintenance Operations277.1Querying the Configurations277.2Detecting the Tunnel Status297.3Processing Alarms307.4Common Problems31

ZXUN-xGW GGSN GRE Configuration Guide Restricted

ZTE Confidential & Proprietary. 2013 ZTE CORPORATION. All rights reserved.26

OverviewThe Generic Routing Encapsulation (GRE) function can encapsulate data packets over protocols of certain network layers (for example, IPV4, IPV6 or certain private protocols), so that these encapsulated data packets can be transmitted over another network-layer protocol. In the PS network, the GRE is commonly used to realize the VPN network from the GGSN to the WAP gateway or the enterprise private network. In the current phase, the IPV4 protocol is used on the network layer. This document describes the principle of the GRE tunnel based on IPV4 and the related configuration procedure in the xGW GGSN. Working PrincipleFormat of GRE PacketsThe format of GRE packets is defined in the RFC 1701. In general, a GRE packet consists of the delivery protocol header, GRE protocol header, and the payload packet, as shown below.

Delivery Header: Protocol header of the delivery protocol. In the PS network, the GRE delivery protocol is usually the IPV4, where the source IP address and the destination IP address are the GRE tunnel addresses on the local end and on the opposite end respectively. In the protocol header, the protocol ID is 0x2F (47), indicating that this packet is a GRE packet. GRE Header: GRE protocol header, which includes a 2-byte protocol type that indicates the type of the payload protocol. At present, the payload protocol in the PS network is the IP protocol, so the Protocol Type in the protocol header is 0x800. Payload: Payload protocol. In the PS network, it indicates the data packets that are actually sent by the GGSN or end users. For the detailed description of the packet format, refer to http://tools.ietf.org/html/rfc1701. The following figure shows the example of a GRE packet captured on the Gi interface. In this packet, the delivery protocol is IPV4, the local-end (GGSN) tunnel address is 211.138.226.212 and the opposite-end (router on the WAP gateway side) tunnel address is 211.142.208.66. The GRE protocol header indicates that the payload protocol inside the tunnel is IP protocol. All optional values of the GRE packet are set to 0. The payload data packet is a AAA charging request packet, where the source IP address is 10.201.0.1 (GGSN) and the destination IP address is 10.0.0.173 (AAA server).

GRE Tunnel EncapsulationWhen the GGSN sends an IP data packet, if the GGSN searches the routing table and finds that the IP data packet needs to be sent out from the GRE tunnel interface, it will make GRE encapsulation. During encapsulation, the GGSN processes optional fields in the GRE packet header according to the settings of the GRE tunnel interface, sets the source IP address in the encapsulated transmission-layer protocol to the local-end GRE tunnel address, sends the destination address to the opposite GRE tunnel address, and searches for the route according to the encapsulated destination address and finally forwards the data packet out. GRE Tunnel De-capsulationWhen the GGSN receives an IP data packet, if the destination address is the local GGSN and its protocol ID is 0x2F(47), it indicates that this data packet is encapsulated by GRE and need to be de-capsulated. After the GRE packet passes validity checks, the GGSN maps the packet to the GRE tunnel ID on the local according to the source address and destination address in the GRE packet. Then, the GGSN processes optional fields in the GRE packet. At present, the xGW GGSN only supports the key option and ignores other options. If the key ID in the GRE packet header is different from the key ID in the corresponding GRE tunnel, or the key ID is set to 1 but the key value is different, the GGSN will discard this data packet. Finally, the GGSN removes GRE encapsulation and gets the actual IP packet of the inner payload. According to the inner IP packet, the GGSN then judges whether to send the packet to the corresponding board for processing or forwards it according to the routing table. Application Scenario and Network PlanningIn the PS network, the GRE tunnel is mainly applied between the GGSN and the WAP gateway or the enterprise network. Due to different scenarios of different carriers and enterprise users, network planning also differs. This document only describes related configurations of the GRE tunnel under different scenarios. For details about networking planning and route configurations, refer to ZXUN xGW Networking Specifications Guide (GGSN Volume) or consult technical support personnel of the data network. Single-Tunnel and Dual-TunnelIf the GGSN Gi interface uses the GE interface, you need to select the single-channel or dual-channel by comprehensively considering the expected busy-hour service traffic and reliability. For APNs with low busy-hour traffic (500Mbps), you need to plan two GRE tunnels and balance the load between them. In addition, in route configuration, you need to make sure that the downlink traffic enters the GGSN evenly through different GE interfaces, so as to avoid traffic congestion on a single GE interface. If the busy-hour APN service traffic is close to or even greater than 1Gbps, it is recommended to change the GE link into a 10 GE link or use multi-GE link congregation. For APNs with high reliability requirements, you should also plan two GRE tunnels to achieve redundancy backup. It is required that the opposite end (WAP gateway or enterprise) use at least two different physical links to interconnect with the GGSN. Busy-hour trafficReliability requirement500Mbps

HighDual-tunnelDual-tunnel

LowSingle-tunnelDual-tunnel

If the GGSN Gi interfaces uses the 10 GE interface, you can ignore the factor of service traffic and select the single-tunnel or dual-tunnel only according to reliability requirements of the carrier and the enterprise. Dedicated Interface and Shared InterfaceThe xGW GGSN supports route forwarding by not only tunnels of several APNs sharing one physical interface (or sub-interface) but also different APNs using a dedicated physical interface (or sub-interface). If the GGSN Gi interface uses the GE interface, you need to comprehensively consider both the service traffic and tunnel planning. For an APN with high traffic, it must use the dedicated physical interface no matter it uses the single tunnel or the dual-tunnel. For an APN that uses the dual-tunnel but has low traffic, it must uses the dedicated physical interface or sub-interface. If the traffic is satisfied, it is recommended to use the sub-interface mode, but different sub-interfaces can still share the bandwidth of one physical interface. For an APN that uses the single-channel and has low traffic, it can share the physical interface or share the sub-interface. If several APNs share one physical interface, the total traffic cannot exceed 500Mbps. For an APN that uses the WAP service, it is recommended to use the dedicated physical interface or sub-interface. If the GGSN Gi interface uses the 10 GE interface, you can ignore the factor or service traffic, and make planning according to the principle that the single-tunnel shares the sub-interface and the dual-tunnel uses the dedicated interface. Note: If the dual-tunnel is configured between the GGSN and the WAP gateway or the enterprise network, you need to enable the keep-alive detection mechanism. According to this detection mechanism, the VRF associated with the APN must be the same as the VRF associated with the PFU interface that the actual route of the tunnel passes through, so the APN configured with a dual-tunnel must use the dedicated physical interface or dedicated sub-interface. Configuration Example of a Single-Tunnel Using a Dedicated Sub-InterfaceData PlanningNo.Parameter NameParameter ValueDescription

1Tunnel interface namegre_tunnel20Sequence number of the tunnel interface name. Value range: 1-4000.

2Tunnel source IP172.16.1.1/32IP address encapsulated by the tunnel on the GGSN side

3Tunnel destination IP172.16.2.1/32IP address encapsulated by the tunnel on the opposite end

4Local-end tunnel interface address192.168.11.1/30Interface IP of the tunnel interface. Usually a pair of private addresses are planned.

5Opposite-end tunnel interface address192.168.11.2/30

6Loopback interface nameLoopback11The local-end tunnel source IP needs to be configured on the loopback interface.

7PFU interface/sub-interface namegei-0/1/1/1.10gei-0/2/1/1.10If the sub-interface is used, it is recommended to set the sub-interface ID to be the same as the VLAN ID.

8PFU interface/sub-interface address192.168.122.94/30192.168.123.94/30IP address by which the PFU interface/sub-interface interconnects with the switch or router

9PFU interface/sub-interface VRFVrf name: vrf_zteVrf id: 10The VRF associated with the GRE tunnel in GRE configuration must be consistent with the VRF associated with the PFU interface.

10VLAN ID of PFU sub-interface10The VLAN ID is allocated on the switch/router side.

11APN namezte.comThe APN name is allocated by the carrier.

12VRF associated with the APNVrf name: vrf_zteVrf id: 10In interface configuration, the VRF associated with the GRE interface must be consistent with the VRF associated with the APN.

13KEY (optional)zteThe carrier or enterprise determines whether to enable the GRE key. The setting on the GGSN must be consistent with that on the opposite end. Usually the key is not enabled.

GGSN Configuration CommandsConfiguring the VRF1.Enable the configuration mode. GGSN#conf ter2.Create a VRF with the VRF name of vrf_zte and the VRF ID of 10. The VRF name and VRF ID are only valid inside this GGSN. For an APN that uses the dedicated interface, the VRF name can reflect the APN brief information, which facilitates daily maintenance. The VRF ID is numbered sequentially in the range of 1-4095. GGSN(config)#ip vrf vrf_zte vpnid 103.Set the VRF RD to 10:1. The VRF RD uniquely identifies a VRF, and it is valid only inside the GGSN. The VRF RDs of different VRFs cannot repeat. You can uniformly set the VRF RD in the format of VRF ID:1. GGSN(config-vrf)#rd 10:14.Set the VRF address family type to IPv4. GGSN(config-vrf)#address-family ipv4GGSN(config-vrf-af)#exitGGSN(config-vrf)#exitGGSN(config)#Configuring the PFU Interface and Sub-Interface1.Enter the physical interface gei-0/1/1/1. GGSN (config)#interface gei-0/1/1/12.Set the interface MAC offset to 1. The MAC offsets of all physical interfaces globally cannot repeat. The value range is 1-63. GGSN (config)#interface mac-address offset 13.Create or enter the sub-interface which is named as gei-0/1/1/1.10. It is recommended to set the sub-interface ID to be consistent with the planned VLAN ID, which facilitates maintenance. If the GGSN uses the physical interface to interconnect with the switch or router, you can directly configure VRF association and IP address on the physical interface, and do not need to configure the sub-interface. GGSN (config)#interface gei-0/1/1/1.104.Set the MAC offset of the sub-interface to 1. The MAC offset of the sub-interface should be the same as that of the physical interface. GGSN (config-subif)#interface mac-address offset 15.Associate the sub-interface with the VRF vrf_zte. GGSN (config-subif)#ip vrf forwarding vrf_zte6.Set the IP address of the sub-interface to 192.168.122.94/30. GGSN (config-subif)#ip address 192.168.122.94 255.255.255.252GGSN (config-subif)#exitGGSN (config)#7.Configure another sub-interface in the same procedure. GGSN (config)#interface gei-0/2/1/1GGSN (config)#interface mac-address offset 11GGSN (config)#interface gei-0/2/1/1.10GGSN (config)#interface mac-address offset 11GGSN (config-subif)#ip vrf forwarding vrf_zteGGSN (config-subif)#ip address 192.168.123.94 255.255.255.252GGSN (config-subif)#exitGGSN (config)#8.Enable the VLAN configuration mode. GGSN (config)#vlan-configuration9.Set the VLAN IDs of the sub-interface gei-0/1/1/1.10 and gei-0/2/1/1.10 to 10. GGSN(config-vlan)# interface gei-0/1/1/1.10GGSN(config-subvlan-if)#encapsulation-dot1q 10GGSN(config-subvlan-if)#exitGGSN(config-vlan)# interface gei-0/2/1/1.10GGSN(config-subvlan-if)#encapsulation-dot1q 10GGSN(config-subvlan-if)#exitGGSN(config-subvlan)#exitGGSN(config)#Configuring the GRE Tunnel1.Create or enter the interface gre_tunnel20. GGSN(config)#interface gre_tunnel202.Associate the GRE interface with the VRF vrf_zte. The VRF associated with the GRE interface in interface configuration must be consistent with the VRF associated with the APN. GGSN(config-if)#ip vrf forwarding vrf_zte3.Set the IP address of the GRE interface to 192.168.11.1/30. The IP address of the GRE interface is only related to the generation of the routing table, and will not appear in service packets. GGSN(config-if)#ip address 192.168.11.1 255.255.255.252GGSN(config-if)#exit4.Create or enter the loopback interface loopback11, which is used to configured the source address of the tunnel. GGSN(config)#interface loopback115.Associate the loopback interface with the VRF vrf_zte. The VRF associated with the loopback interface should be the same as the VRF associated with the outbound PFU interface. GGSN(config-if)#ip vrf forwarding vrf_zte6.Set the IP address of the loopback interface to 172.16.1.1/32, that is the tunnel source address of the GGSN. GGSN(config-if)#ip address 172.16.1.1 255.255.255.255GGSN(config-if)#exit7.Enable the GRE configuration mode. GGSN(config)#gre-config 8.Create or enter the GRE tunnel gre_tunnel20. GGSN(config-gre)#interface gre_tunnel209.Set the tunnel protocol type to IPv4. GGSN(config-gre-if)#tunnel mode ip10.Set the source address of the GRE tunnel to 172.16.1.1, and set its destination address to 172.16.2.1. GGSN(config-gre-if)#tunnel source ipv4 172.16.1.1GGSN(config-gre-if)#tunnel destination ipv4 172.16.2.111.Set the key of the GRE tunnel to zte. The KEY value is the decryption key, which must be consistent between the GGSN and the opposite end. Either you do not enable the key on both ends, or you configure the same KEY for both ends. If the carrier and the enterprise do not have particular requirements, it is recommended not to configure the KEY. GGSN(config-gre-if)#tunnel key zte12.Associate the GRE tunnel with the VRF vrf_zte. The VRF associated with the GRE tunnel in GRE configuration must be consistent with the VRF associated with the PFU interface. GGSN(config-gre-if)#tunnel vrfname vrf_zteGGSN(config-gre-if)#exitGGSN(config-gre)#exitConfiguring the APN1.Enter the GGSN configuration mode. GGSN(config)#xgwGGSN(config-xgw)#ggsn2.Add a new APN with the name of zte.com. GGSN(config-xgw-ggsn)#ap zte.com3.Associate the APN with the VRF vrf_zte. GGSN(config-xgw-ggsn-apn)#vrf vrf_zte4.For other APN configurations, refer to the commissioning document. These configurations are skipped in this document. GGSN(config-xgw-ggsn-apn)#exitGGSN(config-xgw-ggsn)#exitGGSN(config-xgw)#exitConfiguring the Route1.Create an OSPF instance 10 and associate it with the VRF vrf_zte. The VRF associated with the OSPF instance should be consistent with the VRF associated with the outbound interface. GSN94(config)#router ospf 10 vrf vrf_zte2.Set the maximum number of equivalent routes on the OSPF to 4. The value of Maximum-paths should be greater than or equal to the actual number of interfaces for load balance. GGSN(config-ospfv2)#maximum-paths 43.Configure the running areas for the OSPF, including the two sub-interfaces and loopback11 of the PFU. After configuration, you can release the interface addresses and loopback11 address (that is, the tunnel source address of the GGSN) of the GGSN. The running area is configured in the format of IP address and subnet mask. The area should be consistent with that of the opposite switch/router. GGSN(config-ospfv2)#network 192.168.122.94 0.0.0.0 area 0.0.0.10GGSN(config-ospfv2)#network 192.168.123.94 0.0.0.0 area 0.0.0.10GGSN(config-ospfv2)#network 172.16.1.1 0.0.0.0 area 0.0.0.10GGSN(config-ospfv2)#exit4.Configure the default static route to the WAP gateway/enterprise, which is forwarded through the GRE tunnel. The VRF of the route table should be consistent with the VRF associated with the APN. GGSN(config)#ip route vrf vrf_zte 0.0.0.0 0.0.0.0 gre_tunnel20 Note: This section only provides an example, and it is not the recommended configuration. You need to determine the specific route protocol according to the actual onsite situation. Configuration Example of a Single-Tunnel Sharing a Sub-InterfaceData PlanningNo.Parameter NameParameter ValueDescription

1Tunnel interface namegre_tunnel20Sequence number of the tunnel interface name. Value range: 1-4000.

2Tunnel source IP172.16.1.1/32IP address encapsulated by the tunnel on the GGSN side

3Tunnel destination IP172.16.2.1/32IP address encapsulated by the tunnel on the opposite end

4Local-end tunnel interface address192.168.11.1/30Interface IP of the tunnel interface. Usually a pair of private addresses are planned.

5Opposite-end tunnel interface address192.168.11.2/30

6Loopback interface nameLoopback11The local-end tunnel source IP needs to be configured on the loopback interface.

7PFU interface/sub-interface namegei-0/1/1/1.10gei-0/2/1/1.10If the sub-interface is used, it is recommended to set the sub-interface ID to be the same as the VLAN ID.

8PFU interface/sub-interface address192.168.122.94/30192.168.123.94/30IP address by which the PFU interface/sub-interface interconnects with the switch or router

9PFU interface/sub-interface VRFVrf name: vrf_greVrf id: 20The VRF associated with the GRE interface in interface configuration must be consistent with the VRF associated with the PFU interface.

10VLAN ID of PFU sub-interface10The VLAN ID is allocated on the switch/router side.

11APN namezte.comThe APN name is allocated by the carrier.

12VRF associated with the APNVrf name: vrf_zteVrf id: 10The VRF associated in GRE configuration must be consistent with the VRF associated with the APN.

13KEY (optional)zteThe carrier or enterprise determines whether to enable the GRE key. The setting on the GGSN must be consistent with that on the opposite end. Usually the key is not enabled.

GGSN Configuration CommandsConfiguring the VRFGGSN94#conf ter1.Create a VRF with the VRF name of vrf_zte and the VRF ID of 10. This VRF is used by the APN zte.com dedicatedly. GGSN(config)#ip vrf vrf_zte vpnid 10GGSN(config-vrf)#rd 10:1GGSN(config-vrf)#address-family ipv4GGSN(config-vrf-af)#exitGGSN(config-vrf)#exit2.Create a VRF with the VRF name of zte_gre and the VRF ID of 20. This VRF is shared by the PFU interface and sub-interfaces. GGSN(config)#ip vrf vrf_gre vpnid 20GGSN(config-vrf)#rd 20:1GGSN(config-vrf)#address-family ipv4GGSN(config-vrf-af)#exitGGSN(config-vrf)#exitGGSN(config)#Configuring the PFU Interface and Sub-InterfaceGGSN (config)#interface gei-0/1/1/1GGSN (config)#interface mac-address offset 11.If the GGSN interconnects with the switch/router through the physical interface, you can configure the IP address associated with the VRF on the physical interface directly, and you do not need to configure the sub-interface. GGSN (config)#interface gei-0/1/1/1.10GGSN (config-subif)#interface mac-address offset 12.Associate the sub-interface with the VRF vrf_gre. GGSN (config-subif)#ip vrf forwarding vrf_greGGSN (config-subif)#ip address 192.168.122.94 255.255.255.252GGSN (config-subif)#exitGGSN (config)#3.Configure the other interface in the same procedure. GGSN (config)#interface gei-0/2/1/1GGSN (config)#interface mac-address offset 11GGSN (config)#interface gei-0/2/1/1.10GGSN (config)#interface mac-address offset 11GGSN (config-subif)#ip vrf forwarding vrf_greGGSN (config-subif)#ip address 192.168.123.94 255.255.255.252GGSN (config-subif)#exitGGSN (config)#

GGSN (config)#vlan-configurationGGSN(config-vlan)# interface gei-0/1/1/1.10GGSN(config-subvlan-if)#encapsulation-dot1q 10GGSN(config-subvlan-if)#exitGGSN(config-vlan)# interface gei-0/2/1/1.10GGSN(config-subvlan-if)#encapsulation-dot1q 10GGSN(config-subvlan-if)#exitGGSN(config-subvlan)#exitConfiguring the GRE Tunnel1.While configuring the tunnel of the shared sub-interface, you need to pay particular attention that the VRF associated with gre_tunnel in interface configuration should be consistent with that of the APN, and the VRF associated with gre_tunnel in GRE configuration should be consistent with that of the PFU interface/sub-interface. These two VRFs are different. GGSN(config)#interface gre_tunnel202.Associate the GRE interface with the VRF vrf_zte. The VRF associated with the GRE interface in interface configuration should be consistent with the VRF associated with the APN. GGSN(config-if)#ip vrf forwarding vrf_zteGGSN(config-if)#ip address 192.168.11.1 255.255.255.252GGSN(config-if)#exit3.Associate the loopback interface with the VRF vrf_gre. The VRF associated with the loopback interface should be consistent with the VRF associated with the PFU interface/sub-interface. Different APNs can share one tunnel source address. If you have configured the loopback interface and tunnel source address for one APN, you do not need to configure them for other APNs repeatedly. GGSN(config)#interface loopback11GGSN(config-if)#ip vrf forwarding vrf_greGGSN(config-if)#ip address 172.16.1.1 255.255.255.255GGSN(config-if)#exit

GGSN(config)#gre-config GGSN(config-gre)#interface gre_tunnel20GGSN(config-gre-if)#tunnel mode ipGGSN(config-gre-if)#tunnel source ipv4 172.16.1.1GGSN(config-gre-if)#tunnel destination ipv4 172.16.2.14.Set the key of the GRE tunnel to zte. The KEY value is the decryption key, which must be consistent between the GGSN and the opposite end. Either you do not enable the key on both ends, or you configure the same KEY for both ends. If the carrier and the enterprise do not have particular requirements, it is recommended not to configure the KEY. GGSN(config-gre-if)#tunnel key zte5.Associate the GRE tunnel with the VRF vrf_gre. The VRF associated with the GRE tunnel in GRE configuration must be consistent with the VRF associated with the PFU interface. GGSN(config-gre-if)#tunnel vrfname vrf_greGGSN(config-gre-if)#exitGGSN(config-gre)#exitConfiguring the APNGGSN(config)#xgwGGSN(config-xgw)#ggsnGGSN(config-xgw-ggsn)#ap zte.com1.Associate the APN with the VRF vrf_zte. GGSN(config-xgw-ggsn-apn)#vrf vrf_zte2.For other APN configurations, refer to the commissioning document. The detailed configuration steps are skipped in this section. GGSN(config-xgw-ggsn-apn)#exitGGSN(config-xgw-ggsn)#exitGGSN(config-xgw)#exitConfiguring the Route1.Create an OSPF instance 10 and associate it with the VRF vrf_gre. The VRF associated with the OSPF should be consistent with the instance associated with the outbound PFU interface. GSN94(config)#router ospf 10 vrf vrf_gre2.Set the maximum number of equivalent routes on the OSPF to 4.The value of Maximum-paths should be greater than or equal to the actual number of interfaces for load balance.GGSN(config-ospfv2)#maximum-paths 4GGSN(config-ospfv2)#network 192.168.122.94 0.0.0.0 area 0.0.0.10GGSN(config-ospfv2)#network 192.168.123.94 0.0.0.0 area 0.0.0.10GGSN(config-ospfv2)#network 172.16.1.1 0.0.0.0 area 0.0.0.10GGSN(config-ospfv2)#exit3.Configure the default static route to the WAP gateway or enterprise network, which forwards packets through the GRE tunnel. The VRF in the route table should be consistent with the VRF associated with the APN. GGSN(config)#ip route vrf vrf_zte 0.0.0.0 0.0.0.0 gre_tunnel20Configuration Example of a Dual-TunnelData PlanningNo.Parameter NameParameter ValueDescription

1Interface name of tunnel 1gre_tunnel21Sequential number of the tunnel interface name. Value range: 1-4000.

2Source IP of tunnel 1172.16.1.1/32IP address encapsulated by the tunnel on the GGSN side

3Destination IP of tunnel 1172.16.2.1/32IP address encapsulated by the tunnel on the opposite side

4Local-end interface address of tunnel 1192.168.11.1/30IP address of the tunnel interface. Usually a pair of private addresses is planned.

5Opposite-end address of tunnel 1192.168.11.2/30

6Interface name of tunnel 2gre_tunnel22

7Source IP of tunnel 2172.16.3.1/32The two GGSN tunnels can share one source IP address or use different source IP addresses. It is recommended to use different source IP addresses.

8Destination IP of tunnel 2172.16.4.1/32

9Local-end interface address of tunnel 2192.168.12.1/30

10Opposite-end interface address of tunne2192.168.12.2/30

11Loopback interface nameLoopback11The several source IP addresses of the local-end tunnel can be configured on the same loopback interface.

12PFU interface/sub-interface namegei-0/1/1/1.10gei-0/2/1/1.10If the sub-interface is used, it is recommended to set the sub-interface ID to the same as VLAN ID.

13PFU interface/sub-interface address192.168.122.94/30192.168.123.94/30Set it to the address through which the PFU interface/sub-interface interconnects to the switch or router.

14VRF of the PFU interface/sub-interfaceVrf name: vrf_zteVrf id: 10The VRF associated with the GRE interface in interface configuration must be consistent with the VRF associated with the PFU interface.

15VLAN ID of the PFU sub-interface10VLAN ID is allocated by the switch/router side.

16APN namezte.comThe APN name is allocated by the carrier.

17VRF associated with the APNVrf name: vrf_zteVrf id: 10The VRF associated in GRE configuration must be the VRF associated with the APN.

18KEY (optional)zteThe carrier or the enterprise decides whether to enable the GRE key. This setting must be consistent between the GGSN and the opposite end.

GGSN Configuration CommandsConfiguring the VRF1.Enable the configuration mode. GGSN94#conf ter2.Create a VRF with the VRF name of vrf_zte and the VRF ID of 10. GGSN(config)#ip vrf vrf_zte vpnid 103.Set the VRF RD to o10:1. GGSN(config-vrf)#rd 10:14.Set the VRF address family type to IPv4. GGSN(config-vrf)#address-family ipv4GGSN(config-vrf-af)#exitGGSN(config-vrf)#exitConfiguring the PFU Interface and Sub-Interface1.Enter the physical interface gei-0/1/1/1. GGSN (config)#interface gei-0/1/1/12.Set the MAC offset of the interface to 1. GGSN (config)#interface mac-address offset 13.Create or enter the sub-interface which is named as gei-0/1/1/1.10. If the GGSN uses the physical interface to interconnect with the switch or router, you can directly configure VRF association and IP address on the physical interface, and do not need to configure the sub-interface. GGSN (config)#interface gei-0/1/1/1.104.Set the MAC offset of the sub-interface to 1. GGSN (config-subif)#interface mac-address offset 15.Associate the sub-interface with the VRF vrf_zte. GGSN (config-subif)#ip vrf forwarding vrf_zte6.Set the IP address of the sub-interface to 192.168.122.94/30. GGSN (config-subif)#ip address 192.168.122.94 255.255.255.252GGSN (config-subif)#exit7.Configure the other sub-interface according to the same procedure. GGSN (config)#interface gei-0/2/1/1GGSN (config)#interface mac-address offset 11GGSN (config)#interface gei-0/2/1/1.10GGSN (config)#interface mac-address offset 11GGSN (config-subif)#ip vrf forwarding vrf_zteGGSN (config-subif)#ip address 192.168.123.94 255.255.255.252GGSN (config-subif)#exitGGSN (config)#8.Enable the VLAN configuration mode. GGSN (config)#vlan-configuration9.Set the VLAN IDs of both sub-interfaces gei-0/1/1/1.10 and gei-0/2/1/1.10 to 10. GGSN(config-vlan)# interface gei-0/1/1/1.10GGSN(config-subvlan-if)#encapsulation-dot1q 10GGSN(config-subvlan-if)#exitGGSN(config-vlan)# interface gei-0/2/1/1.10GGSN(config-subvlan-if)#encapsulation-dot1q 10GGSN(config-subvlan-if)#exitGGSN(config-subvlan)#exitConfiguring the GRE Tunnel1.Create or enter the GRE interface gre_tunnel21. GGSN(config)#interface gre_tunnel212.Associate the GRE interface with the VRF vrf_zte. The VRF associated with the GRE interface in interface configuration must be consistent with the VRF associated with the APN. GGSN(config-if)#ip vrf forwarding vrf_zte3.Set the GRE interface address to 192.168.11.1/30. GGSN(config-if)#ip address 192.168.11.1 255.255.255.252GGSN(config-if)#exit4.Configure gre_tunnel22 according to the above procedure. GGSN(config)#interface gre_tunnel22GGSN(config-if)#ip vrf forwarding vrf_zteGGSN(config-if)#ip address 192.168.12.1 255.255.255.252GGSN(config-if)#exit5.Create or enter the loopback interface loopback11 to create the tunnel source address. GGSN(config)#interface loopback116.Associate the loopback interface with vrf_zte. The VRF associated with the loopback interface should be the same as the VRF associated with the outbound PFU interface. GGSN(config-if)#ip vrf forwarding vrf_zte7.Set the IP address of the loopback interface to 172.16.1.1/32 and 172.16.3.1/32, that is, the tunnel source address of the GGSN. GGSN(config-if)#ip address 172.16.1.1 255.255.255.255GGSN(config-if)#ip address 172.16.3.1 255.255.255.255 secondaryGGSN(config-if)#exit8.Enable the GRE configuration mode. GGSN(config)#gre-config 9.Create or enter the GRE tunnel gre_tunnel21. GGSN(config-gre)#interface gre_tunnel2110.Set the tunnel protocol type to IPv4. GGSN(config-gre-if)#tunnel mode ip11.Set the source address of the GRE tunnel to 172.16.1.1, and set its destination address to 172.16.2.1. GGSN(config-gre-if)#tunnel source ipv4 172.16.1.1GGSN(config-gre-if)#tunnel destination ipv4 172.16.2.112.Set the key of the GRE tunnel to zte. The KEY value is the decryption key, which must be consistent between the GGSN and the opposite end. Either you do not enable the key on both ends, or you configure the same KEY for both ends. If the carrier and the enterprise do not have particular requirements, it is recommended not to configure the KEY. GGSN(config-gre-if)#tunnel key zte13.Associate the GRE tunnel with the VRF vrf_zte. The VRF associated with the GRE tunnel in GRE configuration must be consistent with the VRF associated with the PFU interface. GGSN(config-gre-if)#tunnel vrfname vrf_zte14.Enable the keep-alive function on the tunnel. The keep-alive function needs to be enabled on both parties. By default, the GGSN sends a keep-alive packet every 10 seconds, and it can retransmits the packet three times if it does not receive any response upon time-out. If the GGSN detects a fault with the tunnel, the tunnel on the GGSN side will be turned into the down status, the corresponding routes become ineffective automatically, and services are switched over to another tunnel. Note:If the opposite device is an HW or H3C router, the opposite route may set the Recursion Control parameter in GRE Header of the keep-alive packet to 1, so the GGSN cannot identify the keep-alive packet sent by the opposite router and the tunnel is always in down status. Under this situation, the opposite router is requested to modify the configuration by setting Recursion Control to 0 according to requirements of RFC 1701. GGSN(config-gre-if)#tunnel keepaliveGGSN(config-gre-if)#exit15.Configure gre_tunnel22 according to the above steps. GGSN(config-gre)#interface gre_tunnel22GGSN(config-gre-if)#tunnel mode ip16.Set the source address of the GRE tunnel to 172.16.3.1, and set its destination address to 172.16.4.1. GGSN(config-gre-if)#tunnel source ipv4 172.16.3.1GGSN(config-gre-if)#tunnel destination ipv4 172.16.4.1GGSN(config-gre-if)#tunnel key zte17.Associate the GRE tunnel to the VRF vrf_zte. GGSN(config-gre-if)#tunnel vrfname vrf_zteGGSN(config-gre-if)#tunnel keepaliveGGSN(config-gre-if)#exitGGSN(config-gre)#exit Note: If the opposite device is an HW or H3C router, the opposite route may set the Recursion Control parameter in GRE Header of the keep-alive packet to 1, so the GGSN cannot identify the keep-alive packet sent by the opposite router and the tunnel is always in down status. Under this situation, the opposite router is requested to modify the configuration by setting Recursion Control to 0 according to requirements of RFC 1701. The current xGE GGSN version (V4.10.22) supports to enable the keep-alive function for at most 200 GRE tunnels. If you need to enable the keep-alive function on more than 200 tunnels, you need to contact the CN product support department for confirmation. Configuring the APNGGSN(config)#xgwGGSN(config-xgw)#ggsnGGSN(config-xgw-ggsn)#ap zte.com1.Associate the APN with the VRF vrf_zte. GGSN(config-xgw-ggsn-apn)#vrf vrf_zte2.For other APN configurations, refer to the commissioning manual. The detailed configurations are not described in this document. GGSN(config-xgw-ggsn-apn)#exitGGSN(config-xgw-ggsn)#exitGGSN(config-xgw)#exitConfiguring the Route1.Create a new OSPF instance with the ID of 10 and associate it with the VRF vrf_zte. The VRF associated with the OSPF instance must be consistent with the VRF associated with the outbound PFU interface. GSN94(config)#router ospf 10 vrf vrf_zte2.Set the maximum number of equivalent routes on the OSPF to 4. The value of Maximum-paths should be greater than or equal to the actual number of interfaces for load balance.GGSN(config-ospfv2)#maximum-paths 43.Configure the running area of the OSPF, including the two sub-interfaces of the PFU and loopback11. After the configurations are made, the interface addresses and loopback11 address (that is, the source tunnel address of the GGSN) can be released. GGSN(config-ospfv2)#network 192.168.122.94 0.0.0.0 area 0.0.0.10GGSN(config-ospfv2)#network 192.168.123.94 0.0.0.0 area 0.0.0.10GGSN(config-ospfv2)#network 172.16.1.1 0.0.0.0 area 0.0.0.10GGSN(config-ospfv2)#network 172.16.3.1 0.0.0.0 area 0.0.0.10GGSN(config-ospfv2)#exit4.Configure the default static route to the WAP gateway or enterprise, which is forwarded through the GRE tunnel. The VRF in the route table is consistent with the VRF associated with the APN. GGSN(config)#ip route vrf vrf_zte 0.0.0.0 0.0.0.0 gre_tunnel21GGSN(config)#ip route vrf vrf_zte 0.0.0.0 0.0.0.0 gre_tunnel22GRE Maintenance OperationsQuerying the Configurations1.Query configurations of the GRE tunnel. GRE tunnel configurations include interface configurations and GRE configurations. You can log in to the xGW GGSN foreground, and run the show running-config-interface command to query these two configurations at one time. The query results are shown as follows: GGSN#show running-config-interface gre_tunnel1! interface gre_tunnel1 ip mtu 1472 ip vrf forwarding uniwap ip address 172.16.78.85 255.255.255.252!! ! gre-config interface gre_tunnel1 tunnel mode ip tunnel source ipv4 10.123.117.233 tunnel destination ipv4 10.123.112.249 tunnel keepalive 10 3 tunnel vrfname uniwap! GGSN#2.Query interface and sub-interface configurations. GRE configurations involve PFU interfaces, sub-interfaces and loopback interfaces. You can run the show running-config-interface command to query interface and sub-interface configurations. After you run the command of querying PFU physical interfaces, the command result is shown as follows: GGSN#show running-config-interface xgei-0/1/1/1! interface xgei-0/1/1/1 description GI no shutdown interface mac-address offset 32!! After you run the command of querying PFU sub-interfaces, the command result is shown as follows:GGSN#show running-config-interface xgei-0/1/1/1.10! interface xgei-0/1/1/1.10 description uniwap interface mac-address offset 32 ip vrf forwarding uniwap ip address 10.241.157.102 255.255.255.252!! ! vlan-configuration interface xgei-0/1/1/1.10 encapsulation-dot1q 10! GGSN#After you run the command of querying loopback interfaces, the command result is shown as follows:GGSN#show running-config-interface loopback6! interface loopback6 description GRE ip vrf forwarding uniwap ip address 10.123.117.233 255.255.255.255 ip address 10.123.117.234 255.255.255.255 secondary ip address 172.16.77.85 255.255.255.255 secondary ip address 10.123.172.9 255.255.255.255 secondary!! 3.Query routes. Run the show ip forwarding route command to query routes. Make sure that you have entered the correct VRF name. GGSN#show ip forwarding route vrf uniwapIPv4 Routing Table:status codes: *valid, >best Dest Gw Interface Owner Pri Metric*> 0.0.0.0/0 172.16.78.85 gre_tunnel1 static 1 0*> 0.0.0.0/0 172.16.78.105 gre_tunnel2 static 1 0GGSN#Detecting the Tunnel StatusIf the GRE tunnel has been enabled with the keep-alive function, you can query the GRE interface status directly to query whether the tunnel status is normal. If both the interface and the protocol are in up status, it indicates that the GRE tunnel is normal. The query results are shown as follows: GGSN#show interface gre_tunnel1gre_tunnel1 is up, line protocol is up Description is none Hardware is Gre Tunnel Internet address is 172.16.78.85/30 IP MTU 1472 bytes BW 10000000 Kbits There is no statistic about this interface!GGSN#If the keep-alive function is not enabled, run the ping command to test whether network communication between the GGSN and the opposite router is normal. Usually you need to perform two ping tests: In the ping test, set the destination address to the local-end tunnel address and set the VRF to the VRF where the tunnels outbound route passes the PFU interface/sub-interface. If no packet is discarded, it indicates that the network between the GGSN and the opposite router is normal. GGSN#ping vrf uniwap 10.123.112.249 source 10.123.117.233sending 5,100-byte ICMP echoes to 10.123.112.249,timeout is 2 seconds.!!!!!Success rate is 100 percent(5/5),round-trip min/avg/max= 3/3/3 ms.Or, in the ping test, set the destination address to the opposite-end tunnel interface, set the source address to the local-end tunnel interface, and set the VRF to the VRF associated with the APN. If no packet is discarded, it indicates that the GRE tunnel between the GGSN and the opposite-end router is encapsulated normally. GGSN#ping vrf uniwap 172.16.78.86 source 172.16.78.85sending 5,100-byte ICMP echoes to 172.16.78.86,timeout is 2 seconds.!!!!!Success rate is 100 percent(5/5),round-trip min/avg/max= 3/3/3 ms.The ping test function may be disabled in some enterprise networks. If you cannot ping the destination address successfully, it does not necessarily mean that the GRE tunnel is disconnected. You can activate the test SIM card and then ping the server inside the enterprise network from the terminal to make verification. Processing AlarmsAfter detecting that the GRE tunnel is in faulty status, the GGSN will report the interface DOWN alarm with the alarm code of 150101 and the alarm severity level of warning. After viewing the detailed alarm information, you will see the detailed tunnel interface name where the alarm occurs. When the GGSN detects that the GRE tunnel is down, usually one of the following three situations occurs: All routes from the GGSN to the opposite tunnel address become ineffective. For example, the static route is deleted or does not learn the OSPF route. Under this situation, you can query the GGSN route table for troubleshooting. Keep-alive detection is timed out. This situation occurs only when the keep-alive mechanism is enabled. You can perform the ping test to check whether network communication between the GGSN and the opposite router is normal. The interface that the GGSN uses as the GRE tunnels source address is down. At present, the GGSN usually uses the loopback interface as the tunnels source address and the loopback interface wont be down. This situation may occur only when the PFU interface is used as the tunnels source address.

Common Problems1.Services fail because VRF association is wrong. In the APN configuration of using a single tunnel and sharing the interface, the GRE tunnel configuration involves two different VRFs. If VRF association is wrong, services may fail. Make checks by referring to Chapter 5 Configuration Example of a Single-Tunnel Sharing a Sub-Interface. 2.Services fail because a fault occurs to the interim network. For the consideration of lower costs, some enterprises may provide only one small-scale router and then rent a dedicated line to enable the GRE tunnel with the GGSN, or even enable the GRE tunnel with the GGSN through the public network, which has very poor reliability. If a fault occurs to the interim network or the router on the enterprise side, there is no redundant link or device, so services will fail. This situation is relatively common in actual networking structures. You can perform the ping test to check whether it is a network fault with the GGSN side. After eliminating this possibility, you can report the fault to the related department of the carrier for processing. 3.Services fail because GGSN configurations are inconsistent with those on the opposite end. In GRE tunnel configurations, the two sides need to negotiate about the tunnel source address, destination address and whether to configure the KEY and keep-alive function. If configurations are inconsistent between two parties, services will fail. 1ZTE Confidential Proprietary

6 2013

Delivery Header

GRE Header

Payload