Re: BGP prefix filter list

On 2019-05-31 01:18 +, Mel Beckman wrote: > No, that's not the situation being discussed. Actually, that *was* the example I was trying to give, where I suspect many are *not* following the rules of RFC 1930. > As I've pointed out, a multi homed AS without an IGP connecting all > prefixes

Re: BGP prefix filter list

--- valdis.kletni...@vt.edu wrote: From: "Valdis Klētnieks" On Thu, 30 May 2019 16:07:53 -0700, "Scott Weeks" said: > Having been on quite a few networks in my career, > (eyeball/enterprise) I'd say many struggle with > having a "single and clearly defined routing policy" Which part do they

Re: BGP prefix filter list

: Thursday, May 30, 2019 5:58:34 PM To: Mel Beckman Cc: Thomas Bellman; nanog@nanog.org Subject: Re: BGP prefix filter list On Fri, 31 May 2019 00:10:42 -, Mel Beckman said: > What are you talking about? Do you use multi homed BGP? If so, I???d expect > you > to know that an org

Re: BGP prefix filter list

On Fri, 31 May 2019 00:10:42 -, Mel Beckman said: > What are you talking about? Do you use multi homed BGP? If so, I’d expect > you > to know that an organization with multiple sites having their own Internet > still uses a single AS. They have IGP paths to route traffic between sites >

Re: BGP prefix filter list

On Thu, 30 May 2019 16:07:53 -0700, "Scott Weeks" said: > Having been on quite a few networks in my career, > (eyeball/enterprise) I'd say many struggle with > having a "single and clearly defined routing policy" Which part do they find problematic, the "single" part, or the "clearly defined"

Re: BGP prefix filter list

"Citation needed". :-) How is it clear that the vast majority are following this? Uh, because the Internet works? Think about it. If an AS advertises prefixes that can’t be reached through all of its border routers, those prefixes would lose packets. But I don’t need to provide a citation.

Re: BGP prefix filter list

--- bell...@nsc.liu.se wrote: From: Thomas Bellman ... prefixes with a "single and clearly defined routing policy" -- Having been on quite a few networks in my career, (eyeball/enterprise) I'd say many struggle with having a "single and clearly

Re: BGP prefix filter list

On 2019-05-30 20:00 +, Mel Beckman wrote: > I’m sure we can find corner cases, but it’s clear that the vast ^ > majority of BGP users are following the standard. "Citation needed". :-) How is it clear that the vast majority are following

Re: BGP prefix filter list

On 5/30/19 1:48 PM, William Herrin wrote: > 1. What happens to the packets when the /24 gets filtered from one > source (in favor of an aggregate) but not from the other?  > > 2. In exchange for this liability, did you gain any capacity in your router? It was my understanding that the argument

Re: BGP prefix filter list

Yes, my original quote wasn’t exactly word-for-word from the standard, but it was semantically identical. I’m sure we can find corner cases, but it’s clear that the vast majority of BGP users are following the standard. Anycast isn’t a violation of the standards because it’s defined in BGP as

Re: BGP prefix filter list

> On Thu, May 30, 2019 at 10:58 AM Mel Beckman wrote: > > Come on now. The definition of an autonomous system is well established in RFC1930, which is still Best Current Practice: > > https://tools.ietf.org/html/rfc1930#section-3 Your quote wasn't from the RFC. Sorry, my google fu is only good

Re: BGP prefix filter list

Required or not, I've seen a number of networks doing this. At some point "single global ASN" became a marketable pitch and folks realized they don't actually have to have a single Network to get it. Matt (Oops +nanog, sorry Mel + William) > On May 30, 2019, at 13:10, Mel Beckman wrote: > >

Re: BGP prefix filter list

On Thu, 30 May 2019 10:42:17 -0700, William Herrin said: > Heck, most networking courses still teach class A, B and C... definitions > which were explicitly invalidated a quarter of a century ago. If you had asked me back in 1993 if I was going to be retired before class A/B/C was gone from

Re: BGP prefix filter list

Bill, Come on now. The definition of an autonomous system is well established in RFC1930, which is still Best Current Practice: https://tools.ietf.org/html/rfc1930#section-3 An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and

