Virtual Port Channel et HSRP : Routed MAC

août 26, 2013  |   Blog   |     |   0 commentaire

Introduction

Le Virtual Port Channel (vPC) est une technologie Cisco qui permet sur la gamme Nexus de créer un port channel qui se termine sur deux Nexus distincts.

Tout d’abord, un rapide rappel de ce que permet le vPC :
Pour faire simple, le vPC permet de faire apparaître une paire de cisco 7000 ou 5000 comme un seul équipement d’un point de vue de la topologie de niveau 2 :


Attention, contrairement à la technologie VSS des Catalyst 6500, les équipements se comportent de manière indépendante au niveau du plan de contrôle, et notamment comme deux équipements distincts au niveau 3.

Il ne s’agit pas ici de faire une présentation de la technologie vPC ni de détailler toute la configuration nécessaire (on peut trouver facilement des ressources sur le sujet, notamment la documentation sur le site de Cisco ) mais de parler d’un cas concret tiré d’une expérience réelle où une compréhension partielle de certains mécanismes mis en jeu (liée à une documentation officielle un peu légère) peut amener un admin réseau à s’arracher les cheveux.

Ici il s’agit de l’intégration entre vPC et HSRP

Le cas

Passons tout de suite au cas concret, illustré par le schéma suivant :

Il s’agit d’une architecture assez simple :

Deux Nexus 7000 reliés en vPC à un Nexus 5000. Le PortChannel entre les 7000 et le 5000 transporte 3 VLANs :

  • VLAN 10 : 192.168.10.0/24
  • VLAN 11 : 192.168.11.0/24
  • VLAN 12 : 192.168.12.0/24

Pour chacun de ces VLANs, les Nexus 7000 portent une SVI (Switch Virtual Interface, c.a.d. une interface VLAN) en .252 et .253 et partagent une adresse HSRP .254.

Un firewall (Cisco ASA) possède une interface trunk permettant d’avoir accès à ces 3 VLANs.

Les 3 VLANs ne sont pas autorisés à communiquer entre eux via les Nexus 7k.

Pour cela on met en place une access-list sur chaque interface VLAN.

Voici par exemple l’ACL appliquée sur l’interface VLAN 10, qui permet d’autoriser uniquement ce VLAN à communiquer avec le subnet 10.1.0.0 (un autre VLAN porté par les 7k mais non représenté sur le schéma) :

10 permit ip 192.168.10.0/24 10.1.0.0/16
20 permit ip 10.1.0.0/16 192.168.10.0/24
30 deny any any

Le problème

Une fois la configuration mise en place, on commence par un test simpliste qui consiste à pinguer les 3 adresses portées par les Nexus 7k dans chaque VLAN, et là c’est le drame !

Par exemple depuis le Firewall, pour le VLAN 10

ASA# ping 192.168.10.252
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.246.28, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
ASA# ping 192.168.10.253
[...]
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
ASA# ping 192.168.10.254
[...]
?????
Success rate is 0 percent (0/5)

De la même façon sur les autres VLANs, Une ou plusieurs IPs parmis les 3 IPs des Nexus ne répondent pas. Pire encore, si l’on teste depuis différentes sources, on obtient des résultats différents !

Nous allons essayer d’y voir plus clair en examinant plus en détail ce qu’il se passe pour chacun des pings effectués depuis l’ASA

Pour le Nexus 5k qui fonctionne ici uniquement au niveau 2, les 7k apparaissent comme un seul équipement relié en port-channel, il forward donc les paquets sur un lien choisi par l’algorithme de load-balancing :

5k1# sh port-channel load-balance

Port Channel Load-Balancing Configuration:

System: source-dest-ip

Ici le load-balancing est effectué à l’aide de l’IP source et destination, on peut donc déterminer pour chaque flux, quelle interface à été choisie.

Par exemple pour connaître le lien choisi depuis l’ASA (192.168.10.1) vers les 3 IPs du VLAN 10 :

