subject:"BGP prefix filter list"

No, that's not the situation being discussed. As I've pointed out, a multi 
homed AS without an IGP connecting all prefixes is non-compliant with the BGP 
definition of an AS. Your Tokyo/DC example is additionally non-compliant 
because it doesn't have a single routing policy. It has two policies. That this 
may work in certain circumstances doesn't make it compliant with the standard.


I can stop a car by throwing out a boat anchor, but that doesn't comply with 
DOT standards for braking :)


From: Valdis Kletnieks  on behalf of Valdis Klētnieks 

Sent: 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 organization with multiple sites having their own Internet
> still uses a single AS. They have IGP paths to route traffic between sites
> (e.g., by using dedicated circuits).

The situation being discussed is an organization with multiple sites that 
*don't*
have a behind-the-scenes dedicated circuit, tunnel, or other interconnect.

For example, XYZ Corp has a POP in Tokyo announcing a /16 to their provider
there, and a POP in DC announcing a different /16 to their North American
provider, using the same ASN for both - but traffic between the two /16s
traverses the commodity Internet.

Or they advertise the same /16 and pray to the anycast gods. :)

(Actually, that's OK too, as long as both Tokyo and DC also announce a second
route (possibly a more-specific, or different address space) for their 
interconnect
needs)

Re: BGP prefix filter list

2019-05-30 Thread Valdis Klētnieks

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
> (e.g., by using dedicated circuits).

The situation being discussed is an organization with multiple sites that 
*don't*
have a behind-the-scenes dedicated circuit, tunnel, or other interconnect.

For example, XYZ Corp has a POP in Tokyo announcing a /16 to their provider
there, and a POP in DC announcing a different /16 to their North American
provider, using the same ASN for both - but traffic between the two /16s
traverses the commodity Internet.

Or they advertise the same /16 and pray to the anycast gods. :)

(Actually, that's OK too, as long as both Tokyo and DC also announce a second
route (possibly a more-specific, or different address space) for their 
interconnect
needs)


pgpK5HN3ErxzH.pgp
Description: PGP signature

Re: BGP prefix filter list

2019-05-30 Thread 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 find problematic, the "single" part, or the
"clearly defined" part? ;)


pgpEDgtmbIinm.pgp
Description: PGP signature

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. The burden of proof is on the person 
making the assertion, and the assertion by Bill was that having disconnected 
prefixes in an AS was common. That’s the assertion that needs a citation. My 
statement is just an opinion that it is clear that  most AS’s are following the 
standard.

And we’re not talking about single-homed AS’s using private ASNs. Those are 
definition excluded, because, being single homed, there is only one path to 
their prefixes.

Any organization that has multiple sites with their own Internet
connections, would then need an AS number for each site.

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 
(e.g., by using dedicated circuits).

 -mel

On May 30, 2019, at 3:55 PM, Thomas Bellman 
mailto:bell...@nsc.liu.se>> wrote:

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 this?

I wouldn't be at all surprised if it *is* literally true; e.g,
quite a lot of BGP users are probably single-homed and thus are
forced to use private ASNs for talking BGP to their ISP; and lots
of BGP users are also single-site, and don't engage in traffic
engineering.

But those cases are also not very interresting for this.  It is
more interresting to look at those that according to RFC 1930
*should* use multiple ASNs; how many of those *do* have separate
ASNs for each group of prefixes with a "single and clearly defined
routing policy", and how many *don't*?

Any organization that has multiple sites with their own Internet
connections, would then need an AS number for each site.  How many
people follow that?  Can I get multiple ASNs from RIPE/ARIN/et.c
for this case?  (That's an honest question; the policies I found
does mention sites or connected groups of networks, but they also
mention organizations in a way that makes me wonder.)

As others have mentioned, if you do traffic engineering by announcing
prefixes with e.g. different BGP communities, or different amounts of
ASN prefixing, you should according to RFC 1930 get a separate ASN
for each unique combination of communities and ASN prefixing.  Will
RIPE/APNIC/et.c grant us multiple ASNs for that?  I kind of suspect
that we would be told to get lost if we requested 256 ASNs from RIPE
for traffic engineering our /16 into 256 /24:s...


   /Bellman

Re: BGP prefix filter list

2019-05-30 Thread Scott Weeks




--- 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 defined routing policy"

>;-)   <=== evil grin
scott

Re: BGP prefix filter list

2019-05-30 Thread Thomas Bellman

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 this?

I wouldn't be at all surprised if it *is* literally true; e.g,
quite a lot of BGP users are probably single-homed and thus are
forced to use private ASNs for talking BGP to their ISP; and lots
of BGP users are also single-site, and don't engage in traffic
engineering.

But those cases are also not very interresting for this.  It is
more interresting to look at those that according to RFC 1930
*should* use multiple ASNs; how many of those *do* have separate
ASNs for each group of prefixes with a "single and clearly defined
routing policy", and how many *don't*?

Any organization that has multiple sites with their own Internet
connections, would then need an AS number for each site.  How many
people follow that?  Can I get multiple ASNs from RIPE/ARIN/et.c
for this case?  (That's an honest question; the policies I found
does mention sites or connected groups of networks, but they also
mention organizations in a way that makes me wonder.)

As others have mentioned, if you do traffic engineering by announcing
prefixes with e.g. different BGP communities, or different amounts of
ASN prefixing, you should according to RFC 1930 get a separate ASN
for each unique combination of communities and ASN prefixing.  Will
RIPE/APNIC/et.c grant us multiple ASNs for that?  I kind of suspect
that we would be told to get lost if we requested 256 ASNs from RIPE
for traffic engineering our /16 into 256 /24:s...

/Bellman

signature.asc
Description: OpenPGP digital signature

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 for filtering at your own
edge, routes which you receive that has an aggregate covering route and
a /24 more specific prefix.

For a single multi-homed network with two transit ISP's it won't make
much of a difference unless you are strapped for outbound bandwidth.
Filter away, because you have a covering aggregate route.

I'm not saying this will work for ALL networks of any size, but for
organizations with just a couple of transit links and not much TE going
on, it would be a perfectly viable option rather than overloading your
TCAM due to budget constraints...

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

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 a single destination address having multiple 
routing paths to two or more endpoints.

 -mel

On May 30, 2019, at 12:48 PM, William Herrin 
mailto:b...@herrin.us>> wrote:

> On Thu, May 30, 2019 at 10:58 AM Mel Beckman 
> mailto:m...@beckman.org>> 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 enough to find 
your actual quote, not the similar one you didn't reference.

> > An AS is a connected group of one or more IP prefixes run by one
> >   or more network operators which has a SINGLE and CLEARLY DEFINED
> >   routing policy.

Interesting but it bears little resemblance to modern practice. Consider an 
anycast announcement, for example, where multiple distributed servers at 
isolated pops terminate the packet. Consider Amazon where both region-local 
unicast announcements and global anycast announcements all originate from AS 
16509. Indeed the whole concept of traffic engineering rests on the premise 
that an AS' routing policy is NOT the same at every border.

Regsards,
Bill Herrin

--
William Herrin
b...@herrin.us
https://bill.herrin.us/

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 enough to
find your actual quote, not the similar one you didn't reference.

> > An AS is a connected group of one or more IP prefixes run by one
> >   or more network operators which has a SINGLE and CLEARLY DEFINED
> >   routing policy.

Interesting but it bears little resemblance to modern practice. Consider an
anycast announcement, for example, where multiple distributed servers at
isolated pops terminate the packet. Consider Amazon where both region-local
unicast announcements and global anycast announcements all originate from
AS 16509. Indeed the whole concept of traffic engineering rests on the
premise that an AS' routing policy is NOT the same at every border.

Regsards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: BGP prefix filter list

