Este documento describe un error de asignación de dirección IP que ocurre debido a un tipo de protocolo de datos de paquetes (PDP) desconocido o a errores de tipo PDP en GTP_CREATE_PDP_RESPONSE. Este problema se notifica en el router de servicios de agregación de Cisco (ASR) serie 5x00 que funciona como un nodo de soporte GPRS (GGSN) de puerta de enlace.
El equipo de usuario (UE) solicita una dirección IP estática <x.x.x.x>.
El usuario dispone de asignación de dirección IP estática desde Home Location Register (HLR)/Home Subscriber Server (HSS) para un nombre de punto de acceso (APN) concreto, por lo que no se supone que se asigne al usuario final una dirección IP de forma dinámica desde GGSN.
Este error fue observado desde el suscriptor del monitor que resultó en una falla de la sesión de establecimiento:
#Monitor subscriber Imsi <> (enable options x, a, y, verbosity 4)
----------------------------------------------------------------------
Incoming Call:
----------------------------------------------------------------------
MSID/IMSI : <> Callid : <>
IMEI : <> MSISDN : <>
Username : <> SessionType : ggsn-pdp-type-ipv4
Status : Active Service Name: GGSN_SVC
Src Context : <>
----------------------------------------------------------------------
INBOUND>>>>> 21:50:38:497 Eventid:47000(3)
GTPC Rx PDU, from <IP>:34273 to <IP>:2123 (213)
TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG
(0x10) >>>1st Create PDP Request
Sequence Number:: 0x7B16 (31510)
<<<<OUTBOUND 21:50:38:501 Eventid:47001(3)
GTPC Tx PDU, from <IP>:2123 to <IP>:34273 (103)
TEID:0x179E3645, Message type: GTP_CREATE_PDP_CONTEXT_RES_MSG
(0x11) >>>1st Create PDP Response
Sequence Number:: 0x7B16 (31510)
----------------------------------------------------------------------
(Switching Trace) - New Incoming Call:
----------------------------------------------------------------------
MSID/IMSI : <> Callid : <>
IMEI : <> MSISDN : <>
Username : <> SessionType : ggsn-pdp-type-ipv4
Status : Active Service Name: GGSN_SVC
Src Context : <>
----------------------------------------------------------------------
INBOUND>>>>> 21:50:41:346 Eventid:47000(3)
GTPC Rx PDU, from <IP>:34273 to <IP>:2123 (213)
TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG
(0x10) >>>2nd PDP Request
Sequence Number:: 0x7B20 (31520)
***CONTROL*** 21:50:41:360 Eventid:10083
Sessmgr-80 Failed to allocate static IPv4 address <IP> mask 0xffffffff poolname
<Pool_name> for call (errcode=VPN_MSG_STATUS_DUPLICATE_INSTANCE)
<<<<OUTBOUND 21:50:41:363 Eventid:47001(3)
GTPC Tx PDU, from <IP>:2123 to <IP>:34273 (103)
TEID: 0x179E36C5, Message type: GTP_CREATE_PDP_CONTEXT_RES_MSG
(0x11) >>>2nd PDP Response
Sequence Number:: 0x7B20 (31520)
INBOUND>>>>> 21:58:04:155 Eventid:47000(3)
GTPC Rx PDU, from <IP>:34273 to <IP>:2123 (16)
TEID: 0x9D052050, Message type: GTP_DELETE_PDP_CONTEXT_REQ_MSG (0x14)
Sequence Number:: 0x801F (32799)
<<<<OUTBOUND 21:58:04:156 Eventid:47001(3)
GTPC Tx PDU, from <IP>:2123 to <IP>:34273 (14)
TEID: 0x179E36C5, Message type: GTP_DELETE_PDP_CONTEXT_RES_MSG (0x15)
Sequence Number:: 0x801F (32799)
***CONTROL*** 21:58:04:170 Eventid:10285
CALL STATS: msisdn <>, apn <apn_name>, imsi <>, Call-Duration(sec): 443
input pkts: 7 output pkts: 19
input bytes: 301 output bytes: 928
input bytes dropped: 0 output bytes dropped: 0
input pkts dropped: 0 output pkts dropped: 0
pk rate from user(bps): 0 pk rate to user(bps): 53
ave rate from user(bps): 0 ave rate to user(bps): 26
sust rate from user(bps): 0 sust rate to user(bps): 27
pk rate from user(pps): 0 pk rate to user(pps): 0
ave rate from user(pps): 0 ave rate to user(pps): 0
sust rate from user(pps): 0 sust rate to user(pps): 0
link online/active percent: 100
ipv4 bad hdr: 0 ipv4 ttl exceeded: 0
ipv4 fragments sent: 0 ipv4 could not fragment: 0
ipv4 input acl drop: 0 ipv4 output acl drop: 0
ipv4 bad length trim: 0
ipv4 input non-mip drop: 0 ipv4 output non-mip drop: 0
ipv4 input css drop: 0 ipv4 output css drop: 0
output gre xoff pkts drop: 0 output gre xoff bytes drop: 0
ipv4 output no-flow drop: 0
ipv4 source violations: 0 ipv4 early pdu drop: 0
ipv4 proxy-dns redirect: 0 ipv4 proxy-dns pass-thru: 0
ipv4 proxy-dns drop: 0 ipv4 proxy-dns redirect tcp connection: 0
ipv6 bad hdr: 0 ipv6 bad length trim: 0
ip source violation no acct: 0 ip source violation ignored: 0
dlnk pkts exceeded bw: 0 dlnk pkts violated bw: 0
uplnk pkts exceeded bw: 0 uplnk pkts violated bw: 0
Disconnect Reason: Remote-disconnect
Last Progress State: PDP-Type-IPv4-Connected
Cuando se produjo el error "Error al asignar la dirección IPv4 estática <x.x.x.x> máscara 0xffffffffffff nombre de conjunto <pool_name > para la llamada (errcode=VPN_MSG_STATUS_DUPLICATE_INSTANCE)" y la creación de la sesión falló, no había ninguna estación móvil (MS)/UE asignada con la misma dirección IP. Esto se verificó con el comando show subscribers ip-address <x.x.x.x>.
[local]ASR5x00#show subscribers ip-address
No subscribers match the specified criteria
Para cada PDP de creación exitosa para el mismo usuario, la salida del comando show subscriber ip-address <x.x.x.x> muestra que la IP x.x.x.x se mapeó con la misma identidad de suscriptor móvil internacional (IMSI).
[local]ASR5x00# show subscribers ip-address
Sunday October 12 21:51:36 PDT 2014
+-----Access (S) - pdsn-simple-ip (M) - pdsn-mobile-ip (H) - ha-mobile-ip
| Type: (P) - ggsn-pdp-type-ppp (h) - ha-ipsec (N) - lns-l2tp
| (I) - ggsn-pdp-type-ipv4 (A) - asngw-simple-ip (G) - IPSG
| (V) - ggsn-pdp-type-ipv6 (B) - asngw-mobile-ip (C) - cscf-sip
| (z) - ggsn-pdp-type-ipv4v6
| (R) - sgw-gtp-ipv4 (O) - sgw-gtp-ipv6 (Q) - sgw-gtp-ipv4-ipv6
| (W) - pgw-gtp-ipv4 (Y) - pgw-gtp-ipv6 (Z) - pgw-gtp-ipv4-ipv6
| (@) - saegw-gtp-ipv4 (#) - saegw-gtp-ipv6 ($) - saegw-gtp-ipv4-ipv6
| (p) - sgsn-pdp-type-ppp (s) - sgsn (4) - sgsn-pdp-type-ip
| (6) - sgsn-pdp-type-ipv6 (2) - sgsn-pdp-type-ipv4-ipv6
| (L) - pdif-simple-ip (K) - pdif-mobile-ip (o) - femto-ip
| (F) - standalone-fa (J) - asngw-non-anchor
| (e) - ggsn-mbms-ue (i) - asnpc (U) - pdg-ipsec-ipv4
| (E) - ha-mobile-ipv6 (T) - pdg-ssl (v) - pdg-ipsec-ipv6
| (f) - hnbgw-hnb (g) - hnbgw-iu (x) - s1-mme
| (a) - phsgw-simple-ip (b) - phsgw-mobile-ip (y) - asngw-auth-only
| (j) - phsgw-non-anchor (c) - phspc (k) - PCC
| (X) - HSGW (n) - ePDG (t) - henbgw-ue
| (m) - henbgw-sg
| (D) - bng-simple-ip (l) - pgw-pmip (u) - Unknown
|
|+----Access (X) - CDMA 1xRTT (E) - GPRS GERAN (I) - IP
|| Tech: (D) - CDMA EV-DO (U) - WCDMA UTRAN (W) - Wireless LAN
|| (A) - CDMA EV-DO REVA (G) - GPRS Other (M) - WiMax
|| (C) - CDMA Other (N) - GAN (O) - Femto IPSec
|| (P) - PDIF (S) - HSPA (L) - eHRPD
|| (T) - eUTRAN (B) - PPPoE (F) - FEMTO UTRAN
|| (H) - PHS (.) - Other/Unknown
||
||+---Call (C) - Connected (c) - Connecting
||| State: (d) - Disconnecting (u) - Unknown
||| (r) - CSCF-Registering (R) - CSCF-Registered
||| (U) - CSCF-Unregistered
|||
|||+--Access (A) - Attached (N) - Not Attached
|||| CSCF (.) - Not Applicable
|||| Status:
||||
||||+-Link (A) - Online/Active (D) - Dormant/Idle
||||| Status:
|||||
|||||+Network (I) - IP (M) - Mobile-IP (L) - L2TP
||||||Type: (P) - Proxy-Mobile-IP (i) - IP-in-IP (G) - GRE
|||||| (V) - IPv6-in-IPv4 (S) - IPSEC (C) - GTP
|||||| (A) - R4 (IP-GRE) (T) - IPv6 (u) - Unknown
|||||| (W) - PMIPv6(IPv4) (Y) - PMIPv6(IPv4+IPv6) (R) - IPv4+IPv6
|||||| (v) - PMIPv6(IPv6)
||||||
||||||
vvvvvv CALLID MSID USERNAME IP TIME-IDLE
------ -------- --------------- ---------------------- -------------------- ---------
IECNAI <> <> name@apn_name x.x.x.x 00h00m57s
De los rastros se observó que hubo un tiempo muy corto (~20 ms) entre la eliminación y la creación del PDP. Esta es la razón por la que el gateway rechazó el PDP con el código de error VPN_MSG_STATUS_DUPLICATE_INSTANCE.
Configuración de APN inicial
apn apn_name
bearer-control-mode mixed
selection-mode subscribed sent-by-ms chosen-by-sgsn
accounting-mode none
gtpp group CGF1 accounting-context <context_name>
gtpp group CGF2 accounting-context <context_name>
gtpp group CGF3 accounting-context <context_name>
gtpp group CGF4 accounting-context <context_name>
idle-timeout-activity ignore-downlink
apn-ambr rate-limit direction downlink burst-size auto-readjust
duration 1 violate-action drop
apn-ambr rate-limit direction uplink burst-size auto-readjust
duration 1 violate-action drop
ims-auth-service <service name>
timeout idle 14400
ip access-group onegas.com in
ip access-group onegas.com out
ip source-violation check drop-limit 0
ip context-name <context name>
ip address pool name <pool name>
active-charging rulebase <Rulebase>
exit
Una idea es reducir el temporizador de retención de dirección, pero el concepto de "temporizador de retención de dirección" es aplicable solamente para la asignación de direcciones IP dinámicas y no para la asignación estática.
Esto también se comprobó en el laboratorio:
[Gi](config-ctx)#
ip pool SIMPLE-POOL a.b.c.d 255.255.0.0 static address-hold-timer 100
Failure: Hold timer can not be configured for this pool
Cuando existe un intervalo de tiempo pequeño entre la solicitud de eliminación de PDP (DPR) y la solicitud de creación de PDP (CPR) para el mismo IMSI, el servidor Radius devuelve la misma dirección estática.
Cuando ASR 5x00 recibe DPR, procesa la DPR y acepta una nueva RCP, pero mientras tanto conserva la dirección IP estática y tarda algún tiempo (250 ms) en que vpnmgr libere o vacíe la dirección. Dado que la nueva RCP llega antes de que se complete este lavado, el ASR 5x00 rechaza la nueva RCP.
En este caso, el intervalo de tiempo entre la supresión del PDP y la creación del PDP es muy pequeño.
En el diagrama de captura de paquetes, puede ver que el intervalo de tiempo (mostrado en el bloque rojo) entre la eliminación de PDP y la creación de PDP es muy pequeño.
Debe esperar un retraso de 250 ms entre la eliminación y la creación para que la asignación de la dirección IP para la misma dirección sea exitosa.
Este es el requisito de diseño para la arquitectura distribuida. Vea la solución alternativa en la sección Solución para evitar cualquier impacto para la asignación de dirección estática.
Vea esta solución alternativa de configuración aplicada en el gateway.
config
context <>
ggsn-service <>
newcall duplicate-subscriber-requested-address accept
exit
Este comando habilita o deshabilita las nuevas conexiones de llamada cuando la UE no puede desconectarse correctamente de la red de datos de paquetes (PDN) empresarial antes de intentar volver a conectarse a través de otro método de acceso. Cuando está habilitado, este comando cierra la sesión anterior para aceptar la nueva conexión con la misma asignación de dirección IP.
Este comando también permite que el GGSN acepte una solicitud para una dirección de suscriptor estática, incluso si la dirección ya está siendo utilizada por otra sesión. Si esta función no está activada, se rechazará una nueva solicitud con la misma dirección IP para otra sesión.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
21-Apr-2016 |
Versión inicial |