Aller au contenu principal

Guide de Configuration M3UA & M2PA STP

← Retour à la Documentation Principale

Ce guide fournit des instructions détaillées pour utiliser OmniSS7 en tant que Point de Transfert de Signalisation (STP).

Table des Matières​

  1. Qu'est-ce qu'un STP ?
  2. Rôles Réseau STP
  3. Interface avec les Réseaux TDM
  4. Activation du Mode STP
  5. Configuration des Pairs
  6. Support du Protocole M2PA
  7. Routage par Code de Point
  8. Routage par Titre Global
  9. Fonctionnalités de Gestion des Routes
  10. Routage Avancé
  11. Tester la Configuration
  12. Métriques et Surveillance
  13. Surveillance des Pairs M3UA

Qu'est-ce qu'un Point de Transfert de Signalisation (STP) ?​

Un Point de Transfert de Signalisation (STP) est un élément critique du réseau dans les réseaux de signalisation SS7 et basés sur IP qui achemine les messages de signalisation entre les nœuds du réseau.

Aperçu du Routage

Fonctions du STP​

  • Routage de Messages : Achemine le trafic de signalisation SS7 en fonction du Code de Point de Destination (PC) ou du Titre Global (GT)
  • Traduction de Protocole : Relie les réseaux SS7 traditionnels avec les réseaux M3UA/SCTP basés sur IP
  • Distribution de Charge : Distribue le trafic entre plusieurs destinations en utilisant un routage basé sur la priorité
  • Passerelle Réseau : Connecte différents réseaux de signalisation et fournisseurs de services
  • Masquage de Topologie : Peut réécrire les adresses pour masquer la topologie interne du réseau

Diagramme Réseau STP​

Rôles Réseau STP Expliqués​

