A has a route learnt from C. A configures a long AS path prepend, but because of a bug activated by a too long AS path, it sends no AS path. B receives it, but does not withdraw the route. It announces the route to C. C had a better route before, but due to policy did not announce it to B. C starts sending traffic to B. B send to A. A sends to C. loop.
Here is the way: If you can isolate an error to a set of routes withdraw them. If not, drop the session and withdraw all routes from it. RFD takes care of flapping sessions. On Wednesday, May 09, 2012 12:37 AM, bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> wrote: > From: grow Jakob Heitz Sent: Wednesday, May 09, 2012 3:08 AM >> On Monday, May 07, 2012 10:58 AM, Jeffrey Haas <> wrote: >> >>> On Fri, Apr 13, 2012 at 07:27:36PM +0100, Rob Shakir wrote: >>>> I'd like to ask the WG their collective opinion on a couple of >>>> matters in this draft, which come from some discussions at IETF83 >>>> (in particular with John Scudder and Adam Simpson) about how the >>>> requirements are currently written regarding repeated errors. >>> >>> In reviewing this thread, there's another possible tool we could >>> leverage. The consensus seems to be trending toward "if the session >>> is bad enough, take it down. Potentially hold it down if it >>> continues to be bad." >>> >>> An alternative before you get to such a stage is to perform BGP >>> graceful shutdown procedures on the session's routes. This permits >>> the routes to be routes of last resort until the issue is dealt >>> with. >> >> That raises the possibility that the routes are actually used. >> That may cause loops. > > Would you mind sharing an example of such loops following an eBGP > session failure? > That would help me. (Hopefully some others). > > Thanks, > Bruno > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, France > Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender > and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. Thank you. -- Jakob Heitz. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
