limitation de trafic entrant dans le cas d'une architecture BGP multihomed
2 réponses
totolitoto
Bonjour ou re bonjour.
j'ai posé pas mal de questions ces derniers jours ...et je reviens à la
charge.
j'ai en gros deux connexion à INternet via deux FAI en BGP, tout est
redondant. (merci pour votre aide à tous)
mr Jacques, la semaine passée m'a conseillé de ne pas dépasser les 50 %
de charge totale en cas de chtute d'un lien ( tout le trafic arrivant
sur l'autre)
sur une plateforme cisco, comme puis-je faire ?
cela doit passer par des mécanismes de QOS certainement.
autre question , est-ce que cela peut être activé juste en cas de besoin
ou bien ce genre de config reste-t-elle ad vitam dans le routeur ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques Caron
Salut,
On Sat, 10 Apr 2004 17:48:16 +0200, totolitoto wrote:
mr Jacques, la semaine passée m'a conseillé de ne pas dépasser les 50 % de charge totale en cas de chtute d'un lien ( tout le trafic arrivant sur l'autre)
Pour être précis, je conseille de ne pas dépasser 50% du total (par exemple si deux liens à 2 Mbit/s, le trafic total ne doit pas dépasser 2 Mbit/s dans chaque sens), pour éviter qu'en cas de chute d'un lien, on se retrouve avec 4 Mbit/s à faire passer dans un lien à 2 Mbit/s...
Evidemment, dans les faits, ça veut dire qu'on fait plutôt l'inverse: on se débrouille pour avoir au moins le double de capacité que ce dont on a besoin. Ou, si on veut avoir un meilleur rendement, on fait du N+1, et si on a par exemple 4 Mbit/s de trafic total, on a 3 liens (totalement indépendants) à 2 Mbit/s, comme ça même si l'un tombe, on en a toujours 2 pour transporter tout le trafic. Mais comme il n'est pas toujours facile d'avoir 3 liens (ou plus) totalement indépendants...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Sat, 10 Apr 2004 17:48:16 +0200, totolitoto <toto@correo.es> wrote:
mr Jacques, la semaine passée m'a conseillé de ne pas dépasser les 50 %
de charge totale en cas de chtute d'un lien ( tout le trafic arrivant
sur l'autre)
Pour être précis, je conseille de ne pas dépasser 50% du total (par
exemple si deux liens à 2 Mbit/s, le trafic total ne doit pas dépasser 2
Mbit/s dans chaque sens), pour éviter qu'en cas de chute d'un lien, on se
retrouve avec 4 Mbit/s à faire passer dans un lien à 2 Mbit/s...
Evidemment, dans les faits, ça veut dire qu'on fait plutôt l'inverse: on
se débrouille pour avoir au moins le double de capacité que ce dont on a
besoin. Ou, si on veut avoir un meilleur rendement, on fait du N+1, et si
on a par exemple 4 Mbit/s de trafic total, on a 3 liens (totalement
indépendants) à 2 Mbit/s, comme ça même si l'un tombe, on en a toujours 2
pour transporter tout le trafic. Mais comme il n'est pas toujours facile
d'avoir 3 liens (ou plus) totalement indépendants...
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Sat, 10 Apr 2004 17:48:16 +0200, totolitoto wrote:
mr Jacques, la semaine passée m'a conseillé de ne pas dépasser les 50 % de charge totale en cas de chtute d'un lien ( tout le trafic arrivant sur l'autre)
Pour être précis, je conseille de ne pas dépasser 50% du total (par exemple si deux liens à 2 Mbit/s, le trafic total ne doit pas dépasser 2 Mbit/s dans chaque sens), pour éviter qu'en cas de chute d'un lien, on se retrouve avec 4 Mbit/s à faire passer dans un lien à 2 Mbit/s...
Evidemment, dans les faits, ça veut dire qu'on fait plutôt l'inverse: on se débrouille pour avoir au moins le double de capacité que ce dont on a besoin. Ou, si on veut avoir un meilleur rendement, on fait du N+1, et si on a par exemple 4 Mbit/s de trafic total, on a 3 liens (totalement indépendants) à 2 Mbit/s, comme ça même si l'un tombe, on en a toujours 2 pour transporter tout le trafic. Mais comme il n'est pas toujours facile d'avoir 3 liens (ou plus) totalement indépendants...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
www.frameip.com
"Jacques Caron" a écrit dans le message de news:
Pour être précis, je conseille de ne pas dépasser 50% du total (par exemple si deux liens à 2 Mbit/s, le trafic total ne doit pas dépasser 2 Mbit/s dans chaque sens), pour éviter qu'en cas de chute d'un lien, on se retrouve avec 4 Mbit/s à faire passer dans un lien à 2 Mbit/s...
Tu peux aussi ne pas faire du 1 pour 1 et admettre un passage en mode dégradé en cas de panne de l'un de tes deux FAI. Le taux acceptable dépend bien évidement du trafic que tu transites et de ton cahier des charges.
Evidemment, dans les faits, ça veut dire qu'on fait plutôt l'inverse: on se débrouille pour avoir au moins le double de capacité que ce dont on a besoin. Ou, si on veut avoir un meilleur rendement, on fait du N+1, et si on a par exemple 4 Mbit/s de trafic total, on a 3 liens (totalement indépendants) à 2 Mbit/s, comme ça même si l'un tombe, on en a toujours 2 pour transporter tout le trafic. Mais comme il n'est pas toujours facile d'avoir 3 liens (ou plus) totalement indépendants...
Sur le même principe qu'une tolérance en mode dégradé, tu peux passer tes deux liens à 3 Mbps et ainsi obtenir 3/4 de ta bande passante en cas de problème.
Je voulais en fait en venir à la remarque que tu as effectuée sur la QOS. Tu peux appliquer des classes de services afin de priorisée tes flux et gérer cette congestion anticipé afin que l'impacte soit minimal. Pour cela, tu peux utiliser les class map de tes équipement Cisco.
Tout dépend de tes flux, si tu ne fais principalement que de l'hébergement, la définition des COS chez toi suffiront certainement. Cependant, si tu utilises des flux plutôt descendant, alors une copie de tes classes seront nécessaires sur les équipement des FAI.
Voici un exemple, tu peux, en cas de panne, ralentir le flux smtp pour garantir celui de tes flux métiers.
-- SebF
http://www.frameip.com Pour ceux qui aiment TCPIP
Email : H323 : h323.frameip.com
"Jacques Caron" <jc@imfeurope.com> a écrit dans le message de news:
opr58zs9d9q1hokb@news.free.fr...
Pour être précis, je conseille de ne pas dépasser 50% du total (par
exemple si deux liens à 2 Mbit/s, le trafic total ne doit pas dépasser 2
Mbit/s dans chaque sens), pour éviter qu'en cas de chute d'un lien, on se
retrouve avec 4 Mbit/s à faire passer dans un lien à 2 Mbit/s...
Tu peux aussi ne pas faire du 1 pour 1 et admettre un passage en mode
dégradé en cas de panne de l'un de tes deux FAI. Le taux acceptable dépend
bien évidement du trafic que tu transites et de ton cahier des charges.
Evidemment, dans les faits, ça veut dire qu'on fait plutôt l'inverse: on
se débrouille pour avoir au moins le double de capacité que ce dont on a
besoin. Ou, si on veut avoir un meilleur rendement, on fait du N+1, et si
on a par exemple 4 Mbit/s de trafic total, on a 3 liens (totalement
indépendants) à 2 Mbit/s, comme ça même si l'un tombe, on en a toujours 2
pour transporter tout le trafic. Mais comme il n'est pas toujours facile
d'avoir 3 liens (ou plus) totalement indépendants...
Sur le même principe qu'une tolérance en mode dégradé, tu peux passer tes
deux liens à 3 Mbps et ainsi obtenir 3/4 de ta bande passante en cas de
problème.
Je voulais en fait en venir à la remarque que tu as effectuée sur la QOS. Tu
peux appliquer des classes de services afin de priorisée tes flux et gérer
cette congestion anticipé afin que l'impacte soit minimal. Pour cela, tu
peux utiliser les class map de tes équipement Cisco.
Tout dépend de tes flux, si tu ne fais principalement que de l'hébergement,
la définition des COS chez toi suffiront certainement. Cependant, si tu
utilises des flux plutôt descendant, alors une copie de tes classes seront
nécessaires sur les équipement des FAI.
Voici un exemple, tu peux, en cas de panne, ralentir le flux smtp pour
garantir celui de tes flux métiers.
Pour être précis, je conseille de ne pas dépasser 50% du total (par exemple si deux liens à 2 Mbit/s, le trafic total ne doit pas dépasser 2 Mbit/s dans chaque sens), pour éviter qu'en cas de chute d'un lien, on se retrouve avec 4 Mbit/s à faire passer dans un lien à 2 Mbit/s...
Tu peux aussi ne pas faire du 1 pour 1 et admettre un passage en mode dégradé en cas de panne de l'un de tes deux FAI. Le taux acceptable dépend bien évidement du trafic que tu transites et de ton cahier des charges.
Evidemment, dans les faits, ça veut dire qu'on fait plutôt l'inverse: on se débrouille pour avoir au moins le double de capacité que ce dont on a besoin. Ou, si on veut avoir un meilleur rendement, on fait du N+1, et si on a par exemple 4 Mbit/s de trafic total, on a 3 liens (totalement indépendants) à 2 Mbit/s, comme ça même si l'un tombe, on en a toujours 2 pour transporter tout le trafic. Mais comme il n'est pas toujours facile d'avoir 3 liens (ou plus) totalement indépendants...
Sur le même principe qu'une tolérance en mode dégradé, tu peux passer tes deux liens à 3 Mbps et ainsi obtenir 3/4 de ta bande passante en cas de problème.
Je voulais en fait en venir à la remarque que tu as effectuée sur la QOS. Tu peux appliquer des classes de services afin de priorisée tes flux et gérer cette congestion anticipé afin que l'impacte soit minimal. Pour cela, tu peux utiliser les class map de tes équipement Cisco.
Tout dépend de tes flux, si tu ne fais principalement que de l'hébergement, la définition des COS chez toi suffiront certainement. Cependant, si tu utilises des flux plutôt descendant, alors une copie de tes classes seront nécessaires sur les équipement des FAI.
Voici un exemple, tu peux, en cas de panne, ralentir le flux smtp pour garantir celui de tes flux métiers.