ASP (Processus de Serveur d'Application)​

  • Rôle : Client se connectant à un SGP/STP distant
  • Direction : Connexion sortante
  • Cas d'Utilisation : Votre STP se connecte au STP d'un réseau partenaire

SGP (Processus de Passerelle de Signalisation)​

  • Rôle : Serveur acceptant les connexions des ASP
  • Direction : Connexion entrante
  • Cas d'Utilisation : Les réseaux partenaires se connectent à votre STP

AS (Serveur d'Application)​

  • Définition : Regroupement logique d'un ou plusieurs ASP
  • Objectif : Fournit redondance et partage de charge
  • Cas d'Utilisation : Plusieurs ASP servant la même destination

Interface avec les Réseaux TDM via des Passerelles de Signalisation​

OmniSS7 est une plateforme de signalisation basée sur IP qui utilise les protocoles SIGTRAN (M3UA/M2PA sur SCTP). Pour échanger des signaux avec des réseaux SS7 basés sur TDM hérités, vous avez besoin d'une Passerelle de Signalisation (SGW) pour relier les deux mondes.

Qu'est-ce qu'une Passerelle de Signalisation ?​

Une Passerelle de Signalisation (SGW) est un élément de réseau qui convertit la signalisation SS7 entre :

  • Côté TDM : SS7 traditionnel utilisant MTP1/MTP2/MTP3 sur des liaisons E1/T1
  • Côté IP : SIGTRAN utilisant M3UA ou M2PA sur SCTP/IP

La SGW agit en tant que traducteur de protocole, permettant aux applications basées sur IP comme OmniSS7 de communiquer avec des équipements TDM hérités (commutateurs, STP, HLR) qui ne prennent pas en charge la signalisation IP.

Architecture TDM à IP​

Comparaison de la Pile de Protocoles​

CoucheTDM SS7Passerelle de SignalisationIP (SIGTRAN)
Partie UtilisateurSCCP/TCAP/MAP← Transparent →SCCP/TCAP/MAP
RéseauMTP3ConversionM3UA/M2PA
LiaisonMTP2TerminaisonSCTP
PhysiqueMTP1 (E1/T1)TerminaisonIP/Ethernet

La SGW termine MTP1/MTP2 côté TDM et présente les données utilisateur MTP3 sur M3UA ou M2PA côté IP. Les couches supérieures (SCCP, TCAP, MAP, CAP) passent de manière transparente.

Connexion d'OmniSS7 à une Passerelle de Signalisation​

OmniSS7 se connecte à une Passerelle de Signalisation en tant qu'ASP (Processus de Serveur d'Application), tandis que la SGW agit en tant que SGP (Processus de Passerelle de Signalisation).

Exemple de Configuration​

config :omniss7,
  # Se connecter à la Passerelle de Signalisation en tant qu'ASP
  map_client_m3ua: %{
    mode: "ASP",
    callback: {MapClient, :handle_payload, []},
    process_name: :sgw_connection,
    # Point de terminaison local (OmniSS7)
    local_ip: {10, 0, 0, 1},
    local_port: 0,                    # Port local dynamique
    # Point de terminaison de la Passerelle de Signalisation
    remote_ip: {10, 0, 0, 100},       # Adresse IP de la SGW
    remote_port: 2905,                # Port M3UA de la SGW
    routing_context: 1                # Assigné par la SGW
  },

  # Ou configurer comme un pair pour le routage STP
  peers: [
    %{
      peer_id: 1,
      name: "TDM_Gateway",
      role: :client,                  # OmniSS7 initie la connexion
      local_ip: {10, 0, 0, 1},
      local_port: 0,
      remote_ip: {10, 0, 0, 100},     # Adresse IP de la SGW
      remote_port: 2905,
      routing_context: 1,
      point_code: 100,                # Plage de code de point derrière la SGW
      network_indicator: :international
    }
  ],

  # Routage des codes de point du réseau TDM via la passerelle
  m3ua_routes: [
    %{
      dest_pc: 100,                   # Code de point MSC TDM
      peer_id: 1,                     # Route via le pair SGW
      priority: 1,
      network_indicator: :international
    },
    %{
      dest_pc: 200,                   # Code de point HLR TDM
      peer_id: 1,
      priority: 1,
      network_indicator: :international
    }
  ]

Considérations de Configuration SGW​

Lors de la configuration de votre Passerelle de Signalisation pour fonctionner avec OmniSS7 :

ParamètreDescriptionValeur Typique
Remote IPAdresse IP d'OmniSS7Adresse IP de votre serveur
Remote PortPort SCTP d'OmniSS72905
Routing ContextIdentifiant AS à la SGWAssigné par l'administrateur SGW
Point CodesCodes de point du réseau TDM accessibles via SGWSpécifique au réseau
Traffic ModeMode de gestion du trafic ASPOverride ou Loadshare

Scénarios de Déploiement​

Scénario 1 : Application IP Accédant au Réseau TDM​

OmniSS7 envoie des requêtes MAP (SRI-SM, PRN) aux HLR basés sur TDM via la SGW :

OmniSS7 (ASP) → SGW (SGP) → Réseau TDM → HLR
     M3UA          MTP2           MTP3

Scénario 2 : OmniSS7 en tant que STP entre IP et TDM​

OmniSS7 achemine le trafic entre les éléments de réseau basés sur IP et les réseaux TDM :

IP SMSC → OmniSS7 STP → SGW → HLR TDM
              ↓
         HLR basé sur IP

Scénario 3 : Dual SGW pour Redondance​

Connectez-vous à deux Passerelles de Signalisation pour une haute disponibilité :

peers: [
  %{
    peer_id: 1,
    name: "SGW_Primary",
    role: :client,
    remote_ip: {10, 0, 0, 100},
    remote_port: 2905,
    point_code: 100,
    # ... autre config
  },
  %{
    peer_id: 2,
    name: "SGW_Backup",
    role: :client,
    remote_ip: {10, 0, 0, 101},
    remote_port: 2905,
    point_code: 100,
    # ... autre config
  }
],

m3ua_routes: [
  # Route primaire via SGW_Primary
  %{dest_pc: 100, peer_id: 1, priority: 1, network_indicator: :international},
  # Route de secours via SGW_Backup
  %{dest_pc: 100, peer_id: 2, priority: 2, network_indicator: :international}
]

Activation du Mode M3UA STP​

OmniSS7 peut fonctionner en différents modes. Pour l'utiliser comme STP, vous devez activer le mode STP dans la configuration.

Changement au Mode STP​

Le fichier config/runtime.exs d'OmniSS7 contient trois modes opérationnels préconfigurés. Pour activer le mode STP :

  1. Ouvrir config/runtime.exs
  2. Trouver les trois sections de configuration (lignes 53-174) :
    • Configuration 1 : Mode STP (lignes 53-85)
    • Configuration 2 : Mode HLR (lignes 87-123)
    • Configuration 3 : Mode SMSc (lignes 125-174)
  3. Commenter la configuration actuellement active (ajouter # à chaque ligne)
  4. Décommenter la configuration STP (retirer # des lignes 53-85)
  5. Personnaliser les paramètres de configuration selon les besoins
  6. Redémarrer l'application : iex -S mix

Vérification de l'État des Pairs M3UA

Configuration du Mode STP​

La configuration complète du STP ressemble à ceci :

config :omniss7,
  # Drapeaux de mode - Activer uniquement les fonctionnalités STP
  map_client_enabled: true,
  hlr_mode_enabled: false,
  smsc_mode_enabled: false,

  # Configuration de Connexion M3UA
  # Se connecter en tant qu'ASP (Processus de Serveur d'Application) au STP/SGW distant
  map_client_m3ua: %{
    mode: "ASP",
    callback: {MapClient, :handle_payload, []},
    process_name: :stp_client_asp,
    # Point de terminaison local (ce système)
    local_ip: {10, 179, 4, 10},
    local_port: 2905,
    # Point de terminaison STP/SGW distant
    remote_ip: {10, 179, 4, 11},
    remote_port: 2905,
    routing_context: 1
  }

Paramètres de Configuration à Personnaliser​

Pour une référence complète de tous les paramètres de configuration, voir la Référence de Configuration.

ParamètreTypePar DéfautDescriptionExemple
map_client_enabledBooléentrueActiver les capacités de client MAP et de routagetrue
local_ipTuple ou ListeRequisAdresse(s) IP de votre système. Unique : {10, 0, 0, 1} ou Liste pour multihoming : [{10, 0, 0, 1}, {10, 0, 0, 2}]{10, 179, 4, 10}
local_portEntier2905Port SCTP local2905
remote_ipTuple ou ListeRequisAdresse(s) IP de la STP/SGW distante. Unique ou Liste pour multihoming{10, 179, 4, 11}
remote_portEntier2905Port SCTP distant2905
routing_contextEntier1Identifiant de contexte de routage M3UA1
enable_gt_routingBooléenfalseActiver le routage par Titre Global (en plus du routage par PC)true

Astuce : Utilisez le multihoming SCTP en fournissant une liste d'adresses IP pour local_ip et/ou remote_ip pour activer le basculement automatique. Voir le Guide de Multihoming SCTP.

Que se Passe-t-il Lorsque le Mode STP est Activé​

Lorsque map_client_enabled: true, l'interface web affichera :

  • ✅ Événements SS7 - Journalisation des événements
  • ✅ Client SS7 - Tests de fonctionnement MAP
  • ✅ M3UA - État de la connexion
  • ✅ Routage - Gestion de la table de routage ← Spécifique au STP
  • ✅ Test de Routage - Test de routage ← Spécifique au STP
  • ✅ Ressources - Surveillance du système
  • ✅ Configuration - Visualiseur de configuration

Les onglets Liens HLR et Liens SMSc seront masqués.

Notes Importantes​

  • Le protocole SCTP (protocole IP 132) doit être autorisé à travers les pare-feu
  • Le port M3UA par défaut est 2905 (norme de l'industrie)
  • Assurez-vous de disposer de ressources système suffisantes pour gérer le trafic de routage
  • Persistance du Routage : Toutes les routes configurées via l'Interface Web ou l'API sont stockées dans la base de données Mnesia et survivent aux redémarrages
  • Fusion de Configuration : Les routes de runtime.exs sont chargées au démarrage et fusionnées avec les routes Mnesia
  • Après avoir changé de modes, vous devez redémarrer l'application pour que les modifications prennent effet
  • Interface Web : Voir le Guide de l'Interface Web pour gérer les routes via l'interface web
  • Accès API : Voir le Guide API pour la documentation de l'API REST et l'accès à Swagger UI

Mode STP Autonome​

En plus des capacités de routage STP disponibles lorsque map_client_enabled: true, vous pouvez exécuter un serveur STP M3UA autonome qui écoute les connexions entrantes.

Activation du STP Autonome​

Ajoutez cette configuration à config/runtime.exs :

config :omniss7,
  sctp_handler: %{
    enabled: true,
    local_ip: {127, 0, 0, 1},    # Adresse IP à écouter
    local_port: 2905,             # Port à écouter
    point_code: 100               # Code de point propre à ce STP
  }

Paramètres de Configuration STP​

ParamètreTypePar DéfautDescriptionExemple
enabledBooléenfalseActiver le serveur STP autonometrue
local_ipTuple{127, 0, 0, 1}Adresse IP à écouter pour les connexions{0, 0, 0, 0}
local_portEntier2905Port à écouter2905
point_codeEntierRequisCode de point SS7 propre à ce STP100

Quand Utiliser le STP Autonome​

  • Routage Pur : Lorsque vous avez uniquement besoin de routage M3UA sans fonctionnalité de client MAP
  • STP Central : Pour créer un routeur de signalisation central pour plusieurs éléments de réseau
  • Architecture Hub : Connecter plusieurs HLR, MSC et SMSC via un STP central

Remarque : Vous pouvez activer à la fois map_client_m3ua et sctp_handler simultanément si vous avez besoin à la fois de connexions sortantes et de fonctionnalités STP entrantes.

Persistance de la Table de Routage (Mnesia)​

Toutes les tables de routage (pairs, routes par Code de Point et routes par Titre Global) sont stockées dans une base de données Mnesia pour la persistance.

Comment Fonctionne le Routage​

  1. Routes Runtime.exs : Les routes définies dans config/runtime.exs sous peers (ou l'ancien m3ua_peers), m3ua_routes, et m3ua_gt_routes sont chargées au démarrage de l'application
  2. Routes Interface Web : Les routes ajoutées via la page de routage de l'Interface Web sont stockées dans Mnesia
  3. Fusion de Routes : Au redémarrage, les routes runtime.exs sont fusionnées avec les routes Mnesia existantes (pas de doublons)
  4. Persistance : Toutes les routes configurées via l'Interface Web survivent aux redémarrages de l'application

Type de Stockage Mnesia​

Contrôlez comment les tables de routage sont stockées. Pour plus de détails sur la configuration de la base de données, voir Paramètres de Base de Données dans la Référence de Configuration.

config :omniss7,
  mnesia_storage_type: :disc_copies  # ou :ram_copies pour les tests
Type de StockageDescriptionPersistanceCas d'Utilisation
:disc_copiesStockage sur disque (par défaut)Survit aux redémarragesEnvironnements de production
:ram_copiesSeulement en mémoirePerdu au redémarrageTests, développement

Par Défaut : :disc_copies

Emplacement de la Base de Données Mnesia​

Mnesia stocke les tables de routage dans le répertoire Mnesia de l'application :

  • Emplacement : Mnesia.{node_name}/ (par exemple, Mnesia.nonode@nohost/)
  • Tables : m3ua_peer, m3ua_route, m3ua_gt_route

Gestion des Routes​

Vous avez trois options pour gérer les routes :

  1. Runtime.exs - Configuration statique chargée au démarrage
  2. Interface Web - Gestion interactive des routes (voir Guide de l'Interface Web)
  3. API REST - Gestion programmatique des routes (voir Guide API)

Meilleure Pratique : Utilisez runtime.exs pour la configuration de base et l'Interface Web pour les modifications dynamiques de routes pendant l'exploitation.

Configuration des Pairs M3UA​

Les pairs représentent les points de terminaison de connexion M3UA (autres STP, HLR, MSC, SMSC). Ajoutez des pairs à config/runtime.exs.

Définition des Pairs M3UA

Exemple de Configuration de Pair​

Remarque : La clé de configuration peers est la norme actuelle. L'ancienne clé m3ua_peers est toujours prise en charge pour des raisons de compatibilité.

config :omniss7,
  peers: [
    # Connexion sortante au STP Partenaire (rôle : :client)
    %{
      peer_id: 1,                           # Identifiant unique
      name: "Partner_STP_West",             # Nom descriptif
      role: :client,                        # :client pour sortant, :server pour entrant
      local_ip: {10, 0, 0, 1},             # IP locale à lier
      local_port: 0,                        # 0 = attribution dynamique du port
      remote_ip: {10, 0, 0, 10},           # IP du pair distant
      remote_port: 2905,                    # Port du pair distant
      routing_context: 1,                   # Contexte de routage M3UA
      point_code: 100,                      # Code de point de ce pair
      network_indicator: :international     # :international ou :national
    },

    # Connexion au HLR Local (rôle : :client)
    %{
      peer_id: 2,
      name: "Local_HLR",
      role: :client,
      local_ip: {10, 0, 0, 1},
      local_port: 0,
      remote_ip: {10, 0, 0, 20},
      remote_port: 2905,
      routing_context: 2,
      point_code: 200,
      network_indicator: :international
    },

    # Connexion entrante du MSC Distant (rôle : :server)
    # Pour le rôle :server, le STP attend une connexion entrante
    %{
      peer_id: 3,
      name: "Remote_MSC",
      role: :server,                        # Accepter la connexion entrante
      remote_ip: {10, 0, 0, 30},           # IP source attendue
      remote_port: 2905,                    # Port source attendu (0 = accepter de n'importe quel port)
      routing_context: 3,
      point_code: 300,
      network_indicator: :international
    },

    # Connexion entrante avec port source dynamique (sans filtrage de port)
    %{
      peer_id: 4,
      name: "Dynamic_Client",
      role: :server,
      remote_ip: {10, 0, 0, 40},           # IP source attendue
      remote_port: 0,                       # 0 = accepter les connexions de n'importe quel port source
      routing_context: 4,
      point_code: 400,
      network_indicator: :international
    }
  ]

Vérification de l'État des Pairs M3UA

Paramètres de Configuration des Pairs​

ParamètreTypeRequisDescription
peer_idEntierOuiIdentifiant numérique unique pour le pair
nameChaîneOuiNom lisible par l'homme pour les journaux et la surveillance
roleAtomeOui:client (sortant) ou :server (entrant)
local_ipTuple ou ListeOui (client)Adresse(s) IP locale(s) à lier. Unique : {10, 0, 0, 1} ou Multiple pour le multihoming SCTP : [{10, 0, 0, 1}, {10, 0, 0, 2}]
local_portEntierOui (client)Port local (0 pour dynamique)
remote_ipTuple ou ListeOuiRôle Client : Tuple unique ou liste pour un pair distant multihomé. Rôle Serveur : Seulement un tuple - l'IP à partir de laquelle le pair distant se connecte (voir note ci-dessous)
remote_portEntierOuiPort du pair distant (0 pour entrant = accepter de n'importe quel port source)
routing_contextEntierOuiIdentifiant de contexte de routage M3UA
point_codeEntierOuiCode de point SS7 de ce pair
network_indicatorAtomeNon:international ou :national

Multihoming SCTP pour le Rôle Serveur (Connexions Entrantes) : Lors de l'acceptation de connexions entrantes d'un pair distant multihomé, vous devez uniquement spécifier l'adresse IP unique que le pair distant utilise pour initier la connexion SCTP (SCTP INIT). Cela doit être un tuple unique, pas une liste. SCTP découvrira automatiquement les autres adresses IP multihomées du pair lors de la poignée de main d'association. Le format liste pour remote_ip est uniquement utilisé pour le rôle client lors de la connexion à un pair distant multihomé.

Multihoming SCTP pour le Rôle Client (Connexions Sortantes) : Pour la redondance réseau lors de la connexion à des pairs distants, vous pouvez configurer plusieurs adresses IP pour local_ip et remote_ip en utilisant des listes. Cela permet un basculement automatique si un chemin réseau échoue. Voir le Guide de Multihoming SCTP pour des exemples de configuration détaillés et des meilleures pratiques.

Filtrage de Port Source pour les Connexions Entrantes​

Pour les connexions entrantes (rôle : :server), le paramètre remote_port contrôle le filtrage de port source :

  • Port Spécifique (par exemple, remote_port: 2905) : N'accepter que les connexions de ce port source exact

    • Fournit une sécurité supplémentaire en validant le port source
    • Utiliser lorsque le pair distant utilise un port source fixe

  • N'importe quel Port (remote_port: 0) : Accepter les connexions de n'importe quel port source

    • Utile lorsque le pair distant utilise des ports source dynamiques/éphémères
    • Valide uniquement l'adresse IP source
    • Plus flexible mais légèrement moins sécurisé

Exemple :

# Accepter uniquement de 10.5.198.200:2905 (port spécifique)
%{
  peer_id: 1,
  name: "Strict_Peer",
  role: :server,
  remote_ip: {10, 5, 198, 200},
  remote_port: 2905,
  # ... autre config
}

# Accepter de 10.5.198.200 avec n'importe quel port source
%{
  peer_id: 2,
  name: "Flexible_Peer",
  role: :server,
  remote_ip: {10, 5, 198, 200},
  remote_port: 0,  # Accepter de n'importe quel port source
  # ... autre config
}

Support du Protocole M2PA​

OmniSS7 prend en charge à la fois les protocoles M3UA et M2PA pour le transport de signalisation SS7.

Qu'est-ce que M2PA ?​

M2PA (MTP2 User Peer-to-Peer Adaptation Layer) est un protocole normalisé par l'IETF (RFC 4165) pour transporter les messages MTP3 SS7 sur des réseaux IP utilisant SCTP.

M3UA vs M2PA : Différences Clés​

FonctionnalitéM3UAM2PA
ArchitectureClient/Serveur (ASP/SGW)Pair-à-Pair
Cas d'UtilisationPasserelle entre SS7 et IPLiaisons directes point à point
Gestion de l'État de LiaisonNiveau application (ASPUP/ASPAC)Style MTP2 (Alignement, Test, Prêt)
Numéros de SéquencePas de séquençage inhérentBSN/FSN 24 bits pour livraison ordonnée
Déploiement TypiquePasserelle SS7 vers IP, STPLiaisons de signalisation directes entre nœuds
RFCRFC 4666RFC 4165

Conseils de Sélection de Protocole​

Recommandation : Utilisez M3UA par défaut. N'utilisez M2PA que lorsque cela est spécifiquement requis.

Quand Utiliser M3UA (Recommandé)​

M3UA est le protocole recommandé pour la plupart des déploiements :

  • Déploiements STP : Implémentations standard de point de transfert de signalisation
  • Fonctions de Passerelle : Relier les réseaux SS7 avec la signalisation basée sur IP
  • Connexions d'Éléments de Réseau : Connecter HLR, MSC, SMSC et d'autres éléments de réseau à votre STP
  • Passerelle de Signalisation (SGW) : Passerelle centrale acceptant des connexions de plusieurs Serveurs d'Application
  • Topologies Flexibles : Architectures client/serveur avec contrôle centralisé
  • Réseaux Multi-Fournisseurs : Norme de l'industrie largement supportée (RFC 4666)

Utilisez M3UA pour connecter des éléments de réseau (HLR, MSC, SMSC, VLR, etc.) à votre STP.

Quand Utiliser M2PA (Uniquement dans des Cas Spécifiques)​

M2PA ne doit être utilisé que dans des scénarios spécifiques :

  • Liaisons STP à STP : Connexions directes point à point entre Points de Transfert de Signalisation dans un réseau multi-STP
  • Remplacement TDM Hérité : Remplacer des liaisons SS7 TDM traditionnelles lorsque le système distant exige spécifiquement M2PA
  • Compatibilité MTP2 Requise : Lors de la connexion à des systèmes hérités qui imposent une gestion d'état de liaison de style MTP2
  • Exigence Partenaire : Lorsqu'un partenaire ou une interconnexion exige spécifiquement le protocole M2PA

Important : Ne pas utiliser M2PA pour connecter des éléments de réseau (HLR, MSC, SMSC) à votre STP - utilisez M3UA à la place. M2PA est conçu pour les interconnexions STP à STP où les deux côtés fonctionnent comme des nœuds de routage.

Configuration des Pairs M2PA​

Les pairs M2PA sont configurés de la même manière que les pairs M3UA, avec un paramètre protocol supplémentaire.

Configuration de Pair M2PA​

Ajoutez des pairs M2PA à votre configuration peers dans config/runtime.exs (les pairs M3UA et M2PA partagent la même section de configuration, différenciée par le paramètre protocol) :

Paramètres Clés pour M2PA :

ParamètreValeurDescription
protocol:m2paSpécifie le protocole M2PA (par défaut :m3ua si omis)
role:client ou :serverDirection de la connexion
local_portEntierPort SCTP local (le port standard M2PA est 3565)
remote_portEntierPort SCTP distant (le port standard M2PA est 3565)
point_codeEntierVotre code de point
adjacent_point_codeEntierCode de point du pair distant (spécifique à M2PA)
send_sltmBooléenContrôle le comportement SLTM (voir Configuration SLTM ci-dessous)
network_indicatorAtome:international ou :national - doit correspondre au pair distant

Remarque : M2PA utilise le port 3565 comme norme de l'industrie (différent du port 2905 de M3UA).

Configuration SLTM​

SLTM (Message de Test de Liaison de Signalisation) et SLTA (Accusé de Réception de Test de Liaison de Signalisation) sont des messages de maintenance MTP3 utilisés pour vérifier la connectivité de bout en bout après qu'une liaison M2PA atteigne l'état PRÊT. Selon l'ITU-T Q.707, un côté envoie SLTM et l'autre répond avec SLTA pour confirmer que la liaison est opérationnelle.

Comportement SLTM​

Le paramètre send_sltm contrôle quel côté initie le test SLTM :

Valeur send_sltmComportement
trueNous envoyons SLTM lorsque la liaison devient PRÊTE, attendons SLTA
falseNous attendons que le pair envoie SLTM, répondons avec SLTA
Non défini (par défaut)Suit Q.707 : le répondant SCTP envoie SLTM, l'initiateur SCTP attend

Comportement par Défaut (Conforme à Q.707) :

  • Si initiate_connection: true (initiateur/client SCTP) → Nous attendons que le pair envoie SLTM
  • Si initiate_connection: false (répondant/server SCTP) → Nous envoyons SLTM

Quand Surcharger les Valeurs par Défaut de SLTM​

Surchargez le comportement par défaut lors de la connexion à des équipements qui ne suivent pas les conventions Q.707 :

# Exemple : Forcer notre côté à envoyer SLTM indépendamment du rôle SCTP
%{
  peer_id: 100,
  name: "Partner_STP",
  protocol: :m2pa,
  role: :client,
  local_ip: {10, 0, 0, 1},
  local_port: 3565,
  remote_ip: {10, 0, 0, 2},
  remote_port: 3565,
  point_code: 7415,
  adjacent_point_code: 15528,
  network_indicator: :international,
  send_sltm: true  # Surcharge : Nous envoyons SLTM même si nous sommes l'initiateur SCTP
}

Flux de Messages SLTM​

Dépannage des Problèmes SLTM​

Symptôme : La liaison atteint PRÊT mais aucun trafic ne circule

Les deux côtés peuvent attendre que l'autre envoie SLTM. Vérifiez les journaux pour :

"waiting for peer to send SLTM"

Résolution : Configurez send_sltm: true d'un côté pour briser le blocage.

Symptôme : SLTM envoyé mais aucun SLTA reçu

Causes possibles :

  1. adjacent_point_code est incorrect (SLTM envoyé avec DPC erroné)
  2. Mismatch de l'indicateur de réseau (:international vs :national)
  3. Le pair distant n'est pas configuré pour répondre à notre code de point

Résolution : Vérifiez que adjacent_point_code correspond au code de point de STP (configuré dans sctp_handler.point_code).

États de Liaison M2PA​

Les liaisons M2PA progressent à travers plusieurs états lors de l'initialisation :

  1. Down - Aucune connexion établie
  2. Alignment - Phase de synchronisation initiale (~1 seconde)
  3. Proving - Vérification de la qualité de la liaison (~2 secondes)
  4. Ready - Liaison active et prête pour le trafic

La progression des états de liaison garantit une signalisation fiable avant l'échange de trafic.

Gestion des Pairs M2PA via l'Interface Web​

La page Routage dans l'Interface Web fournit un support complet pour la gestion des pairs M2PA :

  1. Naviguer vers la page de Routage
  2. Sélectionner l'onglet "Pairs"
  3. Cliquer sur "Ajouter un Nouveau Pair"
  4. Choisir "M2PA (RFC 4165)" dans le menu déroulant Protocole
  5. Remplir la configuration du pair :
    • Nom du Pair (identifiant descriptif)
    • Protocole : M2PA
    • Rôle : client ou serveur
    • Code de Point (votre PC)
    • Adresses IP locales/distantes
    • Ports locaux/distants (typiquement 3565 pour M2PA)
    • Indicateur de Réseau (international ou national)
  6. Cliquer sur "Sauvegarder le Pair"

La table des pairs affiche le type de protocole avec un code couleur :

  • Bleu - Pairs M3UA
  • Vert - Pairs M2PA

Comportement de Routage M2PA​

Les pairs M2PA s'intègrent parfaitement au système de routage d'OmniSS7 :

  • Routes par Code de Point : Fonctionnent de manière identique pour M2PA et M3UA
  • Routes par Titre Global : Entièrement prises en charge sur les liaisons M2PA
  • Priorité de Route : Les pairs M2PA et M3UA peuvent être mélangés dans les mêmes tables de routage
  • Relais de Message : Les messages peuvent arriver sur M2PA et être routés vers M3UA, et vice versa

Métriques M2PA​

M2PA fournit des métriques Prometheus complètes pour surveiller la santé des liaisons et le trafic :

Métriques de Trafic :

  • m2pa_messages_sent_total - Total des messages MTP3 envoyés par liaison
  • m2pa_messages_received_total - Total des messages MTP3 reçus par liaison
  • m2pa_bytes_sent_total - Total des octets envoyés sur M2PA
  • m2pa_bytes_received_total - Total des octets reçus sur M2PA

Toutes les métriques de trafic sont étiquetées par : link_name, point_code, adjacent_pc

Métriques d'État de Liaison :

  • m2pa_link_state_changes_total - Transitions d'état de liaison (DOWN → ALIGNMENT → PROVING → READY)
    • Étiquettes : link_name, from_state, to_state

Métriques d'Erreur :

  • m2pa_errors_total - Total des erreurs par type
    • decode_error - Échecs de décodage de message M2PA
    • encode_error - Échecs d'encodage de message M2PA
    • sctp_send_error - Échecs de transmission SCTP
    • Étiquettes : link_name, error_type

Accès aux Métriques :

  • Point de terminaison Prometheus : http://your-server:8080/metrics
  • Les métriques s'enregistrent automatiquement au démarrage de l'application

Meilleures Pratiques M2PA​

  1. Sélection de Port : Utilisez le port 3565 pour M2PA (norme de l'industrie)
  2. Surveillance de Liaison : Surveillez les changements d'état de liaison via les métriques
  3. Règles de Pare-feu : Assurez-vous que SCTP (protocole IP 132) est autorisé
  4. Codes de Point : Assurez-vous que les codes de point adjacents sont correctement configurés des deux côtés
  5. Indicateur de Réseau : Doit correspondre entre les pairs (international ou national)
  6. Tests : Utilisez la page de Test de Routage pour vérifier la connectivité après configuration

Exigences de Socket M2PA​

M2PA utilise des sockets partagés SCTP.SocketHandler. Tous les pairs M2PA utilisent automatiquement le SCTP.SocketHandler pour la gestion des sockets, ce qui permet à plusieurs pairs de partager efficacement le même port SCTP.

Exigences :

  • SCTP.SocketHandler doit être activé et en cours d'exécution
  • Le socket partagé doit être configuré avant que les pairs M2PA ne démarrent

Exemple :

# Activer SCTP.SocketHandler
sctp_handler: %{
  enabled: true,
  local_ip: {10, 179, 4, 10},
  local_port: 3565,
  point_code: 100
}

# Les pairs M2PA utilisent automatiquement le socket partagé
peers: [
  %{
    peer_id: 1,
    name: "M2PA_Link_1",
    protocol: :m2pa,
    role: :client,
    local_ip: {10, 179, 4, 10},
    local_port: 3565,
    remote_ip: {10, 179, 4, 20},
    remote_port: 3565,
    point_code: 100,
    adjacent_point_code: 200
  },
  %{
    peer_id: 2,
    name: "M2PA_Link_2",
    protocol: :m2pa,
    role: :client,
    local_ip: {10, 179, 4, 10},
    local_port: 3565,           # Même port partagé entre les pairs
    remote_ip: {10, 179, 4, 30},
    remote_port: 3565,
    point_code: 100,
    adjacent_point_code: 300
  }
]

Exigences SCTP :

  • Livraison ordonnée (pas de unordered flag)
  • PPID 5 (identifiant M2PA selon RFC 4165)

Configuration du Routage par Code de Point​

Le routage par Code de Point dirige les messages en fonction du Code de Point de Destination (DPC) dans l'en-tête MTP3.

Comprendre les Codes de Point dans la Pile de Protocole SS7​

Les codes de point existent à différentes couches de la pile de protocole SS7. Comprendre cette distinction est important :

Couches de la Pile de Protocole :

┌─────────────────────────────────────────┐
│  Couche d'Application (SCCP/TCAP/MAP)   │
├─────────────────────────────────────────┤
│  Couche MTP3                           │ ← Routage des Données Utilisateur
│  - Étiquette de Routage : DPC, OPC, SLS │ ← Utilisé pour le routage STP
│  - Octet d'Information de Service (SIO) │
├─────────────────────────────────────────┤
│  M3UA ou M2PA (Couche d'Adaptation)    │ ← Protocole de Transport
│  - Données de Protocole (contient MTP3) │
│  - Gestion de Réseau (DUNA/DAVA)       │ ← État du Réseau
├─────────────────────────────────────────┤
│  SCTP (Transport)                       │
└─────────────────────────────────────────┘

Deux Types de Codes de Point :

  1. Codes de Point de Couche MTP3 (Utilisés pour le Routage) :

    • Situés dans l'étiquette de routage MTP3 (DPC, OPC)
    • Présents dans le paramètre Données de Protocole M3UA (tag 528)
    • Présents dans les messages de Données Utiles M2PA
    • Le STP utilise ces valeurs DPC pour les décisions de routage
    • Elles déterminent où le message est finalement livré

  2. Codes de Point de Couche M3UA (Utilisés pour la Gestion du Réseau) :

    • Présents dans les messages de gestion M3UA (DUNA, DAVA, SCON, DUPU)
    • Indiquent les codes de point affectés pour l'état du réseau
    • Indiquent aux pairs quelles destinations sont disponibles/inaccessibles
    • Non utilisés pour le routage des données utilisateur

Comment Fonctionne le Routage STP :

  • Pour les messages M3UA DATA : Le STP extrait le message MTP3 du paramètre Données de Protocole (tag 528), qui contient l'étiquette de routage MTP3 (DPC, OPC, SLS). Le DPC de la couche MTP3 est utilisé pour rechercher des routes.
  • Pour les messages de Données Utiles M2PA : Le STP extrait le message MTP3 du champ de données utilisateur M2PA, puis lit le DPC de l'étiquette de routage MTP3.
  • Messages de gestion M3UA : Les messages de gestion du réseau (DUNA, DAVA, SCON) contiennent des codes de point affectés au niveau M3UA pour le statut de signalisation entre pairs.

Routes de Code de Point de Base​

Ajoutez des routes à config/runtime.exs :

config :omniss7,
  m3ua_routes: [
    # Route tout le trafic pour le PC 100 vers le pair 1 (STP Partenaire)
    %{
      dest_pc: 100,                    # Code de point de destination
      peer_id: 1,                      # Pair à travers lequel router
      priority: 1,                     # Priorité (plus bas = plus haute priorité)
      network_indicator: :international
      # mask: 14                       # Optionnel : par défaut 14 (correspondance exacte)
    },

    # Route tout le trafic pour le PC 200 vers le pair 2 (HLR Local)
    %{
      dest_pc: 200,
      peer_id: 2,
      priority: 1,
      network_indicator: :international
    },

    # Exemple d'équilibrage de charge : PC 300 avec routes primaire et de secours
    %{
      dest_pc: 300,
      peer_id: 3,                      # Route primaire
      priority: 1,
      network_indicator: :international
    },
    %{
      dest_pc: 300,
      peer_id: 4,                      # Route de secours (numéro de priorité plus élevé)
      priority: 2,
      network_indicator: :international
    }
  ]

Remarque : Le champ mask est optionnel et par défaut à 14 (correspondance exacte). Ne spécifiez mask que lorsque vous avez besoin d'un routage basé sur des plages (voir la section sur les Masques de Code de Point ci-dessous).

Logique de Routage​

  1. Le STP reçoit un message M3UA DATA ou M2PA Données Utiles
  2. Le STP extrait le message MTP3 du paramètre Données de Protocole (M3UA) ou du champ de Données Utiles (M2PA)
  3. Le STP lit le Code de Point de Destination (DPC) de l'étiquette de routage MTP3
  4. Recherche dans la table de routage pour un DPC correspondant (en tenant compte des masques)
  5. Si plusieurs routes existent, sélectionne la route avec le masque le plus spécifique (valeur de masque la plus élevée), puis le numéro de priorité le plus bas
  6. Enveloppe le message MTP3 dans M3UA DATA ou M2PA Données Utiles pour le pair de destination
  7. Route le message vers le pair correspondant
  8. Si le pair sélectionné est hors service, essaie la route de priorité suivante

Définition des Routes PC

Masques de Code de Point​

Les codes de point sont des valeurs de 14 bits (plage 0-16383). Par défaut, les routes correspondent à un code de point unique exactement (masque /14). Cependant, vous pouvez utiliser des masques de code de point pour créer des routes qui correspondent à des plages de codes de point.

Comprendre les Masques​

Le masque spécifie combien de bits les plus significatifs doivent correspondre entre le PC de destination de la route et le DPC du message entrant. Les bits restants peuvent avoir n'importe quelle valeur, créant une plage de codes de point correspondants.

Tableau de Référence des Masques :

MasqueCodes de Point CorrespondantsCas d'Utilisation
/141 PC (correspondance exacte)Destination unique (par défaut)
/132 PCsPetite plage
/124 PCsPetite plage
/118 PCsPetite plage
/1016 PCsPlage moyenne
/932 PCsPlage moyenne
/864 PCsPlage moyenne
/7128 PCsPlage moyenne-grande
/6256 PCsGrande plage
/5512 PCsGrande plage
/41,024 PCsTrès grande plage
/32,048 PCsTrès grande plage
/24,096 PCsPlage extrêmement grande
/18,192 PCsLa moitié de tous les PCs
/016,384 PCsTous les PCs (route par défaut/de secours)

Exemples de Masques de Code de Point​

Remarque : Le champ mask est optionnel dans tous les exemples. S'il est omis, il par défaut à 14 (correspondance exacte).

Exemple 1 : Code de Point Unique (Comportement par Défaut)

# Sans champ de masque (recommandé pour un PC unique)
%{
  dest_pc: 1000,
  peer_id: 1,
  priority: 1,
  network_indicator: :international
}
# Masque par défaut à 14 - Correspond à : Seulement le PC 1000

# Masque explicite (même résultat)
%{
  dest_pc: 1000,
  peer_id: 1,
  priority: 1,
  mask: 14,                              # Correspondance exacte explicite
  network_indicator: :international
}
# Correspond à : Seulement le PC 1000

Exemple 2 : Petite Plage

%{
  dest_pc: 1000,
  peer_id: 2,
  priority: 1,
  mask: 12,                              # Correspond à 4 PCs
  network_indicator: :international
}
# Correspond à : PC 1000, 1001, 1002, 1003

Exemple 3 : Plage Moyenne

%{
  dest_pc: 1000,
  peer_id: 3,
  priority: 1,
  mask: 8,                               # Correspond à 64 PCs
  network_indicator: :international
}
# Correspond à : PC 1000-1063 (64 codes de point consécutifs)

Exemple 4 : Route par Défaut / de Secours

%{
  dest_pc: 0,
  peer_id: 4,
  priority: 10,                          # Basse priorité (numéro élevé)
  mask: 0,                               # Correspond à tous les PCs
  network_indicator: :international
}
# Correspond à : Tous les codes de point (0-16383)
# Utiliser comme route de secours/catch-all avec faible priorité

Combinaison de Routes Spécifiques et Masquées​

Vous pouvez combiner des routes spécifiques avec des routes masquées pour un routage flexible :

config :omniss7,
  m3ua_routes: [
    # Route spécifique pour le PC 1000 (prend la priorité)
    %{
      dest_pc: 1000,
      peer_id: 1,
      priority: 1,
      network_indicator: :international
      # masque par défaut à 14 (correspondance exacte)
    },

    # Route de plage pour les PCs 1000-1063
    %{
      dest_pc: 1000,
      peer_id: 2,
      priority: 1,
      mask: 8,                           # Correspond à 64 PCs
      network_indicator: :international
    },

    # Route par défaut pour tous les autres PCs
    %{
      dest_pc: 0,
      peer_id: 3,
      priority: 10,                      # Basse priorité
      mask: 0,                           # Correspond à tous les PCs
      network_indicator: :international
    }
  ]

Décision de Routage pour le DPC 1000 :

  1. Correspond à la route masque /14 (PC 1000 exactement) - Sélectionnée (la plus spécifique)
  2. Correspond également à la route masque /8 (plage PC 1000-1063) - Ignorée (moins spécifique)
  3. Correspond également à la route masque /0 (tous les PCs) - Ignorée (moins spécifique)

Décision de Routage pour le DPC 1015 :

  1. Ne correspond pas à la route masque /14 (PC 1000 uniquement)
  2. Correspond à la route masque /8 (plage PC 1000-1063) - Sélectionnée (correspondance la plus spécifique)
  3. Correspond également à la route masque /0 (tous les PCs) - Ignorée (moins spécifique)

Décision de Routage pour le DPC 5000 :

  1. Ne correspond pas à la route masque /14
  2. Ne correspond pas à la route masque /8
  3. Correspond à la route masque /0 (tous les PCs) - Sélectionnée (seule correspondance, route de secours)

Meilleures Pratiques​

  1. Omettre mask pour les Destinations Uniques : Pour les correspondances exactes de code de point, omettez le champ mask entièrement (par défaut à /14)
  2. Utiliser /14 Explicitement Seulement Lorsque Nécessaire : Ne spécifiez mask: 14 que lorsque vous devez le clarifier dans la documentation ou lorsque vous mélangez avec des routes de plage
  3. Utiliser des Masques de Plage pour les Blocs Réseau : Routez des segments de réseau entiers vers des pairs spécifiques avec des masques /0 à /13
  4. Utiliser /0 comme Route de Secours : Créez une route par défaut avec une faible priorité pour capturer le trafic non apparié
  5. La Plus Spécifique Gagne : Le moteur de routage sélectionne toujours la route la plus spécifique (valeur de masque la plus élevée) en premier
  6. Priorité comme Critère de Départage : Si plusieurs routes ont le même masque, le numéro de priorité le plus bas gagne

Configuration du Routage par Titre Global (GT)​

Le routage par Titre Global permet un routage basé sur le contenu utilisant des numéros de téléphone ou des valeurs IMSI au lieu de codes de point. Pour un routage avancé par Titre Global basé sur le numéro appelant/appelé, voir le Guide NAT par Titre Global.

Définition des Routes GT

Prérequis​

  • Activer le routage GT : enable_gt_routing: true dans config/runtime.exs

Configuration des Routes GT​

config :omniss7,
  # Activer le routage GT
  enable_gt_routing: true,

  m3ua_gt_routes: [
    # Route tous les numéros du Royaume-Uni (préfixe 44) vers le pair 1
    %{
      gt_prefix: "44",                 # Préfixe de Titre Global à correspondre
      peer_id: 1,                      # Pair de destination
      priority: 1,                     # Priorité (plus bas = plus haut)
      description: "Numéros du Royaume-Uni"        # Description pour la journalisation
    },

    # Route les numéros américains (préfixe 1) vers le pair 2
    %{
      gt_prefix: "1",
      peer_id: 2,
      priority: 1,
      description: "Numéros américains"
    },

    # Route plus spécifique : numéros mobiles britanniques commençant par 447
    %{
      gt_prefix: "447",                # La correspondance du préfixe le plus long gagne
      peer_id: 3,
      priority: 1,
      description: "Numéros mobiles britanniques"
    },

    # Routage spécifique à SSN (optionnel)
    %{
      gt_prefix: "555",
      source_ssn: 8,                   # Ne correspond que si SSN source = 8 (SMSC)
      peer_id: 4,
      dest_ssn: 6,                     # Réécrit SSN de destination à 6 (HLR)
      priority: 1,
      description: "Trafic SMS pour le préfixe 61"
    }
  ]

Logique de Routage GT​

L'algorithme de routage GT suit ce processus de décision :

Étapes de Routage :

  1. Correspondance du Préfixe le Plus Long : Le STP trouve toutes les routes GT où le préfixe correspond au début du Titre Global

    • Exemple : GT "447712345678" correspond à "44" et "447", mais "447" gagne (correspondance la plus longue)

  2. Correspondance SSN (Optionnel) :

    • Si source_ssn est spécifié, la route ne correspond que lorsque le SSN de la Partie Appelée SCCP est égal à cette valeur
    • Si source_ssn est nil, la route correspond à n'importe quel SSN (wildcard)

  3. Correspondance TT/NPI/NAI (Optionnel) :

    • Si source_tt, source_npi, ou source_nai sont spécifiés, les routes doivent correspondre à ces indicateurs
    • Les valeurs nil agissent comme des wildcards (correspondent à n'importe quelle valeur)

  4. Sélection Basée sur la Spécificité :

    • Les routes avec des critères de correspondance plus spécifiques gagnent sur les wildcards
    • Ordre de priorité : Longueur du Préfixe GT → SSN Spécifique → TT → NPI → NAI → Numéro de Priorité le Plus Bas

  5. Réécriture des Indicateurs (Optionnel) :

    • Si dest_ssn, dest_tt, dest_npi, ou dest_nai sont spécifiés, le STP réécrit ces indicateurs
    • Utile pour la normalisation des protocoles et l'interconnexion des réseaux

  6. Retour au Code de Point :

    • Si aucune route GT ne correspond, le STP revient au routage par Code de Point en utilisant le DPC

Exemples de Routage GT​

GT AppeléSSN SourceTTNPINAIRoute CorrespondanteRaison
4477123456786---"447" → pair 3Correspondance de préfixe la plus longue
4412345678906---"44" → pair 1Correspondance de préfixe, aucune route plus spécifique
121255512346---"1" → pair 2Correspondance de préfixe pour les numéros américains
5558812345678---"555" (SSN 8) → pair 4Correspondance GT + SSN, réécrit SSN à 6
5558812345676---"555" (wildcard SSN) → pair XCorrespondance GT, aucune réécriture SSN
4412345678906014"44" (TT=0) → pair 1Correspondance GT + TT, transforme TT à 3
121255512348014"1" (TT=0, NPI=1, NAI=4)La plus spécifique : correspondance GT+TT+NPI+NAI

Utilisations Pratiques pour le Routage TT/NPI/NAI​

  1. Normalisation de l'Interconnexion Réseau

    • Différents réseaux peuvent utiliser des conventions d'indicateurs différentes
    • Transformer les indicateurs au point d'interconnexion pour assurer la compatibilité
    • Exemple : Le réseau partenaire utilise TT=0 pour international, votre réseau utilise TT=1

  2. Conversion de Protocole

    • Convertir entre des plans de numérotation lors du routage entre différents types de réseaux
    • Exemple : Route d'un réseau mobile (NPI=6) vers le PSTN (NPI=1)

  3. Standardisation du Format d'Adresse

    • Normaliser tout le trafic entrant pour utiliser des valeurs NAI cohérentes
    • Exemple : Convertir tous les formats internationaux (NAI=4) en format national (NAI=3) pour le routage domestique

  4. Routage Spécifique au Fournisseur

    • Router en fonction du type de traduction vers différents fournisseurs de services
    • Exemple : TT=0 routé vers le Fournisseur A, TT=2 routé vers le Fournisseur B

  5. Intégration de Systèmes Hérités

    • Les systèmes modernes peuvent utiliser des valeurs d'indicateur différentes des systèmes hérités
    • Transformer au STP pour maintenir la compatibilité descendante

Fonctionnalités de Gestion des Routes​

Désactivation des Routes​

Les routes peuvent être temporairement désactivées sans être supprimées. Cela est utile pour les tests, la maintenance ou la gestion du trafic.

Drapeau Activé​

Les routes par Code de Point et par Titre Global prennent en charge un drapeau enabled optionnel :

config :omniss7,
  m3ua_routes: [
    # Route active
    %{
      dest_pc: 100,
      peer_id: 1,
      priority: 1,
      network_indicator: :international,
      enabled: true  # La route est active (par défaut si omis)
    },

    # Route désactivée (non évaluée lors du routage)
    %{
      dest_pc: 200,
      peer_id: 2,
      priority: 1,
      network_indicator: :international,
      enabled: false  # La route est désactivée
    }
  ],

  m3ua_gt_routes: [
    # Route GT désactivée
    %{
      gt_prefix: "44",
      peer_id: 1,
      priority: 1,
      description: "Numéros du Royaume-Uni - temporairement désactivés",
      enabled: false
    }
  ]

Comportement par Défaut :

  • Si enabled n'est pas spécifié, les routes par défaut sont enabled: true
  • Les routes désactivées sont complètement ignorées lors de la recherche de routes
  • Utilisez l'Interface Web pour basculer les routes activées/désactivées sans modifier la configuration

Cas d'Utilisation :

  • Tester les changements de flux de trafic
  • Fenêtres de maintenance temporaires
  • Test A/B de différents chemins de routage
  • Déploiement progressif de nouvelles routes

Routes DROP : Prévention des Boucles de Routage​

Les routes DROP (avec peer_id: 0) rejettent silencieusement le trafic au lieu de le transférer. Cela empêche les boucles de routage et permet un filtrage avancé du trafic.

Configuration des Routes DROP​

config :omniss7,
  m3ua_routes: [
    # Route DROP pour un code de point spécifique
    %{
      dest_pc: 999,
      peer_id: 0,        # peer_id=0 signifie DROP
      priority: 1,
      network_indicator: :international
    }
  ],

  m3ua_gt_routes: [
    # Route DROP pour préfixe GT
    %{
      gt_prefix: "999",
      peer_id: 0,        # peer_id=0 signifie DROP
      priority: 99,
      description: "Bloquer la plage de test"
    }
  ]

Comment Fonctionnent les Routes DROP​

Lorsqu'un message correspond à une route DROP :

  1. Le moteur de routage identifie peer_id: 0
  2. Le message est silencieusement rejeté (non transféré)
  3. Un journal INFO est généré : "DROP route matched for DPC 999" ou "DROP route matched for GT 999"
  4. La recherche de routage retourne {:error, :dropped}

**

Dernière mise à jour le