Cisco France Blog / Réseaux / J’ai testé pour vous : les EVC (ou comment bridger sur un ASR 1000 et bien plus encore…)

J’ai mis la main sur un petit stock d’ASR 1000 et comme toujours je vais essayer de vous faire profiter de quelques instants de bonheur dans mon lab 🙂 Tout est venu de la demande d’un client qui me demandait si l’on pouvait bridger sur l’ASR 1000… On avait depuis presque le début de la plateforme possibilité de faire un bridge simple entre 2 sous-interfaces ou 2 interfaces (sans gestion de table de forwarding L2) mais rien de transcendant. Ensuite est arrivé le support des EVC (Ethernet Virtual Circuits) qui permettent de faire plus ou moins tout ce qu’on veut sur Ethernet, qui a été ensuite complété par l’arrivée de VPLS fin 2011. Donc en matière de bridging on sait faire pas mal de choses sur l’ASR 1000, mais ceux qui s’attendent à le faire via un bête “switchport” vont être un peu déboussolés. Ce post aidera un peu j’espère!

Un peu de théorie

Les EVC c’est quoi? Ceux qui ont joué avec nos switchs ME ou nos cartes ES (sur 7600 ou 6500) connaissent déjà. Il s’agit selon la définition du Metro-Ethernet forum (MEF) de l’association de plusieurs interfaces Ethernet qui va nous permettre de créer un service point-à-point ou multipoint-à-multipoint. Maintenant en pratique chez Cisco ca va se traduire par un ensemble de commandes qui vont permettre de manipuler Ethernet sur un équipement et qui vont un peu au delà du simple “switchport”. Tout cela nous arrive des aficionados du Metro-Ethernet qui avaient les besoins les plus poussés en la matière. On va sur l’équipement créer des Ethernet Flow Points (EFP – toujours selon la définition du MEF) qui vont être le point de départ de toute configuration de service. On va donc définir:

• ce qui va tomber dans cet EFP (par exemple un simple VLAN, un ensemble de VLAN, une chaîne de 2 VLANs pour du QinQ, un champ CoS…)
• ce qu’on va offrir comme service sur cet EFP (bridger, manipulation de trames…)

On va créer ces EFP via la commande “service instance …” et c’est certainement la raison pour laquelle on utilisera peut-être plus volontiers le terme de “service instance” que d’EFP. C’est donc le terme de “service instance” que je vais utiliser dans le reste de ce post. Pour bridger il va donc falloir tout simplement définir des “service instances” et les placer dans le même bridge-domain.

Objectif du lab

Montrer simplement le fonctionnement d’EVC sur l’ASR 1000 et bridger entre 2 sous-interfaces.

Diagramme du lab

Matériel et IOS utilisé

2 ASR 1002 et un 1 ASR 1004 (RP1) en IOS-XE 3.7.0S (Advanced Enterprise Services) – asr1000rp1-adventerprisek9.03.07.00.S.152-4.S.bin

Configuration

Commençons par configurer simplement ASR1 et ASR3

! ASR1
interface GigabitEthernet0/0/0.10
 encapsulation dot1Q 10
 ip address 100.0.0.1 255.255.255.0
!ASR3
interface GigabitEthernet0/0/0.20
 encapsulation dot1Q 20
 ip address 100.0.0.3 255.255.255.0

Là, il n’y a rien de compliqué 🙂 C’est maintenant qu’il faut être un peu attentif parce qu’on va attaquer la configuration d’ASR2. Je vais définir sur Gi0/0/0 la “service instance” 1000 qui va matcher le VLAN 10. Sur Gi0/0/1 je vais configurer la “service instance” 1001 qui va matcher le VLAN 20. Je vais placer ces 2 “service instances” dans le même bridge-domain sur lequel on peut configurer quelques paramètres: ici j’ai mis de l’IGMP snooping et changé le temps de présence par défaut dans la table de bridging. Il y a une dernière petite chose à faire: manipuler les tags dot1q pour que ça ait une cohérence! Contrairement à un bête “switchport access vlan …” le routeur ne vas supprimer le tag 802.1Q quand il est matché par la “service instance”. Donc si l’on ne fait rien on bridge bien mais ce qui arrive sur le VLAN 10 sur l’interface Gi0/0/0 repart sur le VLAN 10 sur Gi0/0/1 (au lieu du VLAN 20). Il va donc falloir supprimer les en-têtes 802.1Q quand les trames arrivent et les ré-appliquer quand elles ressortent: c’est fait par les commandes “rewrite” ci-dessous. Ne pas oublier le “symmetric” à la fin!

