Guide complet de configuration et de dépannage de Frame Relay
Table des matières
Introduction
Le Frame Relay est un standard de l'industrie, un protocole de couche de liaison de données commutées qui gère plusieurs circuits virtuels utilisant l'encapsulation de High-Level Data Link Control (HDLC) entre les périphériques connectés. Dans de nombreux cas, le Frame Relay est plus efficace que le X.25, le protocole pour lequel il est généralement considéré comme le remplacement. La figure suivante montre une trame de Frame Relay (ANSI T1.618).
Notez, dans la figure ci-dessus, que les adresses Q.922, telles qu’elles sont définies actuellement, font deux octets et contiennent un identifiant de connexion de liaison de données (DLCI) de 10 bits. Dans certains réseaux, les adresses Q.922 peuvent éventuellement être augmentées à trois ou quatre octets.
Les champs « flag » (indicateur) délimitent le début et la fin de la trame. Suivant le champ « flag » principal figurent deux octets d’information sur l’adresse. De ces deux octets, dix bits constituent l’identifiant du circuit réel (appelé « DLCI », soit l’identifiant de connexion de liaison de données).
La valeur de 10 bits du DLCI est au cœur de l’en-tête du relayage de trames. Il indique la connexion logique qui est multiplexée dans le canal physique. Dans le mode d’adressage de base (c’est-à-dire non étendu par l’interface de gestion locale [LMI]), les identificateurs DLCI ont une signification locale ; en d’autres termes, les périphériques finaux situés à deux extrémités différentes d’une connexion peuvent utiliser un identificateur DLCI différent pour désigner cette même connexion.
Avant de commencer
Conventions
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Conditions préalables
Pour de plus amples renseignements et des définitions de la terminologie utilisée dans le présent document, consultez le glossaire sur le relayage de trames.
Composants utilisés
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.
Théorie générale
Le relayage de trames a été conçu à l’origine comme un protocole à utiliser sur les interfaces ISDN. Les premières propositions à cet effet ont été soumises au Secteur de la normalisation des télécommunications de l’Union internationale des télécommunications [UIT-T] (anciennement le Comité consultatif international télégraphique et téléphonique [CCITT]) en 1984. Des travaux sur le relayage de trames ont également été entrepris aux États-Unis par le comité des normes T1S1 homologué ANSI.
En 1990, Cisco Systems, StrataCom, Northern Telecom et Digital Equipment Corporation ont formé un consortium pour concentrer le développement de la technologie de relayage de trames et accélérer l’introduction de produits de relayage de trames compatibles. Ils ont élaboré une spécification conforme au protocole de relayage de trames de base abordé dans le T1S1 et l’ITU-T, mais ils l’ont étendue grâce à des fonctionnalités qui ajoutent des capacités pour les environnements complexes d’interréseautage. Ces extensions de relayage de trames sont appelées collectivement « LMI ». Dans le routeur, il s’agit de la LMI « Cisco », contrairement à la LMI « ANSI » ou « Q933a ».
Le relayage de trames offre une capacité de communication de données par commutation de paquets qui est utilisée sur l’interface entre les périphériques utilisateurs (comme les routeurs, les ponts, les machines hôtes) et l’équipement réseau (comme les nœuds de commutation). Les périphériques utilisateurs sont souvent appelés « équipements terminaux de données » (DTE), tandis que les équipements réseau qui interfacent avec les DTE sont quant à eux appelés communément « équipements de terminaison de circuit de données » (DCE). Le réseau qui fournit l’interface de relayage de trames peut être un réseau public d’un fournisseur ou un réseau d’équipement privé desservant une seule entreprise.
Le relayage de trames diffère considérablement de X.25 par sa fonctionnalité et son format. En particulier, le relayage de trames est un protocole simplifié qui améliore la performance et l’efficacité.
En tant qu’interface entre l’utilisateur et l’équipement réseau, le relayage de trames offre un moyen de multiplexer statistiquement de nombreux échanges de données logiques (appelées « circuits virtuels ») sur une seule liaison de transmission physique. Cette solution contraste avec les systèmes qui utilisent seulement des techniques de multiplexage temporel (TDM) pour prendre en charge de multiples flux de données. Le multiplexage statistique de relayage de trames procure une utilisation plus souple et plus efficace de la bande passante disponible. Il peut être utilisé sans les techniques TDM ou sur les canaux fournis par les systèmes TDM.
Une autre caractéristique importante du relayage de trames, c’est qu’il exploite les récents progrès technologiques liés à la transmission par le réseau étendu (WAN). Les protocoles WAN antérieurs, tels que X.25, ont été développés lorsque les systèmes de transmission analogique et les supports en cuivre étaient prédominants. Ces liaisons sont beaucoup moins fiables que les supports de fibre optique ou les liaisons de transmission numérique qui sont offerts actuellement. Par de telles liaisons, les protocoles de la couche de liaison peuvent renoncer à des algorithmes chronophages de correction d’erreurs, qui seront alors exécutés à des couches supérieures du protocole. Or, il est possible d’améliorer les performances et l’efficacité sans sacrifier l’intégrité des données. Le relayage de trames est conçu selon cette approche. Il comprend un algorithme de contrôle de redondance cyclique (CRC) pour détecter les bits corrompus (ainsi, les données peuvent être rejetées), mais il ne possède aucun mécanisme de protocole pour corriger les données erronées (p. ex., en les réacheminant à ce niveau de protocole).
Une autre différence entre le relayage de trames et X.25 réside dans l’absence d’un contrôle de flux explicite par circuit virtuel dans le relayage de trames. Maintenant que de nombreux protocoles de couche supérieure exécutent efficacement leurs propres algorithmes de contrôle de flux, il est moins nécessaire de disposer de cette fonctionnalité au niveau de la couche de liaison. Le relayage de trames ne comporte donc pas de procédures explicites pour le contrôle de flux qui reproduit celui des couches supérieures. Plutôt, des mécanismes très simples de notification d’encombrement sont fournis pour qu’un réseau puisse informer un périphérique utilisateur que les ressources du réseau sont sur le point d’être congestionnées. Cette notification peut signaler aux protocoles de la couche supérieure qu’un contrôle de flux pourrait être requis.
Configuration du relayage de trames de base
Lorsque vous disposez de connexions fiables vers le commutateur local du relayage de trames aux deux extrémités du circuit virtuel permanent (PVC), il est alors temps de commencer à planifier la configuration du relayage de trames. Dans ce premier exemple, le type par défaut de l’interface LMI est « Cisco » sur Spicey. Par défaut, une interface consiste en une interface « multipoint »; or, la fonctionnalité frame-relay inverse-arp est activée (pour la configuration point à point, il n’y a aucun protocole ARP inversé). La vérification de l’horizon partagé de l’IP est désactivée par défaut pour l’encapsulation de relayage de trames. Ainsi, les mises à jour de routage entrent et sortent par la même interface. Les routeurs détectent les identifiants de connexion de liaison de données (DLCI) qu’ils doivent utiliser à partir du commutateur de relayage de trames lors des mises à jour de la LMI. Les routeurs inversent alors l’ARP pour l’adresse IP distante et associent les DLCI locaux avec les adresses IP distantes correspondantes.
Diagramme du réseau
Configurations
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1705 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 ip address 3.1.3.1 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 140 ! ! router rip network 3.0.0.0 network 124.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1499 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! ! interface Serial1 ip address 3.1.3.2 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 150 ! ! router rip network 3.0.0.0 network 123.0.0.0 ! ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Commandes debug et show
Avant d'exécuter les commandes debug, référez-vous à la section Informations importantes sur les commandes Debug.
-
show frame-relay map
-
show frame-relay pvc
-
show frame-relay lmi
-
ping <device name>
-
show ip route
Spicey
Spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
broadcast,, status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 83 output pkts 87 in bytes 8144
out bytes 8408 dropped pkts 0 in FECN pkts0
in BECN pkts 0 out FECN pkts 0 out BECN pkts0
in DE pkts 0 out DE pkts 0
out bcast pkts 41 out bcast bytes 3652
pvc create time 01:31:50, last time pvc status changed 01:28:28
Spicey#show frame-relay lmi
LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 550 Num Status msgs Rcvd 552
Num Update Status Rcvd 0 Num Status Timeouts 0
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
Spicey#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.3.0 is directly connected, Serial0
124.0.0.0/24 is subnetted, 1 subnets
C 124.124.124.0 is directly connected, Ethernet0
R 123.0.0.0/8 [120/1] via 3.1.3.2, 00:00:08, Serial0
Prasit
Prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 87 output pkts 83 in bytes 8408
out bytes 8144 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 38 out bcast bytes 3464
pvc create time 01:34:29, last time pvc status changed 01:28:05
Prasit#show frame-relay lmi
LMI Statistics for interface Serial1 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 569 Num Status msgs Rcvd 570
Num Update Status Rcvd 0 Num Status Timeouts 0
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.3.0 is directly connected, Serial1
R 124.0.0.0/8 [120/1] via 3.1.3.1, 00:00:19, Serial1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
Configuration du relayage de trames à topologie en étoile
Dans cet exemple, le routeur détecte les identifiants DLCI qu’il utilise à partir du commutateur de relais de trames et les attribue à l’interface principale. Ensuite, le routeur inversera l’ARP pour l’adresse IP distante.
Remarque : vous ne pourrez pas envoyer de requête ping à l'adresse IP série de Prasit à partir d'Aton, sauf si vous ajoutez explicitement des cartes Frame Relay à chaque extrémité. Si le routage est configuré correctement, le trafic provenant des réseaux locaux ne devrait pas poser problème. Vous pourrez envoyer un message Ping si vous utilisez l’adresse IP Ethernet comme adresse source dans un Ping prolongé.
Lorsque la fonctionnalité frame-relay inverse-arp est activée, le trafic IP de diffusion est transmis par la connexion par défaut.
Diagramme du réseau
Configurations
| Spicey |
|---|
spicey#show running-config Building configuration... ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname spicey ! ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 ip address 3.1.3.1 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 130 frame-relay interface-dlci 140 ! ! router rip network 3.0.0.0 network 124.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
prasit#show running-config Building configuration... Current configuration : 1499 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.2 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 150 ! ! router rip network 3.0.0.0 network 123.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Aton |
|---|
aton#show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname aton ! ! interface Ethernet0 ip address 122.122.122.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.3 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 160 ! router rip network 3.0.0.0 network 122.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Commandes show
-
show frame-relay map
-
show frame-relay pvc
-
ping <device name>
Spicey
spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
broadcast,, status defined, active
Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,
broadcast,, status defined, active
spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 32 output pkts 40 in bytes 3370
out bytes 3928 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 30 out bcast bytes 2888
pvc create time 00:15:46, last time pvc status changed 00:10:42
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 282 output pkts 291 in bytes 25070
out bytes 27876 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 223 out bcast bytes 20884
pvc create time 02:28:36, last time pvc status changed 02:25:14
spicey#
spicey#ping 3.1.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
spicey#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Prasit
prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 311 output pkts 233 in bytes 28562
out bytes 22648 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 162 out bcast bytes 15748
pvc create time 02:31:39, last time pvc status changed 02:25:14
prasit#ping 3.1.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
prasit#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Aton
aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
broadcast,, status defined, active
aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 35 output pkts 32 in bytes 3758
out bytes 3366 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 27 out bcast bytes 2846
pvc create time 00:10:53, last time pvc status changed 00:10:53
aton#ping 3.1.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
aton#ping 3.1.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Connexion rayon à rayon (spoke-to-spoke)
Vous ne pouvez pas envoyer un message Ping d’un rayon à une autre dans une configuration en étoile au moyen d’interfaces multipoints, car il n’y a pas de mappage pour les adresses IP des autres rayons. Seule l’adresse du concentrateur est détectée grâce au protocole IARP (Inverse Address Resolution Protocol). Si vous configurez une carte statique à l’aide de la commande « frame-relay map » afin que l’adresse IP d’un rayon distant utilise l’identifiant DLCI, vous pouvez alors envoyer un message Ping aux adresses des autres rayons.
Configurations
| Prasit |
|---|
prasit#show running-config interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial ip address 3.1.3.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 3.1.3.3 150 frame-relay interface-dlci 150 |
Commandes show
-
show frame-relay map
-
ping <device name>
-
show running-config
Prasit
prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
Serial1 (up): ip 3.1.3.3 dlci 150(0x96,0x2460), static,
CISCO, status defined, active
prasit#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/70/80 ms
prasit#ping 122.122.122.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/76 ms
Aton
aton#show running-config
interface Ethernet0
ip address 122.122.122.1 255.255.255.0
!
interface Serial1
ip address 3.1.3.3 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay
frame-relay map ip 3.1.3.2 160
frame-relay interface-dlci 160
aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
broadcast,, status defined, active
Serial1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static,
CISCO, status defined, active
aton#ping 3.1.3.2
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms
aton#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/80 ms
Configuration des sous-interfaces du relayage de trames
Les sous-interfaces de relayage de trames offrent un mécanisme qui sert à prendre en charge des réseaux de relayage de trames partiellement maillés. La plupart des protocoles supposent une transitivité sur un réseau logique ; c'est-à-dire que si la station A peut parler à la station B et que la station B peut parler à la station C, alors la station A doit pouvoir parler directement à la station C. La transition est vraie sur les réseaux locaux, mais pas sur les réseaux à relayage de trames, sauf si A est directement connecté à C.
En outre, certains protocoles, comme AppleTalk et le pont transparent, ne peuvent pas être pris en charge sur les réseaux partiellement maillés, car ils nécessitent un « horizon partagé » dans lequel un paquet qui est reçu sur une interface ne peut être transmis par cette même interface, et ce, même si le paquet est reçu et transmis sur différents circuits virtuels.
La configuration des sous-interfaces de relayage de trames garantit qu’une seule interface physique est traitée comme plusieurs interfaces virtuelles. Cette capacité nous permet de contourner les règles de l’horizon partagé. Les paquets reçus sur une interface virtuelle peuvent maintenant être transférés vers une autre interface virtuelle, même s’ils sont configurés sur la même interface physique.
Les sous-interfaces lèvent les contraintes des réseaux de relayage de trames en offrant une façon de subdiviser un réseau de relayage de trames partiellement maillé en des sous-réseaux plus petits, entièrement maillés (ou point à point). Chaque sous-réseau se voit attribuer son propre numéro de réseau et il apparaît aux protocoles comme s’il était accessible par une interface distincte. (Notez que les sous-interfaces point à point peuvent être non numérotées pour une utilisation avec IP, diminuant ainsi la charge de l’adressage qui pourrait en découler.)
Sous-interfaces point à point
Diagramme du réseau
Configurations
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1338 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! enable password ww ! ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay ! interface Serial0.1 point-to-point ip address 3.1.3.1 255.255.255.0 frame-relay interface-dlci 140 ! ! router igrp 2 network 3.0.0.0 network 124.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1234 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point ip address 3.1.3.2 255.255.255.0 frame-relay interface-dlci 150 ! router igrp 2 network 3.0.0.0 network 123.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Commandes show
-
show frame-relay map
-
show frame-relay pvc
Spicey
Spicey#show frame-relay map
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1
input pkts 193 output pkts 175 in bytes 20450
out bytes 16340 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 50 out bcast bytes 3786
pvc create time 01:11:27, last time pvc status changed 00:42:32
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit
Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1
input pkts 74 output pkts 89 in bytes 7210
out bytes 10963 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 24 out bcast bytes 4203
pvc create time 00:12:25, last time pvc status changed 00:12:25
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Sous-interfaces en étoile (hub and spoke)
L’exemple de configuration en étoile suivant présente deux sous-interfaces point à point et utilise une résolution d’adresse dynamique sur un site distant. Chaque sous-interface est accompagnée d’une adresse de protocole individuelle et d’un masque de sous-réseau, et la commande interface-dlci associe la sous-interface à un identifiant DLCI précisé. Les problèmes d’adresses des destinations distantes pour chaque sous-interface point à point ne sont pas résolus, car ces adresses ont la configuration point à point, et le trafic doit être envoyé à l’homologue se trouvant à l’autre extrémité. L’extrémité à distance (Aton) utilise le protocole ARP inversé pour son mappage, et le concentrateur principal répond en conséquence avec l’adresse IP de la sous-interface. Cela se produit, car le relayage de trames de l’ARP inversé est activé par défaut pour les interfaces multipoints.
Diagramme du réseau
Configurations
| Spicey |
|---|
Spicey#show running-config Building configuration... ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay ! interface Serial0.1 point-to-point ip address 4.0.1.1 255.255.255.0 frame-relay interface-dlci 140 ! interface Serial0.2 point-to-point ip address 3.1.3.1 255.255.255.0 frame-relay interface-dlci 130 ! router igrp 2 network 3.0.0.0 network 4.0.0.0 network 124.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point ip address 4.0.1.2 255.255.255.0 frame-relay interface-dlci 150 ! router igrp 2 network 4.0.0.0 network 123.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Aton |
|---|
Aton#show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime ! hostname Aton ! ! ! interface Ethernet0 ip address 122.122.122.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.3 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 160 ! router igrp 2 network 3.0.0.0 network 122.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Commandes show
-
show frame-relay map
-
show frame-relay pvc
Spicey
Spicey#show frame-relay map
Serial0.2 (up): point-to-point dlci, dlci 130(0x82,0x2020), broadcast
status defined, active
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.2
input pkts 11 output pkts 22 in bytes 1080
out bytes 5128 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 17 out bcast bytes 4608
pvc create time 00:06:36, last time pvc status changed 00:06:36
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1
input pkts 33 output pkts 28 in bytes 3967
out bytes 5445 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 17 out bcast bytes 4608
pvc create time 00:06:38, last time pvc status changed 00:06:38
Spicey#ping 122.122.122.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit
Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1
input pkts 45 output pkts 48 in bytes 8632
out bytes 6661 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 31 out bcast bytes 5573
pvc create time 00:12:16, last time pvc status changed 00:06:23
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Aton
Aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
broadcast,, status defined, active
Aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 699 output pkts 634 in bytes 81290
out bytes 67008 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 528 out bcast bytes 56074
pvc create time 05:46:14, last time pvc status changed 00:05:57
Aton#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Configuration du mappage dynamique et statique pour des sous-interfaces multipoints
Le mappage d’adresses dynamiques utilise l’ARP du relayage de trames pour demander l’adresse du protocole de saut suivant pour une connexion en particulier, à partir d’un identifiant DLCI. Les réponses aux requêtes ARP inverse sont entrées dans une table de mappage adresse-DLCI sur le routeur ou le serveur d’accès ; la table est ensuite utilisée pour fournir l’adresse de protocole du tronçon suivant ou le DLCI pour le trafic sortant.
Étant donné que l’interface physique est maintenant configurée comme plusieurs sous-interfaces, vous devez fournir des renseignements qui distinguent une sous-interface de l’interface physique et qui associent une sous-interface donnée à un identifiant DLCI précis.
L’ARP inversé est activé par défaut pour tous les protocoles qu’il prend en charge, mais il peut être désactivé pour des paires protocole-DLCI données. Par conséquent, vous pouvez utiliser le mappage dynamique pour certains protocoles et le mappage statique pour d’autres protocoles associés au même DLCI. Vous pouvez explicitement désactiver l’ARP inversé pour une paire protocole-DLCI si vous savez que le protocole n’est pas pris en charge à l’autre extrémité de la connexion. Comme l’ARP inversé est activé par défaut pour tous les protocoles qu’il prend en charge, aucune autre commande n’est requise pour configurer le mappage d’adresses dynamiques sur une sous-interface. Une carte statique relie une adresse du protocole de saut suivant à un identifiant DLCI précis. Le mappage statique supprime le besoin de requêtes de protocole ARP inverse ; lorsque vous fournissez un mappage statique, le protocole ARP inverse est automatiquement désactivé pour le protocole spécifié sur le DLCI spécifié. Vous devez utiliser le mappage statique si le routeur à l’autre extrémité ne prend pas du tout en charge l’ARP inversé ou s’il ne prend pas en charge l’ARP inversé pour le protocole que vous souhaitez utiliser pour le relayage de trames.
Diagramme du réseau
Nous avons déjà vu comment configurer un routeur Cisco pour obtenir l’ARP inversé. L’exemple suivant montre comment configurer des cartes statiques au cas où vous en auriez besoin pour des interfaces ou des sous-interfaces multipoints :
Configurations
| Aton |
|---|
Aton#show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Aton ! ! interface Ethernet0 ip address 122.122.122.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 multipoint ip address 4.0.1.3 255.255.255.0 frame-relay map ip 4.0.1.1 160 broadcast ! router igrp 2 network 4.0.0.0 network 122.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Spicey |
|---|
Spicey#show running-config Building configuration...Current configuration : 1652 bytes! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 ip address 4.0.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 4.0.1.2 140 broadcast frame-relay map ip 4.0.1.3 130 broadcast ! router igrp 2 network 4.0.0.0 network 124.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1162 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 multipoint ip address 4.0.1.2 255.255.255.0 frame-relay map ip 4.0.1.1 150 broadcast ! router igrp 2 network 4.0.0.0 network 123.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Commandes debug et show
-
show frame-relay map
-
show frame-relay pvc
Aton
Aton#show frame-relay map
Serial1.1 (up): ip 4.0.1.1 dlci 160(0xA0,0x2800), static, broadcast,
CISCO, status defined, active
Aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1
input pkts 16 output pkts 9 in bytes 3342
out bytes 450 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 9 out bcast bytes 450
pvc create time 00:10:02, last time pvc status changed 00:10:02
Aton#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Spicey
Spicey#show frame-relay map
Serial0 (up): ip 4.0.1.2 dlci 140(0x8C,0x20C0), static, broadcast,
CISCO, status defined, active
Serial0 (up): ip 4.0.1.3 dlci 130(0x82,0x2020), static, broadcast,
CISCO, status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 9 output pkts 48 in bytes 434
out bytes 11045 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 48 out bcast bytes 11045
pvc create time 00:36:25, last time pvc status changed 00:36:15
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 17 output pkts 26 in bytes 1390
out bytes 4195 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 16 out bcast bytes 3155
pvc create time 00:08:39, last time pvc status changed 00:08:39
Spicey#ping 122.122.122.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36
Prasit
Prasit#show frame-relay map
Serial1.1 (up): ip 4.0.1.1 dlci 150(0x96,0x2460), static,
broadcast,
CISCO, status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.1
input pkts 28 output pkts 19 in bytes 4753
out bytes 1490 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 9 out bcast bytes 450
pvc create time 00:11:00, last time pvc status changed 00:11:00
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Pour en savoir plus sur ces commandes, consultez Commandes de relayage de trames.
Configuration du relayage de trames non numérotée de l’IP
Si vous ne disposez pas de l’espace d’adressage IP suffisant pour utiliser de nombreuses sous-interfaces, vous pouvez toujours utiliser l’adresse IP non numérotée sur chaque sous-interface. Dans un tel cas, vous devez utiliser des routes statiques ou dynamiques pour que votre trafic soit acheminé comme d’habitude, et vous devez utiliser des sous-interfaces point à point.
Diagramme du réseau
Voici ce qu’illustre l’exemple ci-dessous :
Configurations
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1674 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay ! interface Serial0.1 point-to-point ip unnumbered Ethernet0 frame-relay interface-dlci 140 ! router igrp 2 network 124.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1188 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point ip unnumbered Ethernet0 frame-relay interface-dlci 150 ! router igrp 2 network 123.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Commandes show
-
show frame-relay map
-
show frame-relay pvc
Spicey
Spicey#show frame-relay map
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial0.1
input pkts 23 output pkts 24 in bytes 3391
out bytes 4952 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 14 out bcast bytes 3912
pvc create time 00:04:47, last time pvc status changed 00:04:47
Spicey#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
124.0.0.0/24 is subnetted, 1 subnets
C 124.124.124.0 is directly connected, Ethernet0
123.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
I 123.0.0.0/8 [100/8576] via 123.123.123.1, 00:01:11, Serial0.1
I 123.123.123.0/32 [100/8576] via 123.123.123.1, 00:01:11,
Serial0.1
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit
Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1
input pkts 24 output pkts 52 in bytes 4952
out bytes 10892 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 41 out bcast bytes 9788
pvc create time 00:10:54, last time pvc status changed 00:03:51
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
I 124.0.0.0/8 [100/8576] via 124.124.124.1, 00:00:18, Serial1.1
I 124.124.124.0/32 [100/8576] via 124.124.124.1, 00:00:18,
Serial1.1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/120/436 ms
Configuration de la sauvegarde du relayage de trames
Sauvegarde du relayage de trames sur le réseau ISDN
Vous pourriez vouloir sauvegarder les circuits de relayage de trames en utilisant l’ISDN. Il existe plusieurs façons de le faire. La première façon, et probablement la meilleure, consiste à utiliser des routes statiques flottantes qui acheminent le trafic vers une adresse IP d’interface de débit de base (BRI) et à utiliser un indicateur de routage approprié. Vous pouvez également utiliser une interface de sauvegarde sur l’interface principale ou sur une base d’identifiant DLCI. Il se peut que la sauvegarde de l’interface principale ne soit pas bien utile, car vous pourriez perdre des circuits virtuels permanents sans que l’interface principale cesse de fonctionner. Rappelez-vous que le protocole est échangé avec le commutateur local de relayage de trames et non avec le routeur distant.
Configurations
| Routeur 1 |
|---|
ROUTER1# ! hostname ROUTER1 ! username ROUTER2 password same isdn switch-type basic-dms100 ! interface Ethernet 0 ip address 172.16.15.1 255.255.255.248 ! interface serial 0 ip address 172.16.24.129 255.255.255.128 encapsulation FRAME-RELAY ! interface BRI0 description Backup ISDN for frame-relay ip address 172.16.12.1 255.255.255.128 encapsulation PPP dialer idle-timeout 240 dialer wait-for-carrier-time 60 dialer map IP 172.16.12.2 name ROUTER2 broadcast 7086639706 ppp authentication chap dialer-group 1 isdn spid1 0127280320 2728032 isdn spid2 0127295120 2729512 ! router igrp 1 network 172.16.0.0 ! ip route 172.16.15.16 255.255.255.248 172.16.12.2 150 !--- Floating static route. ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 dialer-list 1 LIST 101 ! |
| Routeur 2 |
|---|
ROUTER2# ! hostname ROUTER2 ! username ROUTER1 password same isdn switch-type basic-dms100 ! interface Ethernet 0 ip address 172.16.15.17 255.255.255.248 ! interface Serial 0 ip address 172.16.24.130 255.255.255.128 encapsulation FRAME-RELAY ! interface BRI0 description ISDN backup interface for frame-relay ip address 172.16.12.2 255.255.255.128 encapsulation PPP dialer idle-timeout 240 dialer map IP 172.16.12.1 name ROUTER1 broadcast ppp authentication chap pulse-time 1 dialer-group 1 isdn spid1 0191933333 4445555 isdn spid2 0191933334 4445556 ! router igrp 1 network 172.16.0.0 ! ip route 172.16.15.0 255.255.255.248 172.16.12.1 150 !--- Floating static route. ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 162.27.9.0 0.0.0.255 dialer-list 1 LIST 101 ! |
Commandes show
Pour vérifier si l’ISDN fonctionne, utilisez les commandes de débogage suivantes. Avant d'exécuter les commandes debug, référez-vous à la section Informations importantes sur les commandes Debug.
-
debug isdn q931
-
debug ppp neg
-
debug ppp auth
Essayez de passer un appel ISDN du côté appelant au côté central sans les commandes de sauvegarde. Si vous réussissez, ajoutez les commandes de sauvegarde au côté appelant.
Remarque : pour tester la sauvegarde, n'utilisez pas la commande shutdown sur l'interface série, mais émulez un véritable problème de ligne série en retirant le câble de la ligne série.
Configuration par la sauvegarde de l’interface DCLI
Supposons maintenant que Spicey est le côté central et que Prasit est le côté qui établit les connexions avec le côté central (Spicey). Veillez à ajouter les commandes de sauvegarde uniquement au côté qui communique avec le côté central.
Remarque : la charge de sauvegarde n'est pas prise en charge sur les sous-interfaces. Comme nous ne faisons aucun suivi des niveaux de trafic sur les sous-interfaces, aucune charge n’est calculée.
Diagramme du réseau
Configurations
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1438 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! username Prasit password 0 cisco ! ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay ! interface Serial0.1 point-to-point ip address 4.0.1.1 255.255.255.0 frame-relay interface-dlci 140 ! interface BRI0 ip address 3.1.6.1 255.255.255.0 encapsulation ppp dialer map ip 3.1.6.2 name Prasit broadcast dialer-group 1 isdn switch-type basic-net3 no peer default ip address no cdp enable ppp authentication chap ! router igrp 2 network 3.0.0.0 network 4.0.0.0 network 124.0.0.0 ! ip classless ip route 123.123.123.0 255.255.255.0 3.1.6.2 250 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1245 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! username Spicey password 0 cisco ! ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point backup delay 5 10 backup interface BRI0 ip address 4.0.1.2 255.255.255.0 frame-relay interface-dlci 150 ! interface BRI0 ip address 3.1.6.2 255.255.255.0 encapsulation ppp dialer map ip 3.1.6.1 name Spicey broadcast 6106 dialer-group 1 isdn switch-type basic-net3 ppp authentication chap ! router igrp 2 network 3.0.0.0 network 4.0.0.0 network 123.0.0.0 ! ip route 124.124.124.0 255.255.255.0 3.1.6.1 250 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Commandes show
-
show frame-relay map
-
show ip route
-
show isdn history
-
show isdn status
-
show interface bri 0
-
show isdn active
Spicey
Spicey#show frame-relay map
Serial0.2 (up): point-to-point dlci, dlci 130(0x82,0x2020), broadcast
status defined, active
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
status defined, active
Spicey#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 2 subnets C
3.1.3.0 is directly connected, Serial0.2 C
3.1.6.0 is directly connected, BRI0
4.0.0.0/24 is subnetted, 1 subnets C
4.0.1.0 is directly connected, Serial0.1
124.0.0.0/24 is subnetted, 1 subnets C
124.124.124.0 is directly connected, Ethernet0
123.0.0.0/8 is variably subnetted, 2 subnets, 2 masks I
123.0.0.0/8 [100/8576] via 4.0.1.2, 00:00:00, Serial0.1 S
123.123.123.0/24 [250/0] via 3.1.6.2 I
122.0.0.0/8 [100/8576] via 3.1.3.3, 00:00:37, Serial0.2
Spicey#
*Mar 1 00:59:12.527: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar 1 00:59:13.983: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
*Mar 1 00:59:18.547: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6105 Prasit
Spicey#show isdn history
--------------------------------------------------------------------------------
ISDN CALL HISTORY
--------------------------------------------------------------------------------
Call History contains all active calls, and a maximum of 100 inactive calls.
Inactive call data will be retained for a maximum of 15 minutes.
--------------------------------------------------------------------------------
Call Calling Called Remote Seconds Seconds Seconds
Charges
Type Number Number Name Used Left Idle Units/Currency
--------------------------------------------------------------------------------
In 6105 6106 Prasit 31 90 29
--------------------------------------------------------------------------------
Spicey#
*Mar 1 01:01:14.547: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected
from 6105 Prasit, call lasted 122 seconds
*Mar 1 01:01:14.663: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 1 01:01:15.663: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to down
Prasit
Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
status defined, active
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
I 3.0.0.0/8 [100/10476] via 4.0.1.1, 00:00:55, Serial1.1
4.0.0.0/24 is subnetted, 1 subnets
C 4.0.1.0 is directly connected, Serial1.1
124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
S 124.124.124.0/24 [250/0] via 3.1.6.1
I 124.0.0.0/8 [100/8576] via 4.0.1.1, 00:00:55, Serial1.1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
I 122.0.0.0/8 [100/10576] via 4.0.1.1, 00:00:55, Serial1.1
La ligne série cesse de fonctionner.
Prasit#
*Mar 1 01:23:50.531: %LINK-3-UPDOWN: Interface Serial1, changed state to down
*Mar 1 01:23:51.531: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial1, changed state to down
*Mar 1 01:23:53.775: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 1 01:23:53.791: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
*Mar 1 01:23:53.827: %LINK-3-UPDOWN: Interface BRI0, changed state to up
*Mar 1 01:23:57.931: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 64 changed to up
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF,IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.6.0 is directly connected, BRI0
124.0.0.0/24 is subnetted, 1 subnets
S 124.124.124.0 [250/0] via 3.1.6.1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
Prasit#show isdn status
Global ISDN Switchtype = basic-net3
ISDN BRI0 interface
dsl 0, interface ISDN Switchtype = basic-net3
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80000003
Total Allocated ISDN CCBs = 0
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!
*Mar 1 01:25:47.383: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms
Prasit#
*Mar 1 01:25:48.475: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
Prasit#
*Mar 1 01:25:53.407: %ISDN-6-CONNECT: Interface BRI0:1 is now connected
to 6106 Spicey
Prasit#show isdn status
Global ISDN Switchtype = basic-net3
ISDN BRI0 interface
dsl 0, interface ISDN Switchtype = basic-net3
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
1 Active Layer 3 Call(s)
CCB:callid=8003, sapi=0, ces=1, B-chan=1, calltype=DATA
Active dsl 0 CCBs = 1
The Free Channel Mask: 0x80000002
Total Allocated ISDN CCBs = 1
Prasit#show isdn active
--------------------------------------------------------------------------------
ISDN ACTIVE CALLS
--------------------------------------------------------------------------------
Call Calling Called Remote Seconds Seconds Seconds Charges
Type Number Number Name Used Left Idle Units/Currency
--------------------------------------------------------------------------------
Out 6106 Spicey 21 100 19 0
--------------------------------------------------------------------------------
Prasit#
*Mar 1 01:27:49.027: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected
from 6106 Spicey, call lasted 121 seconds
*Mar 1 01:27:49.131: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 1 01:27:50.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to down
*Mar 1 01:28:09.215: %LINK-3-UPDOWN: Interface Serial1, changed state to up
*Mar 1 01:28:10.215: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial1, changed state to up
*Mar 1 01:28:30.043: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0,
TEI 64 changed to down
*Mar 1 01:28:30.047: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI
64 changed to down
*Mar 1 01:28:30.371: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode
*Mar 1 01:28:30.387: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 1 01:28:30.403: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
Prasit#
La connexion série est rétablie.
Prasit#show isdn status
Global ISDN Switchtype = basic-net3
ISDN BRI0 interface
dsl 0, interface ISDN Switchtype = basic-net3
Layer 1 Status:
DEACTIVATED
Layer 2 Status:
Layer 2 NOT Activated
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80000003
Total Allocated ISDN CCBs = 0
Prasit#show interface bri 0
BRI0 is standby mode, line protocol is down
Hardware is BRI
Internet address is 3.1.6.2/24
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set
Last input 00:01:00, output 00:01:00, output hang never
Last clearing of "show interface" counters 01:28:16
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
128 packets input, 601 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
132 packets output, 687 bytes, 0 underruns
0 output errors, 0 collisions, 10 interface resets
0 output buffer failures, 0 output buffers swapped out
14 carrier transitions
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Topologie en étoile avec profils de ligne
Voici un exemple de configuration en étoile par DLCI de secours. Les routeurs de rayon appellent le routeur du concentrateur. Comme vous pouvez le constater, nous autorisons un seul canal B par côté au moyen de l’option « max-link » sur le groupe du numéroteur du côté du concentrateur.
Remarque : la charge de sauvegarde n'est pas prise en charge sur les sous-interfaces. Comme nous ne faisons aucun suivi des niveaux de trafic sur les sous-interfaces, aucune charge n’est calculée.
Diagramme du réseau
Configurations
| Aton |
|---|
Aton#show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Aton ! ! username Spicey password 0 cisco ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 122.122.122.1 255.255.255.0 ! ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point ip address 3.1.3.3 255.255.255.0 backup delay 5 10 backup interface BRI0 frame-relay interface-dlci 160 ! interface BRI0 ip address 155.155.155.3 255.255.255.0 encapsulation ppp no ip route-cache no ip mroute-cache dialer map ip 155.155.155.2 name Spicey broadcast 6106 dialer-group 1 isdn switch-type basic-net3 ppp authentication chap ! router igrp 2 network 3.0.0.0 network 122.0.0.0 network 155.155.0.0 ! ip route 124.124.124.0 255.255.255.0 155.155.155.2 250 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1887 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! username Prasit password 0 cisco username Aton password 0 cisco ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay ! interface Serial0.1 point-to-point ip address 4.0.1.1 255.255.255.0 frame-relay interface-dlci 140 ! interface Serial0.2 point-to-point ip address 3.1.3.1 255.255.255.0 frame-relay interface-dlci 130 ! interface BRI0 no ip address encapsulation ppp no ip route-cache no ip mroute-cache dialer pool-member 2 max-link 1 dialer pool-member 1 max-link 1 isdn switch-type basic-net3 no peer default ip address no cdp enable ppp authentication chap ! interface Dialer1 ip address 160.160.160.1 255.255.255.0 encapsulation ppp no ip route-cache no ip mroute-cache dialer pool 1 dialer remote-name Prasit dialer-group 1 ppp authentication chap ! interface Dialer2 ip address 155.155.155.2 255.255.255.0 encapsulation ppp no ip route-cache no ip mroute-cache dialer pool 2 dialer remote-name Aton dialer-group 1 ppp authentication chap ! router igrp 2 network 3.0.0.0 network 4.0.0.0 network 124.0.0.0 network 155.155.0.0 network 160.160.0.0 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1267 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! username Spicey password 0 cisco ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point backup delay 5 10 backup interface BRI0 ip address 4.0.1.2 255.255.255.0 frame-relay interface-dlci 150 ! interface BRI0 ip address 160.160.160.2 255.255.255.0 encapsulation ppp dialer map ip 160.160.160.1 name Spicey broadcast 6106 dialer-group 1 isdn switch-type basic-net3 ppp authentication chap ! router igrp 2 network 4.0.0.0 network 123.0.0.0 network 160.160.0.0 ! ip route 124.124.124.0 255.255.255.0 160.160.160.1 250 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Commandes show
-
show frame-relay map
-
show ip route
-
show frame map
-
show frame-relay pvc
Aton
Aton#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast
status defined, active
Aton#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Aton#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
I 155.155.0.0/16 [100/182571] via 3.1.3.1, Serial1.1
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.3.0 is directly connected, Serial1.1
I 4.0.0.0/8 [100/10476] via 3.1.3.1, Serial1.1
I 160.160.0.0/16 [100/182571] via 3.1.3.1, Serial1.1
124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
S 124.124.124.0/24 [250/0] via 155.155.155.2
I 124.0.0.0/8 [100/8576] via 3.1.3.1, Serial1.1
I 123.0.0.0/8 [100/10576] via 3.1.3.1, Serial1.1
122.0.0.0/24 is subnetted, 1 subnets
C 122.122.122.0 is directly connected, Ethernet0
Aton#
La série 1 cesse de fonctionner.
Aton#
01:16:33: %LINK-3-UPDOWN: Interface Serial1, changed state to down
01:16:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1,
changed state to down
01:16:37: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
01:16:37: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
01:16:37: %LINK-3-UPDOWN: Interface BRI0, changed state to up
01:16:41: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 64 changed to up
Aton#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
155.155.0.0/24 is subnetted, 1 subnets
C 155.155.155.0 is directly connected, BRI0
124.0.0.0/24 is subnetted, 1 subnets
S 124.124.124.0 [250/0] via 155.155.155.2
122.0.0.0/24 is subnetted, 1 subnets
C 122.122.122.0 is directly connected, Ethernet0
Aton#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
01:21:33: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms
Aton#
01:21:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed state to up
01:21:39: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6106
Spicey
Aton#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/123/296 ms
Aton#
La série 1 est rétablie.
Aton#
01:24:02: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 6106
Spicey, call lasted 149 seconds
01:24:02: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
01:24:03: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed state to down
Aton#show frame map
Serial1.1 (down): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast
status deleted
Aton#
01:26:35: %LINK-3-UPDOWN: Interface Serial1, changed state to up
01:26:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1,
changed state to up
01:26:56: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0, TEI 64 changed
to down
01:26:56: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI 64 changed
to down
01:26:56: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode
01:26:56: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
01:26:56: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
Aton#show frame map
Serial1.1 (up): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast
status defined, active
Aton#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Aton#ping 124.124.124.1
Aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1
input pkts 60 output pkts 69 in bytes 9694
out bytes 10811 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 44 out bcast bytes 7565
pvc create time 01:28:35, last time pvc status changed 00:02:19
Spicey
Spicey#show frame-relay map
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
status defined, active
Serial0.2 (up): point-to-point dlci, dlci 130(0x82,0x2020), broadcast
status defined, active
Spicey#ping 122.122.122.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Spicey#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
155.155.0.0/24 is subnetted, 1 subnets
C 155.155.155.0 is directly connected, Dialer2
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.3.0 is directly connected, Serial0.2
4.0.0.0/24 is subnetted, 1 subnets
C 4.0.1.0 is directly connected, Serial0.1
160.160.0.0/24 is subnetted, 1 subnets
C 160.160.160.0 is directly connected, Dialer1
124.0.0.0/24 is subnetted, 1 subnets
C 124.124.124.0 is directly connected, Ethernet0
I 123.0.0.0/8 [100/8576] via 4.0.1.2, 00:00:55, Serial0.1
I 122.0.0.0/8 [100/8576] via 3.1.3.3, 00:00:35, Serial0.2
Les deux lignes série du côté appelant cessent de fonctionner.
Spicey#
*Mar 1 01:21:30.171: %LINK-3-UPDOWN: Interface BRI0:1, changed state toup
*Mar 1 01:21:30.627: %DIALER-6-BIND: Interface BR0:1 bound to profile Di2
*Mar 1 01:21:31.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
*Mar 1 01:21:36.191: %ISDN-6-CONNECT: Interface BRI0:1 is now connected
to 6104 Aton
*Mar 1 01:21:40.923: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar 1 01:21:41.359: %DIALER-6-BIND: Interface BR0:2 bound to profile Di1
*Mar 1 01:21:42.383: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:2, changed state to up
*Mar 1 01:21:46.943: %ISDN-6-CONNECT: Interface BRI0:2 is now connected
to 6105 Prasit
*Mar 1 01:23:59.819: %DIALER-6-UNBIND: Interface BR0:1 unbound from
profile Di2
*Mar 1 01:23:59.831: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected
from 6104 Aton, call lasted 149 seconds
*Mar 1 01:23:59.927: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 1 01:24:00.923: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to down
*Mar 1 01:24:03.015: %DIALER-6-UNBIND: Interface BR0:2 unbound from
profile Di1
*Mar 1 01:24:03.023: %ISDN-6-DISCONNECT: Interface BRI0:2 disconnected
from 6105 Prasit, call lasted 142 seconds
*Mar 1 01:24:03.107: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
*Mar 1 01:24:04.107: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:2, changed state to down
Spicey#show frame map
Serial0.1 (down): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
status defined, inactive
Serial0.2 (down): point-to-point dlci, dlci 130(0x82,0x2020), broadcast
status defined, inactive
Spicey#
Les deux lignes série sont rétablies.
Spicey#show frame pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial0.2
input pkts 54 output pkts 61 in bytes 7014
out bytes 9975 dropped pkts 3 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 40 out bcast bytes 7803
pvc create time 01:28:14, last time pvc status changed 00:02:38
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial0.1
input pkts 56 output pkts 60 in bytes 7604
out bytes 10114 dropped pkts 2 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 39 out bcast bytes 7928
pvc create time 01:28:15, last time pvc status changed 00:02:29
Prasit
Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
status defined, active
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
I 155.155.0.0/16 [100/182571] via 4.0.1.1, 00:00:41, Serial1.1
I 3.0.0.0/8 [100/10476] via 4.0.1.1, 00:00:41, Serial1.1
4.0.0.0/24 is subnetted, 1 subnets
C 4.0.1.0 is directly connected, Serial1.1
I 160.160.0.0/16 [100/182571] via 4.0.1.1, 00:00:41, Serial1.1
124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
S 124.124.124.0/24 [250/0] via 160.160.160.1
I 124.0.0.0/8 [100/8576] via 4.0.1.1, 00:00:41, Serial1.1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
I 122.0.0.0/8 [100/10576] via 4.0.1.1, 00:00:42, Serial1.1
Prasit#
La série 1 cesse de fonctionner.
Prasit#
*Mar 1 01:16:08.287: %LINK-3-UPDOWN: Interface Serial1, changed state to down
*Mar 1 01:16:09.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial1, changed state to down
*Mar 1 01:16:11.803: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 1 01:16:11.819: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
*Mar 1 01:16:11.855: %LINK-3-UPDOWN: Interface BRI0, changed state to up
*Mar 1 01:16:15.967: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI
64 changed to up
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
160.160.0.0/24 is subnetted, 1 subnets
C 160.160.160.0 is directly connected, BRI0
124.0.0.0/24 is subnetted, 1 subnets
S 124.124.124.0 [250/0] via 160.160.160.1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
*Mar 1 01:21:38.967: %LINK-3-UPDOWN: Interface BRI0:1, changed state to
up.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms
Prasit#
*Mar 1 01:21:40.063: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
*Mar 1 01:21:44.991: %ISDN-6-CONNECT: Interface BRI0:1 is now connected
to 6106 Spicey
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit#
La série 1 est rétablie.
Prasit#
*Mar 1 01:26:40.579: %LINK-3-UPDOWN: Interface Serial1, changed state to up
*Mar 1 01:26:41.579: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial1, changed state to up
*Mar 1 01:27:01.051: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0,
TEI 64 changed to down
*Mar 1 01:27:01.055: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI
64 changed to down
*Mar 1 01:27:01.363: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode
*Mar 1 01:27:01.379: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 1 01:27:01.395: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
Prasit#show frame map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
status defined, active
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/116/432 ms
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1
input pkts 58 output pkts 66 in bytes 9727
out bytes 10022 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 46 out bcast bytes 7942
pvc create time 01:27:37, last time pvc status changed 00:01:59
Configuration de la commutation du relayage de trames
La commutation de relayage de trames est un moyen de commuter les paquets reposant sur l’identifiant DLCI. Nous pouvons considérer ce moyen comme l’équivalent du relayage de trames d’une adresse MAC (Media Access Control). Vous effectuez la commutation en configurant votre routeur ou votre serveur d’accès Cisco dans un réseau à relayage de trames. Un réseau à relayage de trames comporte deux parties :
-
Équipement terminal de traitement de données en mode relayage de trames (DTE) – le routeur ou le serveur d’accès.
-
Commutateur de l’équipement de terminaison de circuit de données en mode relayage de trames (DCE).
Remarque : dans le logiciel Cisco IOS version 12.1(2)T et ultérieure, la commande frame route a été remplacée par la commande connect.
Regardons un exemple de configuration. Dans la configuration ci-dessous, nous utilisons le routeur America comme commutateur de relayage de trames. Nous utilisons Spicey comme routeur du concentrateur, puis Prasit et Aton comme routeurs de rayons. Nous les avons connectés ainsi :
-
Le port de console du commutateur (DTE) Prasit de série 1 (s1) est relié à l’équipement de terminaison de circuit de données America de série 1/4 (s1/4).
-
Le DTE Spicey de série 0 (s0) est relié au DCE America de série 1/5 (s1/5).
-
Le DTE Aton série 1 (s1) est relié au DCE America de série 3/4 (s3/4).
Diagramme du réseau
Dans le présent document est utilisée la configuration suivante :
Configurations
| Spicey |
|---|
Spicey#show running-config Building configuration... ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 ip address 3.1.3.1 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 130 frame-relay interface-dlci 140 ! ! router rip network 3.0.0.0 network 124.0.0.0 ! line con 0 ! exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1499 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.2 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 150 ! ! router rip network 3.0.0.0 network 123.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Aton |
|---|
Aton#show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Aton ! ! ! interface Ethernet0 ip address 122.122.122.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.3 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 160 ! router rip network 3.0.0.0 network 122.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Amérique |
|---|
america#show running-config Building configuration... Current configuration: ! ! service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname america ! frame-relay switching ! ! interface Serial1/4 description *** static DCE connection to s1 Prasit no ip address encapsulation frame-relay clockrate 2000000 frame-relay intf-type dce frame-relay route 150 interface Serial1/5 140 ! interface Serial1/5 description *** static DCE connection to s0 spicy no ip address encapsulation frame-relay bandwidth 1000000 tx-queue-limit 100 frame-relay intf-type dce frame-relay route 130 interface Serial3/4 160 frame-relay route 140 interface Serial1/4 150 transmitter-delay 10 ! interface Serial3/4 description *** static DCE connection to s1 Aton encapsulation frame-relay no ip mroute-cache clockrate 2000000 frame-relay intf-type dce frame-relay route 160 interface Serial1/5 130 ! |
Commandes show
Utilisez les commandes « show » (afficher) suivantes pour tester le bon fonctionnement de votre réseau :
-
show frame-relay map
-
show frame-relay pvc
La sortie indiquée ci-dessous est le résultat obtenu par la saisie de ces commandes sur les périphériques que nous utilisons dans cet exemple de configuration.
Spicey
Spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
broadcast,, status defined, active
Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,
broadcast,, status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 32 output pkts 40 in bytes 3370
out bytes 3928 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 30 out bcast bytes 2888
pvc create time 00:15:46, last time pvc status changed 00:10:42
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 282 output pkts 291 in bytes 25070
out bytes 27876 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 223 out bcast bytes 20884
pvc create time 02:28:36, last time pvc status changed 02:25:14
Prasit
Prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 311 output pkts 233 in bytes 28562
out bytes 22648 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 162 out bcast bytes 15748
pvc create time 02:31:39, last time pvc status changed 02:25:14
Aton
Aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic, broadcast, status defined, active
Aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial
input pkts 35 output pkts 32 in bytes 3758
out bytes 3366 dropped pkts 0 in FECN pkt 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 27 out bcast bytes 2846
pvc create time 00:10:53, last time pvc status changed 00:10:53
Configuration de la hiérarchisation du DLCI du relayage de trames
La hiérarchisation des identifiants DLCI est le processus par lequel différents types de trafic sont placés sur des DLCI distincts de sorte qu’un réseau à relayage de trames puisse fournir un taux d’information engagée différent pour chaque type de trafic. Il peut être utilisé conjointement avec la mise en file d’attente personnalisée ou prioritaire pour fournir un contrôle de la gestion de la bande passante sur le lien d’accès au réseau à relayage de trames. En outre, certains fournisseurs de services de relayage de trames et certains commutateurs de relayage de trames (p. ex., Stratacom Internetwork Packet Exchange [IPX], IGX et BPX ou AXIS) procurent une hiérarchisation dans le nuage de relayage de trames selon ce paramètre de hiérarchisation.
Considérations relatives à la mise en œuvre
Veuillez noter les points suivants lors de la mise en œuvre de la hiérarchisation des DLCI :
-
Si un DLCI secondaire cesse de fonctionner, seulement le trafic qui est destiné à cette file d’attente est perdu.
-
Si le DLCI principal cesse de fonctionner, la sous-interface s’arrête et alors tout le trafic est perdu.
Diagramme du réseau
Pour utiliser cette configuration, vous devez avoir quatre DLCI pour le côté qui utilisera la hiérarchisation des DLCI. Dans cet exemple, nous avons configuré Spicey pour la mise en file d’attente prioritaire comme suit :
-
Le message Ping se trouve dans la file d’attente à priorité élevée.
-
Telnet se trouve dans la file d’attente de priorité moyenne.
-
Le protocole File Transfer Protocol (FTP) est quant à lui dans la file d’attente à priorité normale.
-
Tout autre trafic IP se situe dans la file d’attente à faible priorité.
Remarque : assurez-vous de configurer les identificateurs DLCI pour qu'ils correspondent à la liste de priorités, sinon le système n'utilisera pas la file d'attente correcte.
Configurations
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1955 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec ! hostname Spicey ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay priority-group 1 ! interface Serial0.1 point-to-point ip address 4.0.1.1 255.255.255.0 frame-relay priority-dlci-group 1 140 180 190 200 frame-relay interface-dlci 140 ! router igrp 2 network 4.0.0.0 network 124.0.0.0 ! access-list 102 permit icmp any any priority-list 1 protocol ip high list 102 priority-list 1 protocol ip medium tcp telnet priority-list 1 protocol ip normal tcp ftp priority-list 1 protocol ip low ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec ! hostname Prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 ip address 4.0.1.2 255.255.255.0 encapsulation frame-relay ! router igrp 2 network 4.0.0.0 network 123.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Commandes debug et show
Utilisez les commandes show (afficher) et debug (déboguer) suivantes pour tester le bon fonctionnement de votre réseau. Avant d'exécuter les commandes debug, référez-vous à la section Informations importantes sur les commandes Debug.
-
show frame-relay pvc
-
show frame-relay map
-
show queueing priority
-
debug priority
La sortie indiquée ci-dessous est le résultat obtenu par la saisie de ces commandes sur les périphériques que nous utilisons dans cet exemple de configuration.
Spicey
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 4 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1
input pkts 106 output pkts 15 in bytes 6801
out bytes 1560 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
pvc create time 00:29:22, last time pvc status changed 00:20:37
Priority DLCI Group 1, DLCI 140 (HIGH), DLCI 180 (MEDIUM)
DLCI 190 (NORMAL), DLCI 200 (LOW)
DLCI = 180, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1
input pkts 0 output pkts 51 in bytes 0
out bytes 2434 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
pvc create time 00:29:23, last time pvc status changed 00:14:48
DLCI = 190, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1
input pkts 0 output pkts 13 in bytes 0
out bytes 3653 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 13 out bcast bytes 3653
pvc create time 00:29:23, last time pvc status changed 00:14:28
DLCI = 200, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1
input pkts 0 output pkts 42 in bytes 0
out bytes 2554 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 10 out bcast bytes 500
pvc create time 00:29:24, last time pvc status changed 00:14:09
Spicey#show frame-relay map
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
status defined, active
Priority DLCI Group 1, DLCI 140 (HIGH), DLCI 180 (MEDIUM)
DLCI 190 (NORMAL), DLCI 200 (LOW)
Spicey#show queueing priority
Current priority queue configuration:
List Queue Args
1 high protocol ip list 102
1 medium protocol ip tcp port telnet
1 normal protocol ip tcp port ftp
1 low protocol ip
Pour vérifier la file d’attente prioritaire, utilisez la commande debug priority (déboguer la priorité).
Spicey#debug priority Priority output queueing debugging is on Spicey#ping 123.123.123.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48 ms Spicey# *Mar 1 00:32:30.391: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high *Mar 1 00:32:30.395: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high *Mar 1 00:32:30.399: PQ: Serial0 output (Pk size/Q 104/0) *Mar 1 00:32:30.439: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high *Mar 1 00:32:30.443: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high *Mar 1 00:32:30.447: PQ: Serial0 output (Pk size/Q 104/0) *Mar 1 00:32:30.487: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high *Mar 1 00:32:30.491: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high *Mar 1 00:32:30.495: PQ: Serial0 output (Pk size/Q 104/0) *Mar 1 00:32:30.535: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high *Mar 1 00:32:30.539: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high *Mar 1 00:32:30.543: PQ: Serial0 output (Pk size/Q 104/0) *Mar 1 00:32:30.583: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high *Mar 1 00:32:30.587: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high *Mar 1 00:32:30.587: PQ: Serial0 output (Pk size/Q 104/0)Spicey# Spicey#telnet 123.123.123.1 Trying 123.123.123.1 ... Open User Access Verification Password: *Mar 1 00:32:59.447: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.451: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.451: PQ: Serial0 output (Pk size/Q 48/1) *Mar 1 00:32:59.475: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.479: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.483: PQ: Serial0 output (Pk size/Q 44/1) *Mar 1 00:32:59.487: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.487: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.491: PQ: Serial0 output (Pk size/Q 53/1) *Mar 1 00:32:59.495: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.499: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.499: PQ: Serial0 output (Pk size/Q 44/1) *Mar 1 00:32:59.511: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.511: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.515: PQ: Serial0 output (Pk size/Q 47/1) *Mar 1 00:32:59.519: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.519: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.523: PQ: Serial0 output (Pk size/Q 47/1) *Mar 1 00:32:59.527: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.527: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.531: PQ: Serial0 output (Pk size/Q 53/1) *Mar 1 00:32:59.539: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.543: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.547: PQ: Serial0 output (Pk size/Q 47/1) *Mar 1 00:32:59.751: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.755: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:32:59.755: PQ: Serial0 output (Pk size/Q 44/1) Password:
L’autre trafic IP passe par la file d’attente à faible priorité
Spicey# *Mar 1 00:53:57.079: PQ: Serial0 output (Pk size/Q 13/0) *Mar 1 00:53:58.851: PQ: Serial0: ip -> low *Mar 1 00:53:58.907: PQ: Serial0: ip -> low *Mar 1 00:53:58.907: PQ: Serial0 output (Pk size/Q 36/3) *Mar 1 00:53:59.459: PQ: Serial0: ip -> low *Mar 1 00:53:59.463: PQ: Serial0: ip -> low *Mar 1 00:53:59.463: PQ: Serial0 output (Pk size/Q 50/3) Spicey#
Prasit
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 134 output pkts 119 in bytes 12029
out bytes 7801 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 18 out bcast bytes 1260
pvc create time 00:21:15, last time pvc status changed 00:21:15
Prasit#show frame-relay map
Serial1 (up): ip 4.0.1.1 dlci 150(0x96,0x2460), dynamic,
broadcast, status defined, active
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48
Here is the debug output shown on Spicey when you use the command above to ping to Spicey from Prasit.
Spicey#
*Mar 1 00:33:26.755: PQ: Serial0 output (Pk size/Q 13/0)
*Mar 1 00:33:28.535: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar 1 00:33:28.539: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar 1 00:33:28.543: PQ: Serial0 output (Pk size/Q 104/0)
*Mar 1 00:33:28.583: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar 1 00:33:28.587: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar 1 00:33:28.587: PQ: Serial0 output (Pk size/Q 104/0)
*Mar 1 00:33:28.631: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar 1 00:33:28.635: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar 1 00:33:28.635: PQ: Serial0 output (Pk size/Q 104/0)
*Mar 1 00:33:28.679: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar 1 00:33:28.683: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar 1 00:33:28.683: PQ: Serial0 output (Pk size/Q 104/0)
*Mar 1 00:33:28.723: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar 1 00:33:28.727: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar 1 00:33:28.731: PQ: Serial0 output (Pk size/Q 104/0)
Prasit#telnet 124.124.124.1
Trying 124.124.124.1 ... Open
User Access Verification
Password:
Spicey>exit
[Connection to 124.124.124.1 closed by foreign host]
Prasit#
Voici la sortie de débogage affichée sur Spicey lorsque vous utilisez la commande ci-dessus pour Telnet, de Prasit à Spicey.
Spicey# *Mar 1 00:33:54.499: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.499: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.503: PQ: Serial0 output (Pk size/Q 48/1) *Mar 1 00:33:54.527: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.531: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.531: PQ: Serial0 output (Pk size/Q 56/1) *Mar 1 00:33:54.547: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.551: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.555: PQ: Serial0 output (Pk size/Q 86/1) *Mar 1 00:33:54.559: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.563: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.563: PQ: Serial0 output (Pk size/Q 47/1) *Mar 1 00:33:54.571: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.575: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.575: PQ: Serial0 output (Pk size/Q 47/1) *Mar 1 00:33:54.779: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.783: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:54.783: PQ: Serial0 output (Pk size/Q 44/1) *Mar 1 00:33:56.755: PQ: Serial0 output (Pk size/Q 13/0) *Mar 1 00:33:57.143: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:57.143: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:57.147: PQ: Serial0 output (Pk size/Q 44/1) *Mar 1 00:33:57.447: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:57.447: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:57.451: PQ: Serial0 output (Pk size/Q 44/1) *Mar 1 00:33:57.899: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:57.899: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:57.903: PQ: Serial0 output (Pk size/Q 53/1) *Mar 1 00:33:59.491: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:59.495: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:59.495: PQ: Serial0 output (Pk size/Q 45/1) *Mar 1 00:33:59.711: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:59.715: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:59.715: PQ: Serial0 output (Pk size/Q 45/1) *Mar 1 00:33:59.951: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:59.951: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:33:59.955: PQ: Serial0 output (Pk size/Q 45/1) *Mar 1 00:34:00.123: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:34:00.123: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:34:00.127: PQ: Serial0 output (Pk size/Q 45/1) *Mar 1 00:34:00.327: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:34:00.327: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:34:00.331: PQ: Serial0 output (Pk size/Q 46/1) *Mar 1 00:34:00.495: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:34:00.499: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:34:00.499: PQ: Serial0 output (Pk size/Q 44/1) *Mar 1 00:34:00.543: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:34:00.543: PQ: Serial0: ip (tcp 23) -> medium *Mar 1 00:34:00.547: PQ: Serial0 output (Pk size/Q 44/1)
File d’attente de diffusion du relayage de trames
La file d’attente de diffusion est une fonctionnalité importante utilisée dans les réseaux IP ou IPX de moyenne à grande taille, où les diffusions de routage et de point d’accès au service (SAP) doivent passer par le réseau de relayage de trames. La file d’attente de diffusion est gérée indépendamment de la file de l’interface normale, possède ses propres tampons et possède une taille et un débit de service configurables. Cette file d’attente de diffusion ne sert pas aux mises à jour transitoires du protocole Spanning Tree (BPDU) en raison des contraintes de temps. Ces paquets circuleront dans les files d’attente normales. Voici la commande d’interface pour activer la file d’attente de diffusion :
frame-relay broadcast-queue size byte-rate packet-rate
Une file d’attente de diffusion reçoit une limite maximale de vitesse de transmission (débit), mesurée en octets par seconde et en paquets par seconde. La file d’attente vise à garantir que seule cette limite maximale est offerte. La file d’attente de diffusion a priorité lorsque sa vitesse de transmission est inférieure à la limite configurée; or, une attribution de bande passante minimale est donc garantie. Les deux limites de vitesse de transmission servent alors à éviter les diffusions d’inonder l’interface. La limite réelle par seconde constitue la première limite de vitesse atteinte. Compte tenu de la contrainte de vitesse de transmission, une mise en mémoire tampon supplémentaire est requise pour stocker les paquets de diffusion. La file d’attente de diffusion est configurable pour stocker un grand nombre de paquets de diffusion. La taille de la file d’attente doit être définie pour éviter la perte de paquets de mise à jour de routage de diffusion. La taille exacte dépend du protocole utilisé et du nombre de paquets requis pour chaque mise à jour. Pour vous éviter des surprises, la taille de la file d’attente doit être définie de sorte qu’une mise à jour de routage complète issue de chaque protocole et pour chaque identifiant DLCI puisse être stockée. Règle générale, commencez avec 20 paquets par DLCI. Le taux d’octets doit être inférieur à ce qui suit :
-
N/4 fois la vitesse minimale de l’accès à distance (mesurée en octets par seconde), où « N » représente le nombre de DLCI auxquels la diffusion doit être répliquée;
-
1/4 la vitesse d’accès local (mesurée en octet par seconde).
Le débit de paquets n’est pas essentiel si le taux d’octets est défini sans exagération. En général, le débit de paquets doit être fixé en supposant des paquets de 250 octets. Les valeurs par défaut pour les interfaces série sont fixées à 64 pour la taille de file d’attente, à 256 000 octets par seconde (2 048 000 bit/s) et à 36 paquets/sec. Les valeurs par défaut pour les interfaces série haute vitesse (HSSI) sont fixées à 256 pour la taille de file d’attente, à 1 024 000 octets par seconde (8 192 000 bit/s) et à 144 paquets/sec.
Modélisation du trafic
La modélisation du trafic utilise un mécanisme de contrôle du débit appelé « filtre du seau à jetons ». Ce filtre du seau à jetons est réglé comme suit :
excès de rafale plus rafale engagée (Bc + Be) = vitesse maximale du circuit virtuel (VC)
Le trafic supérieur à la vitesse maximale est mis en mémoire tampon dans une file d’attente destinée à la modélisation du trafic, qui équivaut à la file d’attente à équité pondérée (WFQ). Le filtre du seau à jetons ne filtre pas le trafic, mais plutôt contrôle le débit d’envoi du trafic sur l’interface sortante. Pour en savoir plus sur les filtres du seau à jetons, consultez l’aperçu sur le contrôle et la modélisation.
Ce document fait un survol sur la modélisation du trafic générique et la modélisation du trafic de relayage de trames.
Paramètres de modélisation du trafic
Nous pouvons utiliser les paramètres suivants de modélisation du trafic :
-
CIR = débit minimal garanti (= délai moyen)
-
EIR = débit d’information excédentaire
-
TB = seau à jetons (= Bc + Be)
-
Bc = taille de rafale garantie (= taille de rafale soutenue)
-
Be = taille de rafale en excès
-
DE = priorité de rejet
-
Tc = intervalle de mesure
-
AR = débit d’accès correspondant au débit de l’interface physique (donc si vous utilisez un T1, l’AR est d’environ 1,5 Mbit/s).
Voyons plus en détail certains de ces paramètres :
Débit d’accès (AR)
Le nombre maximal de bits par seconde qu’une station d’extrémité peut transmettre au réseau est limité par le débit d’accès de l’interface utilisateur-réseau. La vitesse de ligne de la connexion réseau utilisateur limite le débit d’accès. Vous pouvez l’établir dans votre abonnement au fournisseur de services.
Taille de rafale garantie (Bc)
La quantité maximale de données garanties que vous pouvez offrir au réseau correspond à Bc. Bc est une mesure du volume de données pour lequel le réseau garantit la livraison des messages dans des conditions normales. Cette mesure est prise pendant le Tc du débit garanti.
Taille de rafale en excès (Be)
Le nombre de bits non engagés (hors du CIR) qui sont toujours acceptés par le commutateur de relayage de trames, mais qui sont considérés comme admissibles au rejet (DE).
Le seau à jetons est un tampon « virtuel ». Il contient des jetons, vous permettant ainsi d’envoyer un nombre limité de données par intervalle de temps. Le seau à jetons est rempli de bits Bc par Tc. La taille maximale du seau est Bc + Be. Si Be est très grande et si, à T0, le seau est rempli de jetons Bc + Be, vous pouvez envoyer des bits Bc + Be au débit d’accès. La limite n’est pas imposée par le Tc, mais par le temps nécessaire pour envoyer la Be. Tout dépend du débit d’accès.
Débit minimal garanti (CIR)
Le CIR représente la quantité de données autorisée que le réseau s’engage à acheminer dans des conditions normales. Le débit moyen est calculé selon un Tc à incrément de temps. Le CIR est également appelé « débit minimal acceptable ». Les tailles Bc et Be sont exprimées en bits, le Tc en secondes, et le débit d’accès et le CIR en bits par seconde.
Les valeurs Bc, Be, Tc et CIR sont définies par identifiant DLCI. C’est pour cette raison que le filtre du seau à jetons contrôle le débit par identifiant DLCI. Le débit d’accès est valide par interface utilisateur-réseau. Pour Bc, Be et CIR, les valeurs entrantes et sortantes peuvent être différenciées. Si la connexion est symétrique, les valeurs dans les deux sens sont alors identiques. Pour les circuits virtuels permanents, nous définissons les entrées et les sorties des Bc, Be et CIR lors de l’abonnement.
-
Valeur maximale = vitesse maximale de l’identifiant DLCI. La bande passante pour ce DLCI en particulier.
-
Tc = Bc / CIR
-
Valeur maximale = CIR + Be/Tc = CIR (1 + Be/Bc)
Si la Tc est d’une seconde, alors :
-
Valeur maximale = CIR + Be = Bc + Be
-
EIR = Be
Dans l’exemple que nous utilisons ici, le routeur envoie du trafic entre 48 kbit/s et 32 kbit/s en fonction de la congestion présente dans le réseau. Les réseaux peuvent marquer les trames supérieures à la Bc comme admissibles au rejet, mais ils ont une grande capacité pour transporter la trame. L'inverse est également possible : ils peuvent avoir une capacité limitée, mais éliminer immédiatement les trames excessives. Les réseaux peuvent indiquer des trames supérieures à Bc + Be comme admissibles au rejet, voire les transporter, ou simplement les abandonner comme le suggère la spécification ITU-T I.370 du secteur de normalisation des télécommunications de l’Union internationale des télécommunications. La modélisation du trafic ralentit le trafic en fonction des paquets étiquetés de la notification explicite de congestion vers l’arrière (BECN) à partir du réseau du commutateur. Si vous recevez 50 % de la BECN, le routeur diminue le trafic d’un huitième de la bande passante actuelle transmise pour cet identifiant DLCI en particulier.
Exemple
La vitesse de transmission est de 42 Ko. Le routeur réduit la vitesse à 42 moins 42 divisé par 8 (42 - 42/8), soit 36,75 Ko. Si la congestion diminue après le changement, le routeur réduit davantage le trafic, passant à un huitième de la bande passante actuelle transmise. Le trafic est réduit jusqu’à ce qu’il atteigne la valeur de CIR configurée. Cependant, la vitesse peut chuter sous le CIR lorsque nous pouvons encore voir les BECN. Vous pouvez préciser une limite inférieure, comme CIR/2. Le réseau n’est plus congestionné lorsque l’ensemble des trames reçues du réseau n’ont plus de bit de BECN pour un intervalle de temps donné. La valeur par défaut pour cet intervalle est de 200 ms.
Generic Traffic Shaping
La fonctionnalité de modélisation du trafic générique est un outil de modélisation de trafic indépendant de l’encapsulation et du support et il permet de réduire le débit du trafic sortant en cas de congestion dans le nuage, sur le lien ou au routeur du point d’extrémité de la réception. Nous pouvons le configurer sur des interfaces ou des sous-interfaces dans un routeur.
La modélisation du trafic générique est utile dans les situations suivantes :
-
Si votre topologie de réseau comprend une connexion haute vitesse (vitesse de ligne T1) au site central et une connexion basse vitesse (inférieure à 56 kbit/s) aux sites des succursales ou du télétravail. En raison du défaut d’appariement de la vitesse, il existe souvent un goulot d’étranglement pour le trafic des sites des succursales ou du télétravail lorsque le site central envoie des données à une plus grande vitesse que celle vers les sites distants. Un goulot d’étranglement se produit alors dans le dernier commutateur avant le routeur distant.
-
Si vous êtes un fournisseur qui offre des services à débit réduit, cette fonctionnalité vous permet d’utiliser le routeur pour partitionner vos liens T1 ou T3, par exemple, en canaux plus petits. Vous pouvez configurer chaque sous-interface avec un compartiment de filtres de jetons qui correspond au service commandé par un client.
Sur votre connexion de relayage de trames, vous voudrez peut-être que le routeur limite le trafic au lieu de l’envoyer dans le réseau. Le contrôle du trafic limiterait la perte de paquets dans le nuage du fournisseur de services. La capacité à contrôler le trafic basée sur la BECN qui accompagne cette fonctionnalité vous permet de limiter le trafic de façon dynamique grâce au routeur en fonction de la réception de paquets étiquetés de la BECN à partir du réseau. Un tel contrôle maintient les paquets dans la mémoire tampon du routeur pour réduire le flux de données du routeur dans le réseau de relayage de trames. Le routeur limite le trafic sur une sous-interface, et le débit est augmenté lorsque moins de paquets étiquetés pour la BECN sont reçus.
Commandes pour la modélisation du trafic générique
Pour définir le contrôle de débit, utilisez cette commande :
traffic-shape rate bit-rate [burst-size [excess-burst-size]] [group access-list]
Pour limiter les BECN sur une interface de relayage de trames, utilisez la commande suivante :
traffic-shape adaptive [bit-rate]
Pour configurer une sous-interface de relayage de trames afin d’estimer la bande passante disponible lorsqu’elle reçoit des BECN, utilisez la commande traffic-shape adaptive.
Remarque : vous devez activer la mise en forme du trafic sur l'interface à l'aide de la commande traffic-shape rate avant de pouvoir utiliser la commande traffic-shape adaptive.
Le débit indiqué pour la commande traffic-shape rate est la limite supérieure de la modélisation du trafic lorsque l’interface reçoit les BECN, et celui précisé pour la commande traffic-shape adaptative représente la limite inférieure (généralement la valeur du CIR). Le débit utilisé en réalité se situe normalement entre ces deux valeurs. Vous devez configurer la commande traffic-shape adaptative aux deux extrémités du lien, car elle configure également le périphérique à l’extrémité du débit afin de refléter les signaux de notification explicite de congestion vers l’avant (FECN) en tant que BECN. Cela permet au routeur haute vitesse de détecter la congestion et de s’y adapter, même si le trafic circule principalement dans une direction.
Exemple
Dans l’exemple suivant est configurée la modélisation du trafic sur l’interface 0.1 selon une limite supérieure (généralement Bc + Be) de 128 kbit/s et une limite inférieure de 64 kbit/s. Ainsi, le lien peut exécuter de 64 à 128 kbit/s, selon le degré de la congestion. Si la limite supérieure du côté central est de 256 kbit/s, vous devez utiliser la valeur inférieure de la limite supérieure.
Voici ce que nous avons configuré sur ces routeurs :
Central# interface serial 0 encapsulation-frame-relay interface serial 0.1 traffic-shape rate 128000 traffic-shape adaptive 64000 Client# interface serial 0 encapsulation-frame-relay interface serial 0.1 traffic-shape rate 128000 traffic-shape adaptive 64000
Formatage de trafic de relais de trame
Grâce à la modélisation du trafic générique, vous ne pouvez préciser qu’un débit maximal (limite supérieure) par interface physique et une valeur de CIR (limite inférieure) par sous-interface. Grâce à la mise en forme du trafic de relayage de trames, vous commencez un filtre du seau à jetons par circuit virtuel.
La modélisation du trafic sur le relayage de trames offre les fonctionnalités suivantes :
-
Application du débit par circuit virtuel : vous pouvez configurer un débit de pointe pour limiter le trafic sortant au débit de données garanti ou à une autre valeur définie, telle que le débit d'informations excédentaires (EIR).
-
Prise en charge BECN généralisée par circuit virtuel : le routeur peut surveiller les BECN et réguler le trafic en fonction des commentaires de paquets marqués BECN provenant du réseau Frame Relay.
-
Mise en file d’attente prioritaire (PQ), mise en file d’attente personnalisée (CQ) ou prise en charge WFQ au niveau du circuit virtuel. Une granularité plus fine est alors possible dans la priorisation et la mise en file d’attente du trafic, vous permettant ainsi de mieux contrôler le débit du trafic sur un circuit virtuel individuel. La modélisation du trafic sur le relayage de trames s’applique aux circuits virtuels permanents (PVC) et aux circuits virtuels commutés (SVC) du relayage de trames.
Exemple
Interface Serial 0 no ip address encapsulation frame-relay frame-relay traffic-shaping ! interface Serial0.100 ip address 1.1.1.1 255.255.255.252 frame-relay interface-dlci 100 frame-relay class fast ! interface Serial0.200 ip address 1.1.1.5 255.255.255.252 frame-relay interface-dlci 200 frame-relay class slow ! map-class frame-relay slow frame-relay traffic-rate 64000 128000 ! map-class frame-relay fast frame-relay traffic-rate 16000 64000 !
Dans cet exemple, le routeur ajoute deux seaux à jetons.
-
L’un fonctionne entre 64 000 (CIR) et 128 000 (Bc + Be).
-
L’autre fonctionne entre 16 000 (CIR) et 64 000 (Bc + Be).
Si le trafic entrant d’Ethernet est supérieur au filtre du seau à jetons, le trafic est mis en mémoire tampon dans la file d’attente du trafic de relayage de trames.
Pour afficher un organigramme illustrant le flux de paquets lors de la modélisation du trafic de relayage de trames, consultez l’organigramme de modélisation du trafic de relayage de trames. Pour afficher un organigramme utilisant particulièrement un filtre du seau à jetons, consultez l’organigramme Modélisation du trafic de relayage de trames – Seau à jetons.
Commandes courantes du relayage de trames
Cette section décrit deux commandes Cisco IOS® qui sont particulièrement utiles lors de la configuration du relayage de trames.
show frame-relay pvc
Cette commande montre l’état du circuit virtuel permanent (PVC), les paquets entrants et sortants, les paquets perdus en cas de congestion sur la ligne par la FECN et la BECN, etc. Pour une description détaillée des champs utilisés avec la commande show frame-relay pvc, cliquez ici.
Si vous obtenez le résultat de la commande show frame-relay pvc de votre périphérique Cisco, vous pouvez utiliser l’outil interpréteur de sortie (clients inscrits seulement) pour afficher les problèmes éventuels et les correctifs.
Un exemple de sortie est présenté ci-dessous :
RouterA#show frame-relay pvc PVC Statistics for interface Serial0 (Frame Relay DTE) DLCI = 666, DLCI USAGE = UNUSED, PVC STATUS = DELETED, INTERFACE = Serial0 input pkts 0 output pkts 0 in bytes 0 out bytes 0 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 pvc create time 0:03:18 last time pvc status changed 0:02:27 Num Pkts Switched 0 DLCI = 980, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0 input pkts 19 output pkts 87 in bytes 2787 out bytes 21005 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 pvc create time 1:17:47 last time pvc status changed 0:58:27
Le champ DLCI USAGE contient une des entrées suivantes :
-
SWITCHED – Le routeur ou le serveur d’accès est utilisé comme commutateur.
-
LOCAL – Le routeur ou le serveur d’accès est utilisé comme équipement terminal de traitement de données (DTE).
-
UNUSED – L’identifiant DLCI n’est pas référencé par les commandes de configuration que saisit l’utilisateur sur le routeur.
Le PVC peut avoir quatre états possibles. Celles-ci sont indiquées par le champ PVC STATUS ainsi :
-
ACTIF – Le PVC fonctionne normalement.
-
INACTIVE – Le PVC n’est pas de bout en bout. Ce peut être parce qu’il n’y a aucun mappage (ou que le mappage est incorrect) pour l’identifiant DLCI local dans le nuage de relayage de trames ou que l’extrémité distante du PVC est supprimée.
-
SUPPRIMÉ - L'interface de gestion locale (LMI) n'est pas échangée entre le routeur et le commutateur local, ou le commutateur n'a pas de DLCI configuré sur le commutateur local.
-
STATIC – Aucune fonction Keepalive n’est configurée sur l’interface de relayage de trames du routeur.
show frame-relay map
Utilisez cette commande pour déterminer si la commande frame-relay inverse-arp a converti une adresse IP distante en un DLCI local. Cette commande n’est pas activée pour les sous-interfaces point à point. Elle sert seulement pour les interfaces multipoints et les sous-interfaces. Un exemple de sortie est présenté ci-dessous :
RouterA#show frame-relay map
Serial0 (up): ip 157.147.3.65 dlci 980(0x3D4,0xF440), dynamic,
broadcast,, status defined, active
Pour une description détaillée des champs utilisés avec la commande show frame-relay map, veuillez consulter la Documentation sur les commandes frame relay.
Si vous obtenez le résultat de la commande show frame-relay map de votre périphérique Cisco, vous pouvez utiliser l’outil interpréteur de sortie (clients inscrits seulement) pour afficher les problèmes éventuels et les correctifs.
Relayage de trames et pont
Les messages de configuration appelés BPDU (ou « unités de données de protocole en pont ») sont utilisés dans les protocoles Spanning Tree (SPT) pris en charge dans les ponts et les routeurs Cisco. Ils circulent à intervalles réguliers entre les ponts et constituent une quantité importante de trafic, étant donné qu’ils sont fréquents. Il existe deux types de protocoles Spanning Tree dans le pont transparent. D’abord présenté par Digital Equipment Corporation (DEC), l’algorithme a ensuite été révisé par le comité IEEE 802 et publié dans la spécification IEEE 802.1d. Le protocole SPT de DEC émet des BPDU à des intervalles d’une seconde, tandis que l’IEEE en émet à des intervalles de deux secondes. Chaque paquet fait 41 octets, y compris un message de BPDU de configuration de 35 octets, un en-tête de relayage de trames de 2 octets, un type EtherType de 2 octets et un FCS également de 2 octets.
Relayage de trames et mémoire
L’utilisation de la mémoire pour les ressources de relayage de trames se produit dans quatre zones :
-
Chaque identificateur de connexion de liaison de données (DLCI) : 216 octets
-
Chaque instruction de mappage : 96 octets (ou mappage généré dynamiquement)
-
Chaque IDB (interface matérielle + encapsulation Frame Relay) : 5 040 + 8 346 = 13 386 octets
-
Chaque IDB (sous-interface logicielle) : 2 260 octets
Par exemple, un Cisco 2501 qui utilise deux interfaces de relayage de trames, chacune ayant quatre sous-interfaces, avec un total de huit DLCI, et les cartes associées requiert ce qui suit :
-
IDB matériel à 2 interfaces x 13 386 = 26 772
-
IDB à 8 sous-interfaces x 2 260 = 18 080 sous-interfaces
-
8 DLCI x 216 = 1 728 DLCI
-
8 déclarations de carte x 96 = 768 déclarations de carte ou cartes dynamiques
Le total est égal à 47 348 octets de RAM utilisés.
Remarque : les valeurs utilisées ici sont valides pour le logiciel Cisco IOS versions 11.1, 12.0 et 12.1.
Dépannage du relayage de trames
Cette section contient des parties de la sortie possible de la commande show interface pendant le dépannage. Des explications quant à la sortie sont également fournies.
« Serial0 est arrêté, le protocole de ligne est arrêté »
Cette sortie signifie que vous avez un problème avec le câble, l’unité de service de canal/unité de service de données (CSU/DSU) ou la ligne série. Vous devez résoudre le problème au moyen d’un test de boucle avec retour. Voici la marche à suivre pour réaliser ce test :
-
Réglez l’encapsulation de ligne série sur HDLC et fixez la fonction Keepalive à 10 secondes. Pour ce faire, entrez les commandes encapsulation hdlc et keepalive 10 sous l’interface série.
-
Placez la CSU/DSU ou le modem en mode de boucle locale. Si le protocole de ligne apparaît lorsque la CSU, la DSU ou le modem est en mode de boucle avec retour local [indiqué par le message « line protocol is up (looped) »], ce peut être parce que le problème se produit au-delà de la CSU/DSU locale. Si la ligne d’état ne change pas de valeur, il est probable qu’un problème touche le routeur, le câble de connexion, la CSU/DSU ou le modem. Dans la plupart des cas, le problème provient de la CSU/DSU ou du modem.
-
Envoyez un message Ping à votre propre adresse IP grâce à la CSU/DSU ou le modem en boucle. Il ne devrait y avoir aucun échec. Un message Ping prolongé de 0x0000 est utile pour résoudre les problèmes de ligne, car T1 ou E1 extrait l’horloge des données et nécessite une transition tous les 8 bits. B8ZS donne cette garantie. Un schéma de données zéro lourd aide à déterminer si les transitions sont forcées de la bonne manière sur la ligne principale. Un schéma lourd est utilisé pour simuler correctement une charge nulle élevée advenant une paire d’onduleurs de données sur le chemin. Le modèle alternatif (0x5555) représente un schéma de données « typique ». Si vos messages Ping échouent ou si vous obtenez des erreurs lors du contrôle de redondance cyclique (CRC), il faut alors un testeur de taux d’erreur sur les bits (BERT) avec un analyseur approprié de la compagnie de téléphone.
-
Lorsque vous avez effectué le test, assurez-vous de retourner l’encapsulation au relayage de trames.
« Serial0 est actif, le protocole de ligne est arrêté »
Cette ligne dans la sortie signifie que le routeur reçoit un signal de l’opérateur de la CSU/DSU ou du modem. Assurez-vous que le fournisseur du relayage de trames a activé son port et que vos paramètres LMI (Local Management Interface) correspondent. Généralement, le commutateur de relayage de trames ignore l’équipement terminal de traitement de données (DTE), à moins qu’il détecte la bonne interface LMI (sélectionnez la valeur par défaut de Cisco, soit LMI « cisco »). Vérifiez bien que le routeur Cisco transmet les données. Vous devrez probablement vérifier l’intégrité de la ligne à l’aide de tests de boucle à divers endroits, en commençant par la CSU locale et en poursuivant jusqu’au commutateur de relayage de trames du fournisseur. Consultez la section précédente pour savoir comment effectuer un test de boucle avec retour.
« Serial0 est actif, le protocole de ligne est actif »
Si vous n’avez pas désactivé Keepalive, cette ligne de sortie signifie que le routeur communique avec le commutateur du fournisseur de relayage de trames. Vous devriez voir un échange réussi du trafic bidirectionnel sur l’interface série, sans erreurs CRC. Les Keepalive sont nécessaires au relayage de trames, car il s’agit du mécanisme qu’utilise le routeur pour détecter les identifiants DLCI que le fournisseur a mis en service. Pour surveiller l’échange, vous pouvez utiliser sans souci la commande debug frame-relay lmi dans presque toutes les situations. La commande debug frame-relay lmi génère très peu de messages et peut fournir des réponses à des questions comme celles-ci :
-
Le routeur Cisco communique-t-il avec le commutateur local de relayage de trames?
-
Le routeur reçoit-il des messages d’état LMI complets pour les circuits virtuels permanents (PVC) inscrits du fournisseur de relayage de trames?
-
Les DLCI sont-ils corrects?
Voici quelques exemples de la sortie debug frame-relay lmi provenant d’une connexion réussie :
*Mar 1 01:17:58.763: Serial0(out): StEnq, myseq 92, yourseen 64, DTE up *Mar 1 01:17:58.763: datagramstart = 0x20007C, datagramsize = 14 *Mar 1 01:17:58.763: FR encap = 0x0001030800 75 95 01 01 01 03 02 5C 40 *Mar 1 01:17:58.767: *Mar 1 01:17:58.815: Serial0(in): Status, myseq 92 *Mar 1 01:17:58.815: RT IE 1, length 1, type 1 *Mar 1 01:17:58.815: KA IE 3, length 2, yourseq 65, myseq 92 *Mar 1 01:18:08.763: Serial0(out): StEnq, myseq 93, yourseen 65, DTE up *Mar 1 01:18:08.763: datagramstart = 0x20007C, datagramsize = 14 *Mar 1 01:18:08.763: FR encap = 0x0001030800 75 95 01 01 01 03 02 5D 41 *Mar 1 01:18:08.767: *Mar 1 01:18:08.815: Serial0(in): Status, myseq 93 *Mar 1 01:18:08.815: RT IE 1, length 1, type 1 *Mar 1 01:18:08.815: KA IE 3, length 2, yourseq 66, myseq 93 *Mar 1 01:18:18.763: Serial0(out): StEnq, myseq 94, yourseen 66, DTE up *Mar 1 01:18:18.763: datagramstart = 0x20007C, datagramsize = 14 *Mar 1 01:18:18.763: FR encap = 0x0001030800 75 95 01 01 00 03 02 5E 42 *Mar 1 01:18:18.767: *Mar 1 01:18:18.815: Serial0(in): Status, myseq 94 *Mar 1 01:18:18.815: RT IE 1, length 1, type 0 *Mar 1 01:18:18.819: KA IE 3, length 2, yourseq 67, myseq 94 *Mar 1 01:18:18.819: PVC IE 0x7 , length 0x3 , dlci 980, status 0x2
Remarquez l’état « DLCI 980 » dans la sortie ci-dessus. Les valeurs possibles du champ d’état sont expliquées ci-dessous :
-
0x0-Added/inactive signifie que ce DLCI est programmé dans le commutateur, mais pour une raison quelconque (p. ex., l’arrêt de l’autre extrémité du PVC), il est inutilisable.
-
0x2-Added/active signifie que le commutateur de relayage de trames possède le DLCI et que tout est opérationnel. Vous pouvez commencer à lui envoyer du trafic avec ce DLCI dans l’en-tête.
-
0x3-0x3 est une combinaison d’un état actif (0x2) et du RNR (ou r-bit) qui est défini (0x1). Cela signifie que le commutateur, ou une file d’attente particulière sur le commutateur, pour ce PVC est sauvegardé et que vous arrêtez la transmission au cas où des trames seraient répandues.
-
0x4-Deleted signifie que le DLCI du commutateur de relayage de trames n’est pas programmé pour le routeur. Toutefois, il a déjà été programmé. Ce pourrait aussi être causé par l’inversion des DLCI sur le routeur ou par la suppression du PVC par la compagnie de téléphone dans le nuage de relayage de trames. La configuration d’un DLCI (absent dans le commutateur) apparaîtra comme un 0x4.
-
0x8-New/inactive
-
0x0a-New/active
Caractéristiques du relayage de trames
Cette section explique plusieurs caractéristiques du relayage de trames dont vous devez tenir compte.
Vérification de l’horizon partagé de l’IP
La vérification de l’horizon partagé de l’IP est désactivée par défaut pour l’encapsulation de relayage de trames. Ainsi, les mises à jour de routage entrent et sortent par la même interface. Les routeurs détectent les identifiants DLCI qu’ils doivent utiliser à partir du commutateur de relayage de trames grâce aux mises à jour de la LMI. Les routeurs utilisent alors l’ARP inversé pour l’adresse IP distante et associent les DLCI locaux avec les adresses IP distantes correspondantes. En outre, certains protocoles, comme AppleTalk, le pont transparent et l’IPX, ne peuvent pas être pris en charge sur les réseaux partiellement maillés, car ils nécessitent un « horizon partagé » dans lequel un paquet qui est reçu sur une interface ne peut être transmis par cette même interface, et ce, même si le paquet est reçu, puis transmis sur différents circuits virtuels. La configuration des sous-interfaces de relayage de trames garantit qu’une seule interface physique est traitée comme plusieurs interfaces virtuelles. Cette capacité nous permet de contourner les règles de l’horizon partagé. Les paquets reçus sur une interface virtuelle peuvent maintenant être transférés vers une autre interface virtuelle, même s’ils sont configurés sur la même interface physique.
Envoi d’un message Ping à votre adresse IP sur un relayage de trames multipoints
Vous ne pouvez pas envoyer un message Ping à votre adresse IP sur une interface de relayage de trames multipoint. En effet, les [sous-]interfaces multipoints de relayage de trames sont des sous-interfaces point à point de relayage de trames non diffusées (contrairement à la commande de liaison de données à haut niveau [HDLC] des interfaces Ethernet et point à point).
En outre, vous ne pouvez pas envoyer de message Ping d’un rayon à un autre dans une configuration en étoile. En effet, il n’y a aucun mappage pour votre adresse IP (et aucun n’a été détecté par l’ARP inversé). Mais si vous configurez une carte statique (à l’aide de la commande frame-relay map) pour votre adresse IP (ou une pour le rayon distant) afin d’utiliser le DLCI local, vous pouvez alors envoyer un message Ping à vos périphériques.
aton#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
aton#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
aton(config)#interface serial 1
aton(config-if)#frame-relay map ip 3.1.3.3 160
aton(config-if)#
aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
broadcast,, status defined, active
Serial1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static,
CISCO, status defined, active
Serial1 (up): ip 3.1.3.3 dlci 160(0xA0,0x2800), static,
CISCO, status defined, active
aton#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/68/76 ms
aton#
aton#show running-config
!
interface Serial1
ip address 3.1.3.3 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay
frame-relay map ip 3.1.3.2 160
frame-relay map ip 3.1.3.3 160
frame-relay interface-dlci 160
!
La diffusion du mot clé
Le mot clé broadcast fournit deux fonctions : il transmet les diffusions lorsque la multidiffusion n'est pas activée et il simplifie la configuration d'Open Shortest Path First (OSPF) pour les réseaux non-diffusion qui utilisent Frame Relay.
Le mot clé broadcast peut également être requis pour certains protocoles de routage, par exemple AppleTalk, qui dépendent de mises à jour régulières de la table de routage, en particulier lorsque le routeur du côté distant attend l'arrivée d'un paquet de mise à jour de routage avant d'ajouter la route.
En exigeant la sélection d’un routeur désigné, OSPF traite un réseau multiaccès sans diffusion, tel que le relayage de trames, de la même manière qu’il traite un réseau de diffusion. Dans les versions précédentes, il fallait une affectation manuelle dans la configuration OSPF au moyen de la commande neighbour interface router. Lorsque la commande frame-relay map est comprise dans la configuration avec le mot clé broadcast et que la commande ip ospf network (avec le mot clé broadcast) est configurée, il n’est plus nécessaire de configurer les voisins manuellement. Désormais, OSPF fonctionne automatiquement sur le réseau de relayage de trames, en tant que réseau de diffusion. (Consultez la commande ip ospf network interface pour plus de détails.)
Remarque : le mécanisme de diffusion OSPF suppose que les adresses IP de classe D ne sont jamais utilisées pour le trafic régulier sur Frame Relay.
Exemple
L’exemple suivant mappe l’adresse IP de destination 172.16.123.1 au DLCI 100 :
interface serial 0 frame-relay map IP 172.16.123.1 100 broadcast
OSPF utilise le DLCI 100 pour diffuser les mises à jour.
Reconfiguration d’une sous-interface
Lorsque vous créez un type particulier de sous-interfaces, vous ne pouvez plus le modifier sans rechargement. Par exemple, vous ne pouvez pas créer une sous-interface multipoint Serial0.2 pour ensuite la changer en sous-interface point à point. Pour la modifier, vous devez soit recharger le routeur, soit créer une autre sous-interface. C’est ainsi que fonctionne le code de relayage de trames dans le logiciel Cisco IOS®.
Restrictions de l’interface DLCI
Espace DLCI
Environ 1 000 DLCI peuvent être configurés sur un seul lien physique, à partir d’une adresse de 10 bits. Étant donné que certains DLCI sont réservés (en fonction de la mise en œuvre du fournisseur), le maximum est d’environ 1 000. La portée d’une LMI de Cisco est de 16 à 1 007. La portée indiquée pour ANSI/ITU est de 16 à 992. Ce sont ces DLCI qui transportent les données d’utilisateur.
Toutefois, lors de la configuration des circuits virtuels de relayage de trames sur les sous-interfaces, vous devez tenir compte d’une limite pratique appelée « limite IDB ». Le nombre total d’interfaces et de sous-interfaces par système est limité par le nombre de blocs de descripteurs d’interface (IDB) que prend en charge votre version de Cisco IOS. Un IDB est une partie de la mémoire qui contient des renseignements sur l’interface, comme les compteurs et l’état de l’interface. IOS gère un IDB pour chaque interface présente sur une plateforme et maintient un IDB pour chaque sous-interface. Les interfaces à haute vitesse nécessitent plus de mémoire que celles à faible vitesse. Chaque plateforme contient un nombre maximal différent d’IDB, et ces limites peuvent changer selon la version de Cisco IOS.
Pour plus d'informations, consultez Nombre maximal d'interfaces et de sous-interfaces pour les plates-formes logicielles Cisco IOS : Limites IDB.
Mise à jour de l’état de la LMI
Le protocole LMI exige que tous les rapports d’état du circuit virtuel permanent (PVC) entrent dans un seul paquet et limite généralement le nombre de DLCI à moins de 800, selon la taille de l’unité de transmission maximale (MTU).
La valeur par défaut de la MTU sur les interfaces série est de 1 500 octets, pour un maximum de 296 DLCI par interface. Vous pouvez augmenter la MTU pour que soit pris en charge un plus grand message de mise à jour d’état complet provenant du commutateur de relayage de trames. Si le message de mise à jour complète de l’état est supérieur à la MTU de l’interface, le paquet est perdu, et le compteur géant de l’interface est incrémenté. Lorsque vous modifiez la MTU, assurez-vous que la même valeur est configurée sur le routeur distant et les périphériques réseau qui interviennent.
Veuillez noter que ces chiffres varient légèrement selon le type de LMI. Les DLCI maximaux par plateforme de routeur (et non d’interface), reposant sur l’extrapolation issue des données empiriques établies sur une plateforme de routeur Cisco 7000, sont les suivants :
-
Cisco 2500 : 1 liaison T1/E1 à 60 DLCI par interface = 60 au total
-
Cisco 4000 : 1 liaison T1/E1 à 120 DLCI par interface = 120 au total
-
Cisco 4500 : 3 liaisons T1/E1 à 120 DLCI par interface = 360 au total
-
Cisco 4700 : 4 liaisons T1/E1 à 120 DLCI par interface = 480 au total
-
Cisco 7000 : 4 liaisons T1/E1/T3/E3 à 120 DLCI par interface = 480 au total
-
Cisco 7200 : 5 liaisons T1/E1/T3/E3 à 120 DLCI par interface = 600 au total
-
Cisco 7500 : 6 liaisons T1/E1/T3/E3 à 120 DLCI par interface = 720 au total
Remarque : ces chiffres ne sont fournis qu'à titre indicatif et supposent que tout le trafic est à commutation rapide.
Autres considérations
Une limite DLCI pratique dépend également de l’utilisation d’un protocole de routage statique ou dynamique par les circuits virtuels. Les protocoles de routage dynamique, ainsi que d’autres protocoles comme le SAP IPX qui échangent des tableaux de bases de données, acheminent des messages Hello et des messages d’information que le CPU doit voir et traiter. En règle générale, l’utilisation de routes statiques vous permettra de configurer un plus grand nombre de circuits virtuels sur une interface de relayage de trames.
Adresse IP/IPX/AT
Si vous utilisez des sous-interfaces, ne placez pas d’adresse IP, IPX ou AT sur l’interface principale. Pour vous assurer que la commande frame-relay inverse-arp fonctionne correctement, assignez les DLCI à leurs sous-interfaces avant d’activer l’interface principale. Voici la marche à suivre en cas de défaillance :
-
Désactivez le protocole ARP (Inverse Address Resolution Protocol) pour ce DLCI en utilisant les commandes no frame-relay inverse-arp ip 16 et clear frame-relay-inarp.
-
Corrigez votre configuration.
-
Réactivez la commande frame-relay inverse-arp.
RIP et IGRP
Les mises à jour du protocole RIP (Routing Information Protocol) ont lieu toutes les 30 secondes. Chaque paquet RIP peut contenir jusqu’à 25 entrées de route, pour un total de 536 octets ; 36 octets de ce total sont des informations d’en-tête et chaque entrée de route comporte 20 octets. Par conséquent, si vous annoncez 1 000 routes sur un lien de relayage de trames configuré pour 50 identifiants DLCI, le résultat donne 1 Mo de données pour la mise à jour du routage toutes les 30 secondes ou de 285 kbit/s pour la bande passante utilisée. Sur une liaison T1, cette utilisation représenterait 18,7 % de la bande passante, et chaque durée de mise à jour serait de 5,6 secondes. Une telle quantité de bande passante est considérable et jugée à la limite acceptable, mais le CIR devrait alors se situer dans la région de la vitesse d’accès. Évidemment, tout ce qui est inférieur à une liaison T1 entraînerait une surcharge du système. Exemple :
-
1000/25 = 40 paquets X 36 = 1 440 octets d’en-tête
-
1000 X 20 octets = 20 000 octets d’entrées de route
-
Total de 21 440 octets X 50 DLCI = 1 072 Mo de mises à jour RIP toutes les 30 secondes
-
1 072 000 octets / 30 s X 8 bits = 285 kbit/s
Les mises à jour du protocole IGRP (Interior Gateway Routing Protocol) ont lieu toutes les 90 secondes (cet intervalle est configurable). Chaque paquet IGRP peut contenir 104 entrées de routage, pour un total de 1 492 octets, dont 38 octets d’information d’en-tête, et chaque entrée de route fait 14 octets. Si vous annoncez 1 000 routes sur un lien de relayage de trames configuré avec 50 identifiants DLCI, la demande est d’environ 720 Ko de données pour la mise à jour du routage toutes les 90 secondes ou de 64 kbit/s pour la bande passante utilisée. Sur un lien T1, cette utilisation représenterait 4,2 % de la bande passante, et chaque durée de mise à jour serait de 3,7 secondes. Cette utilisation de la bande passante est acceptable :
-
1000/104 = 9 paquets X 38 = 342 octets d’en-tête
-
1000 X 14 = 14 000 octets d’entrées de routage
-
Total = 14 342 octets X 50 DLCI = 717 Ko de mises à jour de l’IGRP toutes les 90 secondes
-
717 000 octets / 90 X 8 bits = 63,7 kbit/s
Les mises à jour de routage du protocole RTMP (routing table maintenance protocol) ont lieu toutes les 10 secondes (cet intervalle est configurable). Chaque paquet RTMP peut contenir 94 entrées de routage étendues, pour un total de 564 octets, 23 octets d’information d’en-tête, et chaque entrée de routage fait 6 octets. Si vous publiez 1 000 réseaux AppleTalk sur un lien de relayage de trames configuré pour 50 identifiants DLCI, le résultat est d’environ 313 Ko de mises à jour RTMP toutes les 10 secondes, soit une bande passante de 250 kbit/s. Pour rester au degré de bande passante acceptable de 15 % ou moins, un débit T1 est requis. Exemple :
-
1000/94 = 11 paquets X 23 octets = 253 octets d’en-tête
-
1000 X 6 = 6000 octets d’entrées de routage
-
Total = 6 253 X 50 DLCI = 313 Ko de mises à jour du RTMP toutes les 10 secondes
-
313 000/10 s X 8 bits = 250 kbit/s
Les mises à jour des paquets RIP IPX se produisent toutes les 60 secondes (cet intervalle est configurable). Chaque paquet RIP IPX peut contenir 50 entrées de routage pour un total de 536 octets, 38 octets d’information d’en-tête, et chaque entrée de routage fait 8 octets. Si vous publiez 1 000 routes IPX sur un lien de relayage de trames configuré pour 50 identifiants DLCI, le résultat est de 536 Ko de mises à jour IPX toutes les 60 secondes, soit une bande passante de 58,4 kbit/s. Afin de maintenir un degré acceptable pour la bande passante (15 % ou moins), un débit de 512 kbit/s est requis. Exemple :
-
1000/50 = 20 paquets X 38 octets = 760 octets d’en-tête
-
1000 X 8 = 8 000 octets d’entrées de routage
-
Total = 8760 X 50 DLCI = 438 000 octets de mises à jour IPX toutes les 60 secondes
-
438 000/60 s X 8 bits = 58,4 kbit/s
Les mises à jour des paquets du point d’accès au service (SAP) IPX ont lieu toutes les 60 secondes (cet intervalle est configurable). Chaque paquet des SAP IPX peut contenir sept entrées de diffusion pour un total de 536 octets, 38 octets d’information d’en-tête, et chaque entrée de diffusion fait 64 octets. Si vous publiez 1 000 annonces IPX sur un lien de relayage de trames configuré pour 50 identifiants DLCI, le résultat est de 536 Ko de mises à jour IPX toutes les 60 secondes, soit une bande passante de 58,4 kbit/s. Afin de maintenir un degré acceptable pour la bande passante (15 % ou moins), un débit supérieur à 2 kbit/s est requis. Évidemment, dans ce scénario, le filtre SAP est nécessaire. Comparativement aux autres protocoles mentionnés dans la présente section, les mises à jour des SAP IPX nécessitent le plus de bande passante :
-
1000/7 = 143 paquets X 38 octets = 5 434 octets d’en-tête
-
1000 X 64 = 64 000 octets d’entrées de routage
-
Total = 69 434 X 50 DLCI = 3 471 700 octets d’annonces de services IPX toutes les 60 secondes
-
3 471 700 / 60 s X 8 bits = 462 kbit/s
Keepalive
Dans certains cas, la connexion sur le périphérique Cisco doit être maintenue pour une durée légèrement inférieure (environ 8 secondes) à celle du commutateur. Vous constaterez un tel besoin si l’interface continue à monter et à descendre.
Interfaces série
Les interfaces série, qui sont multipoints par défaut, sont des supports non diffusés, tandis que les sous-interfaces point à point sont quant à elles diffusées. Si vous utilisez des routes statiques, une orientation est alors possible vers le prochain saut ou la sous-interface série. Pour la configuration multipoint, il faut une orientation vers le saut suivant. Ce concept est très important lorsque vous utilisez OSPF sur le relayage de trames. Le routeur doit savoir qu’il s’agit d’une interface de diffusion pour que la configuration OSPF fonctionne.
OSPF et multipoint
Les configurations OSPF et multipoint peuvent être très problématiques. OSPF a besoin d’un routeur désigné (DR). Si vous commencez à perdre des PVC, la connexion peut être interrompue sur certains routeurs, qui tenteront alors de devenir un DR, même si d’autres routeurs détectent toujours l’ancien DR. Ainsi, une défaillance du processus OSPF se produit.
La surcharge associée à OSPF n’est pas aussi évidente et prévisible que celle des protocoles traditionnels de routage à vecteur de distance. L’imprévisibilité provient de la stabilité des liaisons réseau du processus OSPF. Si toutes les contiguïtés d’un routeur de relayage de trames sont stables, seuls les paquets Hello voisins (keepalive) circuleront, ce qui cause beaucoup moins de surcharge que le protocole à vecteur de distance (comme RIP et IGRP). Si, toutefois, les routes (contiguïtés) sont instables, une inondation d’état des liaisons se produira, et la bande passante peut alors être consommée rapidement. De plus, OSPF est gourmand en processeur lors de l’exécution de l’algorithme de Dijkstra, qui est utilisé pour calculer les routes.
Dans les versions antérieures du logiciel Cisco IOS, une attention particulière devait être apportée lors de la configuration d’OSPF sur des supports multiaccès sans diffusion, par exemple, le relayage de trames, X.25 et ATM. Le protocole OSPF considère ces supports comme tout autre support de diffusion, tel qu’Ethernet. Les réseaux en nuage multiaccès sans diffusion (NBMA) sont généralement intégrés à une topologie en étoile. Les circuits virtuels permanents ou commutés sont présentés dans un maillage partiel, et la topologie physique n’offre pas la configuration multiaccès comme le croit le protocole OSPF. Dans le cas d’interfaces série point à point, OSPF maintient toujours une contiguïté entre les voisins. Les contiguïtés d’OSPF échangent des informations de base de données. Afin de réduire au minimum la quantité d’informations échangées sur un segment en particulier, OSPF choisit un routeur comme DR, et un autre comme routeur désigné de secours (BDR) sur chaque segment multiaccès. Le BDR est élu comme mécanisme de sauvegarde au cas où le DR serait en panne.
Le but de cette configuration est de créer un point de contact central pour les routeurs afin qu’ils puissent échanger des informations. Le choix du DR s’est avérer problématique, car le DR et le BDR devaient avoir une connectivité physique complète avec tous les routeurs existant dans le nuage. En outre, vu le manque de capacités de diffusion, le DR et le BDR devaient avoir une liste statique de tous les autres routeurs connectés au nuage. Cette configuration est possible au moyen de la commande neighbor :
neighbor ip-address [priority number] [poll-interval seconds]
Dans les versions ultérieures du logiciel Cisco IOS, différentes méthodes peuvent être utilisées pour éviter les complications liées à la configuration de voisins statiques et pour éviter que des routeurs en particulier deviennent des DR ou des BDR sur le réseau en nuage sans diffusion. La méthode à utiliser dépend de la nouvelle configuration du réseau ou de la conception existante à modifier.
Une sous-interface est une façon logique de définir une interface. La même interface physique peut être fractionnée en plusieurs interfaces logiques, avec chaque sous-interface définie comme étant point à point. Ce scénario a été créé à l’origine pour faciliter la gestion des problèmes causés par l’horizon partagé sur le réseau NBMA et les protocoles de routage vectoriel.
Une sous-interface point à point a les propriétés de n'importe quelle interface point à point physique. En ce qui concerne OSPF, une contiguïté est toujours formée au-dessus d'une sous-interface point à point sans élection de DR ou de BDR. OSPF considère le nuage comme un ensemble de liaisons point à point et non comme un réseau multiaccès. Le seul inconvénient du réseau point à point est que chaque segment appartient à un sous-réseau différent. Ce scénario pourrait s’avéré inacceptable, car certains administrateurs ont déjà attribué un sous-réseau IP à l’ensemble du nuage. Une autre solution de contournement consiste à utiliser des interfaces non numérotées IP sur le nuage. Il se peut également que ce scénario pose problème à certains administrateurs qui gèrent le réseau WAN en fonction des adresses IP des lignes série.
Sources
-
International Telegraph and Telephone Consultative Committee, « ISDN Data Link Layer Specification for Frame Mode Support Services », recommandation Q.922 du CCITT, 19 avril 1991.
-
American National Standard For Telecommunications, Integrated Services Digital Network – Core Aspects of Frame Protocol for Use with Frame Relay Support Service, ANSI T1.618-1991, 18 juin 1991.
-
Technologies de l'information - Télécommunications et échange d'informations entre systèmes - Identification de protocole dans la couche réseau, ISO/IEC TR 9577: 1990 (E) 1990-10-15.
-
International Standard, Information Processing Systems - Local Area Networks - Logical Link Control, ISO 8802-2: 1989 (E), IEEE Std 802.2-1989, 1989-12-31.
-
Internetworking Technology Overview, octobre 1994, Cisco Systems
-
Finlayson, R., Mann, R., Mogul, J. et M. Theimer, « Reverse Address Resolution Protocol », STD 38, RFC 903, Stanford University, juin 1984.
-
Postel, J. et Reynolds, J., « Standard for the Transmission of IP Datagrams over IEEE 802 Networks », RFC 1042, USC/Information Sciences Institute, février 1988.
-
Frame Relay Forum (FRF) 1.1-User-Network Interface (UNI)
-
FRF 2.1-Frame Relay Network-to-Network Interface (NNI)
-
FRF 3.1-Multiprotocol encapsulation
-
FRF 4-SVCs
-
FRF 6-Frame Relay service customer network management (MIB)
-
Gang of four LMI
-
Q.922, annexe A
-
ANSI T1.617, annexe D
-
ANSI T1.618, T1.606
-
ITU-T Q.933, Q.922
-
Notes de configuration pour la mise en œuvre améliorée d’IGRP amélioré
Informations connexes
- Plus de renseignements sur les commandes de relayage de trames
- Plus de renseignements sur la configuration du relayage de trames
- Plus de renseignements sur les commandes de la ligne de secours
- Plus de renseignements sur les commandes de débogage ISDN
- Plus de renseignements sur les commandes de débogage PPP
- Plus de renseignements sur les types, les codes et les valeurs de commutateurs ISDN
- Assistance et documentation techniques - Cisco Systems
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)