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 rule. If an attacker knows networks are > > 1) not pointing default, 2) dropping /24's, 3) not validating the > > aggregates, and 4) no actual legitimate aggregate exists, (all > > reasonable assumptions so far for many /24's), then they have a pretty > > good opportunity to capture that traffic. > > > I'm talking about the case where someone has like a /20 and announces > the /20 plus every /24 it contains. I regard those as garbage > announcements. The lesson for all is — do not expect /24s to reach all edges. People have been doing this since we hit 512k routes, and will do it more often, regardless of how much shade you throw on this mailer. Like NAT, this is another way that IPv4 is buckling >
INNOG 2 cfp 7/1 to 7/4 New Delhi, India
NANOG folks - I recognize that this is rather late notice for your travel schedules but if you happen to be in the region or have teams in India please do attend, or forward this. Thanks. INNOG 2: Call for papers The following is an open call for presentations for the conference and tutorial sessions for the 2nd Indian Network Operators Group (INNOG) Meeting being hosted from 1st July to 4th July 2019 in New Delhi, India. Important dates regarding the Call for Papers: Call For Papers Open: Now First Draft Program Published: 25th June 2019 Deadline For Proposals: 20th June 2019 INNOG 2 Conference: 1st July 2019 INNOG 2 Workshops: 2nd July to 4th July 2019 Please submit Online at https://submission.apnic.net/user/login.php?event=94 Event website: https://www.innog.net/ Note: Any marketing, sales and vendor proprietary content in the presentation is against the spirit of INNOG and it is strictly prohibited. We are looking forward to welcoming you to INNOG 2 in New Delhi, India. Thanks and warm regards, On behalf of the INNOG 2 Program Committee --srs
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 /24's, 3) not validating the aggregates, and 4) no actual legitimate aggregate exists, (all reasonable assumptions so far for many /24's), then they have a pretty good opportunity to capture that traffic. I'm talking about the case where someone has like a /20 and announces the /20 plus every /24 it contains. I regard those as garbage announcements.
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 several researchers fleshed > > out the possible algorithms and projected gains. As I recall they found > > a 30% to 60% reduction in FIB use depending on which algorithm was > > chosen, how many peers you had, etc. > > A good start would be killing any /24 announcement where a covering > aggregate exists. Only when the routes are identical -- same origin, same path. Otherwise you're potentially throwing away your only path to that destination. And if you lose the aggregate, the /24 has to be reintroduced to the FIB. Which means you have to interlink the routes in the RIB data structure so that the update algorithm dealing with the aggregate knows there's an associated /24. There's some real subtlety a FIB Compression implementor must take in to account. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
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 aggregates, and 4) no actual legitimate aggregate exists, (all reasonable assumptions so far for many /24's), then they have a pretty good opportunity to capture that traffic. John
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 projected gains. As I recall they found a 30% to 60% reduction in FIB use depending on which algorithm was chosen, how many peers you had, etc. A good start would be killing any /24 announcement where a covering aggregate exists.
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 acting now. I could be wrong? Follow the registry, IMHO. John? Best, -M< On Wed, May 15, 2019 at 08:25 Anderson, Charles R wrote: > 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 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 > similar? > > > > 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 route to catch all. > > > > Thanks, > > > > Baldur >
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 models with a larger FIB, which don't need compression algorithms to accommodate the routing table growth for a couple of years. Best regards, Martijn On 20 May 2019 23:05:45 BST, William Herrin wrote: >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 provider, keep only the routes where they have better >> routing. This way you only use FIB space for the smaller provider. >> Everything else goes by default through the larger provider. >> > >Hi Baldur, > >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 projected gains. As I recall they found a 30% >to >60% reduction in FIB use depending on which algorithm was chosen, how >many >peers you had, etc. > >As far as I know there are no production implementations. Likely the >extra >complexity needed to process RIB updates in to FIB updates outweighs >the >cost of simply adding more TCAM. Another down side is that you lose the >implicit discard default route, which means that routing loops become >possible. > >Regards, >Bill Herrin
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 provider, keep only the routes where they have better > routing. This way you only use FIB space for the smaller provider. > Everything else goes by default through the larger provider. > Hi Baldur, 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 projected gains. As I recall they found a 30% to 60% reduction in FIB use depending on which algorithm was chosen, how many peers you had, etc. As far as I know there are no production implementations. Likely the extra complexity needed to process RIB updates in to FIB updates outweighs the cost of simply adding more TCAM. Another down side is that you lose the implicit discard default route, which means that routing loops become possible. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Free Program to take netflow
I've done that a couple ways. I've used a nProbe license to add the ASN information in. There are other utilities that do this, but I forgot what they are. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Dennis Burgess via NANOG" To: nanog@nanog.org Sent: Monday, May 20, 2019 8:36:47 AM Subject: RE: Free Program to take netflow Please let me clarify. Currently the Netflow data that this customer is sending does NOT supply AS information. So I need something to generate that AS data and display. The goal is to figure out where we need to peer next. Where the top traffic is coming in from (what AS) on our paid transit. Dennis Burgess, From: NANOG On Behalf Of Dennis Burgess via NANOG Sent: Friday, May 17, 2019 9:27 AM To: nanog@nanog.org Subject: Free Program to take netflow I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. Thanks in advance. Dennis Burgess
RE: Free Program to take netflow
It specifically states it uses AS data from the netflow source. I don't have that ☹ FROM website: collects NetFlow v8/v9 AS aggregation records Dennis Burgess, -Original Message- From: NANOG On Behalf Of na...@jack.fr.eu.org Sent: Monday, May 20, 2019 8:43 AM To: nanog@nanog.org Subject: Re: Free Program to take netflow Check out AS-Stats¹, with perl-ip2as [1] https://github.com/manuelkasper/AS-Stats On 05/20/2019 03:36 PM, Dennis Burgess via NANOG wrote: > Please let me clarify. Currently the Netflow data that this customer is > sending does NOT supply AS information. So I need something to generate that > AS data and display. The goal is to figure out where we need to peer next. > Where the top traffic is coming in from (what AS) on our paid transit. > > > > Dennis Burgess, > > From: NANOG On Behalf Of Dennis Burgess via NANOG > Sent: Friday, May 17, 2019 9:27 AM > To: nanog@nanog.org > Subject: Free Program to take netflow > > I am looking for a free program to take netflow and output what the top > traffic ASes to and from my AS are. Something that we can look at every > once in a while, and/or spin up and get data then shutdown.. Just have two > ports need netflow from currently. > > Thanks in advance. > > > > Dennis Burgess > >
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?) and its TCAM organization process, it stored /32 routes in a dedicated area for faster lookups and did the same for /24 routes. If one were to remove just the /24 routes from their RIB, the result would free up space in the storage area dedicated for /24's, but would consequently put more pressure on the areas reserved for prefixes between /0 and /23 as covering routes are installed into FIB. The result of removing /24's from the RIB on this platform would, unintuitively, put the user in a worse position with regard to TCAM utilization - not a better one. If one is going to filter routes from his or her router's RIB, doing so based on subnet size seems to be a poor way. Doing so based on AS depth (your second solution) has fewer disadvantages in my opinion. As others have mentioned, there are even more intelligent ways of filtering but they rely on outside knowledge like cost, bandwidth, delay, or the importance to your customers of reaching a given destination - stuff not normally known to BGP. Alejandro Acosta wrote on 5/18/2019 10:35 AM: 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 that the people (networks) that is less affected are those who learn small network prefixes (such as /24, /23, /22, /21 in the v4 world). If you learn, let's say, up to /22 (v4), and someone hijacks one /21 you will learn the legitimate prefix and the hijacked prefix. Now, the owner of the legitimate prefix wants to defends their routes announcing /23 or /24, of course those prefixes won't be learnt if they are filtered. We published this some time ago (sorry, in Spanish): http://w4.labs.lacnic.net/site/BGP-network-size-filters That's it, my two cents. Alejandro, On 5/15/19 7:43 AM, 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 if there is a ready made prefix list or similar? 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 route to catch all. Thanks, Baldur
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 within your network is what BGP is already doing anyway. It is possible to remove some of that information from the local FIB too without losing anything at all. Using a default also gives you a dramatically shorter convergence time if one of the transits goes down. Having 800k routes can be harmful to your network even with equipment that can handle it. Yes I am aware that I am not doing what I am preaching here, but I am considering it :-). Thanks for the clarification. Yes, you are correct that each router will have its own unique view. By full view I meant that a router has at least one route for every prefix advertised into the DFZ. One should also expect that each transit provider will provide a slight variation in the routes provided via its "full BGP feed" because each transit provider has its own unique view and may include routes in its feeds that are not advertised into the DFZ. Appreciate the discourse my friend, --B
Re: Free Program to take netflow
Check out AS-Stats¹, with perl-ip2as [1] https://github.com/manuelkasper/AS-Stats On 05/20/2019 03:36 PM, Dennis Burgess via NANOG wrote: > Please let me clarify. Currently the Netflow data that this customer is > sending does NOT supply AS information. So I need something to generate that > AS data and display. The goal is to figure out where we need to peer next. > Where the top traffic is coming in from (what AS) on our paid transit. > > > > Dennis Burgess, > > From: NANOG On Behalf Of Dennis Burgess via NANOG > Sent: Friday, May 17, 2019 9:27 AM > To: nanog@nanog.org > Subject: Free Program to take netflow > > I am looking for a free program to take netflow and output what the top > traffic ASes to and from my AS are. Something that we can look at every > once in a while, and/or spin up and get data then shutdown.. Just have two > ports need netflow from currently. > > Thanks in advance. > > > > Dennis Burgess > >
RE: Free Program to take netflow
Please let me clarify. Currently the Netflow data that this customer is sending does NOT supply AS information. So I need something to generate that AS data and display. The goal is to figure out where we need to peer next. Where the top traffic is coming in from (what AS) on our paid transit. Dennis Burgess, From: NANOG On Behalf Of Dennis Burgess via NANOG Sent: Friday, May 17, 2019 9:27 AM To: nanog@nanog.org Subject: Free Program to take netflow I am looking for a free program to take netflow and output what the top traffic ASes to and from my AS are. Something that we can look at every once in a while, and/or spin up and get data then shutdown.. Just have two ports need netflow from currently. Thanks in advance. Dennis Burgess