2019-05-30 Thread Matt Corallo

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:
> 
> 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 assigned to that organization and provides 
> a single routing policy to systems outside the AS.
> 
> “...a connected group..." implies that all the prefixes in an AS must have 
> direct connectivity to each other (direct meaning within the IGP of the AS). 
> I realize that some AS’s have hot backup facilities that they advertise with 
> heavy prefixing, but in my experience, the backup facility must still be 
> interconnected with the rest of the AS, because prefixing doesn’t guarantee 
> no packets will its that border router. 
> 
>  -mel
> 
> 
>> On May 30, 2019, at 9:54 AM, William Herrin  wrote:
>> 
>> 
>> 
>>> 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 is inoperable. Good job!
>>> 
>>> 
>>> It would be dropped only if the origin-as was the same. Your AS and your
>>> carriers aggregate announcement would be from two different origin AS.
>>> At least that's the gist of it...
>> 
>> Hi Robert,
>> 
>> 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 origin AS when 
>> you see it even though it's actually from a downstream multihomed customer.
>> 
>> Error #2: An AS is an informative handle, not a route. In routing research 
>> parlance, an identifier not a locator. Prefixes from the same AS are not 
>> required to have direct connectivity to each other and many do not. The 
>> origin AS could solve this by disaggregating the announcement and sending no 
>> covering route, but that's exactly what you DON'T want them to do.
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> -- 
>> William Herrin
>> b...@herrin.us
>> https://bill.herrin.us/
>

Re: BGP prefix filter list

2019-05-30 Thread Valdis Klētnieks

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 common usage and documentation, I'd have called you a crazy
person.

I have to wonder how much the IPv6 deployment has been stalled by similar
outdated documentation and coursework (like the "security" recommendation to
"block all ICMP").



pgp9dVSj5nIQS.pgp
Description: PGP signature

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 CLEARLY DEFINED
  routing policy.

This is not an “approximate explanation“. It’s a standard, as strong as any 
standard that exists for the Internet.

How is your statement "Prefixes from the same AS are not required to have 
direct connectivity to each other and many do not” supported by the published 
standard? :-)

 -mel

On May 30, 2019, at 10:42 AM, William Herrin 
mailto:b...@herrin.us>> wrote:

> On Thu, May 30, 2019 at 10:11 AM Mel Beckman 
> mailto:m...@beckman.org>> 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 more blocks of IP addresses, 
> > called IP prefixes, that have been assigned to that organization and 
> > provides a single routing policy to systems outside the AS.

From -what- BGP definitions? This one? 
https://www.scribd.com/document/202454953/Computer-Networking-Definitions

Lots of things get claimed in books and CS courses that are neither reflected 
in the standards nor match universal practice. Heck, most networking courses 
still teach class A, B and C... definitions which were explicitly invalidated a 
quarter of a century ago.

Even where authors are knowledgeable, they're constrained to present 
approximate explanations lest the common use get lost in the minutiae. When you 
want to act on the knowledge in an unusual way, you do not have that luxury. 
The experts in the IRTF Routing Research Group spent something like 6 years 
trying to find a way to filter the BGP RIB in the middle without damaging the 
Internet. They came up with zip. A big zero. They all but proved that it's 
impossible to build a routing protocol that aggregates anything anywhere but at 
the edges while still obeying the most basic policy constraints like not 
stealing transit. Forget getting BGP to do it, they couldn't come up with an 
entirely new protocol that did better.

Regards,
Bill Herrin

--
William Herrin
b...@herrin.us
https://bill.herrin.us/

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 will have that provider's
> > origin AS when you see it even though it's actually from a downstream
> > multihomed customer.
>
> If you were a multi-homed customer the route would still originate from
> two different AS's, both of your upstream ISP's. If it's the same ISP,
> then that would not apply. But then again, if it were the same ISP they
> could filter the more specific and learn downstream customer routes
> either by IGP, filtering or tagging the /24 with no-export

Hi Robert,

Figured someone would stumble in to this one.

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?

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

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 though it's actually from a downstream
> multihomed customer.

If you were a multi-homed customer the route would still originate from
two different AS's, both of your upstream ISP's. If it's the same ISP,
then that would not apply. But then again, if it were the same ISP they
could filter the more specific and learn downstream customer routes
either by IGP, filtering or tagging the /24 with no-export.

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

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 more blocks of IP
addresses, called IP prefixes, that have been assigned to that organization
and provides a single routing policy to systems outside the AS.

>From -what- BGP definitions? This one?
https://www.scribd.com/document/202454953/Computer-Networking-Definitions

Lots of things get claimed in books and CS courses that are neither
reflected in the standards nor match universal practice. Heck, most
networking courses still teach class A, B and C... definitions which were
explicitly invalidated a quarter of a century ago.

Even where authors are knowledgeable, they're constrained to present
approximate explanations lest the common use get lost in the minutiae. When
you want to act on the knowledge in an unusual way, you do not have that
luxury. The experts in the IRTF Routing Research Group spent something like
6 years trying to find a way to filter the BGP RIB in the middle without
damaging the Internet. They came up with zip. A big zero. They all but
proved that it's impossible to build a routing protocol that aggregates
anything anywhere but at the edges while still obeying the most basic
policy constraints like not stealing transit. Forget getting BGP to do it,
they couldn't come up with an entirely new protocol that did better.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: BGP prefix filter list

2019-05-30 Thread Saku Ytti

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 origin AS when 
> you see it even though it's actually from a downstream multihomed customer.

This may not be common interpretation of the section you cite.
Remove-private-asn implementation (CSCO, JNPR) does not remove
privates after head. As your transit provider will receive head having
your public ASN, they cannot remove any subsequent private ASNs. Only
one who can remove private-asn is the originator. Your transit
provider can only drop the route or propagate route with private asn
in it.

It would be inadvisable to send paths with private ASN to your transit
operator, as not all transit operators are comfortable propagating
those.

-- 
  ++ytti

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 assigned to that organization and provides a 
single routing policy to systems outside the AS.

“...a connected group..." implies that all the prefixes in an AS must have 
direct connectivity to each other (direct meaning within the IGP of the AS). I 
realize that some AS’s have hot backup facilities that they advertise with 
heavy prefixing, but in my experience, the backup facility must still be 
interconnected with the rest of the AS, because prefixing doesn’t guarantee no 
packets will its that border router.

 -mel

On May 30, 2019, at 9:54 AM, William Herrin 
mailto:b...@herrin.us>> wrote:

On Thu, May 30, 2019 at 8:30 AM Robert Blayzor 
mailto:rblayzor.b...@inoc.net>> 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 is inoperable. Good job!

It would be dropped only if the origin-as was the same. Your AS and your
carriers aggregate announcement would be from two different origin AS.
At least that's the gist of it...

Hi Robert,

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 origin AS when you 
see it even though it's actually from a downstream multihomed customer.

Error #2: An AS is an informative handle, not a route. In routing research 
parlance, an identifier not a locator. Prefixes from the same AS are not 
required to have direct connectivity to each other and many do not. The origin 
AS could solve this by disaggregating the announcement and sending no covering 
route, but that's exactly what you DON'T want them to do.

Regards,
Bill Herrin

--
William Herrin
b...@herrin.us
https://bill.herrin.us/

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 is inoperable. Good job!
>
>
> It would be dropped only if the origin-as was the same. Your AS and your
> carriers aggregate announcement would be from two different origin AS.
> At least that's the gist of it...
>

Hi Robert,

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 origin AS
when you see it even though it's actually from a downstream multihomed
customer.

Error #2: An AS is an informative handle, not a route. In routing research
parlance, an identifier not a locator. Prefixes from the same AS are not
required to have direct connectivity to each other and many do not. The
origin AS could solve this by disaggregating the announcement and sending
no covering route, but that's exactly what you DON'T want them to do.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

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 origin-as was the same. Your AS and your
carriers aggregate announcement would be from two different origin AS.
At least that's the gist of it...

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

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: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: BGP prefix filter list

2019-05-25 Thread James Jun

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 likely, in the event of your CenturyLink circuit outage, the following
is likely to happen:

