X.25 est une norme de protocole ITU-T (International Telecommunication Union-Telecommunication Standardization Sector) pour les communications WAN qui définit la manière dont les périphériques utilisateur et les périphériques réseau établissent et maintiennent les connexions. X.25 est plus souvent visible sur les réseaux sujets aux erreurs. Ce document aborde certaines des questions fréquemment posées concernant X.25
A. L'annexe G prend uniquement en charge le routage X.25 et les appels assembleur/désassembleur de paquets (PAD). Il en va de même pour les services de réseau en mode connexion (CMNS) et X.25 sur TCP (XOT). Vous pouvez transférer un appel RFC1536 X.25, mais vous ne pouvez pas le transmettre via un identificateur de connexion de liaison de données (DLCI) de l'annexe G.
Afin de transporter le trafic IP et X.25 sur une interface Frame Relay, vous devez utiliser deux DLCI ou transporter le trafic X.25 via XOT sur un DLCI prenant en charge IP, plutôt qu'un DLCI Annexe G. Pour plus d'informations, reportez-vous à la documentation de l'annexe G (X.25 sur Frame Relay). Voir aussi Configuration de X.25 sur Frame Relay (Annexe G) (documentation pour le logiciel Cisco® IOS Version 12.2).
A. La technologie RNIS dynamique (AODI) est prise en charge depuis la version 11.3(3)T du logiciel Cisco IOS. Pour plus d'informations, référez-vous à AO/DI (Always On/Dynamic ISDN).
A. La commande X.25 hold-queue permet de spécifier le nombre maximal de paquets à stocker par circuit virtuel avant de tenter de créer un autre circuit virtuel (SVC). Si un autre circuit virtuel ne peut pas être créé, les paquets sont abandonnés. Reportez-vous à la référence des commandes X.25 (version 12.2 du logiciel Cisco IOS) pour plus d'informations. Pour créer un autre circuit virtuel, vous avez besoin de la commande x25 nvc X où X est le nombre de circuits virtuels pouvant être ouverts simultanément vers la même destination.
A. La commande hold-queue <length> {in/out} est une commande de bas niveau qui contrôle le nombre de mémoires tampon reçues qui peuvent être en attente dans le routeur. Un pilote refuse d'accepter de nouvelles données une fois qu'elles ont dépassé la limite d'entrée de l'interface, qui ne peut être traitée qu'une fois que certains des paquets reçus dans le routeur ont été éliminés. Cette commande ne doit pas être confondue avec la commande X25 hold-queue et n'est pas liée à LAPB et X.25, au-delà du fait que LAPB surveille l'état de la limite d'entrée et émet un récepteur non prêt (RNR) lorsque le service ne peut plus recevoir de trames d'E. Pour plus d'informations, reportez-vous à la référence des commandes de l'interface Cisco IOS (version 12.2 du logiciel Cisco IOS).
A. La raison d'une augmentation de la file d'attente d'entrée peut être que l'interface a trop de trafic à traiter, en particulier lorsque ces paquets sont destinés au routeur lui-même, par exemple SNMP (Simple Network Management Protocol). Lors de l'utilisation de X.25 pour transporter IP, vous devez fragmenter le datagramme IP en plusieurs paquets X.25.
Par exemple, un datagramme IP peut être fragmenté en cinq paquets X.25. Chacun de ces paquets X.25 est équipé d'un bit M, sauf le dernier. Sur le routeur Cisco distant, vous devez attendre le dernier paquet pour reconstruire le datagramme IP d’origine. Dans notre exemple ci-dessus, les quatre premiers paquets (ceux avec M-bit) doivent être mis en file d'attente. Elles sont mises en file d'attente dans la file d'attente d'entrée de l'interface. Cela ne se produit que si l'appel est terminé sur le routeur (par exemple, s'il est terminé par une carte x25).
Si un grand nombre d'appels sont interrompus sur le routeur (par exemple IP et QLLC [Qualified Logical Link Control]), la file d'attente d'entrée peut augmenter, car tous les circuits virtuels envoient des paquets de bits M. Cela peut avoir un effet secondaire négatif, car le routeur envoie une RNR sur la couche 2 lorsque la file d'attente d'entrée a atteint le maximum. Vous pouvez régler la file d'attente d'entrée à l'aide de la commande hold-queue x.
A. Cisco ne prend pas en charge GAP. GAP est un protocole DEC propriétaire qui transporte X.25 depuis VAX via une liaison NSP (Network-Services Protocol) DECnet vers la passerelle X.25 qui extrait les informations X.25 et les transmet au réseau X.25. Pour obtenir des fonctionnalités similaires avec le logiciel Cisco IOS, utilisez CMNS (Connection-Mode Network Service) (également appelé CONS en termes DEC). Le CMNS utilise X.25 sur Logical Link Control, type 2 (LLC2) , qui peut être réalisé sur VAX avec DECnet PhV et P.S.I. version 5 ou ultérieure.
A. Premièrement, essayez de négocier une taille de paquet cohérente pour l'appel. Si vous ne pouvez pas le faire (une raison étant que la négociation de taille de paquet est désactivée) et que l'accusé de réception local est activé, gérez la segmentation et le réassemblage du circuit conformément aux recommandations X.25.
Dans l'exemple ci-dessous, Serial 1 est configuré pour 128 et Serial 0 pour 256 :
3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 5 PR 4 !--- Two packets of 128 incoming. 3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 6 PR 4 3d22h: Serial0: X.25 O D1 Data (259) 8 lci 1024 M PS 5 PR 4 !--- One packet of 256 outgoing on other interface. 3d22h: Serial1: X.25 O D1 RR (3) 8 lci 1024 PR 7 3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 7 PR 4 3d22h: Serial0: X.25 I D1 RR (3) 8 lci 1024 PR 6 3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 0 PR 4 3d22h: Serial0: X.25 O D1 Data (259) 8 lci 1024 M PS 6 PR 4 3d22h: Serial1: X.25 O D1 RR (3) 8 lci 1024 PR 1 3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 1 PR 4 3d22h: Serial0: X.25 I D1 RR (3) 8 lci 1024 PR 7 3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 2 PR 4 3d22h: Serial0: X.25 O D1 Data (259) 8 lci 1024 M PS 7 PR 4
A. Oui, les groupes de recherche et l'équilibrage de charge X.25 sont pris en charge. Cette fonctionnalité a été introduite dans le logiciel Cisco IOS Version 12.0(3)T. Référez-vous à Configuration de l'équilibrage de charge X.25 pour plus de détails.
A. L'UIT-T (anciennement CCITT) a défini la norme X.75 (système de signalisation à commutation de paquets entre les réseaux publics fournissant des services de transmission de données) pour prendre en charge l'interconnexion des réseaux de données publics X.25. Cisco n'implémente pas cela.
Une pile de protocoles qui transporte un flux de caractères asynchrone sur une session LAPB sur un canal B RNIS est également appelée X.75, bien que la seule similitude qu'elle a avec X.75 soit l'utilisation de LAPB comme protocole de couche liaison (que X.75 partage avec X.25). Cisco appelle cet adaptateur de terminal LAPB (LAPB-TA), et ceci est pris en charge. Référez-vous à RNIS LAPB-TA pour plus d'informations.
A. Le logiciel Cisco IOS a toujours pris en charge X.25 version 1984, et c'est toujours le cas dans le logiciel Cisco IOS version 12.2. Avant la version 11.3 du logiciel Cisco IOS, lors de la configuration de l'encapsulation DDN ou BFE, la version utilisée était 1980. Si l'encapsulation était X.25, la version utilisée était 1984, avec l'ajout de la version 1988 pour les valeurs de débit.
A. Dans les versions 11.2 et antérieures du logiciel Cisco IOS, les appels de traduction avec des identificateurs de protocole non standard (PID) ont été incorrectement acceptés. L'adresse de destination correspond à la première entrée de traduction qui n'a pas spécifié de CUD (Call User Data).
Cette traduction est plus précise dans le logiciel Cisco IOS Version 12.0. Le PID doit être appelé PAD (0x01000000) et les données CUD doivent être vides (la traduction se produit si PAD est 0x0100000, mais pas si le champ de données du CUD contient des données). La ligne de traduction doit correspondre à cette valeur. Cela est nécessaire car le PID fait référence à la manière dont une application gère l'appel entrant. Dans notre cas, la traduction est toujours une fonction PAD. Si le routeur reçoit un appel entrant avec un PID incorrect, il refuse l'appel car, sur l'hôte distant, l'application ne fait pas référence à une fonction PAD.
Il existe plusieurs solutions pour accepter les appels entrants qui ne font pas référence à un PAD. La plus courante est la commande x25 default-pad. Ne supposez pas qu'un appel entrant avec PID 0xC000000 peut être traité sans erreur à l'application PAD du routeur. Les deux systèmes font référence à différentes façons de traiter l'appel. Cela peut fonctionner, mais dans certains cas les paramètres X3 ne seront pas échangés, ce qui entraîne l'affichage de caractères illisibles sur le terminal ou la désactivation de l'appel.
Pour un problème de PID, si un appel est reçu avec le PID 0x01000F00, essayez d'utiliser le cud \001.* dans la commande de traduction (001 c'est la valeur octale). Veuillez noter les inconvénients de cette configuration, comme expliqué ci-dessus.
Pour une partie de données CUD, essayez la traduction. Autrement dit, traduire X.25 10 cud .* tcp 1.1.1.1. Ceci accepte tous les appels PAD (avec le PID 0x01000000) quelle que soit la partie données.
Référez-vous à Configuration de la traduction de protocole et des périphériques asynchrones virtuels pour plus d'informations.
A. Pour les appels entrants, la table de mappage a la priorité sur la table de routage. Si une entrée correspondante du PAD est trouvée, elle est appliquée exclusivement et la table de routage n'est pas consultée. La table de routage n'est consultée qu'après qu'une entrée de carte ne correspondant pas a été trouvée.
Pour les appels sortants, une carte configurée sur l'interface ne peut pas être routée. Tous les autres appels, PAD internes ou commutés peuvent être soumis à la table de routage. La première correspondance disponible est toujours utilisée.
A. Dans le logiciel Cisco IOS Version 11.3 et ultérieure, lorsque le routeur demande un appel clear, il attend une confirmation claire, qui est le comportement par défaut de bout en bout. Sur le logiciel Cisco IOS Version 11.2, le comportement à appeler la requête clear est différent. Pour que le logiciel Cisco IOS Version 11.2 envoie une confirmation claire, il faut une commande masquée xot-confirm-svc-reset au niveau mondial. En plus de la commande ci-dessus, les commandes service tcp keepalive-in et service tcp keepalive-out et xot-keepalive doivent être activées dans les routeurs du logiciel Cisco IOS version 11.2 et 11.3. Cela nettoie tous les circuits virtuels commutés et les sessions TCP terminées.
A. Actuellement, XOT n'autorise aucune commande telle que x25 default-pad, car il n'y a aucune interface sur laquelle effectuer cette opération. Cependant, le profil xot sera pris en charge dans une version ultérieure. La cible actuelle est la version 12.2-7.T du logiciel Cisco IOS.
A. Vous ne pouvez pas réacheminer l'appel X.25 qu'une commande x25 map veut émettre. Cependant, X.25 Remote Failure Detection est une fonctionnalité intéressante pour détecter une défaillance distante - par exemple, où un deuxième routeur peut être ciblé pour afficher une carte X.25.
A. X.25 est pris en charge jusqu'à 2 Mo. Vous pouvez être en mesure de fonctionner à une vitesse supérieure mais, si vous tentez cela, considérez la puissance de processus nécessaire pour gérer 4 095 circuits virtuels à une vitesse de, disons, 34 Mo. Cela aurait un effet négatif, il est donc recommandé de conserver une vitesse de 2 Mo.
A. Oui, l’encapsulation X.25 est prise en charge sur RNIS. X.25 peut être configuré en mode physique ou en mode numéroteur. Pour plus d'informations sur la configuration de X.25 en mode physique, référez-vous à Configuration de X.25. Pour plus d'informations sur la configuration de X.25 en mode de numérotation, référez-vous à Encapsulations multiples dynamiques pour la numérotation sur RNIS. Pour plus d'informations sur la configuration de X.25 sur le canal d, référez-vous à Configuration de X.25 sur RNIS.
A. Oui. Pour plus d'informations, référez-vous à Configuration de groupes d'utilisateurs fermés X.25.
A. Le choix de l'IETF (Internet Engineering Task Force) rend l'encapsulation compatible avec RFC 1356 .
A. La mise en file d'attente par priorité et la mise en file d'attente personnalisée sont prises en charge pour les interfaces X.25 depuis la version 11.3 du logiciel Cisco IOS. Cet exemple montre comment placer un paquet RIP (Routing Information Protocol) dans la file d'attente prioritaire.
interface Serial0 description Connection to Packet Handler ph3.F007 port 11 ip address 10.10.10.1 255.255.255.0 no ip directed-broadcast encapsulation x25 no ip mroute-cache x25 map ip 10.10.10.2 22222 packetsize 128 128 x25 map ip 10.10.10.3 33333 packetsize 128 128 x25 map ip 10.10.10.4 44444 packetsize 128 128 priority-group 2 ! priority-list 2 protocol ip high udp rip priority-list 2 protocol ip lowPour plus d'informations sur la mise en file d'attente prioritaire, référez-vous à Configuration de la mise en file d'attente prioritaire . Pour plus d'informations sur la mise en file d'attente personnalisée, référez-vous à Configuration de la mise en file d'attente personnalisée.
A. Oui, la compression peut être utilisée sur X.25. Exemple :
interface Serial3/0:2 ip address 133.11.102.101 255.255.255.0 encapsulation x25 x25 address 3101 x25 map ip 133.11.102.210 3210 broadcast compressVous avez besoin d'un dictionnaire par circuit virtuel X.25, car le dictionnaire est réinitialisé lorsque le bit M=0 est reçu, et vous pouvez recevoir des fragments X.25 entrelacés avec le bit Mbit=1 sur plusieurs circuits virtuels. Par conséquent, la mémoire requise est de 24 kB * nombre de circuits virtuels pour la compression.
Remarque : L'algorithme de compression est réinitialisé au début de chaque paquet X.25. Cela signifie que la compression de charge utile est plus efficace lorsque de gros paquets sont utilisés.
A. Notez que les diagnostics et les diagnostics ne sont pas tous standard. La plupart des constructeurs X.25 ou des hôtes X.25 appliquent leur propre diagnostic. Si tel est le cas, reportez-vous à la documentation appropriée. Pour plus d'informations sur les diagnostics standard, référez-vous à Codes de cause et de diagnostic X.25.
A. L'expression régulière est un bon outil pour prendre des décisions différentes sur une route X.25. L'expression régulière se trouve dans la documentation Expressions régulières.
A. Reportez-vous à Configuration de DDN ou BFE X.25.
A. Le compteur de retransmission (T1) détermine la durée pendant laquelle une trame envoyée peut rester sans accusé de réception. Pour trouver une valeur appropriée de T1, recherchez la longueur maximale de paquet X.25 (par exemple 128, 256, 1024) et multipliez-la par huit pour obtenir un nombre de bits. Puis divisez par la vitesse de la ligne en Kbits/s. Cela donne le temps de transmission en millisecondes. Le temps de transmission du paquet au commutateur le plus proche est le minimum pour la valeur T1 LAPB. Utilisez un facteur de sécurité de trois ou quatre pour obtenir une valeur T1 en évitant les retransmissions inutiles.
Pour une ligne de 19,2 kbits/s et des paquets de 128 octets, cela conduit à une valeur de 200 ms. Vérifiez les informations fournies par le fournisseur de réseau X.25 qui conseille généralement une valeur.
N'utilisez pas la commande ping pour évaluer le temps de transmission. Cela vous donne le temps sur l'ensemble du réseau, et non sur la liaison à laquelle le compteur s'applique.
A. Oui, le basculement est pris en charge avec X.25. La commande x25 fail-over a été introduite dans le logiciel Cisco IOS Version 12.1(1)T.
A. La fonction de traduction de protocole assure une traduction transparente des protocoles entre les systèmes exécutant différents protocoles. Pour plus d'informations sur la fonction de traduction de protocole, consultez Configuration de la traduction de protocole et des périphériques asynchrones virtuels.