Re: BGP prefix filter list

On Thu, May 30, 2019 at 10:43 AM Robert Blayzor wrote: > On 5/30/19 12:54 PM, William Herrin wrote: > > It's permissible to announce to your transits with a private AS which > > they remove before passing the announcement to the wider Internet. As a > > result, the announcement from each provider

Re: BGP prefix filter list

On 5/30/19 12:54 PM, William Herrin wrote: > It's permissible to announce to your transits with a private AS which > they remove before passing the announcement to the wider Internet. As a > result, the announcement from each provider will have that provider's > origin AS when you see it even

Re: BGP prefix filter list

> On Thu, May 30, 2019 at 10:11 AM Mel Beckman wrote: > > Are your sure about your Error #2, where you say "Prefixes from the same AS are not required to have direct connectivity to each other and many do not."? > > > > From BGP definitions: > > > > The AS represents a connected group of one or

Re: BGP prefix filter list

Hey William, > Error #1: https://tools.ietf.org/html/rfc6996 section 4. > > It's permissible to announce to your transits with a private AS which they > remove before passing the announcement to the wider Internet. As a result, > the announcement from each provider will have that provider's

Re: BGP prefix filter list

Bill, Are your sure about your Error #2, where you say "Prefixes from the same AS are not required to have direct connectivity to each other and many do not."? From BGP definitions: The AS represents a connected group of one or more blocks of IP addresses, called IP prefixes, that have been

Re: BGP prefix filter list

On Thu, May 30, 2019 at 8:30 AM Robert Blayzor wrote: > On 5/24/19 2:22 PM, William Herrin wrote: > > Get it? I announce the /24 via both so that you can reach me when there > > is a problem with one or the other. If you drop the /24, you break the > > Internet when my connection to CenturyLink

Re: BGP prefix filter list

On 5/24/19 2:22 PM, William Herrin wrote: > Get it? I announce the /24 via both so that you can reach me when there > is a problem with one or the other. If you drop the /24, you break the > Internet when my connection to CenturyLink is inoperable. Good job! It would be dropped only if the

Re: BGP prefix filter list

On 5/15/19 2:52 PM, Mike Hammett wrote: > You can't do uRPF if you're not taking full routes. > > You also have a more limited set of information for analytics if you > don't have full routes. Or instead of uRPF (loose) on transit links, just take a BOGON feed? -- inoc.net!rblayzor XMPP:

Re: BGP prefix filter list

On Fri, May 24, 2019 at 11:22:48AM -0700, William Herrin wrote: > > Get it? I announce the /24 via both so that you can reach me when there is > a problem with one or the other. If you drop the /24, you break the > Internet when my connection to CenturyLink is inoperable. Good job! > Or also

Re: BGP prefix filter list

On Fri, May 24, 2019 at 11:34 AM Blake Hudson wrote: > William Herrin wrote on 5/24/2019 1:22 PM: > > If you drop the /24, you break the Internet when my connection to > > CenturyLink is inoperable. > > Not really. The remote networks that drop visibility to your /24 > announcement still have a

Re: BGP prefix filter list

William Herrin wrote on 5/24/2019 1:22 PM:  If you drop the /24, you break the Internet when my connection to CenturyLink is inoperable. Not really. The remote networks that drop visibility to your /24 announcement still have a default route. They just just leave the decision of the best

Re: BGP prefix filter list

On Fri, May 24, 2019 at 10:29 AM Mike Hammett wrote: > If networks are going to make unconventional announcements, I'm not > concerned if they suffer because of it. > No, no no. You're not getting it. I'm a customer of Verizon. I'm a customer of CenturyLink. I get a /24 from CenturyLink and

Re: BGP prefix filter list

To: "Ross Tajvar" Cc: "nanog" Sent: Friday, May 24, 2019 12:03:52 PM Subject: Re: BGP prefix filter list Hi, They can, but they don't necessarily have to. In the example I mentioned, there was a private peering between them. Well, until very recently. My point bei

Re: BGP prefix filter list

