Cellular Network Infrastructure » Core Network (CN) » OsmoSTP

From IRC:

01:43 < neeels> 20190313014039861 DLSS7 INFO asp-asp-dyn-16: RKM: Registering routing key 4 for DPC 0.23.3 (xua_rkm.c:197)
01:43 < neeels> 20190313014039862 DLSS7 NOTICE asp-asp-dyn-16: RKM: Found existing AS for RCTX 4 (xua_rkm.c:215)
01:43 < neeels> 20190313014039862 DLSS7 NOTICE asp-asp-dyn-16: RKM: DPC doesn't match (2236 != 187) (xua_rkm.c:218)
01:44 < neeels> If I configure one of the two with a different routing key, both can connect.

07:31 <@LaF0rge> neeels: routing keys are at the M3UA/SIGTRAN level. Point codes at the MTP level and SCCP addresses at the SCCP level.  And every protocol level neds unique identifiers.
07:32 <@LaF0rge> neeels: however, in the pcap files you shared with me around last midnignt, the  different BSCs were indeed using different routing keys
07:40 <@LaF0rge> neeels: two M3UA connections with the same routing key *intentionally* map to the same AS. This is used for round-robin/load-sharing setups or alternatively, depending on the traffic mode, for fail-over

The interesting bit here is why, when using dynamic routing key registration, both BSCs would get the same routing key. That would clearly be a bug. The entire point of dynamic registration is to avoid any "a priori" manual configuration of settings like routing keys on all related systems. That's what the "RKM" (routing key management) sub-system of SIGTRAN/M3UA is all about.

If you look at the attached pcap file and specifically look for the "RKM" messages "m3ua.message_class == 9", then you will see:

• system with point code 188 registers for hard coded routing context 4
• system with point code 185 registers for routing context 0 (dynamic) and gets allocated 2
• system with point code 189 registers for routing context 0 (dynamic) and gets allocated 3
• system with point code 187 registers for hard coded routing context 4
• system with point code 188 registers for hard coded routing context 4

So somehow, some of the M3UA clients use overlapping statically-configured routing keys while others do the right thing and ask the STP to allocate one dynamically. This could either be a configuration mistake, or it could be bugs in the respective code base. *