le - dernière modification le par
Jimena Saez
Ci-dessous vous retrouverez les questions qui ont été répondues par nos experts durant le webcast.
Conduit par Michael Di Bartolomeo, ce webcast explique comment déployer le Virtual Port Channel (vPC), avec une explication de l'opération et configurations avancées nécessaires ou disponibles. Cette vidéo inclut une démonstration.
Notre expert : Michael Di Bartolomeo (présentateur)
Pour plus d'informations, visitez la section Data Center.
Cliquez sur les boutons pour accéder aux contenus proposés
Sujets abordés lors de la présentation : Virtual Port-Channel (vPC), Nexus, peer-gateway, routing over vPC et CFS.
Virtual Port-Channel : Opération et Configuration Avancée
Q: Question des loops sur un vPC Nexus en vPC vers un FI vers un serveur 2 liens. Au lieu de mettre le serveur en Teaming nous avons fait un bridge... et nous avons eu un loop. Y a-t'il quelque chose que nous puissions mettre en place pour éviter ce loop ?
R : M.DB. - Sera répondue plus tard car on nécessite plus d'informations sur la topologie. (Réponse en cours, pourra être reprise dans l'événement Ask Me Anything ).
Q: Bonjour, question d'ordre simplement pratique. Comment peut-on voir la vPC consistency quand nous avons beaucoup de vlan? (en général on ne voit que les 1ers)
R : M.D. - Vous pouvez obtenir plus d'info avec la commande "show system internal vpcm info global".
R : M.DB. - Dans mon lab. j'avais montré la commande "show vpc consistency parameter global". C'est un output qui montre toutes les VLAN, absolument toutes les VLAN crées sur un switch et sur l'autre, qui sont autorisées à transiter sur le domaine vPC, et on voit également toutes les interfaces VLAN associées, si jamais le switch a des capacités L3. Donc on voit la liste complète des VLAN, et souvent là on voit ce qui manque d'un côté ou de l'autre. Si on a énormément d’interfaces VLAN, c’est parfois un peu complexe de tout visualiser, mais les informations recherchées devraient être visibles. S’il y a d’autres questions vis-à-vis de cette commande, on peut en discuter sur l’espace dédié après session.
Q: VRRP fonctionne bien avec vPC ?
R : M.DB. - Oui, VRRP marche avec vPC, ça ne pose pas de problème. Le principe actif-actif pour le data plane pour le transit reste exactement le même que pour HSRP.
Q: Est-il possible d'utiliser le PKA dans le PL ?
R : M.DB. - Transiter le PKA à travers le Peer Link, c'est Extrêmement déconseillé - je ne sais même pas si ça pourrait marcher - mais ce n'est probablement pas un scénario supporté. Pour la simple et bonne raison qu'on a essayé de dissocier ces deux fonctionnalités. Pourquoi ? Parce que si jamais on a une défaillance du PL sur l'un de deux switches - je parle du PL « Peer Link » -, on va perdre le PKA et donc on va se retrouver avec un scénario où les switches vont supposer que les deux ne savent plus communiquer, avec chacun des switches supposant que l’autre est fini (est mort). A ce moment précis, on va se retrouver dans un scénario où les deux vont vouloir forwarder le trafic activement, sans savoir lequel est vraiment le primaire ou le secondaire. Donc ici on a un scénario de « split brain » et donc de façon générale pour éviter ça, on utilise un lien L3 dédié pour le PKA, parce que là maintenant si on reprend la situation où le Peer Link fail à un certain moment : le PKA, qui est un autre lien dédié, indiquera encore que l’autre switch est vivant et donc on évitera cette situation de « split brain ». Et c'est là que la notion de primaire sera plus ou moins importante, ce sera le primaire qui va continuer à garder ces liens vPC actifs, alors que le secondaire va shutdown tous ses liens vPC.
En résume, il faut dissocier physiquement le PL et le PKA.
Q: Bonjour, je suis un peu déconcerté par le design de connecter un équipement L3 avec un PO vers les Nexus. Sur la page 76 du best practice Nexus 7K, il est indiqué que ce design n'est pas supporté. Est-ce à dire que la commande layer 3 l'autorise ?
R : M.DB. -
Je ne suis pas particulièrement sûr de ce qu'indique la page 76 des best practices. Donc je pourrai répondre éventuellement à côté de la plaque, si jamais c’est le cas n'hésitez pas à nous voir réagir sur les discutions qui vont prendre lieu après la présentation.
Ici je vois deux aspects à la question, la première : est-ce qu'on supporte des liens L3 du côté vPC ? Non, les liens vPC devront être des liens L2. On ne supporte pas des liens L3 avec vPC, mais rien n'empêche d’avoir un appareil connecté avec un L3 et d’avoir des port accès de l'autre côté qui vont tagger simplement le trafic L3 avec un dot1Q pour le VLAN choisit.
Maintenant si jamais on parle purement de peering l3, layer3 peer-router est là principalement pour autoriser l'adjacence en termes de protocoles de routage unicast, BSPF, BGP, etc.
Pour moi, ces deux points sont deux choses distinctes. Si jamais j'ai n'ai pas bien répondu à la question parce que j’ai mal compris la question, je veux m'en excuser, et on en pourra traiter ça sur le forum de discussion après.
Q: Votre outil de virtualisation réseau semble vraiment agréable à utiliser, duquel s'agit-il ?
R : M.DB. - Pour la démonstration j'ai utilisé Termius, qui est simplement un programme qui permet de se connecter à des appareils via Telnet ou SSH. Maxime va donner plus d'informations, il va indiquer exactement quel est le logiciel que j'utilise. Et donc il n'est ne pas vraiment un outil de virtualisation, c'est simplement un outil console - on peut le voir comme ça - qui permet de se connecter en SSH ou Telnet à nos appareils.
M.D. - Michael utilise "Termius" qui est un logiciel disponible sur macOs/Windows. Plus d'information ici : https://termius.com/
Q: Que se passe-t-il en cas de défaillance du lien PKA ?
R : M.DB. - En cas de défaillance de Peer Keep Alive (PKA). Donc si jamais on perd la connexion L3, par exemple, ici dans le lab que je vous ai montré, on était à travers le management, donc on peut avoir un réseau management complet derrière. Si jamais il y a une défaillance du côté du réseau management, on risque de perdre le PKA effectivement ça n'influencera pas la bonne opération de vPC, on verra un message apparaître disant que le peer keep alive a été perdu, ça ne posera à priori aucun problème, si vPC était déjà établi auparavant. Si on est en train d'établir vPC et que le PKA ne peut pas être formé, là on aura plus de soucis et on n'arrivera pas à emmener vPC à établir un état actif complet.
Q: Que se passe-t-il si je change les IPs des interfaces par lequel le PKA transite?
R : M.DB. - Dans mon cas si jamais je change les IPs de management, par exemple les interfaces de management, on perdra le PKA si on ne change pas la configuration vPC de la bonne manière, évidemment. Donc imaginons qu'on change les IPs des interfaces de management sans changer la configuration vPC, aucun problème vPC va indiquer qu'on a perdu le PKA mais on va continuer la bonne opération vPC. Néanmoins, il peut y avoir un problème si on modifie la configuration et qu'on met à jour le système ou qu’on reboote les switches. Parce à ce moment-là vPC va vouloir boot et la première chose que vPC va vouloir faire après avoir démarré le processus, ça va être de vérifier si jamais on arrive à atteindre les IPs spécifies comme PKA. Si la configuration vPC n'a pas été changée de la même manière que la configuration des interfaces, alors là on aura un problème la vPC ne démarrera pas. La solution sera évidemment de rechanger correctement la configuration pour mettre dans le domaine vPC dans la commande peer keep alive, les IPs correspondantes aux interfaces utilisées pour le peer keep alive.
Q: Comment procéder a une mise à jour des switches en vPC ?
R : M.DB. - Ça peut être un sujet complexe et assez long à préparer, mais de toutes façons - en général - les consignes de base sont d'abord mettre à jour le switch primaire. Et qu'est-ce qui va se passer si on fait cela, le switch qui est le secondaire va prendre le rôle du primaire parce qu’il va remarquer que le peer keep alive ne répond pas, le peering qui est down, il va rester secondaire mais va il va avoir le rôle opérationnel du primaire. Ensuite le switch qui est mis à jour va revenir à la vie, et il va découvrir qu'il est maintenant primaire avec le rôle opérationnel de secondaire, c’est à dire que les rôles opérationnels ont été échanges entre les deux appareils, et après on mettra à jour le secondaire qui fera l'inverse, donc maintenant celui qui était primaire opérationnel secondaire passera de nouveau primaire et l'appareil qui était secondaire initialement, après sa mise à jour, repassera secondaire de façon normale. C'est en général ce qu'on conseille pour la mise à jour des switches en vPC. A savoir que si on procède de cette façon-là, en général on arrive à éviter une disruption de service avec le switch qui reste actif, qui est toujours capable de faire transiter le trafic. Et il y a également un détail qui est légèrement intéressant, qui est l'état au moment où le premier switch qui a été mis à jour revient à la vie, et que le deuxième n'a pas encore été mis à jour. On a une version qui n'est pas même sur les deux switches. C'est quelque chose qui est nécessaire en principe pour vPC. Maintenant, dans le cas d’une mise à jour, il peut y avoir un très court instant pendant lequel cette situation peut intervenir et qui est sensée ne pas poser de problème.
Q: Que se passe-t-il en cas de défaillance du PL, mais que le PKA reste actif ?
R : M.DB. - On a juste une défaillance du Peer Link et que le PKA reste actif. Donc, si jamais le PKA n'est transmis à travers le Peer Link évidement, on va avoir un vPC primary, donc le primaire, qui va rester actif en termes de trafic forwarding et qui va garder tous ses vPC ports PL actifs et up. Et le secondaire vPC va voir que le PL est encore vivant, même si le Peer Link ne marche plus, et va simplement arrêter de transiter le trafic à travers ces port PL - il va les suspendre - jusqu'à ce que le port redevienne actif.
Q: Comment se comporte PIM avec vPC ?
R : M.DB. - Et bien PIM avec vPC, donc comme je l'ai mentionné plus tôt, layer3 peer-router marche pour tout ce qui est adjacence layer 3 Unicast. Pour le Multicast, malheureusement on n'a pas de support pour tout ce qui est adjacence over vPC, donc si jamais on forme une adjacence PIM à travers un port tunnel vPC, ce n'est pas supporté ; il faudra donc switcher sur des liens L3 et compter sur L’ECMP (Equal Cost Multi-Path) plutôt que sur vPC à proprement parler.
Q: Quel est l'effet de vPC sur l'ordre de réception de paquets à destination ?
R : M.DB. - Si l’on parle d’une communication host-to-host, l’ordre devrait être respecté. En général, la crainte vient des segment TCP « out-of-order », mais elle n’a bien souvent pas de raison d’être. Les paquets arriveront sur le Nexus 1 ou 2, en fonction du hachage des port-channels. Les port-channels ont un mécanisme de hachage qui prend bien souvent les paramètres suivants en considération :
- IP (Src, dst) ; MAC (Src, dst) ; L4 PORT (Src, dst).
Pour un même flux TCP, ces paramètres ne devraient pas changer, et donc les paquets transiteront tous via le même switch en vPC. En conclusion, l’ordre des paquets transitant sur un domaine vPC n’a aucune raison de changer.
Q: Peut-on faire une adjacence OSPF entre les 2 routeurs vPC via VLAN dans le Peer-Link? (pas besoin de tirer un lien L3 dédié entre les 2 routeurs vPC)
R : M.DB. - Oui. Deux interfaces Vlans devraient être capables de former une adjacence OSPF à travers le peer-link sans aucun problème, même avec peer-gateway activé.
Je vous invite à regarder le document suivant, indiquant les topologies supportées (et non-supportées pour le l’adjacence L3 over vPC :
https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/118997-technote-nexus-00.html
La réponse à votre question se trouve dans la colonne du milieu de la table 1 : « Protocol Adjacency between Nexus-A and Nexus-B ».