-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/Jul/15 19:48, Hugo Slabbert wrote:
Jeebuz; you accept /128s? Perhaps le 24 le 48?
Yes, that was a typo - /48 :-).
Mark.
-BEGIN PGP SIGNATURE-
iQIcBAEBCAAGBQJVlixgAAoJEGcZuYTeKm+GLRQP/2HjuqFJW+pzhuH9qSbltl1D
On Wed 2015-Jul-01 17:02:13 +0200, Mark Tinka mark.ti...@seacom.mu wrote:
On 1/Jul/15 16:54, Nick Hilliard wrote:
you probably want to ignore more rpsl constructs and depend solely on
as-sets, aut-nums and route/route6 objects. RPSL is not going to live up
to your expectations.
Honestly,
On 1/Jul/15 17:11, Nick Hilliard wrote:
The source code is available on github.com/inex. Lots of IXPs use it in
production.
Thanks, Nick. I'll have a bit of a sniff...
Mark.
On Wed, Jul 01, 2015 at 08:25:06AM +0200, Mark Tinka wrote:
On 30/Jun/15 17:09, Job Snijders wrote:
If you are a network providing transit to the leak originator mentioned
in the above paragraph, I believe a prefix based filter could have made
a big difference.
And therein lies the
On 01/07/2015 15:57, Mark Tinka wrote:
Remember some high-end Cisco routers only have 2MB of NVRAM. This could
get tested with a large prefix-list configuration. Junos may not have
much of a space issue since the configuration is stored on the compact
flash or HDD.
Not at all. Even C6500
On 1/Jul/15 17:04, Nick Hilliard wrote:
Naah, trie compilation is simple, particularly with a line oriented
configuration like IOS (one of the worse offenders). Once the config is
syntax-checked, a regexp will split it out trivially and the binary form of
the data can be compiled. Even on
Mauch ja...@puck.nether.net
Cc: North American Network Operators' Group nanog@nanog.org
Sent: Wednesday, July 1, 2015 10:11:13 AM
Subject: Re: Route leak in Bangladesh
On 01/07/2015 16:02, Mark Tinka wrote:
Honestly, I'm ambivalent about using the IRR data for prefix-list
generation (even
On 01/07/2015 16:02, Mark Tinka wrote:
Honestly, I'm ambivalent about using the IRR data for prefix-list
generation (even without RPSL), also because of how much junk there is
in there, and also how redundant some of it really is, e.g., someone
creating a /32 (IPv4) route object and yet we
On 01/07/2015 15:12, Jared Mauch wrote:
I would like to see others participate in the dialog with vendors
so we don't seem to be quite an outlier with wow, you have really
large configs. The vendors haven't quite kept pace with the increase
in density proportional to the number of
On 01/07/2015 15:51, Mark Tinka wrote:
I found RPSL complicated a few years ago, and sort of put that on the
back-burner.
you probably want to ignore more rpsl constructs and depend solely on
as-sets, aut-nums and route/route6 objects. RPSL is not going to live up
to your expectations.
Nick
On 01/07/2015 17:03, Joe Abley wrote:
The idea of configuring this stuff from the IRR is great in terms of
distributing the ops cycles in the right places, but it doesn't help with
verifying that the end result isn't insane, as I think you and Mike have
described on this list over the past
On 1/Jul/15 16:54, Nick Hilliard wrote:
you probably want to ignore more rpsl constructs and depend solely on
as-sets, aut-nums and route/route6 objects. RPSL is not going to live up
to your expectations.
Honestly, I'm ambivalent about using the IRR data for prefix-list
generation (even
On Wed, Jul 01, 2015 at 03:54:16PM +0100, Nick Hilliard wrote:
On 01/07/2015 15:51, Mark Tinka wrote:
I found RPSL complicated a few years ago, and sort of put that on the
back-burner.
you probably want to ignore more rpsl constructs and depend solely on
as-sets, aut-nums and route/route6
On 1/Jul/15 16:52, Nick Hilliard wrote:
This is a strange sort of thing really. There's no reason that a compiled
prefix list of 250k entries should take up much RAM in a trie structure;
there's no reason that a competently written parser shouldn't be able to
handle 20 megs of prefix lists
On 1/Jul/15 16:12, Jared Mauch wrote:
I would like to see others participate in the dialog with vendors
so we don't seem to be quite an outlier with wow, you have really
large configs. The vendors haven't quite kept pace with the increase
in density proportional to the number of
On 1 Jul 2015, at 11:03, Jared Mauch wrote:
On Wed, Jul 01, 2015 at 03:54:16PM +0100, Nick Hilliard wrote:
On 01/07/2015 15:51, Mark Tinka wrote:
I found RPSL complicated a few years ago, and sort of put that on
the
back-burner.
you probably want to ignore more rpsl constructs and depend
On 30/Jun/15 17:04, Nick Hilliard wrote:
plus:
- fully automate ingress prefix management
- use maxprefixes with manual reenable on all ebgp sessions
Yes, good point - forgot about that one; default max-prefix for all eBGP
sessions.
Mark.
On 30/Jun/15 17:09, Job Snijders wrote:
If you are a network providing transit to the leak originator mentioned
in the above paragraph, I believe a prefix based filter could have made
a big difference.
And therein lies the secret sauce.
Given that we've had an incident like this twice in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/Jun/15 16:53, Sandra Murphy wrote:
That sort of AS_PATH filtering would not have helped in this case.
The AS originated the routes, it did not propagate an upstream route.
So an AS_PATH filter to just its own AS would have passed
We have just received alert from bgpmon that AS58587 Fiber @ Home
Limited has hijacked most of our (AS43996) prefixes and Hurricane
Electric gladly accepted them.
Anybody see their prefixes hijacked as well?
--
Grzegorz Janoszka
be nice if some technical details were included
At 10:27 30/06/2015 +0200, Grzegorz Janoszka wrote:
We have just received alert from bgpmon that AS58587 Fiber @ Home Limited
has hijacked most of our (AS43996) prefixes and Hurricane Electric gladly
accepted them.
Anybody see their prefixes hijacked as well?
Welcome to the party :-)
Not
A friend in AS58587 confirmed that this was caused by a configuration
error - it seems like related to redistribution, and they already
fixed that.
-
Matsuzaki Yoshinobu m...@iij.ad.jp
- IIJ/AS2497 INOC-DBA: 2497*629
In message 559252e9.6030...@janoszka.pl
Date: Tue, 30 Jun 2015 10:27:21
Randy Bush ra...@psg.com wrote
A friend in AS58587 confirmed that this was caused by a configuration
error - it seems like related to redistribution, and they already
fixed that.
7007 all over again. do not redistribute bgp into igp. do not
redistribute igp into bgp.
I also suggested
On 30/Jun/15 15:22, Matsuzaki Yoshinobu wrote:
I also suggested them to implement BGP community based route filtering
in their outbound policy. Any other suggestions or thoughts to
prevent such incidents in general?
- Get your downstreams to create route objects before you turn them up.
On Tue, Jun 30, 2015 at 10:22:38PM +0900, Matsuzaki Yoshinobu wrote:
Randy Bush ra...@psg.com wrote
A friend in AS58587 confirmed that this was caused by a configuration
error - it seems like related to redistribution, and they already
fixed that.
7007 all over again. do not
At 18:03 30/06/2015 +0900, Randy Bush wrote:
be nice if some technical details were included
Your prefix: xx.104.150.0/24:
Prefix Description:
Update time: 2015-06-30 07:39 (UTC)
Detected by #peers: 8
Detected prefix: xx.104.150.0/24
Announced by: AS58587
On 30 Jun 2015, at 9:41, Job Snijders wrote:
In addition to the BGP community scheme, outbound as-path filters
could
help.
I agree, but possibly not in the case of a redistribution loop.
(We don't know that's what happened, exactly, but I thought it was worth
mentioning.)
Joe
On Tue, 30 Jun 2015, Matsuzaki Yoshinobu wrote:
Randy Bush ra...@psg.com wrote
A friend in AS58587 confirmed that this was caused by a configuration
error - it seems like related to redistribution, and they already
fixed that.
7007 all over again. do not redistribute bgp into igp. do not
On Jun 30, 2015, at 10:39 AM, Justin M. Streiner strei...@cluebyfour.org
wrote:
On Tue, 30 Jun 2015, Matsuzaki Yoshinobu wrote:
Randy Bush ra...@psg.com wrote
A friend in AS58587 confirmed that this was caused by a configuration
error - it seems like related to redistribution, and they
On Tue, Jun 30, 2015 at 09:44:12AM -0400, Joe Abley wrote:
On 30 Jun 2015, at 9:41, Job Snijders wrote:
In addition to the BGP community scheme, outbound as-path filters could
help.
I agree, but possibly not in the case of a redistribution loop.
(We don't know that's what happened,
On 30/06/2015 14:29, Mark Tinka wrote:
- Get your downstreams to create route objects before you turn them up.
- Get your provisioning teams to validate the prefixes being
provided by your downstreams.
- Use both prefix- and AS_PATH-based filters for your downstreams.
- Use
On 30/06/2015 17:09, Job Snijders wrote:
If you were the network causing a leak of this type, prefix filters on
inbound facing your customers might not have prevented this.
If you are a network providing transit to the leak originator mentioned
in the above paragraph, I believe a prefix
On 30/Jun/15 16:24, Job Snijders wrote:
In this specific situation, for a small to medium sized network, it
might be prudent to apply an outbound prefix-filter on all transit
peering sessions and thus only allowing prefixes which actually belong
to downstream customers and the network
Some more data from BGPmon.net:
This affected close to 28,000 prefixes from 4,477 unique Autonomous systems.
The hijacks were originated by AS58587 and propagated via AS45796
(15,002 prefixes) and AS6939 (25,841). The AS45796 paths were only seen
via one of our peers, while the AS6939 path had a
On Tue, Jun 30, 2015 at 04:38:48PM +0200, Mark Tinka wrote:
On 30/Jun/15 16:24, Job Snijders wrote:
In this specific situation, for a small to medium sized network, it
might be prudent to apply an outbound prefix-filter on all transit
peering sessions and thus only allowing prefixes which
On Tue, Jun 30, 2015 at 10:53:45AM -0400, Sandra Murphy wrote:
That sort of AS_PATH filtering would not have helped in this case.
The AS originated the routes, it did not propagate an upstream route.
So an AS_PATH filter to just its own AS would have passed these
routes.
You would need
On Jun 30, 2015, at 9:41 AM, Job Snijders j...@instituut.net wrote:
In addition to the BGP community scheme, outbound as-path filters could
help. Most network's list of transit providers is fairly static, it
would be easiy with as-path filters to prevent announcing upstream
routes to other
On Tue, 30 Jun 2015, Sandra Murphy wrote:
On Jun 30, 2015, at 10:39 AM, Justin M. Streiner strei...@cluebyfour.org
wrote:
At a minimum, AS-PATH filtering of outgoing routes to just your ASN(s)
and your downstream customer ASNs. Whether this is done manually,
built using AS-SETs from your
I have sent this to a contact at another Bangladeshi ISP that should be able to
reach the right person for this ASAP.
On 30-Jun-2015, at 1:57 pm, Grzegorz Janoszka grzeg...@janoszka.pl wrote:
We have just received alert from bgpmon that AS58587 Fiber @ Home Limited has
hijacked most of our
A friend in AS58587 confirmed that this was caused by a configuration
error - it seems like related to redistribution, and they already
fixed that.
7007 all over again. do not redistribute bgp into igp. do not
redistribute igp into bgp.
randy
: nanog@nanog.org
Asunto: Route leak in Bangladesh
We have just received alert from bgpmon that AS58587 Fiber @ Home
Limited has hijacked most of our (AS43996) prefixes and Hurricane
Electric gladly accepted them.
Anybody see their prefixes hijacked as well?
--
Grzegorz Janoszka
42 matches
Mail list logo