1. traffic comes into CenturyLink, dragged in by their /16 aggregate 
announcement
2. CenturyLink hears your more specific /24 from Verizon PX
3. CenturyLink sends traffic received from one peer, and out to another 
(Verizon),
   without touching a revenue side customer interface (temporary free transit
   situation, or temporary onintended hairpinning)

This assumes you're getting /24 allocation from an aggregate CenturyLink finds
acceptable to reassign to BGP multihomed customers, where they won't filter it 
out
right from their peers (for Level3, 8.0.0.0/8 space is used for this typically).

I agree that this is very common.  I also found, not having LSP setup between
peering-only designated routers (who would've thought a peering router needs to
provide transit to another peering router that has no customers on it?!?) breaks
connectivity to customers that find themselves in this very situation, due to 
the
temporary hairpinning of traffic from one (peer|transit) interface out to 
another.

James

Re: BGP prefix filter list

2019-05-24 Thread William Herrin

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 default route. They just just leave the
> decision of the best path to your /24 up to their upstream provider(s)
> rather than having direct knowledge.
>

If you're talking about a leaf node in the BGP system then sure. You can
ditch whatever you want and replace it with default routes. Ditch whole
/8's if it floats your boat. Partial feed has always been acceptable for
leaf nodes.

If you're talking about a transit node then no, you're breaking the
Internet. Even if you have a default route, your downstream customer, to
whom you fail to provide the /24, will suffer malfunction.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: BGP prefix filter list

2019-05-24 Thread Blake Hudson




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 path to your /24 up to their upstream provider(s) 
rather than having direct knowledge.

Re: BGP prefix filter list

2019-05-24 Thread William Herrin

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 announce it via my two carriers: Verizon and CenturyLink.
CenturyLink also announces the aggregate, let's say /16 that the /24 is a
part of because all of the /16 containing my /24 is their allocation.

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!

There is nothing unconventional about this arrangement. It was commonplace
before ARIN dropped the minimum end-user assignment to /24 and many
networks who themselves up that way have found it inconvenient to renumber.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: BGP prefix filter list

2019-05-24 Thread Mike Hammett

If networks are going to make unconventional announcements, I'm not concerned 
if they suffer because of it. 

- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Sabri Berisha"  
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 being 
that it's not always black and white, and sometimes deaggregation is necessary 
for operational purposes. 

That's not to excuse lazy operators of course. 

Thanks, 

Sabri 

- On May 22, 2019, at 11:23 AM, Ross Tajvar  wrote: 

In that case shouldn't each company advertise a /21? 

On Wed, May 22, 2019, 1:11 PM Sabri Berisha < sa...@cluecentral.net > 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 advertise the /20, while the new AB may advertise the top or 
bottom /21. I know of at least one worldwide e-commerce company that is in that 
situation. 

Thanks, 

Sabri 

- On May 22, 2019, at 9:40 AM, Tom Beecher  wrote: 

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 < 
alejandroacostaal...@gmail.com > wrote: 

On 5/20/19 7:26 PM, John Kristoff wrote: 
> On Mon, 20 May 2019 23:09:02 + 
> Seth Mattinen < se...@rollernet.us > 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. 

+1 John 

Seth approach could be an option _only_ if prefix has an aggregate 
exists && as origin are the same 

> John

Re: BGP prefix filter list

2019-05-24 Thread Sabri Berisha

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 lazy operators of course. 

Thanks, 

Sabri 

- On May 22, 2019, at 11:23 AM, Ross Tajvar  wrote: 

> In that case shouldn't each company advertise a /21?

> On Wed, May 22, 2019, 1:11 PM Sabri Berisha < [ mailto:sa...@cluecentral.net |
> sa...@cluecentral.net ] > 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 advertise the /20, while the new AB may advertise the top or
>> bottom /21. I know of at least one worldwide e-commerce company that is in 
>> that
>> situation.

>> Thanks,

>> Sabri

>> - On May 22, 2019, at 9:40 AM, Tom Beecher  wrote:

>>> 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 < [
>>> mailto:alejandroacostaal...@gmail.com | alejandroacostaal...@gmail.com ] >
>>> wrote:

 On 5/20/19 7:26 PM, John Kristoff wrote:
 > On Mon, 20 May 2019 23:09:02 +
 > Seth Mattinen < [ mailto:se...@rollernet.us | se...@rollernet.us ] > 
 > 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.

 +1 John

 Seth approach could be an option _only_ if prefix has an aggregate
 exists && as origin are the same

 > John

Re: BGP prefix filter list

2019-05-22 Thread Ross Tajvar

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 advertise the /20, while the new AB may advertise
> the top or bottom /21. I know of at least one worldwide e-commerce company
> that is in that situation.
>
> Thanks,
>
> Sabri
>
>
> - On May 22, 2019, at 9:40 AM, Tom Beecher  wrote:
>
> 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 <
> alejandroacostaal...@gmail.com> wrote:
>
>>
>> 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) 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.
>>
>>
>> +1 John
>>
>> Seth approach could be an option _only_ if prefix has an aggregate
>> exists && as origin are the same
>>
>>
>> > John
>>
>
>

Re: BGP prefix filter list

2019-05-22 Thread Sabri Berisha

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 e-commerce company that is in that 
situation. 

Thanks, 

Sabri 

- On May 22, 2019, at 9:40 AM, Tom Beecher  wrote: 

> 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 < [
> mailto:alejandroacostaal...@gmail.com | alejandroacostaal...@gmail.com ] >
> wrote:

>> On 5/20/19 7:26 PM, John Kristoff wrote:
>> > On Mon, 20 May 2019 23:09:02 +
>> > Seth Mattinen < [ mailto:se...@rollernet.us | se...@rollernet.us ] > 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.

>> +1 John

>> Seth approach could be an option _only_ if prefix has an aggregate
>> exists && as origin are the same

>> > John

Re: BGP prefix filter list

2019-05-22 Thread Alejandro Acosta

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 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 
> wrote:

On 5/20/19 7:26 PM, John Kristoff wrote:
> On Mon, 20 May 2019 23:09:02 +
> Seth Mattinen mailto:se...@rollernet.us>>
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.

+1 John

Seth approach could be an option _only_ if prefix has an aggregate
exists && as origin are the same

> John

Re: BGP prefix filter list

2019-05-22 Thread Tom Beecher

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 <
alejandroacostaal...@gmail.com> wrote:

>
> 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) 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.
>
>
> +1 John
>
> Seth approach could be an option _only_ if prefix has an aggregate
> exists && as origin are the same
>
>
> > John
>

Re: BGP prefix filter list

2019-05-22 Thread Blake Hudson


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 and did the same for /24 routes.


Yes that was true for the first generation (trident based) line-cards and is no 
longer the case anymore.

adam


Thanks Adam! For the life of me I could not remember where I read that 
information or what platform it applied to. I do recall it being a very 
transparent view into TCAM organization and I appreciated the insight. 
It was also a good reminder that it pays to understand your platform as 
I had previously (naively) thought that a 1M capacity FIB could hold 1M 
entries with any mask size, whether those be 1M /32 entries (a BRAS with 
1M PPP/BNG subscribers) or 1M /24 or bigger entries (a BGP edge router). 
This was obviously not the case on that platform.

RE: BGP prefix filter list

2019-05-22 Thread adamv0025

> 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 true for the first generation (trident based) line-cards and is no 
longer the case anymore. 

adam

Re: BGP prefix filter list

2019-05-21 Thread Alejandro Acosta




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) 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.



+1 John

Seth approach could be an option _only_ if prefix has an aggregate 
exists && as origin are the same




John

Re: BGP prefix filter list

2019-05-20 Thread Ca By

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


>

Re: BGP prefix filter list

2019-05-20 Thread Seth Mattinen


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

2019-05-20 Thread William Herrin

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

2019-05-20 Thread John Kristoff

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

2019-05-20 Thread Seth Mattinen


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

2019-05-20 Thread Martin Hannigan

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

2019-05-20 Thread i3D . net - Martijn Schmidt

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

2019-05-20 Thread William Herrin

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: BGP prefix filter list