5k1# show port-channel load-balance forwarding-path int po1 vlan 10 src-ip 192.168.10.1 dst-ip 192.168.10.252 | incl Outgoing
crc8_hash: 1 Outgoing port id: Ethernet1/1
5k1# show port-channel load-balance forwarding-path int po1 vlan 10 src-ip 192.168.10.1 dst-ip 192.168.10.253 | incl Outgoing
crc8_hash: 8 Outgoing port id: Ethernet1/2
5k1# show port-channel load-balance forwarding-path int po1 vlan 10 src-ip 192.168.10.1 dst-ip 192.168.10.254 | incl Outgoing
crc8_hash: 0 Outgoing port id: Ethernet1/2
Note : Ethernet1/1 et Ethernet1/2 sont respectivement les interfaces physiques vers N7k1 et N7k2

En effectuant la même manipulation sur les deux autres VLANs, on se rend vite compte du lien entre les pings en échec et le choix du lien au sein du Port-Channel :

A chaque fois que le lien choisi n’est pas celui relié au Nexus 7k portant l’adresse IP destination, le ping est en échec. Autrement dit le problème se pose quand le flux doit passer par le lien entre les deux 7k (le peer-link).

Regardons ce qui se passe au niveau de la table MAC sur le Nexus 7k2 pour comprendre pourquoi l’adresse HSRP ne semble pas joignable dans le VLAN 10 :

7k1# sh mac address-table
Legend:
      * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
      age - seconds since last seen,+ - primary entry using vPC Peer-Link,
      (T) - True, (F) - False
 VLAN     MAC Address      Type      age     Secure NTFY Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+----+------------------

G 10       0000.0c07.acfe    static       -       F    F vPC Peer-Link(R)
G 11       0000.0c07.acfe    static       -       F    F vPC Peer-Link(R)
G 12       0000.0c07.acfe    static       -       F    F vPC Peer-Link(R)
G 10       8478.ac0c.97c2    static       -       F    F vPC Peer-Link(R)
G 11       8478.ac0c.97c2    static       -       F    F vPC Peer-Link(R)
G 12       8478.ac0c.97c2    static       -       F    F vPC Peer-Link(R)
[...]

Notre @ MAC HSRP ( 0000.0c07.acfe ) du vlan 10 apparait bien sur le Peer-Link comme attendu, mais l’information intéressante ici se trouve dans les flag “G” et “(R)” présents sur chacune des adresses vues sur ce lien.

En fait ces flags indiquent que ce sont des adresses de passerelle (G) et qu’il faut router (R) ces adresses. Cela permet au Nexus de router directement les flux qui utiliseraient l’adresse HSRP comme passerelle de sortie même si ce Nexus 7k n’est pas le membre actif du groupe HSRP. On se retrouve donc avec un fonctionnement actif/actif au niveau du plan de données même si au niveau du plan de contrôle, il y a toujours un membre actif et l’autre en standby.

Maintenant en quoi ce fonctionnement est important à connaître ? Parce que notre paquet à destination du Peer-Link est traité exactement comme un paquet routé, ce qui signifie qu’il va être envoyé en CPU (carte sup) qui va décrementer le TTL, determiner la destination mais aussi … appliquer les ACL positionnées sur la SVI puisque le paquet aura quitté son VLAN avant d’y être renvoyé !

Note : Le flag G est ajouté sur les adresses HSRP, et quand l’option “Peer Gateway” est activée (ce qui est le cas par défaut) il est également ajouté sur les adresses propres à chaque peer.

Solution et Conclusion

La solution à notre problème est donc relativement simple : autoriser explicitement dans notre access-list les hôtes d’un VLAN à pinger les adresses de Nexus.

Par exemple ajouter à notre ACL de l’interface VLAN 10 vue précedement la ligne 25 :

10 permit ip 192.168.10.0/24 10.1.0.0/16
20 permit ip 10.1.0.0/16 192.168.10.0/24
25 permit icmp 192.168.10.0/24 192.168.10.0/24
30 deny any any

On voit donc que la compréhension de ce fonctionnement interne est nécessaire pour faire face à certaines situations pour le moins déroutantes au premier abord. Malheureusement ce sont des détails techniques que l’on ne trouve pas dans la documentation officielle, et on découvre souvent le fonctionnement en testant en maquette, ou pire, au moment de la mise en production.