13 commentaires
est ce que tu as vérifié ton Looking Glass chez tes transitaires principaux. si tu vois ton as-path avec 50 sauts c est normal que ça dégage sur une autre route
montre ta conf bird pour l export de tes prefixes vers tes peers
voila la conf de l instance d export pour un des peers transit
protocol bgp upstream_1 {
local as 65001;
neighbor 1.2.3.4 as 1234;
ipv4 {
export filter {
if net = 192.0.2.0/24 then {
bgp_path.prepend(65001);
bgp_path.prepend(65001);
accept;
}
reject;
};
import all;
};
}
tes prepends ont l air propres mais tu devrais checker si tu n as pas des withdrawals massifs dans tes logs bird. si la session flap trop le transitaire va te mettre en flap damping et ton prefixe va disparaitre pendant 30 minutes
regarde tes logs de daemon.log sur la machine qui porte le bgp
je viens de check les logs. j ai plein de messages d erreurs sur le hold timer
bird: upstream_1: BGP error: Hold timer expired
bird: upstream_1: State changed to start
la session tombe toutes les 3 minutes pile poil. on dirait que les keepalives ne passent pas quand on sature le lien
classique. si ton cpu est au taquet ou si ton lien est saturé les paquets bgp passent à la trappe. tu devrais tagger tes paquets bgp avec une priorité dscp cs6
tu as quoi comme hardware sur tes routeurs bird. c est du bare metal ou de la vm
c est du bare metal dell avec des cartes intel x520. le cpu est un xeon assez vieux mais il est pas a plus de 10% de load
on a pas de qos activée pour l instant sur l interface physique
vérifie le mtu sur ton interface. si tu as du mtu 1500 mais que ton fournisseur a du 1492 a cause d un tunnel mpls ou gre les gros updates bgp vont drop mais pas les petits keepalives. ça explique les timeouts bizarres
exact. fais un ping avec une taille de paquet fixe et l argument do not fragment pour voir ou ca bloque
ping -s 1472 -M do 1.2.3.4
bien vu le ping ne passe pas au dessus de 1460 bytes. on a une fragmentation de malade sur le chemin
j ai baissé le mtu de l interface a 1400 pour tester et la session bgp semble stable depuis 10 minutes
cool mais c est pas fini. ton probleme de routage vers singapour vient surement d une mauvaise propagation de tes prepends. certains as utilisent le local preference et ignorent royalement ton as-path length
utilise les communautes bgp pour influencer le routage chez tes providers. check leur documentation technique sur le site d equinix
j ai trouvé les docs. j ai ajouté des tags pour reduire le local pref sur le pop asie
if net = 192.0.2.0/24 then {
bgp_community.add((1234, 100));
accept;
}
on vient de tester depuis un vps a singapour et on est bien routés localement maintenant. et les clients europeens ne partent plus a l autre bout du monde
nickel. oublie pas de monitorer ton status bird avec un exportateur prometheus pour pas louper le prochain hold timer expire
merci les gars. le fix mtu + communautes a reglé le probleme. j installe l exporter prometheus demain matin la je vais dormir
Laisser une réponse
Vous devez être connecté pour poster un message !
on a un souci majeur sur notre infrastructure anycast entre nos datacenters equinix et aws via direct connect. certains clients en europe sont reroutés vers nos pop à singapour ce qui fait exploser la latence
on utilise bird2 pour annoncer nos prefixes /24 en bgp. la conf a l air correcte mais on dirait que nos prepends sont ignorés par certains transitaires ou que le flapping d une session fait tout sauter