2019-05-20 Thread Blake Hudson

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

2019-05-20 Thread Blake Hudson



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: BGP prefix filter list

2019-05-18 Thread Alejandro Acosta

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 at 11:37 AM Alejandro Acosta
> wrote:

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.

I wonder if this really is a consideration to avoid filtering small
prefixes (e.g. /24):

My position is exactly the opposite.

- attackers are quite likely to do sub-prefix hijacks (or say a
specific /24), so I'm not sure this `hits' defenders more than it
`hits' attackers

Yes, you are right, but anyhow -IMHO- this still better than not
learning small prefixes at all.

- I think we're talking only/mostly about small providers here, right?
as larger providers probably will not have such problems of tables
exceeding router resources.I expect such small providers normally
connect thru several tier-2 or so providers... if these upper-tier
providers get hijacked, the fact you've prevented this at the
stub/multihome ISP may not help much - we showed how this happens with
ROV in our NDSS paper on it:
https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/are-we-there-yet-rpkis-deployment-and-security/

You are right here.

Thanks for the link, I will take a look.

Alejandro,

Amir Herzberg
Comcast professor for security innovation
Dept. of Computer Science and Engineering, University of Connecticut

Foundations of Cybersecurity:
https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security

Homepage: https://sites.google.com/site/amirherzberg/home

Re: BGP prefix filter list

2019-05-18 Thread Amir Herzberg

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 /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.
>

I wonder if this really is a consideration to avoid filtering small
prefixes (e.g. /24):

- attackers are quite likely to  do sub-prefix hijacks (or say a specific
/24), so I'm not sure this `hits' defenders more than it `hits' attackers
- I think we're talking only/mostly about small providers here, right? as
larger providers probably will not have such problems of tables exceeding
router resources.I expect such small providers normally connect thru
several tier-2 or so providers... if these upper-tier providers get
hijacked, the fact you've prevented this at the stub/multihome ISP may not
help much - we showed how this happens with ROV in our NDSS paper on it:
https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/are-we-there-yet-rpkis-deployment-and-security/




Amir Herzberg
Comcast professor for security innovation
Dept. of Computer Science and Engineering, University of Connecticut

Foundations of Cybersecurity:
https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security

Homepage: https://sites.google.com/site/amirherzberg/home

Re: BGP prefix filter list

2019-05-18 Thread Alejandro Acosta


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

2019-05-18 Thread Baldur Norddahl

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 down or there is an upstream peering change, both still have a
> complete view. The only time they wouldn't have a complete view is during
> convergence or when there is a simultaneous outage of both transit
> providers at different physical facilities.
>
>
What I mean by not having a complete view, is that your two routers do not
have the same information. One router has all the routes from the transit
directly connected, but only a subset of routes from the other transit
provider. And visa versa for the other router. Therefore the two routers
might not make the same routing decisions.

Let me show you an example from two routers in our network:

albertslund-edge1#show bgp vpnv4 unicast vrf internet detail 8.8.8.0
255.255.255.0
BGP routing table entry for 8.8.8.0/24
20w0d received from 193.239.117.141 (66.249.94.118), path-id 0
   Origin i, nexthop 193.239.117.141, metric 100, localpref 500,weight 0,
rtpref 200, best, block best, selected,
   Community 60876:34307
   As path [15169]
   As4 path
   Received label  notag

Imported from 185.24.168.254 (185.24.168.254); Route Distinguisher:60876:0
(default for vrf internet)
   Origin i, nexthop 185.24.168.254, metric 100, localpref 500,weight 0,
rtpref 200,
   Community 60876:34307
   As path [15169]
   As4 path
   Route target:60876:0
   Received label  164540

---

ballerup-edge1#show bgp vpnv4 unicast vrf internet detail 8.8.8.0
255.255.255.0
BGP routing table entry for 8.8.8.0/24
43w1d received from 193.239.117.141 (66.249.94.118), path-id 0
   Origin i, nexthop 193.239.117.141, metric 100, localpref 500,weight 0,
rtpref 200, best, block best, selected,
   Community 60876:34307
   As path [15169]
   As4 path
   Received label  notag

Imported from 185.24.171.254 (185.24.171.254); Route Distinguisher:60876:0
(default for vrf internet)
   Origin i, nexthop 185.24.171.254, metric 100, localpref 500,weight 0,
rtpref 200,
   Community 60876:34307
   As path [15169]
   As4 path
   Route target:60876:0
   Received label  164140

29w2d received from 216.66.83.101 (216.218.252.202), path-id 0
   Origin i, nexthop 216.66.83.101, metric 100, localpref 450,weight 0,
rtpref 200,
   Community 60876:6939
   As path [6939 15169]
   As4 path
   Received label  notag

43w2d received from 149.6.137.57 (154.26.32.142), path-id 0
   Origin i, nexthop 149.6.137.57, metric 200, localpref 100,weight 0,
rtpref 200,
   Community 174:21100 174:22010 60876:174
   As path [174 6453 15169]
   As4 path
   Received label  notag

---

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 :-).

Regards

Baldur

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 from a router's RIB always comes at some cost (and
some may find this cost perfectly acceptable).


One needs to remember that removing information from RIB is how BGP 
works. If you have the common setup of two BGP edge routers, each with 
a directly connected transit provider link, the routers will only tell 
the other one about the routes it actually uses. Neither router has a 
complete view.



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 down or there is an upstream peering change, both 
still have a complete view. The only time they wouldn't have a complete 
view is during convergence or when there is a simultaneous outage of 
both transit providers at different physical facilities.


I could certainly use a default route (configured statically or received 
via BGP) instead, but that reduces my network's ability to make informed 
decisions. When one of my upstream transit providers is performing 
maintenance and loses a peer, I want that to be reflected in my routing 
so that traffic can be directed via the shortest path. When my transit 
provider's edge router loses upstream connectivity, but maintains 
connectivity to my equipment, I want that reflected in my routing so 
that traffic doesn't go towards the path that leads to the bit bucket. I 
can't detect those conditions and route around them if my router only 
has a default route.

Re: BGP prefix filter list

2019-05-17 Thread Baldur Norddahl

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 happens in your above configuration when your
> "better/default" transit provider is down due to maintenance or outage and
> your equipment continues to use its default route to direct traffic that
> direction?
>

You will of course have two default routes, one to each transit provider.
Using route priorities to program which one is actually used. If that link
goes down, that default becomes invalid and the router will use the other
one. A more advanced setup can use triggers, such as ping, bfd or BGP, to
mark the route as valid or invalid.



> What happens if the transit provider that you normally only retain the
> best paths for becomes the best path for all destinations (for example if
> your connection to the better/default transit provider is down for
> maintenance or there is an upsteam peering change) and your router that
> normally only has a few thousand routes in RIB suddenly gets tasked with a
> 768k-1M route RIB?
>

I am not sure I am following that question. Nothing happens, you will have
a default plus a bunch of redundant routes, but not any more than you had
before the primary transit went down.


>
> 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 from a router's RIB
> always comes at some cost (and some may find this cost perfectly
> acceptable).
>
>
One needs to remember that removing information from RIB is how BGP works.
If you have the common setup of two BGP edge routers, each with a directly
connected transit provider link, the routers will only tell the other one
about the routes it actually uses. Neither router has a complete view.

Regards,

Baldur

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 table)


One point perhaps being missed by some is that routing decisions are 
not always best made in the very last moment when you have a packet 
and need to decide on the destination. The culling of routing table I 
wanted to do is on a full feed from my upstream providers. I am not 
taking a default, but I may add a default manually.


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.


Now doing that in practice is hard because router vendors did 
generally not make route-map or similar constructs flexible enough for 
the needed logic.


But we can do other things, some of which have already been proposed 
in this thread. Like before have a default to the "best" of your 
transit providers and using culling to drop routes. Are we not all 
doing something like that already, with route maps to give some routes 
higher priority instead of always going strict shortest AS-path? Only 
difference is that you can fully drop the routes from FIB if you 
install defaults to handle it instead.


Or what if I know that one of my transit providers are really good 
with Asia? I just want traffic to Asia by default go to them. I can 
install my own covering routes from the APNIC address space and then 
save a ton of FIB space by dropping routes within that space. I can 
have exceptions if needed.


The above does not give you poorer routing decisions and may give you 
better.


Regards,

Baldur



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 happens in your above configuration when your 
"better/default" transit provider is down due to maintenance or outage 
and your equipment continues to use its default route to direct traffic 
that direction? What happens if the transit provider that you normally 
only retain the best paths for becomes the best path for all 
destinations (for example if your connection to the better/default 
transit provider is down for maintenance or there is an upsteam peering 
change) and your router that normally only has a few thousand routes in 
RIB suddenly gets tasked with a 768k-1M route RIB?


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 from a 
router's RIB always comes at some cost (and some may find this cost 
perfectly acceptable).

Re: BGP prefix filter list

2019-05-17 Thread Baldur Norddahl

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
always best made in the very last moment when you have a packet and need to
decide on the destination. The culling of routing table I wanted to do is
on a full feed from my upstream providers. I am not taking a default, but I
may add a default manually.

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.

Now doing that in practice is hard because router vendors did generally not
make route-map or similar constructs flexible enough for the needed logic.

But we can do other things, some of which have already been proposed in
this thread. Like before have a default to the "best" of your transit
providers and using culling to drop routes. Are we not all doing something
like that already, with route maps to give some routes higher priority
instead of always going strict shortest AS-path? Only difference is that
you can fully drop the routes from FIB if you install defaults to handle it
instead.

Or what if I know that one of my transit providers are really good with
Asia? I just want traffic to Asia by default go to them. I can install my
own covering routes from the APNIC address space and then save a ton of FIB
space by dropping routes within that space. I can have exceptions if needed.

The above does not give you poorer routing decisions and may give you
better.

Regards,

Baldur

Re: BGP prefix filter list

2019-05-17 Thread Karsten Elfenbein

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 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 million RIB.
>
> This morning at about 2 AM CET our iBGP session between the two core
> routers started flapping every 5 minutes. This is how long it takes to
> exchange the full table between the routers. The eBGP sessions to our
> transits were stable and never went down.
>
> The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4,
> IPv6 and VRF in a single session.
>
> We are working closely together with another ISP that have the same
> routers. His network went down as well.
>
> Nothing would help until I culled the majority of the IPv6 routes by
> installing a default IPv6 route together with a filter, that drops every
> IPv6 route received on our transits. After that I could not make any more
> experimentation. Need to have a maintenance window during the night.
>
> These routers have shared IPv4 and IPv6 memory space. My theory is that
> the combined prefix numbers is causing the problem. But it could also be
> some IPv6 prefix first seen this night, that triggers a bug. Or something
> else.
>
> Regards,
>
> Baldur
>
>
>

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 routes one can

For me, routing table and available routing protocols are not the only things needed for 
intelligent routing. And the router is not the only component involved in 
"intelligent routing". Not these days/not anymore.

One thing that can help immensely in an internet environment is knowing where the data 
goes and where it comes from. Knowing your "important" traffic 
source/destinations is part of it.

You can say "I can no longer keep all the routes in FIB, so I'll drop the 
/24s", then come to a conclusion that that you have loads of traffic towards an 
anycast node located in a /24 or that you exchange voice with a VoIP provider that 
announces /24. you just lost the ability to do something proper with your important 
destination. On the other hand, you may easily leave via default (in extreme cases even 
drop) traffic to several /16s from Mulgazanzar Telecom which which you barely exchange a 
few packets per day except the quarterly wave of DDoS/spam/scans/[name your favorite 
abuse]. Or you may just drop a few hundred more-specific routes for a destination that 
you do care about, but you cannot do much because network-wise it is too far away.

