-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
hz//dUVzJnG
On Wed 2015-Jul-01 17:02:13 +0200, Mark Tinka 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, I'm ambivalent about
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 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 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
ch"
Cc: "North American Network Operators' Group"
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 wit
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 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 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 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
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 w
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 lis
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 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 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 o
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 ther
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 i
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.
-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 passe
: 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
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 m
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 Tue, 30 Jun 2015, Sandra Murphy wrote:
On Jun 30, 2015, at 10:39 AM, "Justin M. Streiner"
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 route registry of choice
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 n
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.
> - Us
On Jun 30, 2015, at 10:39 AM, "Justin M. Streiner"
wrote:
> On Tue, 30 Jun 2015, Matsuzaki Yoshinobu wrote:
>
>> Randy Bush 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.
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
On Jun 30, 2015, at 9:41 AM, Job Snijders 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 upstreams or
On Tue, 30 Jun 2015, Matsuzaki Yoshinobu wrote:
Randy Bush 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 ig
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 i
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 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, Jun 30, 2015 at 10:22:38PM +0900, Matsuzaki Yoshinobu wrote:
> Randy Bush 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 redistrib
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 u
Randy Bush 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 them to
> 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
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
- IIJ/AS2497 INOC-DBA: 2497*629
In message <559252e9.6030...@janoszka.pl>
Date: Tue, 30 Jun 2015 10:27:21 +0200
Grzegorz
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 (F
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 wrote:
>
> We have just received alert from bgpmon that AS58587 Fiber @ Home Limited has
> hijacked most of our (AS43996) prefix
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 o
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
