Le mardi 08 juillet 2008 à 23:29 +0200, Frédéric Gander a écrit : > On Tue, Jul 08, 2008 at 11:15:41PM +0200, Michael Hallgren wrote: > > Le mardi 08 juillet 2008 à 14:28 +0200, David Ramahefason a écrit : > > > Le prepend n'équilibre pas vraiment le trafic, du moins > > > artificellement car il faut avoir l'oeil sur les graphe en permanence > > > pour "rééquilibrer" les flux. > > > De plus faire un/des prepend par exemple auprès de peer n'aura aucun > > > impact du fait des local pref appliquées sur les peering en général > > > (pas de peer dans l'exemple actuel c'est vrai). > > > > Oui : indiquer son souhait dans la communauté, autrement dit. Le charme > > ainsi que le << problème >> de tout ça, n'est que ça s'inscrit dans le > > réseau plus ou moins globale. Un équilibre << parfait >> locale n'est > > pas une assurance d'une qualité optimale... Le choix de << metric >> > > étant le coeur du métier... IMHO ;) > > > disons que la locale pref est un bon moyen de négociation commerciale > enfin IMHO ;) > > mais meme chez les gros opérateur de transit il doit yavoir des local > pref pour différencier les clients des peer voir du transit sprint > pour ceux qui sont pas tout a fait tier1
Salut, Yep. Right. Le LOCAL_PREF peut bien servir à ça. Meme que << chez moi >> on ne distingue plus entre cust/peer/provider mais qu'entre cust/peer, cette logique de choix de base et locale reste en place. Mon point était : à celui qui achète du transit, où bien qui a des peers, de définir sa propre politique de politique : - oui, LOCAL_PREF (p. ex.) pour sortir son trafic, - prepend (ou autre) pour tenter à influencer le retour. ... et que : il n'est pas forcement un équilibre parfait de volumes que lui ferais son bonheur. Donc : a choisir son << metric. >> Ai-je lu ce thread trop en diagonale ? mh > > > > > > Did I speak french this time, or scrambled? :) > > > > mh > > > > > > > > > > > 2008/7/8 Wallace <[EMAIL PROTECTED]>: > > > > David Ramahefason a écrit : > > > >> > > > >> Bonjour, > > > >> > > > >> pour le trafic sortant une solution (qui ne garantit pas forcement un > > > >> équilibre de traffic) serait de faire du HSRP "croisé". > > > >> Une partie de ton réseau pointe sur la VIP1 et l'autre sur la VIP2, > > > >> apres en jouant sur les weight le traffic arrivant de tes machines sur > > > >> le routeur A partira vers l'upstream connecté à A, idem pour le > > > >> routeur B. > > > >> Pour le rentrant, a part en jouant sur les communauté proposée par les > > > >> upstream il n'y a pas beaucoup d'alternatives. > > > >> > > > > > > > > Très bonne technique sur le sortant en effet, on peut ajouter une > > > > variante > > > > en mettant en route par défaut le routeur de gauche au firewall de > > > > gauche et > > > > pareil à droite. Ca fait du presque 50/50 si les firewall sont de type > > > > actif > > > > actif. > > > > > > > > Sinon pour prioritiser les flux entrant, méthode moche, annoncer en > > > > prépend > > > > plusieurs fois son AS pour ajouter des sauts et donc rendre moins > > > > prioritaire un lien. > > > > > > > > Mais c'est très moche. > > > > > > > > > > > > > > > > > --------------------------- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