Hi, They can, but they don't necessarily have to. In the example I mentioned, there was a private peering between them. Well, until very recently. My point being that it's not always black and white, and sometimes deaggregation is necessary for operational purposes. That's not to excuse

Re: BGP prefix filter list

In that case shouldn't each company advertise a /21? On Wed, May 22, 2019, 1:11 PM Sabri Berisha wrote: > Hi, > > One legitimate reason is the split of companies. In some cases, IP space > needs to be divided up. For example, company A splits up in AA and AB, and > has a /20. Company AA may

Re: BGP prefix filter list

Hi, One legitimate reason is the split of companies. In some cases, IP space needs to be divided up. For example, company A splits up in AA and AB, and has a /20. Company AA may advertise the /20, while the new AB may advertise the top or bottom /21. I know of at least one worldwide

Re: BGP prefix filter list

Hello.., you are totally right, the first reason that came to my mind is traffic engineering but there are other reasons too. On 5/22/19 12:40 PM, Tom Beecher wrote: There are sometimes legitimate reasons to have a covering aggregate with some more specific announcements. Certainly there's a

Re: BGP prefix filter list

There are sometimes legitimate reasons to have a covering aggregate with some more specific announcements. Certainly there's a lot of cleanup that many should do in this area, but it might not be the best approach to this issue. On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta <

Re: BGP prefix filter list

adamv0...@netconsultings.com wrote on 5/22/2019 3:23 AM: From: NANOG On Behalf Of Blake Hudson Sent: Monday, May 20, 2019 4:35 PM As I recall reading about one vendor's platform (the ASR9k perhaps?) and its TCAM organization process, it stored /32 routes in a dedicated area for faster lookups

RE: BGP prefix filter list

> From: NANOG On Behalf Of Blake Hudson > Sent: Monday, May 20, 2019 4:35 PM > > As I recall reading about one vendor's platform (the ASR9k > perhaps?) and its TCAM organization process, it stored /32 routes in a > dedicated area for faster lookups and did the same for /24 routes. > Yes that was

Re: BGP prefix filter list

On 5/20/19 7:26 PM, John Kristoff wrote: On Mon, 20 May 2019 23:09:02 + Seth Mattinen wrote: A good start would be killing any /24 announcement where a covering aggregate exists. I wouldn't do this as a general rule. If an attacker knows networks are 1) not pointing default, 2)

Re: BGP prefix filter list

On Mon, May 20, 2019 at 5:59 PM Seth Mattinen wrote: > On 5/20/19 4:26 PM, John Kristoff wrote: > > On Mon, 20 May 2019 23:09:02 + > > Seth Mattinen wrote: > > > >> A good start would be killing any /24 announcement where a covering > >> aggregate exists. > > I wouldn't do this as a general

Re: BGP prefix filter list

On 5/20/19 4:26 PM, John Kristoff wrote: On Mon, 20 May 2019 23:09:02 + Seth Mattinen wrote: A good start would be killing any /24 announcement where a covering aggregate exists. I wouldn't do this as a general rule. If an attacker knows networks are 1) not pointing default, 2) dropping

Re: BGP prefix filter list

On Mon, May 20, 2019 at 4:09 PM Seth Mattinen wrote: > On 5/20/19 3:05 PM, William Herrin wrote: > > The technique you describe was one variant of FIB Compression. It got > > some attention around 8 years ago on the IRTF Routing Research Group and > > some more attention about 5 years ago when

Re: BGP prefix filter list

On Mon, 20 May 2019 23:09:02 + Seth Mattinen wrote: > A good start would be killing any /24 announcement where a covering > aggregate exists. I wouldn't do this as a general rule. If an attacker knows networks are 1) not pointing default, 2) dropping /24's, 3) not validating the

Re: BGP prefix filter list

On 5/20/19 3:05 PM, William Herrin wrote: The technique you describe was one variant of FIB Compression. It got some attention around 8 years ago on the IRTF Routing Research Group and some more attention about 5 years ago when several researchers fleshed out the possible algorithms and

Re: BGP prefix filter list

