Guest

Preview Tool

Cisco Bug: CSCun10636 - GGSN send CCR to different Peer of Mediation

Last Modified

Jan 29, 2017

Products (1)

  • Cisco ASR 5000 Series

Known Affected Releases

14.0(600)

Description (partial)

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)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.