Cisco Bug: CSCun10636 - GGSN send CCR to different Peer of Mediation
Jan 29, 2017
- Cisco ASR 5000 Series
Known Affected Releases
Symptom: here's a complain from mediation server, that the number of session in mediation is much more higher than GGSN. The reason is that in every mediation server, all of the subscriber are inside the session table. The session table is generated automatically if there's a diameter message passing through it. Our question to be answered in this SR is: why the diameter message of a subscriber exists in all mediation. currently we are using 6 mediation in XL. Let say that the CCR is sent to: <<<<OUTBOUND 19:31:59:786 Eventid:81990(5) Diameter message from 10.198.230.254:53658 to 10.198.233.39:3868 [M] Origin-Host: GGSNB01C.cgy.xl.co.id [M] Origin-Realm: cgy.xl.co.id [M] Destination-Realm: amdocs.com GGSN then receive answer from: INBOUND>>>>> 19:31:59:803 Eventid:81991(5) Diameter message from 10.198.233.39:3868 to 10.198.230.254:53658 [M] [P] Origin-Host: xtces21_ES614.amdocs.com [M] [P] Origin-Realm: amdocs.com Diameter routing table is: sessm-280 D GGSNB01C.cgy.xl xtces21_ES614.amdocs.com@ * Gyprdsur1.eli 10 86399 sessm-280 S GGSNB01C.cgy.xl *@amdocs.com * Gyprdsur1.eli 10 When this case happen, GGSN is sending CCR-U (QHT) to: <<<<OUTBOUND 19:37:06:100 Eventid:81990(5) Diameter message from 10.198.230.254:49565 to 10.198.233.42:3868 [M] Origin-Host: GGSNB01C.cgy.xl.co.id [M] Origin-Realm: cgy.xl.co.id [M] Destination-Realm: amdocs.com <<<<OUTBOUND 19:37:06:102 Eventid:81990(5) Diameter message from 10.198.230.254:59335 to 10.198.233.37:3868 [M] Origin-Host: GGSNB01C.cgy.xl.co.id [M] Origin-Realm: cgy.xl.co.id [M] Destination-Realm: amdocs.com Conditions: From Our analysis, We believe the following is the reason for messages getting distributed: 1. We have the response-timeout configured with less value, so most of the link had timeout in the past. 2. As we had timeout on those routes, the failure count of those routes increased to a considerable amount. 3. So these routes are consider as "failed route" instead of "available route". 4. When session comes up, if there are no "available route" then we will select one of the "failed route". 5. When a "failed route" is selected, we will not set the selected peer as "bound-peer". 6. When we don't set the bound-peer, the subsequent messages will also be considered for fresh route lookup. 7. So every message will undergo routing and we will select round robin routes for each one of them. increasing response-timeout will slowly reduce the route failure and routes will be considered as "available" and we will bind a session to a peer and send all messages to that peer only.
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases