La Fibre
Télécom => Peering Transit (appairage) => 
BGP (technique, questions générales) => Discussion démarrée par: max1330 le 01 mars 2017 à 23:44:22
-
Bonjour,
J'ai un problème étrange.
Sur mon routeur de bordure, j'ai un transitaire connecté, et des peers.
Quand je fais :
router>show ip bgp 109.88.0.0
BGP routing table entry for 109.88.0.0/20, version 497799
Paths: (1 available, best #1, table default)
Not advertised to any peer
1299 12392
Origin IGP, localpref 100, valid, external, best
Je n'ai qu'un chemin vers ce préfixe via mon transitaire.
Par contre, si je fais la même commande, et que je spécifie un CIDR, alors je vois également cette route via mes peers :
router>show ip bgp 109.88.0.0/15
BGP routing table entry for 109.88.0.0/15, version 2731057
Paths: (2 available, best #1, table default)
Not advertised to any peer
12392
194.53.172.36 from 194.53.172.2 (194.53.172.2)
Origin IGP, metric 10, localpref 500, valid, external, best
1299 12392
86.107.123.93 from 86.107.123.93 (185.64.64.40)
Origin IGP, localpref 100, valid, external
Pourquoi en ne définissant pas le CIDR je ne vois pas cette route directe via mon peer ? En plus j'ai défini un localpref plus grand
J'imagine que c'est parce que mon transitaire à une route plus précise (/20) alors que mes peers m'envoient une route moins précise (/15). Je ne sais pour quelle raison mon transitaire à cette route plus précise. Mais comment faire si mes peers l'ont pas, pour quand même forcer le traffic à passer d'abord via mes peers ?
Merci pour vos lumières!
-
Vu que 109.88.0.0/20 et 109.88.0.0/15 ont des objets IRR distinct, je pense que ton transitaire a reçu la route désagrégé pour une raison ou pour une autre.
Si cela te gène, tu peut ajouter une route-map pour rejeter la route en /20.
-
Vu que 109.88.0.0/20 et 109.88.0.0/15 ont des objets IRR distinct, je pense que ton transitaire a reçu la route désagrégé pour une raison ou pour une autre.
Si cela te gène, tu peut ajouter une route-map pour rejeter la route en /20.
Le problème c'est que j'ai pleins de routes qui ont le même problème. Pas moyens de toujours donner la priorité aux peers ? Même si les préfixes sont moins précis ?
-
C'est le principe même du routage de privilégier les routes plus précises 8)
-
J'ai bien compris mais ici y a une incohérence de ne pas avoir les routes plus précises via les peers qui ont un lien direct.
-
Cela serait possible de donner plus d'informations sur ton transitaire (qui pourrait être un peer de TAC-BRUTELE) et du peer qui t'annonce TAC-BRUTELE ?
Adeli par exemple a pour habitude d'annoncer plus précis a ses peering de façon a forcer le maximum de trafic en peering.
-
Le problème c'est que j'ai pleins de routes qui ont le même problème. Pas moyens de toujours donner la priorité aux peers ? Même si les préfixes sont moins précis ?
Bonjour,
La réponse est dans l'algorithme de sélection de routes de BGP : http://www.cisco.com/c/fr_ca/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
Il faut utiliser l'attribut locals-préférence pour influencer ton trafic sortant. Ton peer, en général, fera la même chose pour assurer symétrie du routage entre vous deux.
@++
-
Il faut utiliser l'attribut locals-préférence pour influencer ton trafic sortant. Ton peer, en général, fera la même chose pour assurer symétrie du routage entre vous deux.
J'ai déjà mis en place une localpref sur mes peers à 500, alors que mon transitaire est à 100. Voir ci-dessus. Pourtant rien ne change?
-
J'ai déjà mis en place une localpref sur mes peers à 500, alors que mon transitaire est à 100. Voir ci-dessus. Pourtant rien ne change?
Brutele annonce apparemment un /15 sur le BNIX, alors qu'il annonce ce /15 mais aussi un /20 more-specific à son transit Telia (et aussi sur le NL-IX, je note).
Router via le préfixe le plus spécifique c'est une des bases du routage.
Ils ne veulent pas que le trafic de ce /20 entre par le BNIX, c'est tout.
-
Ils ne veulent pas que le trafic de ce /20 entre par le BNIX, c'est tout.
C'est effectivement ce que j'ai remarqué, mais j'imagine qu'il est possible avec des route-map de forcer le trafic quand même à passer via BNIX ?
A part des route-static, c'est faisable via des route-map?
-
Adeli par exemple a pour habitude d'annoncer plus précis a ses peering de façon a forcer le maximum de trafic en peering.
Ce qui est en contradiction avec la plupart des peering policies, d'ailleurs.
Pratiques de voyous :P
-
C'est effectivement ce que j'ai remarqué, mais j'imagine qu'il est possible avec des route-map de forcer le trafic quand même à passer via BNIX ?
A part des route-static, c'est faisable via des route-map?
Il est interdit d'utiliser des routes statiques sur un point d'échange. C'est tout juste bon à se faire sortir à coups de pieds.
Tu peux toujours dropper le /20 sur ton transit ceci-dit.
-
Il est interdit d'utiliser des routes statiques sur un point d'échange. C'est tout juste bon à se faire sortir à coups de pieds.
Tu peux toujours dropper le /20 sur ton transit ceci-dit.
Le résultat est le même au final :-))) je ne savais pas que c'était proscrit sur les points d'échanges ceci dit.
Cela serait possible de donner plus d'informations sur ton transitaire (qui pourrait être un peer de TAC-BRUTELE) et du peer qui t'annonce TAC-BRUTELE ?
C'est donc Telia qui m'envoi ce /20. Alors que BRUTELE avec qui je peer direct via l'IX BNIX envoi un /15. Je viens de leur poser la question à savoir si c'est une volonté de leur part ou un oubli
Merci pour toutes vos réponses
-
Comme quoi, ça va parfois plus vite de contacter directement le NOC.
Ils viennent de rajouter les routes plus précises également pour leurs peers. C'est donc résolu!
BGP routing table entry for 109.89.0.0/20, version 2923803
Paths: (3 available, best #2, table default)
Not advertised to any peer
12392
Origin IGP, metric 10, localpref 500, valid, external