Introduction

Le VPC est exactement le même concept du Port-Channel classique (Agrégation des liens) sauf qu’il est implémenté entre deux châssis indépendants, ce qui n’était pas faisable avec les Port-Channels classiques. 

La notion du VPC concerne uniquement et bien évidement les switches Nexus.

L’Équipement tiers peut être un switch, un serveur, un Loadbalancer, … à condition qu’il supporte l’Agrégation des liens (LACP). 

Avec cette notion, le Design des Architectures des Data Centers est simplifié. De plus, on multiplie la bande passante entre la couche Access et Distribution (Agrégation) et on obtient 0 ports bloqués par le STP. La convergence devient donc beaucoup plus rapide en perdant un lien par exemple.            

Cela est similaire au concept des Po implémentés vers les Stacks ou les VSSs, mais pour ces derniers, on a toujours un seul Control Plane avec plusieurs Data Planes actifs. Pour les Nexus implémentés avec le VPC, chaque switch possède son Control Plane et son Data Plane dédiés, avec une implémentation des Pos à travers plusieurs châssis possible.

Les composants d’une architecture basée sur les Nexus et contenante un VPC sont les suivants :

-  vPC domain : C’est le domaine global qui englobe les équipements et Ports sur lesquels on monte le VPC, il se caractérise par un identifiant unique dans le DC.

-  vPC peer switches : Les deux switches qui contiennent le VPC. Un équipement est élu Primary et l’autre est Secondary.

-  vPC peer-link : c’est le lien Port-Channel (2 x 10G) qui sert à la synchronisation entre les 2 vPC peers (Identification des Rôles, Flux de multicast et de broadcast, synchro des MACs, HSRP, OSPF …).

-  vPC peer-keepalive link : c’est un lien à part qu’il permet de superviser périodiquement l’état d’un vPC peer (Joignable UP ou non). Il est fortement recommandé qu’il soit dans un Réseau Out-of-Band Management. Aucun trafic DATA ne circule à travers ce lien.

-  vPC : c’est le lien PortChannel entre les vPC peers et les autres équipements (Switches, Serveurs, LoadBalancers, Fexs ,...).

VPC Scénarii Fails

- VPC Peer-Link KO : Le Secondary Peer (le switch avec la priorité la plus élevée) mets tous ses VPC member ports en État « Suspended », puis il « shutdown » les SVI hébergés afin d’éviter les problèmes de routage, d’asymétrie, des boucles, … (vu qu’il n’y a aucune Sychro de configs entre les deux switches). Le trafic continue son acheminement, sans interruption, vers le Switch Actif à travers un seul lien pour chaque VPC. 

- Peer Keepalive Link KO : Aucun Impact, le check de l’état des deux Peers se fait à travers le Peer-Link.  

- Un de deux Peers est KO : Le Peer Keepalive Link détecte ce Failure et le flux est acheminé vers l’autre Peer à travers un seul lien du VPC. 

- Peer Keepalive Link KO et Peer-Link KO : Ce scenario s’appelle “Dual-Active” ou “Split Brain” vPC failure. Les deux switches se considèrent -chacun- comme étant Actif dans le VPC et le trafic est extrêmement perturbé.  

Étapes de Configuration 

Pour expliquer les implémentations, on va se baser sur le schéma suivant :

Activation des Features Nécessaires :

Activation d’un VPC Peer Link entre les deux Équipements : 

Activation de l’Interface du Management sur chaque Switch : 

Activation du Domaine VPC entre les deux Nexus : 

La commande « role priority » permet d’imposer les rôles Primaire et Secondaire sur les deux châssis du domaine VPC. La valeur par défaut est 32 667 et, si configurée manuellement, le switch avec la priorité la plus faible est le vPC Primary Switch.

La commande «peer-gateway» permet à un Peer d’agir en tant que Gateway pour tout le flux destiné à l’adresse MAC de l’autre Peer dans le domaine VPC. Elle active le « local forwarding» du Traffic sans besoin donc de le « forwarder » vers l’autre Peer à travers le vPC Peer-Link.

La commande «peer-switch» permet à un couple de deux Nexus dans le domaine VPC d’apparaître comme étant un seul Root Spanning-tree Bridge dans la Topologie (Layer 2). 

La commande «ip arp synchronize» permet  la synchronisation des deux tables ARP tables de deux Peers. 

La commande « auto-recovery » est conseillée à implémenter, sa fonctionnalité est utile lorsqu’est dans le cas d’un Peer-Link KO (le switch Secondary suspend ses ports). Si en plus, et dans un cas particulier où le switch Actif est aussi KO, cette commande Réactive automatiquement les ports du switch Secondary pour éviter la coupure de service.

Configuration du lien VPC :

Commandes de Vérification
  
Les deux commandes principales pour vérifier la bonne implémentation du VPC sont "show vpc" et "show vpc role" :

Recommandations 

• Ne pas désactiver le STP
• Configurer les vPC peers dans le Spanning-tree en tant que Root et Secondary Root. Si le vPC peer-switch est implémenté, les deux vPC peers se comporteront comme un seul root
• Aligner le STP Primary root et le HSRP actif avec le vPC primaire. 
• Quand on connecte un équipement Layer 3 à un domaine vPC, ne pas former d’adjacence de routage avec les Peers du VPC à travers le peer-link + VPC.
• Utiliser plutôt les liens L3 avec les Peers surtout dans le cas du Routage Dynamique.