Ceci est ma configuration actuelle où j'ai des 40Gbpsliens entre les 4 commutateurs fonctionnant en OSPFutilisant des liens L3 entre eux, mais maintenant je veux doubler ma bande passante entre les commutateurs, donc je prévois d'ajouter (liens en pointillés) des liens L3 et de laisser OSPF équilibrer la charge du trafic sur eux , Pensez-vous qu'il y ait un problème à faire cela ou que ça ira très bien? (je veux une deuxième paire d'yeux)

Voici à quoi ressemble ma configuration ospf sur les 4 commutateurs.

interface Ethernet2/10
  no switchport
  mtu 9216
  ip address 192.168.250.9/30
  no ip ospf passive-interface
  ip router ospf 100 area 0.0.0.0
  no shutdown

interface Ethernet2/11
  no switchport
  mtu 9216
  ip address 192.168.250.13/30
  no ip ospf passive-interface
  ip router ospf 100 area 0.0.0.0
  no shutdown

Plus de détails sur le flux de trafic actuel

mon flux de trafic actuel ressemble actuellement au diagramme suivant SW: le commutateur BGP est actif, donc tout le trafic d'entrée / sortie provenant du FAI. puis SW1 fait le partage de charge entre deux SW3 / 4 en utilisant OSPF ECMP. Au cours des 1 dernières années, nous n'avons eu aucun problème de voix ou de qualité (tout le monde est content). Maintenant, lorsque mon SW1 est en panne, alors OSPF déplace la route BGP vers SW2 et le fait activeet le trafic commence à circuler de SW2 à SW3 / 4 (j'ai testé cette fois plusieurs en décalant manuellement BGP)

Mise à jour - 2

Informations de partage de charge pour OSPF / ECMP

J'ai le partage de charge suivant configuré qui est par défaut sur les commutateurs Cisco Nexus.

# show ip load-sharing
IPv4/IPv6 ECMP load sharing:
Universal-id (Random Seed): 2223335843
Load-share mode : address source-destination port source-destination
GRE-Outer hash is disabled.
Concatenation is disabled.

Comme ce sont des liens point à point, j'envisagerais d'utiliser la panne pour configurer chaque interface / 30 avec ip ospf network point-to-point. (Liens nouveaux et existants). Cela réduit les temporisations bonjour et mort. Cette configuration réduit également la nécessité de négocier un DR et un BDR.

Enfin, je vérifierais les états voisins et les tables de routage OSPF, avant et après le basculement. Vous devriez voir les routes ECMP après les basculements et les voisinages appropriés.

Il y a deux façons de procéder.

• votre méthode proposée, en ajoutant un deuxième lien avec son propre / 30 ou / 31, en vous assurant que OSPF installe plusieurs routes à coût égal dans la table de routage et que le transfert ECMP (EqualCostMultiPath) de CEF gère la transmission de paquets et la distribution des flux à travers l'ensemble des liens disponibles. CEF / ECMP utilise une logique de partage de charge différente de Port-Channel, et peut gérer un nombre inégal de liens beaucoup mieux que les Port-Channel. Voir l' article de blog d'Ivan Pepelniak pour référence.

• use L3 Port-Channels: Déplacez la configuration IP et de routage vers un objet port-channel (qui n'a pas la commande "switchport"), et joignez les interfaces données à cet objet. Laissez la logique de distribution de charge Port-Channel gérer la distribution des flux.

L'idée que vous proposez est plus orientée L3 / routage, mais sa mise à l'échelle peut poser quelques problèmes: vous utiliserez beaucoup de / 30 ou / 31. Vous pouvez évoluer en nombres impairs, mais vous devrez configurer un nouveau lien et éventuellement un sous-réseau pour chaque étape de mise à l'échelle (ou aller ip unnumbered). D'un autre côté, les liens individuels avec leur propre sous-réseau sont plus faciles à dépanner - le ping sur un seul lien donné "vient naturellement".

D'un autre côté, les canaux de port L3 n'ont pas besoin de plus de sous-réseaux IP et ne touchent pas réellement à la logique de configuration de routage donnée. Port-Channel est un peu plus "de style Nexus", car toute l'histoire des commutateurs Nexus est basée sur le concept VPC (qui ne s'applique pas tout à fait ici, je l'admets). La mise à l'échelle de liens supplémentaires est plus facile - il suffit d'en ajouter deux de plus, sans toucher à aucune configuration IP ou de routage. Cependant, les règles pour les canaux de port s'appliquent (par exemple, conserver le nombre de liens avec des puissances de 2), tandis que le dépannage des liens individuels d'un canal de port est moins simple (ne peut pas cingler sur un lien individuel sans le supprimer du port et reconfiguration)

ADDON-1: Et oh oui, suivez absolument les conseils de TDurden pour configurer point à point sur les ... ehm .. liens point à point (vraiment mauvais jeu de mots, je l'admets)

CAVEAT-1: lorsque vous utilisez des canaux de port, assurez-vous de sélectionner une stratégie d'équilibrage de charge qui correspond aux modèles de communication attendus pour la liaison donnée. Lors de la connexion d'un routeur à un routeur (essentiellement seulement deux adresses MAC sur la liaison), "Src / Dst MAC" peut ne pas avoir les résultats souhaités ... Pour référence, consultez le Guide de configuration des interfaces Cisco Nexus 9000 Series NX-OS, Version 9.2 (x)

ADDON-2: Sur Nexus 9000, avec ECMP / CEF, l'algorithme de partage de charge peut être configuré pour inclure les propriétés L4: ip load-sharing address source-destination port source-destinationVoir Configurer le partage de charge dans l'Unicast FIB à partir de la configuration de routage Unicast.

CAVEAT-2 Lorsque vous utilisez L3-Port-Channels, gardez un œil sur la propriété "bande passante" de l'interface port-canal lorsqu'une liaison membre tombe en panne. Selon la plate-forme matérielle / logicielle, la bande passante de l'interface port-canal peut être réduite en conséquence et OSPF peut réagir à cela en augmentant le coût de la liaison donnée. Cela pourrait avoir des conséquences (non) voulues pour la topologie.