Of course, such an approach involves human intervention, either for selecting the 
important and non-important destinations or for writing the code that does it 
automagically. Or both. There is no magic potion. (as a friday afternoon remark, there 
used to be such a potion in France, the "green powder", but they permanently 
ran out of stock in 2004 - see http://poudreverte.org/ - site in fr_FR).



Radu, you're absolutely correct that BGP does not include the metrics 
often needed to make the best routing decisions. I mentioned metrics 
like bandwidth, delay, and loss (which some other routing protocols do 
consider); and you mentioned metrics like importance (I assume for 
business continuity or happy eyeballs) or the amount or frequency of 
data exchanged with a given remote AS/IP network. BGP addresses some 
problems (namely routing redundancy), but it has some intentional 
shortcomings when choosing the cheapest path, best performing path, or 
load balancing (not to mention its security shortcomings). Some folks 
choose to improve upon BGP by using BGP "optimizers", manual local pref 
adjustments, or similar configurations. And as this discussion has 
shown, other folks choose to introduce their own additional shortcomings 
by ignoring part of what BGP does have to offer. Perhaps in the future 
we will be able to agree on a replacement to (or improvements upon) BGP 
that addresses some of these shortcomings; we may also find that 
technology solves the limitations that currently force some folks to 
discard potentially valuable routing information.

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

2019-05-17 Thread Christopher Morrow

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 seems like someone from Russia did BGP hijack, BUT,
> exclusively for google services (most likely some kind of peering).
> Quite by chance, I noticed that the traceroute from the google cloud to
> this subnet goes through Russia, although my country has nothing to do
> with Russia at all, not even transit traffic through them.
> Sure i mailed noc@google, but reaching someone in big companies is not
> easiest job, you need to search for some contact that answers. And good
> luck for realtime communications.
> And, all large CDNs have their own "internet", although they have BGP,
> they often interpret it in their own way, which no one but them can
> monitor and keep history. No looking glass for sure, as well.
> If your network is announced by a malicious party from another country,
> you will not even know about it, but your requests(actually answers from
> service) will go through this party.

Re: BGP prefix filter list

2019-05-17 Thread Radu-Adrian Feurdean

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 available routing protocols are not the only things 
needed for intelligent routing. And the router is not the only component 
involved in "intelligent routing". Not these days/not anymore.

One thing that can help immensely in an internet environment is knowing where 
the data goes and where it comes from. Knowing your "important" traffic 
source/destinations is part of it.

You can say "I can no longer keep all the routes in FIB, so I'll drop the 
/24s", then come to a conclusion that that you have loads of traffic towards an 
anycast node located in a /24 or that you exchange voice with a VoIP provider 
that announces /24. you just lost the ability to do something proper with your 
important destination. On the other hand, you may easily leave via default (in 
extreme cases even drop) traffic to several /16s from Mulgazanzar Telecom which 
which you barely exchange a few packets per day except the quarterly wave of 
DDoS/spam/scans/[name your favorite abuse]. Or you may just drop a few hundred 
more-specific routes for a destination that you do care about, but you cannot 
do much because network-wise it is too far away.

Of course, such an approach involves human intervention, either for selecting 
the important and non-important destinations or for writing the code that does 
it automagically. Or both. There is no magic potion. (as a friday afternoon 
remark, there used to be such a potion in France, the "green powder", but they 
permanently ran out of stock in 2004 - see http://poudreverte.org/ - site in 
fr_FR).

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

2019-05-17 Thread Denys Fedoryshchenko

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 by chance, I noticed that the traceroute from the google cloud to 
this subnet goes through Russia, although my country has nothing to do 
with Russia at all, not even transit traffic through them.
Sure i mailed noc@google, but reaching someone in big companies is not 
easiest job, you need to search for some contact that answers. And good 
luck for realtime communications.
And, all large CDNs have their own "internet", although they have BGP, 
they often interpret it in their own way, which no one but them can 
monitor and keep history. No looking glass for sure, as well.
If your network is announced by a malicious party from another country, 
you will not even know about it, but your requests(actually answers from 
service) will go through this party.

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 of a transit
provider outage?

Speaking of "intelligent routing", this is why doing some targeting on what you 
filter by some criteria other than prefix or as-path length is a good idea. Either 
manually every once in a while (just make sure that you at least check the situation 
every few weeks), or in an automated manner (better). You just need more data (usually 
*flow/ipfix based) in order to be able to take the good decisions.

You can use traffic levels (or better - lack of traffic), traffic criticality 
(?!?! cirticity ?!?!) and prefix count saving as criteria.

--
R-A.F.


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 
only make the simplest of routing decisions; with dynamic default routes 
one can make more informed decisions; with a partial view of the 
internet one can make even better decisions; with a full view of the 
internet one can make good decisions; and with a routing protocol that 
takes into account bandwidth, latency, loss, or other metrics one can 
make the very best decisions.


Determining how intelligent one wants his or her decisions to be, and 
how much he or she is willing to spend to get there, is an exercise for 
the reader. Not all routers need a full view of the internet, but some 
do. The cost of routers that hold a full routing table in FIB is 
generally more than those that do not, but overall is not cost 
prohibitive (in my opinion) for the folks that are already paying to be 
multihomed. Single homed networks (or those with a single transit 
provider and additional peers), probably won't benefit from holding more 
than a default route to their transit provider and therefore may be able 
to get by with a less capable router. Each network is different and the 
choices driven by the needs for redundancy, availability, performance, 
and cost will come out differently as well.

Re: BGP prefix filter list

2019-05-17 Thread Radu-Adrian Feurdean

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 "intelligent routing", this is why doing some targeting on what you 
filter by some criteria other than prefix or as-path length is a good idea. 
Either manually every once in a while (just make sure that you at least check 
the situation every few weeks), or in an automated manner (better). You just 
need more data (usually *flow/ipfix based) in order to be able to take the good 
decisions.

You can use traffic levels (or better - lack of traffic), traffic criticality 
(?!?! cirticity ?!?!) and prefix count saving as criteria.

--
R-A.F.

Re: BGP prefix filter list

2019-05-17 Thread Jörg Kost


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 manually by reading and 
comparing CIDR-reports to current Sflow traffic:


E.g.
https://github.com/ipcjk/asnbuilder/blob/master/customASN.txt
will become
https://github.com/ipcjk/asnbuilder/blob/master/saveTheFIB.txt

Jörg


On 17 May 2019, at 10:59, Jared Brown wrote:

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
https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html


2. Filtering based on region

BGP filter for North American routes
http://gregsowell.com/?p=5505

Substitute prefixes for applicable region(s). Each region is about 
200k prefixes. For more granularity use a geolocation service to 
select prefixes and/or ASNs.



3. Using flow information to install only top routes

SDN Internet Router – Part 2
https://labs.spotify.com/2016/01/27/sdn-internet-router-part-2/
https://blog.ipspace.net/2015/01/sdn-router-spotify-on-software-gone-wild.html


4. Aggregate the routing table

According to the weekly routing table report you can aggregate 
announcements to about half the number of prefixes. You need to roll 
your own software to preprocess the BGP feed. There are some tools out 
there, but I couldn't find a blog post about it with a quick search. 
If you have one, please share!




Jared

Re: BGP prefix filter list

2019-05-17 Thread Jared Brown

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
https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html

2. Filtering based on region

BGP filter for North American routes
http://gregsowell.com/?p=5505

Substitute prefixes for applicable region(s). Each region is about 200k 
prefixes. For more granularity use a geolocation service to select prefixes 
and/or ASNs.

3. Using flow information to install only top routes

SDN Internet Router – Part 2
https://labs.spotify.com/2016/01/27/sdn-internet-router-part-2/
https://blog.ipspace.net/2015/01/sdn-router-spotify-on-software-gone-wild.html

4. Aggregate the routing table

According to the weekly routing table report you can aggregate announcements to 
about half the number of prefixes. You need to roll your own software to 
preprocess the BGP feed. There are some tools out there, but I couldn't find a 
blog post about it with a quick search. If you have one, please share!

Jared

On 05/15/19 13:43 +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

2019-05-16 Thread Blake Hudson

Ca, taking a self-originated default route (with or without an 
additional partial view of the global routing table) from your transit 
provider's edge router seems to make the assumption that your transit 
provider's edge router either has a full table or a working default 
route itself. In the case of transit provider outages (planned or 
unplanned), the transit provider's edge router that you peer with may be 
up and reachable (and generating a default route to your routers), but 
may not have connectivity to the greater internet. Put another way, if 
your own routers don't have a full routing table then they don't have 
enough information to make intelligent routing decisions and are 
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?

Mike Hammett wrote on 5/15/2019 2:19 PM:
As an eyeball network myself, you'll probably want to look at those 
things. You don't need to run a CDN to know where your bits are going.

-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
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, May 15, 2019 at 11:52 AM Mike Hammett <mailto:na...@ics-il.net>> wrote:

You can't do uRPF if you're not taking full routes.

I would never do uRPF , i am not a transit shop, so no problem there. 
BCP38 is as sexy as i get.

You also have a more limited set of information for analytics if
you don't have full routes.

Yep, i don’t run a sophisticate internet  CDN either. Just pumping 
packets from eyeballs to clouds and back, mostly.

-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

*From: *"Ca By" mailto:cb.li...@gmail.com>>
*To: *"Dan White" mailto:dwh...@olp.net>>
*Cc: *nanog@nanog.org <mailto: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 mailto:dwh...@olp.net>> 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 know due to
inefficient
>> routing, e.g. customers hitting a public anycast DNS server
in the wrong
>> location resulting in Geolocation issues.
>
>Ah! Understood. The default route(s) was the bit I missed.
Makes a lot of
>sense if you can't justify buying new routers.
>
>Have you seen issues with Anycast routing thus far? One would
assume that
>routing would still be fairly efficient unless you're picking
up transit
>from non-local providers over extended L2 links.

We've had no issues so far but this was a recent change. There
was no
noticeable change to outbound traffic levels.

+1, there is no issue with this approach.

i have been taking “provider routes” + default for a long time,
works great.

This makes sure you use each provider’s “customer cone” and SLA to
the max while reducing your route load / churn.

IMHO, you should only take full routes if your core business is
providing full bgp feeds to downstrean transit customers.

-- 
Dan White

BTC Broadband
Network Admin Lead
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610            email: dwh...@mybtc.com
<mailto:dwh...@mybtc.com>
http://www.btcbroadband.com

Re: BGP prefix filter list

2019-05-16 Thread Ahad Aboss

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
simplify your network operation, you might want to introduce a pair of
route reflectors to handle all your IP and MPLS VPN routes...

Cheers,
Ahad


On Thu, May 16, 2019 at 4:24 AM 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?
>>
>>
>>
> We are a small network with approx 10k customers and two core routers. The
> routers are advertised as 2 million FIB and 10 million RIB.
>
> This morning at about 2 AM CET our iBGP session between the two core
> routers started flapping every 5 minutes. This is how long it takes to
> exchange the full table between the routers. The eBGP sessions to our
> transits were stable and never went down.
>
> The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4,
> IPv6 and VRF in a single session.
>
> We are working closely together with another ISP that have the same
> routers. His network went down as well.
>
> Nothing would help until I culled the majority of the IPv6 routes by
> installing a default IPv6 route together with a filter, that drops every
> IPv6 route received on our transits. After that I could not make any more
> experimentation. Need to have a maintenance window during the night.
>
> These routers have shared IPv4 and IPv6 memory space. My theory is that
> the combined prefix numbers is causing the problem. But it could also be
> some IPv6 prefix first seen this night, that triggers a bug. Or something
> else.
>
> Regards,
>
> Baldur
>
>
>

Re: BGP prefix filter list

2019-05-16 Thread Mark Tinka

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 find this seems to be
> the thing - needing capacity/feature sets/etc just to be able to stand
> still, but not having the revenue stream to actually pay new for what
> these vendors want to charge for their gear/licenses/etc.
>

It is a quagmire, isn't it?

The revenue from capacity (Ethernet, IP, DWDM, SDH) is falling every
year, to a point where it stops becoming a primary revenue source for
any telecoms provider. However, the cost of equipment is not following
suit, be it on the IP, Transport or Mobile side, terrestrial, marine or
wireless.

Work that is going on in the open space around all of this for hardware
and software needs to pick its pace up, otherwise this disconnect
between the loss of revenue and the cost of capex will remain.

Mark.

Re: BGP prefix filter list

2019-05-15 Thread Tom Beecher

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 were
that 'far away' , there wasn't any good reason for us to keep your route.
Following default was going to be good enough.

It's still a reasonable solution I think in a lot of cases to filter out a
lot of the unnecessary prepend messes out there today.

On Wed, May 15, 2019 at 7:45 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

As an eyeball network myself, you'll probably want to look at those things. You 
don't need to run a CDN to know where your bits are going. 

- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

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, May 15, 2019 at 11:52 AM Mike Hammett < na...@ics-il.net > wrote: 

You can't do uRPF if you're not taking full routes. 

I would never do uRPF , i am not a transit shop, so no problem there. BCP38 is 
as sexy as i get. 

You also have a more limited set of information for analytics if you don't have 
full routes. 

Yep, i don’t run a sophisticate internet CDN either. Just pumping packets from 
eyeballs to clouds and back, mostly. 

- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

From: "Ca By" < cb.li...@gmail.com > 
To: "Dan White" < dwh...@olp.net > 
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 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 
>> location resulting in Geolocation issues. 
> 
>Ah! Understood. The default route(s) was the bit I missed. Makes a lot of 
>sense if you can't justify buying new routers. 
> 
>Have you seen issues with Anycast routing thus far? One would assume that 
>routing would still be fairly efficient unless you're picking up transit 
>from non-local providers over extended L2 links. 

We've had no issues so far but this was a recent change. There was no 
noticeable change to outbound traffic levels. 

+1, there is no issue with this approach. 

i have been taking “provider routes” + default for a long time, works great. 

This makes sure you use each provider’s “customer cone” and SLA to the max 
while reducing your route load / churn. 

IMHO, you should only take full routes if your core business is providing full 
bgp feeds to downstrean transit customers. 

-- 
Dan White 
BTC Broadband 
Network Admin Lead 
Ph 918.366.0248 (direct) main: (918)366-8000 
Fax 918.366.6610 email: dwh...@mybtc.com 
http://www.btcbroadband.com

Re: BGP prefix filter list

2019-05-15 Thread Ca By

On Wed, May 15, 2019 at 11:52 AM Mike Hammett  wrote:

> You can't do uRPF if you're not taking full routes.
>

I would never do uRPF , i am not a transit shop, so no problem there. BCP38
is as sexy as i get.


> You also have a more limited set of information for analytics if you don't
> have full routes.
>
>
Yep, i don’t run a sophisticate internet  CDN either. Just pumping packets
from eyeballs to clouds and back, mostly.


>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> 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:
>
>> 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 anycast DNS server in the
>> wrong
>> >> location resulting in Geolocation issues.
>> >
>> >Ah! Understood. The default route(s) was the bit I missed. Makes a lot of
>> >sense if you can't justify buying new routers.
>> >
>> >Have you seen issues with Anycast routing thus far? One would assume that
>> >routing would still be fairly efficient unless you're picking up transit
>> >from non-local providers over extended L2 links.
>>
>> We've had no issues so far but this was a recent change. There was no
>> noticeable change to outbound traffic levels.
>>
>
> +1, there is no issue with this approach.
>
> i have been taking “provider routes” + default for a long time, works
> great.
>
> This makes sure you use each provider’s “customer cone” and SLA to the max
> while reducing your route load / churn.
>
> IMHO, you should only take full routes if your core business is providing
> full bgp feeds to downstrean transit customers.
>
>
>> --
>> Dan White
>> BTC Broadband
>> Network Admin Lead
>> Ph  918.366.0248 (direct)   main: (918)366-8000
>> Fax 918.366.6610email: dwh...@mybtc.com
>> http://www.btcbroadband.com
>>
>
>

Re: BGP prefix filter list

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. 

- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

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 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 
>> location resulting in Geolocation issues. 
> 
>Ah! Understood. The default route(s) was the bit I missed. Makes a lot of 
>sense if you can't justify buying new routers. 
> 
>Have you seen issues with Anycast routing thus far? One would assume that 
>routing would still be fairly efficient unless you're picking up transit 
>from non-local providers over extended L2 links. 

We've had no issues so far but this was a recent change. There was no 
noticeable change to outbound traffic levels. 

+1, there is no issue with this approach. 

i have been taking “provider routes” + default for a long time, works great. 

This makes sure you use each provider’s “customer cone” and SLA to the max 
while reducing your route load / churn. 

IMHO, you should only take full routes if your core business is providing full 
bgp feeds to downstrean transit customers. 

-- 
Dan White 
BTC Broadband 
Network Admin Lead 
Ph 918.366.0248 (direct) main: (918)366-8000 
Fax 918.366.6610 email: dwh...@mybtc.com 
http://www.btcbroadband.com

Re: BGP prefix filter list

I wouldn't call it shaming the vendor. There are a ton of platforms out there 
by nearly every vendor that can't accommodate modern table sizes. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

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 
incident. We just ran out of bandwidth and brand new MX204 are cheaper than 
100G capable shelves for the old platform. 


Regards, 


Baldur 




On Wed, May 15, 2019 at 8:42 PM < mike.l...@gmail.com > wrote: 





Hello Baldur, 


What routers are you running? 


-Mike 

On May 15, 2019, at 11:22, Baldur Norddahl < baldur.nordd...@gmail.com > wrote: 






Hello 


On Wed, May 15, 2019 at 3:56 PM Mike Hammett < na...@ics-il.net > 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 million RIB. 


This morning at about 2 AM CET our iBGP session between the two core routers 
started flapping every 5 minutes. This is how long it takes to exchange the 
full table between the routers. The eBGP sessions to our transits were stable 
and never went down. 


The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4, IPv6 
and VRF in a single session. 


We are working closely together with another ISP that have the same routers. 
His network went down as well. 


Nothing would help until I culled the majority of the IPv6 routes by installing 
a default IPv6 route together with a filter, that drops every IPv6 route 
received on our transits. After that I could not make any more experimentation. 
Need to have a maintenance window during the night. 


These routers have shared IPv4 and IPv6 memory space. My theory is that the 
combined prefix numbers is causing the problem. But it could also be some IPv6 
prefix first seen this night, that triggers a bug. Or something else. 


Regards, 


Baldur

Re: BGP prefix filter list

2019-05-15 Thread Ca By

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 know due to inefficient
> >> routing, e.g. customers hitting a public anycast DNS server in the wrong
> >> location resulting in Geolocation issues.
> >
> >Ah! Understood. The default route(s) was the bit I missed. Makes a lot of
> >sense if you can't justify buying new routers.
> >
> >Have you seen issues with Anycast routing thus far? One would assume that
> >routing would still be fairly efficient unless you're picking up transit
> >from non-local providers over extended L2 links.
>
> We've had no issues so far but this was a recent change. There was no
> noticeable change to outbound traffic levels.
>

+1, there is no issue with this approach.

i have been taking “provider routes” + default for a long time, works
great.

This makes sure you use each provider’s “customer cone” and SLA to the max
while reducing your route load / churn.

IMHO, you should only take full routes if your core business is providing
full bgp feeds to downstrean transit customers.


> --
> Dan White
> BTC Broadband
> Network Admin Lead
> Ph  918.366.0248 (direct)   main: (918)366-8000
> Fax 918.366.6610email: dwh...@mybtc.com
> http://www.btcbroadband.com
>

Re: BGP prefix filter list

2019-05-15 Thread Baldur Norddahl

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 Wed, May 15, 2019 at 8:42 PM  wrote:

> 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?
>>
>>
>>
> We are a small network with approx 10k customers and two core routers. The
> routers are advertised as 2 million FIB and 10 million RIB.
>
> This morning at about 2 AM CET our iBGP session between the two core
> routers started flapping every 5 minutes. This is how long it takes to
> exchange the full table between the routers. The eBGP sessions to our
> transits were stable and never went down.
>
> The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4,
> IPv6 and VRF in a single session.
>
> We are working closely together with another ISP that have the same
> routers. His network went down as well.
>
> Nothing would help until I culled the majority of the IPv6 routes by
> installing a default IPv6 route together with a filter, that drops every
> IPv6 route received on our transits. After that I could not make any more
> experimentation. Need to have a maintenance window during the night.
>
> These routers have shared IPv4 and IPv6 memory space. My theory is that
> the combined prefix numbers is causing the problem. But it could also be
> some IPv6 prefix first seen this night, that triggers a bug. Or something
> else.
>
> Regards,
>
> Baldur
>
>
>

Re: BGP prefix filter list

2019-05-15 Thread mike . lyon

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?
>> 
>> 
> 
> We are a small network with approx 10k customers and two core routers. The 
> routers are advertised as 2 million FIB and 10 million RIB.
> 
> This morning at about 2 AM CET our iBGP session between the two core routers 
> started flapping every 5 minutes. This is how long it takes to exchange the 
> full table between the routers. The eBGP sessions to our transits were stable 
> and never went down.
> 
> The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4, IPv6 
> and VRF in a single session.
> 
> We are working closely together with another ISP that have the same routers. 
> His network went down as well.
> 
> Nothing would help until I culled the majority of the IPv6 routes by 
> installing a default IPv6 route together with a filter, that drops every IPv6 
> route received on our transits. After that I could not make any more 
> experimentation. Need to have a maintenance window during the night. 
> 
> These routers have shared IPv4 and IPv6 memory space. My theory is that the 
> combined prefix numbers is causing the problem. But it could also be some 
> IPv6 prefix first seen this night, that triggers a bug. Or something else.
> 
> Regards,
> 
> Baldur
> 
>

Re: BGP prefix filter list

2019-05-15 Thread Baldur Norddahl

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 million RIB.

This morning at about 2 AM CET our iBGP session between the two core
routers started flapping every 5 minutes. This is how long it takes to
exchange the full table between the routers. The eBGP sessions to our
transits were stable and never went down.

The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4,
IPv6 and VRF in a single session.

We are working closely together with another ISP that have the same
routers. His network went down as well.

Nothing would help until I culled the majority of the IPv6 routes by
installing a default IPv6 route together with a filter, that drops every
IPv6 route received on our transits. After that I could not make any more
experimentation. Need to have a maintenance window during the night.

These routers have shared IPv4 and IPv6 memory space. My theory is that the
combined prefix numbers is causing the problem. But it could also be some
IPv6 prefix first seen this night, that triggers a bug. Or something else.

Regards,

Baldur

Re: BGP prefix filter list

2019-05-15 Thread Ross Tajvar

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 have not tried it myself but I've only heard good things.

On Wed, May 15, 2019 at 12:01 PM Brielle Bruns  wrote:

> 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 yet.
>
> Cheaply, you could get ConnectX-3 40G PCIe cards and throw them in your
> favorite Dell/HP/Supermicro/other rack mount server with your Linux/BSD
> distro of choice, or VyOS for that matter.
>
> There are instructions online on converting the IB versions of the
> Mellanox cards to their Ethernet counterparts, if you want to cut some
> cost even more.
>
> --
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org/ http://www.ahbl.org
>

Re: BGP prefix filter list

2019-05-15 Thread Radu-Adrian Feurdean

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 route to catch all.

Hi,

You can start here : http://www.cidr-report.org/as2.0/#Gains
You will have to do some manual work in order to identify how to optimally 
filter, but you may save some space.

But the more important questions are:
 - how long will it last after one round of clean-up ?
 - can't you afford to use default route ?

You can use tools like AS-Stats (or the more expensive and much more powerful 
alternatives) if your hardware allows it, in order to get the ASes that you 
have close to no traffic towards and leave those via default.

Or, if you can afford a dedicated internet border router, there are models that 
start getting to decent pricing level on refurbished market (a thought to 
ASR9001 that should be pretty cheap these days).

Re: BGP prefix filter list

2019-05-15 Thread Mike

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
> limitations? How long ago was it deprecated?
>
> One network's deprecated router is another network's new [bargain
> priced]
> core router.  :)
>


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 find this seems to be the thing
- needing capacity/feature sets/etc just to be able to stand still, but
not having the revenue stream to actually pay new for what these vendors
want to charge for their gear/licenses/etc.