Those numbers were subject to fraudulent acquisition. Some end users of these subject prefixes are victims. This blanket approach victimizes them further IMHO. My guess is this direction is why ARIN didn't post the prefixes in their blog post. They are however in the court docs. I don't recommend

Re: BGP prefix filter list

Brocade (now Extreme) does this on their SLX platform to market 1M FIB boxes as 1.3M FIB boxes after compression. We went with the Juniper MX platform instead, the relatively small FIB size on the SLX being one of the main sticking points for me personally. Nowadays there are also some SLX

Re: BGP prefix filter list

On Fri, May 17, 2019 at 9:06 AM Baldur Norddahl wrote: > Think about this way to save at least half the size of the FIB with two > transit providers: Find out which provider has the most prefixes going > their way. Make a default to them and a route-map that drops every route. > For the other

Re: BGP prefix filter list

Gracias Alejandro, I had never considered anti-hijack, anti-DoS, or RTBH advertisements in this equation. Another knock against filtering based on prefix size is that it may not have the intended outcome on some platforms. As I recall reading about one vendor's platform (the ASR9k perhaps?)

Re: BGP prefix filter list

Baldur Norddahl wrote on 5/18/2019 3:57 AM: ... One router knows about 2 paths, the other about 4 paths. Why? Because BGP only advertises the route that is in use. Everyone here of course knows this, I am just pointing it out because culling information before allowing it to be redistributed

Re: BGP prefix filter list

Hello Amir, On 5/18/19 1:08 PM, Amir Herzberg wrote: This discussion is very interesting, I didn't know about this problem, it has implications to our work on routing security, thanks! Your welcome..., since long time ago I wanted to expose our findings in English. On Sat, May 18, 2019

Re: BGP prefix filter list

This discussion is very interesting, I didn't know about this problem, it has implications to our work on routing security, thanks! On Sat, May 18, 2019 at 11:37 AM Alejandro Acosta < alejandroacostaal...@gmail.com> wrote: > >If you learn, let's say, up to /22 (v4), and someone hijacks one

Re: BGP prefix filter list

Hello,    As a comment, after receiving several complains and after looking many cases, we evaluated what is better, to cut the table size filtering "big" network or "small" networks.  Of course this is a difficult scenario and I guess there are mix thinking about this, however, we concluded

Re: BGP prefix filter list

On Fri, May 17, 2019 at 10:43 PM Blake Hudson wrote: > I manage a network like you describe: Two BGP edge routers, both routers > accept a full eBGP feed from transit, both share routing information via > iBGP. Both edge routers in my network have a complete view. If one transit > provider is

Re: BGP prefix filter list

I would argue that one can generally safely add information to his or her router's RIB (such as adding a local preference, weight, or advertising with prepends to direct traffic toward a better performing, less utilized, or lower cost peer), but that removing information

Re: BGP prefix filter list

On Fri, May 17, 2019 at 9:44 PM Blake Hudson wrote: > Baldur, I believe most routing platforms already make use of clever > shortcuts or techniques to reduce their FIB usage, but I don't think anyone > has found a good, reliable method of reducing their RIB at zero cost. For > example, what

Re: BGP prefix filter list

Baldur Norddahl wrote on 5/17/2019 11:05 AM: On Fri, May 17, 2019 at 3:28 PM Blake Hudson > wrote:  From my perspective one's ability to intelligently route IP traffic is directly correlated to the data they have available (their routing protocol and

Re: BGP prefix filter list

On Fri, May 17, 2019 at 3:28 PM Blake Hudson wrote: > From my perspective one's ability to intelligently route IP traffic is > directly correlated to the data they have available (their routing > protocol and table) > One point perhaps being missed by some is that routing decisions are not

Re: BGP prefix filter list

Can you check the actual FIB usage? With 2m IPv4 divided into v4 and v6 * Fast ReRoute could hit the limit. Baldur Norddahl schrieb am Mi., 15. Mai 2019, 20:24: > Hello > > On Wed, May 15, 2019 at 3:56 PM Mike Hammett wrote: > >> What is the most common platform people are using with such

Re: BGP prefix filter list