interface GigabitEthernet0/0/0
 description TEST-EVC
 no ip address
 negotiation auto
 cdp enable
 service instance 1000 ethernet
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 50
 !
!
interface GigabitEthernet0/0/1
 description TEST-EVC
 no ip address
 negotiation auto
 cdp enable
 service instance 1001 ethernet
  encapsulation dot1q 20
  rewrite ingress tag pop 1 symmetric
  bridge-domain 50
!
bridge-domain 50
 mac aging-time 600
 ip igmp snooping

Notez bien que j’aurais pu utiliser le même numéro de “service instance” pour les 2 interfaces. La notion de “service instance” est purement locale à l’interface en question. En revanche le numéro de bridge-domain est global puisqu’il permet de faire correspondre entre elles les différentes “service instances” créées.

Pour voir les “service instances” créés:

ASR2#sh ethernet service instance
Identifier Type Interface State CE-Vlans
1000 static GigabitEthernet0/0/0 Up
1001 static GigabitEthernet0/0/1 Up

Je peux aussi regarder le détail d’une “service instance”:

ASR2#sh ethernet service instance id 1000 interface gi0/0/0 detail
Service Instance ID: 1000
Service Instance Type: static
Associated Interface: GigabitEthernet0/0/0
Associated EVC:
L2protocol drop
CE-Vlans:
Encapsulation: dot1q 10 vlan protocol type 0x8100
Rewrite: ingress tag pop 1 symmetric
Interface Dot1q Tunnel Ethertype: 0x8100
State: Up
EFP Statistics:
 Pkts In Bytes In Pkts Out Bytes Out
 43 3226 18 1658
EFP Microblocks:
****************
Microblock type: Bridge-domain
Bridge-domain: 50
Microblock type: L2Mcast
L2 Multicast GID: 1

Microblock type: dhcp_snoop
L2 Multicast GID: 1

Résultats

Je me place simplement sur ASR1 et je fais un ping vers ASR3 (adresse sur le même lien-local) et on voit bien que l’équipement est joignable:

ASR1#ping 100.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Et un petit traceroute pour bien se rendre compte que personne ne route au milieu:

ASR1#traceroute 100.0.0.3
Type escape sequence to abort.
Tracing the route to 100.0.0.3
VRF info: (vrf in name/id, vrf out name/id)
 1 100.0.0.3 2 msec * 1 msec

Et je peux voir les “service instances” configurées dans le bridge domain 50 et les MAC apprises:

ASR2#sh bridge-domain 50
Bridge-domain 50 (2 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 600 second(s)
 GigabitEthernet0/0/0 service instance 1000
 GigabitEthernet0/0/1 service instance 1001
 MAC address Policy Tag Age Pseudoport
 F866.F25E.7400 forward dynamic 208 GigabitEthernet0/0/1.EFP1001
 B414.8901.AB00 forward dynamic 109 GigabitEthernet0/0/0.EFP1000

Conclusion

Certes ceux qui voulaient faire un simple switchport devront changer un peu leurs habitudes mais il faut bien se rendre compte de la puissance qui est disponible grâce au support des EVC. Au delà de la commutation on peut manipuler largement les en-têtes 802.1Q et s’adapter quasiment à tous les cas de figure. Tout cela est rendu possible grâce aux “service instances” qui sont une couche d’abstraction permettant de ne plus associer obligatoirement le bridging à un numéro de VLAN.

Références

Guide de configuration des EVC sur ASR 1000

Page de l’ASR 1000

Authors

Jerome Durand

Technical Solutions Architect