Mike-

Re: BGP prefix filter list

2019-05-15 Thread Karsten Elfenbein

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 face) there might be the option to switch to a 1m
IPv4 route profile.

Using a default route might influence Reverse Path Forwarding on the
device. But you can apply outbound ACL on upstream ports as well.

The weekly routing table report has lists of worst offenders when it
comes to de aggregation or https://www.cidr-report.org/as2.0/

Karsten

Am Mi., 15. Mai 2019 um 13:45 Uhr schrieb Baldur Norddahl
:
>
> 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

2019-05-15 Thread Brielle Bruns


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 yet.

Cheaply, you could get ConnectX-3 40G PCIe cards and throw them in your 
favorite Dell/HP/Supermicro/other rack mount server with your Linux/BSD 
distro of choice, or VyOS for that matter.


There are instructions online on converting the IB versions of the 
Mellanox cards to their Ethernet counterparts, if you want to cut some 
cost even more.


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: BGP prefix filter list

2019-05-15 Thread Hansen, Christoffer

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
possible with aggregated 10G links?

Re: BGP prefix filter list

2019-05-15 Thread Brielle Bruns


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 feeds for v4 and v6 at home 
- very reasonably priced router with lots of ports and functionality.


Even the old EdgeRouter Lite supported multiple BGP tables - and that 
was 7 years ago at a ~ $100 price point.  But, for sub 200 can get an 
ER4 which will do most of the things the $1000+ routers will do.