Radu-Adrian Feurdean wrote on 5/17/2019 9:15 AM: On Fri, May 17, 2019, at 15:28, Blake Hudson wrote: From my perspective one's ability to intelligently route IP traffic is directly correlated to the data they have available (their routing protocol and table). For example, with static default

Re: BGP prefix filter list / BGP hijacks, different type

Did this get resolved? if not please email me directly. On Fri, May 17, 2019 at 9:46 AM Denys Fedoryshchenko wrote: > > I wanted to mention one additional important point in all these > monitoring discussion. > Right now, for one of my subnets Google services stopped working. > Why? Because it

Re: BGP prefix filter list

On Fri, May 17, 2019, at 15:28, Blake Hudson wrote: > From my perspective one's ability to intelligently route IP traffic is > directly correlated to the data they have available (their routing > protocol and table). For example, with static default routes one can For me, routing table and

Re: BGP prefix filter list / BGP hijacks, different type

I wanted to mention one additional important point in all these monitoring discussion. Right now, for one of my subnets Google services stopped working. Why? Because it seems like someone from Russia did BGP hijack, BUT, exclusively for google services (most likely some kind of peering). Quite

Re: BGP prefix filter list

Radu-Adrian Feurdean wrote on 5/17/2019 5:10 AM: On Thu, May 16, 2019, at 16:38, Blake Hudson wrote: offloading that responsibility onto the transit provider. IMHO, what's the point of being multi-homed if you can't make intelligent routing decisions and provide routing redundancy in the case

Re: BGP prefix filter list

On Thu, May 16, 2019, at 16:38, Blake Hudson wrote: > offloading that responsibility onto the transit provider. IMHO, what's > the point of being multi-homed if you can't make intelligent routing > decisions and provide routing redundancy in the case of a transit > provider outage? Speaking of

Re: BGP prefix filter list

Hi, I did this tool a few years ago to download and built ASN filter lists by region automatically: https://github.com/ipcjk/asnbuilder/releases The tricky part was to build regular expressions for devices, that don't understand number ranges. For some of our routers we (un)select ASNs

Re: BGP prefix filter list

There are a few approaches to culling the routing table. You can do it either statically or dynamically, according to your needs. 1. Filtering based on upstream communities Slimming down the Internet routing table

Re: BGP prefix filter list

http://www.midwest-ix.com *From: *"Ca By" *To: *"Mike Hammett" *Cc: *"Dan White" , nanog@nanog.org *Sent: *Wednesday, May 15, 2019 2:14:21 PM *Subject: *Re: BGP prefix filter list On Wed,

Re: BGP prefix filter list

Hi Baldur, Have you tried disabling storage of received updates from your upstream on your edge/PE or Border? Just remove *soft-reconfiguration inbound* for eBGP peering with your upstream/s. This will resolve your issue. If you have multiple links to different upstream providers and you want to

Re: BGP prefix filter list

On 15/May/19 19:20, Mike wrote: > > This is very true. I picked up a nicely equipped juniper mx240 - > waa overkill for my current operation - for far, far cheaper than > anything I could have otherwise afforded new. Absolutely killer could > not be happier, and J has won a convert. But, I

Re: BGP prefix filter list

At a previous company , about 10-ish years ago, had the same problem due to equipment limitations, and wasn't able to get dollars to upgrade anything. The most effective thing for me at the time was to start dumping any prefix with an as-path length longer than 10. For our business then, if you

Re: BGP prefix filter list

: "Ca By" To: "Mike Hammett" Cc: "Dan White" , nanog@nanog.org Sent: Wednesday, May 15, 2019 2:14:21 PM Subject: Re: BGP prefix filter list On Wed, May 15, 2019 at 11:52 AM Mike Hammett < na...@ics-il.net > wrote: You can't do uRPF if you're n

Re: BGP prefix filter list

Midwest-IX > http://www.midwest-ix.com > > -- > *From: *"Ca By" > *To: *"Dan White" > *Cc: *nanog@nanog.org > *Sent: *Wednesday, May 15, 2019 1:50:41 PM > > *Subject: *Re: BGP prefix filter list > > > > On Wed, May 15, 2019 at 7:27 AM Dan White wrote:

