Juniper Networks

Juniper Networks Confidential
J20 GGSN Configuration

1.0 Introduction
The Juniper J20 is Juniper Networks entry into the mobile space for a router which will act as a GGSN. The GGSN is responsible for terminating GTP tunnels from SGSNs(on the Gn interface), and transporting user data to the IP packet network(over the Gi interface). In addition to those functions, the GGSN is also responsible for charging and billing of user data, lawful intercept(not supported yet), and O&M of the node itself.
1.1 About this document

This document serves as a quick start guide which will allow the reader to configure and understand the configuration of the Juniper J20 router. It does not provide all possible configuration details, but just explains some of the basics needed to get the GGSN into service. Please also note that some configuration options are explicitly required due to the fact that the code is still being developed.
1.2 Terminology
APN GGSN GGSN-C GGSN-U GTP PDP SGSN Access Point Name Gateway GPRS Support Node GGSN Control PIC GGSN User(data) PIC GPRS Tunneling Protocol Packet Data Protocol Serving GPRS Support Node
2.0 Mobile Technology information

This section provides a *very* brief background on the GGSN portion of the EJN offering. For more detailed information, please read the GPRS specifications.
2.1 Hardware
The Juniper GGSN hardware is based upon the J20 chassis, and GGSN PICs (called GGSN-C and GGSN-U PICs). These are explained below.
2.2 1. J20
The J20 is an M20 chassis with a Force RE(new routing engine) and GGSN PICs. Initially, the J20 will go to market with three different packages. All packages will include
J20 GGSN Configuration November 30, 2001 1
the chassis, redundant REs, SSBs and power supplies, the main difference is in the number of service PICs installed. Typically, the GGSN-C PICs will support up to 150K PDP contexts, and the GGSN-U PIC can support about 50Kpps per PIC. For the service PICs, consider one of the GGSN-C PICs to be the "master"(which doesn't handle any PDP contexts), and an additional GGSN-C as a backup. The GGSN-U PICs will all be operational with these configurations. The customers who order these boxes must also purchase the PICs which will connect to their networks(aka: FE, GE, etc). Pkg 1-Low usage: J20 Chassis Redundant Force REs, SSBs, Power Supplies 3 GGSN-C PICs (allows 150K PDP contexts) 3 GGSN-U PICs (allows 150Kpps) Pkg 2-Med usage: J20 Chassis Redundant Force REs, SSBs, Power Supplies 5 GGSN-C PICs (allows 450K PDP contexts) 5 GGSN-U PICs (allows 250Kpps) Pkg 3-High usage: J20 Chassis Redundant Force REs, SSBs, Power Supplies 5 GGSN-C PICs (allows 450K PDP contexts) 7 GGSN-U PICs (allows 350Kpps)
2.3 GGSN-C PIC

The GGSN-C PIC is used for control plane signalling between the SGSN and the GGSN and is based upon the MIPS R7000. It also has the following configuration: 256MB SDRAM 80 MB Flash Serial Console The GGSN-C PIC runs a subset of JUNOS 5.2 on the PIC itself. The memory based filesystem divides the filesystems between the Flash and SDRAM. Since there is no hard drive, all application and data are stored in memory. Also, there is no swap partition. Multiple GGSN-C PICs are supported in the J20. When multiple GGSN-C PICs exist, one PIC is chosen as the master, and the rest of the GGSN-C PICs are either the slaves or
November 30, 2001
serve as in-box backups. The GGSN-C master is called the Node Controller, while the GGSN-C slave is called the Session Controller. 2.3.1 Load Balancing and Redundancy The GGSN-C Node Controller is responsible for load balancing GTP tunnels to the GTPC Session Controllers. The Node Controller will receive all primary PDP context messages and distribute them to the least loaded Session Controller. After this, the Session Controller is responsible for all control messages for the mobile station. The Node Controller does not actively handle any mobile stations, the purpose of the master is for loadbalancing. Keepalives are be sent every 100ms-500ms between the Session Controllers to indicate the module is active. These keepalives also contain loading information, which is how the Node Controller keeps track of loading of the Session Controller PICs. There are two types of redundancy with the GGSN-C PICs No spare redundancy(type 0): All Session Controllers are operating at maximum capacity. When the Node Controller or a Session Controller fails, a loss of capacity will occur due to the fact that we will be operating with one less PIC. N+1 Redundancy(type 1): This includes one "spare" GGSN-C PIC which can take on the role of either Node or Session Controller during a failure. Since there is a dedicated spare, there is no loss of capacity. 2.3.2 GGSN-C Node Controller election process. At startup, all GGSN-C PICs startup in supervision mode with an assigned "internal" IP address. In this phase, the GGSN-C receives the following GGSN configuration information: Maximum GGSN-C redundancy level for the node(type 0 or 1) Address range for the external IP addresses for communication towards the SGSN (including master/main IP address for GGSN Address range for the internal IP address Maximum number of active GGSN-C (implicit node capacity) Slave Radius/DHCP proxy IP address Heartbeat and master election parameters. The master election takes place at start up and a Node Controller failure. The election starts with the detection of the M-bit in initialization messages sent between GGSN-C PICs. If this bit is not seen, then there is no master. The least loaded GGSN-C which has the required Node Controller hardware version elects to be the master and sends the load information message with the PM(Proposed Master) bit set. All other active GGSN-C will accept or reject this proposition
If all active GGSN-C accept the PM, then the election is over and the new Node Controller takes over the external IP address and starts up the Node Controller application.
2.4 GGSN-U PIC

The GGSN-U PIC is responsible for all user data traffic between the SGSN and the Gi Interface. The GGSN-U PIC is based upon the MIPS R7000 and has the following configuration: 256MB SDRAM 80 MB Flash Serial Console
The GGSN-U PIC runs an embedded micro kernel and will receive most of it's direction from the GGSN-C PICs. 2.4.1 Redundancy and Load balancing The GGSN-C Node Controller distributes PDP payloads across the GGSN-U service PICs by the use of "dynamic slicing". Dynamic slicing uses an internal algorithm for breaking large IP address ranges into smaller slices. The Node Controller then directs traffic for these slices into the least loaded GGSN-U PIC. NOTE: The Node Controller learns the loading information as the GGSN-U periodically sends internal broadcast keepalives to the Node Controller containing the number of PDP contexts. Because Node Controller distributes the load, if a GGSN-U PIC goes down, Node Controller can just redistribute those PDP contexts elsewhere. If "minimum number of GGSN-U PICs" is configured, and the number of GGSN-U PICs in the J20 is greater than the configured number, then the extra PICs will be used as in box spares coming online as needed. If an outage does occur, the Node Controller redirects traffic using the following process: 1) Node Controller assigns spare GGSN-U with failed external IP address 2) Node Controller notifies Session Controller to update the GGSN-U spare 3) Session Controller sends PDP context data to the GGSN-U spare 4) Node Controller updates the RE with routing information of the spare GTP-U
2.5 GGSN Software

The standard JUNOS does will not operate the GGSN PICs. If GGSN software is desired, the user must load a jbundle with a -ggsn extension in the name. There are several new daemons which are needed to facilitate communication between the Routing Engine(RE) and the GGSN Pics. Most of the daemons are started from init upon startup. Currently, their order of startup from init is:
November 30, 2001
fsad serviced irsd rtspd
These daemons communicate with the service PICs using an internal routing instance called __juniper_private1__. This algorithm is used when assigning IP addresses to the PICs to ensure each IP address is unique within the __juniper_private1__ VPN. The IP address algorithm is below: RE address = 10.0.0.1 GGSN-C or GGSN-U PIC address = 10.0.0.x where:
x = 16 * (1 + FPC-slot) + PIC-slot Example: gc-0/0/0 = 10.0.0.16 gc-0/1/0 = 10.0.0.17
2.6 New Daemons on the Routing Engine

2.6.1 FSAD - File System Access daemon FSAD provides a simplified way for storage and cache management to be used by service PIC applications. FSAD is started from init and runs on the RE and is tied into the service PIC management routing instance and provides for remote caching and bulk logging of call data records. 2.6.2 Serviced This is a daemon which is an interface between the existing JUNOS UI complex and the Mint service PICs. Serviced provides command routing and configuration check/commitnotification to remote applications running on Mint PICs. Commands are entered at the CLI, then passed to MGD, MGD passes the GGSN commands directly to Serviced which passes the command to the appropriate remote daemon. There is no configuration needed to enable serviced. 2.6.3 RTSPD - Routing Socket Proxy Daemon When new IFLs and IFFs are created by RPD on the RE, this state needs to be passed to the PIC as well. RTSPD is used for syncing state between the kernel and the GGSN pics. Typically, this is type of thing is done by RDP or TNP, in this case, the exchange of messages is done by TCP.
November 30, 2001
2.6.4 IRSD - Internal Routing Service Daemon Facilitates the communication of the kernel and applications on GGSN PICs with the kernel and applications on the other GGSN PICs and the RE on the same box. IRSD runs from /usr/sbin and logs to the RE on /var/log. IRSD is started automatically with the GGSN code and has no configuration syntax. In addition: IRSD uses the internal VPN for communication All nodes (RE, Service PICs) are members of the internal VPN IRSD is responsible for setup of each node IRSD creates logical interfaces and routes for each node When a node is removed, interfaces and routes are removed from internal VPN 2.6.5 IRSD Server(GGIFD) : Daemon on RE(server) which allows applications running on GGSN PICs to discover changes in hardware state and the application state of peer GGSN pics. IRSD Server is located in /usr/sbin on the RE and logs to /var/log. IRSD server uses the same hardware state detection process employed by IRSD. IRSD server starts as part of IRSD daemon via init and listens to TCP port 6222 on the internal routing instance.
2.7 Clients which run on the GGSN PICs

The GGSN-C PICs have their own micro kernel and daemons. This GGSN-C kernel is ported from FreeBSD 4.2. There are some details to the code running on the GGSN-C PICs which might be useful for the users: No swap device: The GGSN PICs have no swap device. As such, they have all paging and swapping turned off in the kernel. The GGSN-C PICs make use of a memory file system. There is no hard drive on the PICs, so PIC coredumps must uploaded to the RE The following GGSN specific daemons are started from init on the PICs: RTSPC PCD (possibly running under PWC) GTCPD (possibly running under PWC) 2.7.1 RTSPC - Routing Socket Proxy Client The client program on service C-PICs which connects to RTSPD in order to receive IFL and IFF state information which is injected into the PIC kernel. Function: RTSPC connects to 10.0.0.1(RE) port 6152 over __juniper_private1__ routing-instance
Sends RTSPD resync messages with type of message it is interested in(eg: IFL message or IFF message). 2.7.2 PCD - PIC Control Daemon PCD provides basic UI support to diagnostic users that can be accessed via CLI and JUNOScript. PCD has no configuration and is run from /usr/sbin on the PIC. NOTE: All PCD commands are hidden and used for diagnosing problems on the GGSN PICs. 2.7.3 PWC - PIC Process Watcher PWC functionality was included in controld/pcd earlier, but was separated due to some usage issues. PWC can be used to watch both PCD and GTPCD daemons. If either of the daemons running under PWC do not write to stdout for some period of time, the process will be sent a SIGABRT, then a SIGKILL. The PWC command line has three arguments followed by the daemon(eg: PCD)command line. startup wait - time allowed for daemon startup (in ms) run wait - time allowed between writes to stdout (in ms) kill wait - time allowed to shutdown following a SIGABRT (in ms) A command for PWC may be: command "/usr/sbin/pwc 5000 2000 2000 /usr/sbin/gtpcd -N";
3.0 How it all comes together

This section gives a brief flow of operations when a new PDP context is added. Starting point, GGSN operational, no PDP contexts are activated SGSN sends PDP Context Activation create request to Juniper GGSN Activation request received by the GGSN-C Node Controller. Gn side IP addresses are dynamically assigned for the GGSN-C Session Controllers and the GGSN-U PICs with Next-Hop pointing to the service PICs. These routes are placed in the VRF associated with the Gn interface. Node Controller passes activation request off to Session Controller Session Controller looks at APN configuration and decides steps needed for IP address assignment for MS (i.e.: if static, MS should already have an address so no work needs to be done, if DHCP, then request address from DHCP server, etc.). When the MS IP address is allocated, the route is added for the MS into the VRF specified by the APN configuration. The next-hop is pointing to a logical interface on the GGSN-U PIC. Session Controller sends PDP Context Activation accepted message to SGSN.
4.0 Configuration Example

This configuration example was taken from one of the Juniper System-test lab routers. The are two diagrams shown below. The first would be the actual physical cabling of the GGSN node, while the second is the logical configuration of the node displaying the configured VRFs, overlapping IP addresses, multiple OSPF instances, etc.
FIGURE 1. Physical topology of Genesis (J20)
FIGURE 2. Logical topology map of Genesis (J20)
November 30, 2001
4.1 J20 GGSN Configuration

Descriptions of the entire J20 configuration are not included below. This portion of the configuration only focuses on the VPN(routing-instance) and Services->GGSN content. The interface blocks are included to show how they relate to the VPN configurations as well as displaying the service PIC configuration.
interfaces { ge-0/0/0 { vlan-tagging; unit 0 { vlan-id 0; family inet { address 172.78.1.1/24; } } unit 1 { vlan-id 1; family inet { address 172.10.1.1/24; } family mpls; } unit 2 { vlan-id 2; family inet { address 172.10.2.1/24; } family mpls; } } gr-0/1/0 { unit 1 { tunnel { source 172.10.1.1; destination 172.10.1.2; routing-instance { destination vrfgi1; } } family inet {
November 30, 2001
address 172.10.3.1/24; } family mpls; } unit 2 { tunnel { source 172.10.2.1; destination 172.10.2.2; routing-instance { destination vrfgi2; } } family inet { address 172.10.4.1/24; } family mpls; } } ip-0/1/0 { unit 1 { tunnel { source 172.10.1.1; destination 172.10.1.2; routing-instance { destination vrfgi1; } } family inet { address 172.10.5.1/24; } family mpls; } unit 2 { tunnel { source 172.10.2.1; destination 172.10.2.2; routing-instance { destination vrfgi2; } } family inet {
address 172.10.6.1/24; } family mpls; } } fe-0/2/0 { unit 0 { family inet { address 172.7.173.1/24; } family mpls; } } fe-0/2/1 { unit 0 { family inet { address 172.8.174.1/24; } family mpls; } } at-0/3/0 { atm-options { vpi 0 maximum-vcs 100; } unit 41 { point-to-point; vci 0.41; family inet { address 172.10.7.1/24; } family mpls; } unit 42 { point-to-point; vci 0.42; family inet { address 172.10.8.1/24; } family mpls; }
Below is the interface designation for the GGSN Service PICs. The GGSN-C PIC names take the form of gc-x/y/c, and the GGSN-U PICs take the form of gu-x/y/z. The bootstring is necessary today, but this will not be needed at some point in the future.
gc-1/0/0 { ggsn-options { boot-string ggsnc.jbf; } } gc-1/1/0 { ggsn-options { boot-string ggsnc.jbf; } } gu-1/2/0 { ggsn-options { boot-string ggsnu.jbf; } } fxp0 { unit 0 { family inet { address 192.168.14.42/24; } } } lo0 { unit 0 { family inet { address 10.255.14.42/32; address 127.0.0.1/32; } } } } routing-options { static { route 0.0.0.0/0 { discard; retain;
November 30, 2001
12
no-readvertise; } route 172.17.0.0/16 { next-hop 192.168.14.254; retain; no-readvertise; } route 192.168.0.0/21 { next-hop 192.168.14.254; retain; no-readvertise; } route 10.255.0.0/16 next-hop 192.168.14.254; route 172.7.250.0/24 next-hop 172.7.173.2; route 172.7.251.0/24 next-hop 172.8.174.2; } }
MPLS is required for interfaces which are included in an instance-type vrf. This is the quick method of turning MPLS on for these interfaces, instead of listing each interface individually.
protocols { mpls { interface all; } }
Both of the policies defined below are referenced within the configured routing-instances.
policy-options { policy-statement dummy { then reject; } policy-statement from-static { term 1 { from protocol static; then { metric 20; external { type 1; } accept; }
} } }
The next several configuration blocks are for the VRF instances on the Gi interface. The examples below show overlapping AS space as well as multiple OSPF Area 0.0.0.0 areas. Also note that the vrf-import and vrf-export policies dummy are included. The policy dummy just makes sure that if there was a PE-PE BGP session configured in the global BGP area above, no routes would be announced to or from this particular VRF.
routing-instances { vrfgi1 { instance-type vrf; interface ge-0/0/0.1; route-distinguisher 1:1; vrf-import dummy; vrf-export dummy; routing-options { static { route 172.7.183.0/24 next-hop 172.10.1.2; } } } vrfgi2 { instance-type vrf; interface ge-0/0/0.2; route-distinguisher 1:2; vrf-import dummy; vrf-export dummy; protocols { ospf { export from-static; area 0.0.0.0 { interface ge-0/0/0.2; } } } } vrfgi3 { instance-type vrf; interface gr-0/1/0.1; route-distinguisher 1:3; vrf-import dummy;
vrf-export dummy; protocols { bgp { export from-static; local-as 65001; group g1 { type external; peer-as 65002; neighbor 172.10.3.2; } } } } vrfgi4 { instance-type vrf; interface gr-0/1/0.2; route-distinguisher 1:4; vrf-import dummy; vrf-export dummy; protocols { ospf { export from-static; area 0.0.0.0 { interface gr-0/1/0.2; } } } } vrfgi5 { instance-type vrf; interface ip-0/1/0.1; route-distinguisher 1:5; vrf-import dummy; vrf-export dummy; protocols { bgp { local-as 65001; group g1 { type external; peer-as 65002; neighbor 172.10.5.2 {
export from-static; } } } } } vrfgi6 { instance-type vrf; interface ip-0/1/0.2; route-distinguisher 1:6; vrf-import dummy; vrf-export dummy; protocols { ospf { export from-static; area 0.0.0.0 { interface ip-0/1/0.2; } } } } vrfgi7 { instance-type vrf; interface at-0/3/0.41; route-distinguisher 1:7; vrf-import dummy; vrf-export dummy; protocols { bgp { local-as 65001; group g1 { type external; peer-as 65002; neighbor 172.10.7.2 { export from-static; } } } } } vrfgi8 {
instance-type vrf; interface at-0/3/0.42; route-distinguisher 1:8; vrf-import dummy; vrf-export dummy; protocols { ospf { export from-static; area 0.0.0.0 { interface at-0/3/0.42; } } } } }
Most of the configuration above was mainly regular JUNOS configuration. The services section of the configuration is where the GGSN information is configured. This configuration allows the creation of new PDP contexts with the creation unblocked line. If maintenance were going to occur on the router in a few hours, this may be changed to creation blocked to stop new PDP contexts from being created, while letting existing PDP contexts expire naturally. The configuration also limits the maximum number of PDP contexts for 450,000, while reserving 10% of these for secondary PDP contexts. The gomrouting-instance configuration is mandatory, and will be used for O&M functions in the future, but is not in use at this time. Also, if a PDP context is idle for 30 minutes(denoted by idle-timeout 30) , then the PDP context will be deleted due to the idle-supervision flag being turned on.
services { ggsn { gom-routing-instance inet.0; pdp-context { idle-supervision; idle-timeout 30; node { creation unblocked; limit 450000; secondary-ratio 10; } }
The configuration of the GGSN-C PICs in the system is next. Again, the gom-addressrange is a requirement, but not used, while the gn-address-range is used for the dynamic assignment of addresses for the Gn interface of the GGSN-C PICs. The GGSN-C PICs
are configured without redundancy with arrangement no-spare , so one GGSN-C PIC will be elected the master, and the rest of the PICs will be acting as slaves. If arrangement spare were configured, then at least one GGSN-C PIC would be reserved as a spare assuming we had more than 2 GGSN-U PICs in the router. The configuration minimumpic 2 determines at what level redundancy occurs with respect to the number of PICs in the router. If minimum-pic was set to 5, arrangement spare was configured, and we had 7 total GGSN-C PICs, the breakdown of PICs would be: 1 GTP-C/m, 4 GTP-C/s, and two backup GGSN-C PICs which could function as either GTP-C/m or GTP-C/s.
ggsnc { gn-address-range 172.7.200.1/24; gom-address-range 172.7.200.1/24; redundancy { arrangement no-spare; minimum-pic 2; } }
The configuration options are the same for the GGSN-U PIC as they with the GGSN-C PIC
ggsnu { gn-address-range 172.7.201.1/24; gom-address-range 172.7.201.1/24; redundancy { arrangement no-spare; minimum-pic 2; } }
The GTP protocol block is next. This set of configuration statements define the protocol settings between the SGSN and GGSN. The GTP tunnels are setup with a diffserv class of be and use inet.0 is the routing instance. n3-requests sets the maximum number of attempts to send a request message to 3, and t3-response time sets the maximum wait for a response to a message.
gtp { keepalive-interval 60; t3-response-time 5; n3-requests 3; diffserv be; no-path-management; gn-routing-instance inet.0; version-list [ 97 98 99 ]; }
November 30, 2001
18
The election and heartbeat values below are required for gtpcd at this moment. In a future release, we will no longer need these two configuration blocks.
election { interval 100; timeout 1000; } heartbeat { interval 200; timeout 800; damping 1000; threshold 200; }
Charging consists of Call Data Records(CDRs) which are compiled from usage information sent from the GGSN-U PICs, to the GGSN-C Session Controller PICs. The Routing Engine will then pull the CDRs from the Session Controller PICs and store the data on the local hard drive to be archived at a remote host in the future. In the configuration below, the user may require the charging function to have a separate node name from the hostname of the router, so the node name should be specified here. The transfer-type is via ftp is where the CDRs are queued on the RE, then the billing gateway will pull the files down. The format is based upon the R99 spec. The characteristics section details GGSN-C PIC behavior. call-detail is a default parameter which just tells the GGSN-C PIC to generate records. The time limit is the amount of time which call detail buffering should occur on the C-PIC before the records are uploaded to the RE.
charging { node genesis; transfer-type ftp-pull; charging-format 99; characteristics { default-characteristics { time-limit 1000; call-detail; change-limit 5; } } }
APN configuration is listed below. All of the APNs listed below are configured for accesstype public . This means the APN is working in transparent mode. The transparent mode of an APN is one where the GGSN is providing basic internet service to the mobile station. If the access-type were configured as restricted, then the APN would be in non-transparent mode and would forward link requests to a private server on an intranet perhaps.
Each of the APNs below are also configured to use a particular VRF(routing-instance) for their forwarding table. The PDP contexts are configured for the APN to accept new PDP context attempts, and the IP address of the mobile station is statically defined by the mobile provider. The gi-address-range statement configures the Gi side IP addresses for the Session Control PICs
apn { apn1.com { access-type public; routing-instance vrfgi1.inet.0; gi-address-range 172.7.1.0/24; pdp-context { creation unblocked; address-allocation static; } addressing { 10.1.0.0/16 allocation-prefix 16; } } apn2.com { access-type public; routing-instance vrfgi2.inet.0; gi-address-range 172.7.2.0/24; pdp-context { creation unblocked; address-allocation static; } addressing { 10.1.0.0/16 allocation-prefix 16; } } apn0.com { access-type public; routing-instance inet.0; gi-address-range 172.7.220.0/24; pdp-context { creation unblocked; address-allocation static; } addressing { 10.1.0.0/16; }
November 30, 2001
20
} apn3.com { access-type public; routing-instance vrfgi3.inet.0; gi-address-range 172.7.3.0/24; pdp-context { creation unblocked; address-allocation static; } addressing { 10.1.0.0/16 allocation-prefix 16; } } apn4.com { access-type public; routing-instance vrfgi4.inet.0; gi-address-range 172.7.4.0/24; pdp-context { creation unblocked; address-allocation static; } addressing { 10.1.0.0/16 allocation-prefix 16; } } apn5.com { access-type public; routing-instance vrfgi5.inet.0; gi-address-range 172.7.5.0/24; pdp-context { creation unblocked; address-allocation static; } addressing { 10.1.0.0/16 allocation-prefix 16; } } apn6.com { access-type public; routing-instance vrfgi6.inet.0; gi-address-range 172.7.6.0/24;
pdp-context { creation unblocked; address-allocation static; } addressing { 10.1.0.0/16 allocation-prefix 16; } } apn7.com { access-type public; routing-instance vrfgi7.inet.0; gi-address-range 172.7.7.0/24; pdp-context { creation unblocked; address-allocation static; } addressing { 10.1.0.0/16 allocation-prefix 16; } } apn8.com { access-type public; routing-instance vrfgi8.inet.0; gi-address-range 172.7.8.0/24; pdp-context { creation unblocked; address-allocation static; } addressing { 10.1.0.0/16 allocation-prefix 16; } } } }
4.2 Routing Table Output

Using the configuration above, 6 PDP Contexts were sent from the SGSN simulator. All connections were to connect to apn1.com and the IP addresses were statically configured. Below is some sample routing-output:
November 30, 2001
22
This is the __juniper_private1__ vrf. This is the internal VPN used for internal communication between the RE and GGSN Service PICs. Note: If problems are occurring on the GGSN node, make sure all GGSN PIC routes and the RE route are listed within this VRF.
__juniper_private1__.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.1/32 10.0.0.32/32 10.0.0.33/32 10.0.0.34/32 10.0.0.48/32 10.0.0.49/32 10.0.0.50/32 *[Local/0] 2d 08:07:34 Local *[Direct/0] 2d 05:37:02 *[Direct/0] 2d 05:36:54 *[Direct/0] 1d 07:57:20 *[Direct/0] 2d 05:36:47 *[Direct/0] 1d 08:38:30 *[Direct/0] 1d 08:38:36 > via gc-1/0/0.0 > via gc-1/1/0.0 > via gu-1/2/0.0 > via gc-2/0/0.0 > via gu-2/1/0.0 > via gu-2/2/0.0
This is the routing-instance which is used for the GTP tunnels to the SGSN. The addresses for the GGSN-C and GGSN-U PICs were allocated dynamically based upon the address range given in the ggsnc and ggsnu blocks.
vrfgn.inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.7.63.0/24 172.7.63.1/32 172.7.200.1/32 172.7.200.2/32 172.7.200.3/32 172.7.201.1/32 172.7.201.2/32 *[Direct/0] 2d 05:37:05 *[Local/0] 2d 05:37:06 Local via ge-3/1/0.0 *[Static/1] 07:09:09 *[Static/1] 07:09:09 *[Static/1] 07:09:07 *[Static/1] 07:09:09 *[Static/1] 07:09:09 > via gc-1/0/0.32769 > via gc-1/1/0.32772 > via gc-2/0/0.32774 > via gu-2/2/0.32770
> via ge-3/1/0.0
November 30, 2001
23
> via gu-2/1/0.32771 172.7.201.3/32 172.8.0.0/16 172.10.250.0/24 172.10.250.1/32 *[Static/1] 07:09:09 *[Static/5] 06:03:54 *[Direct/0] 06:03:54 *[Local/0] 07:44:50 > via gu-1/2/0.32773 > to 172.10.250.2 via ge-0/0/0.250 > via ge-0/0/0.250 Local via ge-0/0/0.250
Now the output for the apn1.com VRF. Below are the routes for the PDP contexts(in the 10.10.1.0/24) range with the next-hops pointing to a logical interface on the GGSN-U PICs. Also included are the routes to the PICs serving the Session Control function.
vrfgi1.inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.1.1/32 10.10.1.2/32 10.10.1.3/32 10.10.1.4/32 10.10.1.5/32 10.10.1.6/32 172.7.1.1/32 172.7.1.2/32 172.7.183.0/24 172.7.183.1/32 172.8.0.0/16 172.10.1.0/24 *[Static/1] 07:06:27 *[Static/1] 07:06:18 *[Static/1] 07:06:10 *[Static/1] 07:06:01 *[Static/1] 07:05:54 *[Static/1] 07:05:45 *[Static/1] 07:06:18 *[Static/1] 07:06:27 *[Direct/0] 1d 09:07:33 *[Local/0] 1d 09:07:33 *[Static/5] 06:03:54 *[Direct/0] 06:03:54
> via gu-1/2/0.32776 > via gu-2/1/0.32778 > via gu-2/2/0.32779 > via gu-1/2/0.32776 > via gu-2/1/0.32778 > via gu-2/2/0.32779 > via gc-1/1/0.32777 > via gc-2/0/0.32775 > via fe-0/2/1.0 Local via fe-0/2/1.0 > to 172.10.1.2 via ge-0/0/0.1 > via ge-0/0/0.1
November 30, 2001
24
172.10.1.1/32 172.11.1.0/24 172.11.1.1/32 172.12.0.0/16
*[Local/0] 2d 05:37:06 Local via ge-0/0/0.1 *[Direct/0] 2d 05:37:05 *[Local/0] 2d 05:37:06 *[Static/5] 06:03:54
> via ge-3/0/0.1 Local via ge-3/0/0.1 > to 172.10.1.2 via ge-0/0/0.1
November 30, 2001
25

Juniper Networks

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Juniper Networks

Загружено:

Авторское право:

Доступные форматы

Juniper Networks Confidential

J20 GGSN Configuration

1.1 About this document

2.0 Mobile Technology information