'Tik, white box Linux/BSD, etc all offer good options at varying price 
points.



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: BGP prefix filter list

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. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Jon 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 deprecated? 

One network's deprecated router is another network's new [bargain priced] 
core router. :) 

-- 
Jon Lewis, MCP :) | I route 
| therefore you are 
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: BGP prefix filter list

2019-05-15 Thread Dovid Bender

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 network's new [bargain priced]
> core router.  :)
>
> --
>   Jon Lewis, MCP :)   |  I route
>   |  therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>

Re: BGP prefix filter list

2019-05-15 Thread Dan White


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 anycast DNS server in the wrong
location resulting in Geolocation issues.


Ah! Understood. The default route(s) was the bit I missed. Makes a lot of
sense if you can't justify buying new routers.

Have you seen issues with Anycast routing thus far? One would assume that
routing would still be fairly efficient unless you're picking up transit
from non-local providers over extended L2 links.


We've had no issues so far but this was a recent change. There was no
noticeable change to outbound traffic levels. 


--
Dan White
BTC Broadband
Network Admin Lead
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610email: dwh...@mybtc.com
http://www.btcbroadband.com

Re: BGP prefix filter list

2019-05-15 Thread Jon Lewis


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.  :)


--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: BGP prefix filter list

2019-05-15 Thread Jon Lewis


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 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.


This may be too old to be terribly useful other than as a starting point, 
but we went through essentially the same thing a little more than 10 years 
ago:


http://jonsblog.lewis.org/2008/01/19#bgp

--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

RE: BGP prefix filter list

2019-05-15 Thread Phil Lavin

> 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 
> location resulting in Geolocation issues.

Ah! Understood. The default route(s) was the bit I missed. Makes a lot of sense 
if you can't justify buying new routers.

Have you seen issues with Anycast routing thus far? One would assume that 
routing would still be fairly efficient unless you're picking up transit from 
non-local providers over extended L2 links.

Re: BGP prefix filter list