Re: BGP prefix filter list

- From: "Ca By" To: "Dan White" Cc: nanog@nanog.org Sent: Wednesday, May 15, 2019 1:50:41 PM Subject: Re: BGP prefix filter list On Wed, May 15, 2019 at 7:27 AM Dan White < dwh...@olp.net > wrote: On 05/15/19 13:58 +, Phil Lavin wrote: >> We'

Re: BGP prefix filter list

- From: "Baldur Norddahl" To: nanog@nanog.org Sent: Wednesday, May 15, 2019 1:47:24 PM Subject: Re: BGP prefix filter list My purpose is not to shame the vendor, but anyway these are ZTE M6000. We are currently planing to implement Juniper MX204 instead, but not because of this in

Re: BGP prefix filter list

On Wed, May 15, 2019 at 7:27 AM Dan White wrote: > On 05/15/19 13:58 +, Phil Lavin wrote: > >> We're an eyeball network. We accept default routes from our transit > >> providers so in theory there should be no impact on reachability. > >> > >> I'm pretty concerned about things that I don't

Re: BGP prefix filter list

My purpose is not to shame the vendor, but anyway these are ZTE M6000. We are currently planing to implement Juniper MX204 instead, but not because of this incident. We just ran out of bandwidth and brand new MX204 are cheaper than 100G capable shelves for the old platform. Regards, Baldur On

Re: BGP prefix filter list

Hello Baldur, What routers are you running? -Mike > On May 15, 2019, at 11:22, Baldur Norddahl wrote: > > Hello > >> On Wed, May 15, 2019 at 3:56 PM Mike Hammett wrote: >> What is the most common platform people are using with such limitations? How >> long ago was it deprecated? >> >> >

Re: BGP prefix filter list

Hello On Wed, May 15, 2019 at 3:56 PM Mike Hammett wrote: > What is the most common platform people are using with such limitations? > How long ago was it deprecated? > > > We are a small network with approx 10k customers and two core routers. The routers are advertised as 2 million FIB and 10

Re: BGP prefix filter list

If you're going whitebox, I would check out Netgate's new product called TNSR. It uses VPP for the data plane, which does all its processing in user space, thus avoiding the inefficiencies of the kernel network stack. That's particularly important at higher speeds like 40G or 100G. Disclaimer: I

Re: BGP prefix filter list

On Wed, May 15, 2019, at 13:44, Baldur Norddahl wrote: > Or maybe we have a list of worst offenders? I am looking for ASN that > announces a lot of unnecessary /24 prefixes and which happens to be far > away from us? I would filter those to something like /20 and then just > have a default

Re: BGP prefix filter list

On 5/15/19 7:26 AM, Dovid Bender wrote: > You have no idea how sad and true this is.  > > On Wed, May 15, 2019 at 10:16 AM Jon Lewis > wrote: > > On Wed, 15 May 2019, Mike Hammett wrote: > > > What is the most common platform people are using with such >

Re: BGP prefix filter list

Hi, did you find https://labs.ripe.net/Members/emileaben/768k-day-will-it-happen-did-it-happen ? It has further links at the end as well. If you hit the 768k issue for IPv4 you might look at IPv6 as well as there might be a 64k limit on some tcam profiles. If there is no IPv6 in use (very sad

Re: BGP prefix filter list

On 5/15/2019 9:46 AM, Hansen, Christoffer wrote: 'Tik, white box Linux/BSD, etc all offer good options at varying price points. Any pointers and/or references, when looking into speeds *above* what is possible with aggregated 10G links? That's a good question - I've not gotten past 10G

Re: BGP prefix filter list

On 15/05/2019 17:28, Brielle Bruns wrote: > Lots of good non-big vendor options these days - times have changed for > sure. Indeed. > 'Tik, white box Linux/BSD, etc all offer good options at varying price > points. Any pointers and/or references, when looking into speeds *above* what is

Re: BGP prefix filter list

On 5/15/2019 9:10 AM, Mike Hammett wrote: Eh...  you'll find it hard to get that past me. I know hundreds of self-funded ISPs that don't have route table size issues. Lots of good non-big vendor options these days - times have changed for sure. I'm running an EdgeRouter Infinity with BGP

