In my situation, if it applied the filter before the limit, everything would work fine.
Maybe the thought is the other peer has some runaway issue that you don't want to spend resources dealing with instead of grooming an otherwise normal condition? *shrugs* ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Baldur Norddahl" <baldur.nordd...@gmail.com> To: nanog@nanog.org Sent: Sunday, October 22, 2017 5:53:48 PM Subject: Re: AS-Path - ORF Draft I do not get why every BGP implementation kills the session at the prefix limit. It appears that is making a bad situation worse. Routing flaps creating lots of visible disturbance for end users. When the BGP session restarts, it will just happen again and again until operator intervention. Instead an implementation could ignore any additional prefixes or it could compare each additional prefix received to already learned prefixes and decide to drop one to make room for the new one. For example you could drop the most specific routes before less specific routes. Regards Baldur Den 23. okt. 2017 00.38 skrev "Mike Hammett" <na...@ics-il.net>: > Network A was sending more routes into the route server than Network B > could handle. Network B would like Network A's routes filtered before they > even got to their router. > > Googling a bit I saw pages talking about saving CPU or what have you, but > the main thing was Network B has a limited FIB. They have a prefix limit > specified to protect that. Their device goes through prefix limit before > prefix filter, so their filters wouldn't even see the advertisements as the > prefix limit already killed the session. Raise the prefix limit so that the > filters can get to work and now you're vulnerable to someone else injecting > a ton of routes and melting their router. > > If that draft were supported by Network B's router and the route servers, > I believe that Network B could tell the route servers to filter Network A's > prefixes before sending them, thus saving their FIB. > > Obviously the most correct answer is for Network A to get routers with big > enough FIBs, but that's not always possible or practical. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Job Snijders" <j...@instituut.net> > To: "Mike Hammett" <na...@ics-il.net>, "NANOG" <nanog@nanog.org> > Sent: Sunday, October 22, 2017 5:29:33 PM > Subject: Re: AS-Path - ORF Draft > > > > > > Hi Mike, > > > On Sun, 22 Oct 2017 at 20:45, Mike Hammett < na...@ics-il.net > wrote: > > > https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-13 > > Not knowing anything about the draft\RFC process (and not really wanting > to go beyond a 30k foot view), is this something with movement? Traction? > > This would have solved a situation I encountered a week ago. > > > > > > > > > > > Can you describe the situation in more detail? > > > > Kind regards, > > > Job >
