Lutter contre l'ingénierie du trafic entrant et sortant vers / depuis les homologues iBGP sur différents POP

Nous sommes un fournisseur de services gérés qui gère un réseau de petite taille dans un seul centre de données à Sydney. Nous avons récemment déployé un nouvel inter-état POP à Melbourne (les deux se trouvent sur la côte est de l'Australie), et pour la première fois je dois faire face à des défis du monde réel en termes d'ingénierie du trafic. J'espère que je pourrai obtenir des conseils ici sur la façon d'obtenir un certain niveau de contrôle sur mes chemins iBGP.

Je posterai probablement quelques questions interdépendantes, mais dans ce cas, je suis spécifiquement préoccupé par l'ingénierie du trafic interne. Je trouve qu'il est étonnamment difficile de comprendre comment obtenir iBGP pour prendre des décisions de routage optimales.

Le principal objectif pour moi est de trouver un moyen de donner à iBGP un concept de frontière et de distance par POP. Je peux donc faire la distinction entre un POP qui se trouve dans la même ville, et un qui est interétatique, et un qui est est contre la côte ouest. Optimisez ensuite le routage entrant / sortant sur cette base.

Je sais qu'il y aura beaucoup de scénarios au cas par cas, mais j'espère que je pourrai développer une stratégie de routage iBGP qui fonctionne peut-être 80% du temps et le reste, je devrais faire face à des cas spéciaux dans le config.

Le contexte

Nous venons d'acquérir 4x ASR 1001-X pour agir en tant que périphériques périphériques à chaque POP (2x par POP, mais en raison des limitations du matériel de commutation, je me concentre uniquement sur le déploiement d'un périphérique périphérique à Melbourne pour l'instant)
Nous utilisons également Juniper pour changer de matériel. EX4500 comme nos «commutateurs principaux» et EX4200 au niveau de la couche d'accès.
Nous avons maintenant deux fournisseurs de transport en commun. Nous nous connectons uniquement à chaque fournisseur dans un seul état chacun.
AS 1000 est un agrégateur et utilise AS 4000 comme l'un de ses principaux en amont à Sydney.
Cela pose un peu de défi car tous les chemins reçus par via AS 1000 sont généralement plus longs de 1 que ceux que nous obtenons d'AS 4000.
J'utilise Ansible pour générer des configurations IOS à l'aide de modèles Jinja2. Donc, ce n'est pas un problème de générer beaucoup de logique de carte de route par homologue iBGP pour faire avancer les choses.

Mes objectifs

Essentiellement, je veux être en mesure d'atteindre un routage optimal entre les POP lors de leur déploiement. Mais en ce moment, je ne suis pas en mesure d'atteindre un niveau de contrôle sur la façon dont iBGP choisit ses chemins.

Ma conception actuelle

J'ai actuellement 2 ASR1K agissant comme routeurs de périphérie avec des tables complètes à Sydney et 1 à Melbourne.
Les deux POP utilisent des fournisseurs de transit différents.
Nous avons un circuit point à point entre les deux POP qui se termine des deux côtés par les périphériques de périphérie sur les sous-interfaces dot1q.
Nous exécutons OSPF sur cette liaison entre tous les périphériques périphériques, et le coût de la liaison est augmenté, il s'agit donc du chemin OSPF de préférence le plus bas.
Nous avons une seule zone OSPF 0 sur les deux POP.
Les périphériques de périphérie sont davantage un noyau / bord convergé - nos commutateurs de base ne font pas beaucoup L3 car ils ne peuvent pas gérer une table complète.
Dans chaque POP, les ASR1K agissent comme des réflecteurs de route pour les autres périphériques BGP dans ce POP - pare-feu, commutateurs principaux, LNS et ainsi de suite.
- Chacun a son propre ID de cluster - pas par POP. Vous cherchez à changer cela par POP.
Chaque ASR1K crée une route par défaut vers les clients à réflecteur de route via BGP.
Tous les ASR1K sont dans un maillage iBGP.
Tous les transits ont la même préférence locale sur tous les sites.

Exemple de routage sous-optimal

Si j'ai tous mes transits Melbourne et Sydney en ligne, le routage sortant fonctionne très bien. Les sorties de trafic de Sydney via Sydney et les sorties de Melbourne via Melbourne.
Le problème est que juste en désactivant par l'administrateur mon transit principal de Sydney, mon transit de Melbourne est automatiquement préféré. Au lieu de mon transit secondaire de Sydney via le routeur BDR02 à Sydney.
Je me retrouve donc souvent avec un scénario où le trafic rebondirait ensuite vers Melbourne par-dessus notre liaison, sortirait à Melbourne, puis retournerait à Sydney. Le chemin qui encourait <1 ms est maintenant d'environ 30 ms.
Pour aggraver les choses, dans ce scénario particulier, je ne peux pas comprendre pourquoi Melbourne est préférée.
- Le poids est identique
- La préférence locale est identique
- AS Path est de même longueur
- Aucun des deux chemins n'est auto-généré.
- Les deux ont IGP comme origine.
- Les deux ont une métrique (MED?) De 0.
- Les deux sont des chemins iBGP du point de vue de ce routeur.
- IGP métrique J'aurais pensé que les corrélations avec le coût de la liaison OSPF car nous utilisons OSPF comme IGP.
- J'ai confirmé que la bande passante de référence 100G est définie sur tous les appareils OSPF.

EDIT: 30/01: Je pense que je me trompe sur la façon dont le coût IGP est calculé et peut-être sont-ils actuellement les mêmes? Toutes mes routes OSPF sont de type E2. Si les coûts IGP sont les mêmes, je suppose qu'il est logique que la meilleure sélection de chemin se fasse en fonction du RID, qui dans ce cas, le RID du MEL BDR serait inférieur à SYD.

J'ai défini le coût de la liaison OSPF entre Sydney à 15 000 beaucoup plus élevé que celui par défaut. J'ai calculé que cela fonctionne de manière fiable avec notre bande passante de référence de 100 Gbit / s.

En termes de coûts de liaison OSPF - il s'agit des préférences OSPF de chaque tronçon suivant des routes BGP:

bdr-01-syd#sh ip route x.x.201.73 (AS 4000 next hop)
Routing entry for x.x.201.72/30
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 15000
  Last update from x.x.13.51 on Port-channel1.1125, 14:57:17 ago
  Routing Descriptor Blocks:
  * x.x.13.51, from x.x.13.66, 14:57:17 ago, via Port-channel1.1125
      Route metric is 20, traffic share count is 1
bdr-01-syd#

bdr-01-syd#sh ip route x.x.31.5 (AS 1000 next hop)
Routing entry for x.x.31.4/30
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 5
  Last update from x.x.216.67 on Port-channel1.36, 1d00h ago
  Routing Descriptor Blocks:
  * x.x.216.67, from x.x.216.163, 1d12h ago, via Port-channel1.36
      Route metric is 20, traffic share count is 1
bdr-01-syd#


x.x.201.73 is the next hop to 139.130.4.4 via the Melbourne path.

x.x.13.51 is the other end of the inter-state Point to Point. x.x.13.66 is BDR-01-MEL.

x.x.31.5 is the next hop to 139.130.4.4 via the Secondary Sydney transit in the same POP as the primary transit - via BDR-02-SYD.

x.x.216.67 is the local OSPF VLAN for the Sydney POP that both BDR01 and BDR02 are in.

x.x.216.163 is the BDR-02-SYD router.

En termes de ces choix OSPF, je peux voir que la "métrique directe" OSPF plus courte est captée. J'aurais pensé que BGP devrait choisir la voie de Sydney sur cette base.

Vous pouvez voir à partir de cette trace que nous sautons immédiatement à Melbourne via Backhaul car le premier saut est de 13 ms: (139.130.4.4 est anycasted et a des chemins dans les deux états).

bdr-01-syd#traceroute 139.130.4.4
Type escape sequence to abort.
Tracing the route to 139.130.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 x.x.13.51 13 msec 13 msec 13 msec
  2 x.x.201.73 14 msec 14 msec 14 msec
  3 x.x.196.54 [AS 4000] [MPLS: Label 25049 Exp 0] 14 msec 14 msec 14 msec
  4 x.x.196.51 [AS 4000] 14 msec 14 msec 14 msec
  5 139.130.110.29 [AS 1221] 14 msec 15 msec 14 msec
  6 203.50.11.113 [AS 1221] 16 msec 14 msec 16 msec
  7 139.130.4.4 [AS 1221] 13 msec 14 msec 14 msec
bdr-01-syd#

bdr-01-syd#sh ip route 139.130.4.4
Routing entry for 139.130.0.0/16
  Known via "bgp 5000", distance 200, metric 0
  Tag 4000, type internal
  Last update from x.x.201.73 06:06:14 ago
  Routing Descriptor Blocks:
  * x.x.201.73, from x.x.13.66, 06:06:14 ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 4000
      MPLS label: none
bdr-01-syd#

bdr-01-syd#sh ip bgp regexp ^1000 1221$
BGP table version is 11307146, local router ID is x.x.216.161
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
              t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
...
 * i  139.130.0.0      x.x.31.5             0    100      0 1000 1221 i
...

Versus the path via AS 4000:

bdr-01-syd#sh ip bgp regexp ^4000 1221$
 *>i  138.130.0.0      x.x.201.73            0    100      0 4000 1221 i

bdr-01-syd#

Dans cette sortie, le transit secondaire de Sydney est un chemin valide, tout comme le transit de Melbourne. Melbourne est choisie comme la meilleure.

bdr-01-syd#sh ip bgp 139.130.4.4
BGP routing table entry for 139.130.0.0/16, version 10794227
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     66
  Refresh Epoch 1
  1000 1221, (received & used)
    x.x.31.5 (metric 20) from x.x.216.163 (x.x.216.163)
      Origin IGP, metric 0, localpref 100, valid, internal
      Community: 1000:65110 5000:1000 5000:1001 5000:1002
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  4000 1221, (received & used)
    x.x.201.73 (metric 20) from x.x.13.66 (x.x.13.66)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 4000:5307 4000:6100 4000:53073 5000:1000 5000:1030 5000:1031
      rx pathid: 0, tx pathid: 0x0
bdr-01-syd#

Ce que j'ai essayé

J'ai essayé d'ajouter un coût de liaison OSPF de 15 000 que j'ai calculé comme un chiffre sûr basé sur ma bande passante de référence de 100 Gbps comme étant toujours le coût OSPF le moins préféré. Je pensais que cela compterait comme «coût IGP» et pourtant BGP préfère toujours la voie de Melbourne pour une raison quelconque.

Après que cela ne semble pas avoir eu d'impact, mon plan principal était d'utiliser AS PATH avant le iBGP. Le plan était que j'aurais des groupes de pairs par POP. Et dans mes modèles, je désignerais le nombre de préfixes à faire, en fonction de la distance entre les deux POP. J'avais pensé que ce serait un type d'objectif assez courant.

Par exemple:

0 précède si intra-POP
1 préfixe si POP intra-état
2 préfixe si POP inter-états
3 préfixe si la côte est-ouest POP

Je pensais que cela fonctionnerait parfaitement, serait une solution assez élégante, et c'est exactement le type de solution que j'espère obtenir. J'ai rédigé les configs en quelques heures et déployé. Mais je me suis gratté la tête jusqu'à ce que je réalise que iBGP ne prend pas en charge le chemin d'accès AS en avance

Même si je pouvais faire fonctionner cela, il semble que ce ne serait jamais une solution prise en charge.

Ce que j'envisage

Ce dernier lien @ ipspace.net mentionne que vous pouvez utiliser local-pref car il persiste dans un AS. Mais j'ai déjà défini une politique de préférence locale pour préférer les itinéraires des clients en aval, IXes, l'habituel ... Il semble que l'utilisation de localpref pour cela ne se mélangerait pas bien. Et Ivan ne le suggère pas!
J'ai envisagé d'utiliser les confédérations BGP - mais cela semble être beaucoup de travail supplémentaire pour notre petit réseau. Et j'ai également lu qu'il n'ajoute de toute façon pas les sauts de chemin AS entre les AS confédérés. Je finirais donc probablement au même endroit.
J'envisagerais d'utiliser MPLS (je pense que MPLS TE?) Mais je suis très vert en ce qui concerne MPLS et j'ai déjà beaucoup de défis devant moi. Je voudrais donc éviter la complexité supplémentaire, à moins que ce ne soit une bonne solution à mon problème.

J'ajouterai plus de détails demain. Pour l'instant, voici un diagramme qui décrit notre configuration actuelle.

cisco bgp ospf ios-xe traffic-engineering Geekman
la source

Vous en demandez beaucoup ici. Pour parler personnellement, résoudre ce genre de problèmes est la façon dont beaucoup d'entre nous gagnent leur vie. Je suis heureux de répondre à des questions spécifiques pour aider quelqu'un, mais je ne pense pas qu'il soit raisonnable pour vous ou votre entreprise de vous attendre à obtenir ce niveau d'ingénierie gratuitement.

Ron Trunk

@Geekman il en manque pour évaluer correctement la sélection du meilleur chemin Cisco BGP, sur la base des informations fournies, il semble gênant de savoir comment contourner ou poursuivre les étapes suivantes. D'après votre sortie, la distance de 200 est iBGP afin que nous puissions passer à l'étape 10. Avez-vous été méthodique sur cette ventilation? Lien vers l'algorithme [ici] [0] [0]: cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/…

DRP

@ RonTrunk Salut Ron, certainement conscient de cela, et a soumis la question en pensant que je pourrais avoir besoin de la réécrire. Je suppose que j'ai l'impression de poser une question, qui est finalement un peu en gras. Je sais juste que cela dépend en grande partie de ce que je veux dire, alors j'aime donner beaucoup de détails et de contexte sur mes objectifs globaux afin que la solution puisse s'adapter. J'ai bien l'intention d'adopter une approche générale et d'adapter les détails pour répondre à mes besoins. Peut-être avez-vous toujours l'impression que cela en demande trop?

Geekman

@RonTrunk Je suppose qu'en fin de compte, j'espérais obtenir quelque chose comme généralement dans une situation comme celle-ci, au lieu de préfixer AS PATH, vous pouvez utiliser la méthode suivante pour imposer une limite sur les distances iBGP qui pourrait bien fonctionner par POP . Peut-être que certaines personnes peuvent parler d'expérience d'une manière qui fonctionne bien? Je ne sais pas si c'est juste le niveau de détail qui donne l'impression que je demande que tous ces objectifs soient complètement atteints - ce que je ne suis pas.