Re: BGP prefix filter list

Lewis" To: "Mike Hammett" Cc: nanog@nanog.org Sent: Wednesday, May 15, 2019 9:14:57 AM Subject: Re: BGP prefix filter list On Wed, 15 May 2019, Mike Hammett wrote: > What is the most common platform people are using with such limitations? How > long ago was it d

Re: BGP prefix filter list

You have no idea how sad and true this is. On Wed, May 15, 2019 at 10:16 AM Jon Lewis wrote: > On Wed, 15 May 2019, Mike Hammett wrote: > > > What is the most common platform people are using with such limitations? > How long ago was it deprecated? > > One network's deprecated router is another

Re: BGP prefix filter list

On 05/15/19 13:58 +, Phil Lavin wrote: We're an eyeball network. We accept default routes from our transit providers so in theory there should be no impact on reachability. I'm pretty concerned about things that I don't know due to inefficient routing, e.g. customers hitting a public

Re: BGP prefix filter list

On Wed, 15 May 2019, Mike Hammett wrote: What is the most common platform people are using with such limitations? How long ago was it deprecated? One network's deprecated router is another network's new [bargain priced] core router. :)

Re: BGP prefix filter list

On Wed, 15 May 2019, Baldur Norddahl wrote: Hello This morning we apparently had a problem with our routers not handling the full table. So I am looking into culling the least useful prefixes from our tables. I can hardly be the first one to take on that kind of project, and I am wondering

RE: BGP prefix filter list

> We're an eyeball network. We accept default routes from our transit providers > so in theory there should be no impact on reachability. > I'm pretty concerned about things that I don't know due to inefficient > routing, e.g. customers hitting a public anycast DNS server in the wrong >

Re: BGP prefix filter list

To: nanog@nanog.org Sent: Wednesday, May 15, 2019 6:43:30 AM Subject: BGP prefix filter list Hello This morning we apparently had a problem with our routers not handling the full table. So I am looking into culling the least useful prefixes from our tables. I can hardly be the first o

Re: BGP prefix filter list

Would also cut out anyone who uses /24s for anycast, or just general traffic control... Or as you put it, an insane amount of important stuff. Sent from my iPhone On May 15, 2019, at 7:44 AM, Phil Lavin wrote: >> We recently filtered out >=/24 prefixes since we're impacted by 768k day. > >

Re: BGP prefix filter list

On 05/15/19 13:44 +, Phil Lavin wrote: We recently filtered out >=/24 prefixes since we're impacted by 768k day. What kind of network are you running? Doing such prefix filtering on an eyeball network strikes me as insane - you'd be cutting off customers from huge swathes of the Internet

Re: BGP prefix filter list

If you have multiple transit providers and still want to be able to push traffic to the best path (no default route), then maybe a filter that will accept only AS Path 2/3 or shorter per transit provider, and a default route for the rest. You will get significantly less prefixes, and BGP path

RE: BGP prefix filter list

> We recently filtered out >=/24 prefixes since we're impacted by 768k day. What kind of network are you running? Doing such prefix filtering on an eyeball network strikes me as insane - you'd be cutting off customers from huge swathes of the Internet (including small companies like us) that

Re: BGP prefix filter list

We recently filtered out >=/24 prefixes since we're impacted by 768k day. I'm attaching our lightly researched list of exceptions. I'm interested in what others' operational experience is with filtering in this way. Filtering /24s cut our table down to around 315K. On 05/15/19 13:43 +0200,

Re: BGP prefix filter list

What about these ones? https://teamarin.net/2019/05/13/taking-a-hard-line-on-fraud/ On Wed, May 15, 2019 at 01:43:30PM +0200, Baldur Norddahl wrote: > Hello > > This morning we apparently had a problem with our routers not handling > the full table. So I am looking into culling the least

BGP prefix filter list

Hello This morning we apparently had a problem with our routers not handling the full table. So I am looking into culling the least useful prefixes from our tables. I can hardly be the first one to take on that kind of project, and I am wondering if there is a ready made prefix list or