SUMMARY STEPS
1. enable
2. configure terminal
3. ip slb vserver virtual-server
4. virtual ip-address [netmask [group]] {esp | gre | protocol} or virtual ip-address [netmask [group]] {tcp | udp} [port | any] [service service] or virtual ip-address [netmask [group]] [ipv6 ipv6-address [prefix ipv6-prefix]] {tcp | udp} [port | any] [service service]
5. serverfarm primary-farm [backup backup-farm [sticky] | [map map-id priority priority]] or serverfarm [primary-farm [backup backup-farm ]] [[ipv6-primary ipv6-primary-farm [ipv6-backup ipv6-backup-farm]]] [map map-id priority priority]
6. access interface [route framed-ip]
7. advertise [active]
8. client {ip-address netmask [exclude] | gtp carrier-code [code]}
9. delay {duration | radius framed-ip duration}
10. gtp notification cac [reassign-count]
11. gtp session
12. hand-off radius duration
13. idle [asn request duration | asn msid msid | gtp imsi duration [query [max-queries]] | gtp request duration | ipmobile request duration| radius {request | framed-ip} duration]
14. replicate casa listen-ip remote-ip port [interval] [password [encrypt] secret-string timeout]
15. replicate interval interval
16. replicate slave
17. sticky {duration [group group-id] [netmask netmask] | asn msid [group group-id] | gtp imsi [group group-id] | radius calling-station-id | radius framed-ip [group group-id] | radius username [msid-cisco] [group group-id]}
18. synguard syn-count interval
19. inservice [standby group-name] [active]
Troubleshooting GTP-SLB IPv6 Support Configuration
This section describes how to troubleshoot GTP-SLB IPv6 support configuration. These are some troubleshooting scenarios:
- Unable to configure least connections attribute(Leastconns) on GTP-SLB.
Leastconns is not supported on GTP-SLB as the loadbalancer does not track the number of open PDP sessions in a real server. SLB only load balances the create PDP requests and maintains a session object for each PDP request to ensure request retransmissions are delivered to the assigned real server.
- The IOS SLB sticky connections are not functioning as expected.
Complete these steps to verify a valid sticky connection:
– Reconfigure all the sticky connections.
– Start a client connection.
– Run the show ip slb reals detail and show ip slb conns commands.
– Check the real server connection counts. Note that the new client connection is assigned to the real server with increased counts.
– Run the show ip slb sticky command to display the sticky relationships stored by IOS SLB.
– Terminate the connection.
– Check if the real server connection decreased by a single count.
– Restart the connection within the sticky timeout value.
– Run the show ip slb conns command.
– Check the real server connection count again and verify that the sticky connection is assigned to the same real server.
- Server failures are not detected correctly.
Complete these steps to check the servers:
– Check if the number of clients is very less, reduce the numclients value on the faildetect numconns (real server) to an optimum value.
– Run the show ip slb reals detail command to view the status of the real servers.
– Check the status and connection counts of the real servers. A failed server shows one of the following statuses: FAILED, TESTING, or READY_TO_TEST.
Note When a real server fails, connections that are assigned but not established (no SYN or ACK is received) are reassigned to another real server on the first inbound SYN after the reassign threshold. However, connections already established to a real server are forwarded to the same real server.
Note For weighted least connections, a new real server starts slowly so that it is not overloaded with new connections. (See the Slow Start section for more information.) The connection count also show dummy connections on the new real server, which IOS SLB uses to artificially inflate the connection counts for the real server during the slow start period.
- There is no improvement in failure detection when both faildetect inband and Internet Control Message Protocol (ICMP) probes are configured on a real server.
When a real server is configured with both the ICMP probes and faildetect inband, the faildetect takes precendence. The ICMP probes are health probes, the state of the ICMP probes remain OPERATIONAL as long as the physical interfaces of a real server are accessible. The faildetectinband detects the failure of an application serving a client request on a real server. The ICMP probes transit states when a physical interface failure occurs. It is recommended to have either an ICMP probe or faildetect enabled for real server failure detection.
- The no inservice command does not disable a resource immediately
The no inservice command allows the connection to complete the process before disabling the resource. To stop all the existing connections for an entire firewall farm or virtual server immediately, use the clear ip slb connections command.
- The vserver status, active or standby chassis, configured with GTPLB and HSRP is shown for both the chassis. At an instance both the chasis are shown as active or standby.
Check the configuration for these issues:
– HSRP interface should be configured with a unique group number if more than one HSRP instances are configured.
– HSRP group name is casesensitive and should be unique.
- You can load-balance a packet through layer 3 and non-layer 2 adjacent connections in the Nat server serverfarm configuration.
- Dispatched mode does not function in the GGSN(PGW).
Verify that the GGSN is configured with the VIP address as the loopback.
- Notification messages do not reach the SLB in directed mode
Verify that the virtual server address with next hop IP address is configured on the gateway.
- Unable to allocate the MS address, though the address pool is configured in GGSN.
The address specified while creating the PDP request from SGPRS might not match the address in the pool defined.